Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-ARC] ARC Teleconference reminder and connection info - Oct 7, 11am ET



--- This message came from the IEEE 802.11 ARC Reflector ---

Thanks, Peter, and Brian!

 

A question back (to Brian, I assume):

 

Do we really need to know or say what a read of “Activated” means, in terms of getting a “0” versus an error?  As I see it, if some external entity wants to enable a feature, it can (and would) issue a write to set “Activated” to “1”.  If the device doesn’t support the feature, I believe it should return some sort of error trying to set “Activated” to “1”.  I think this is considerably less risky an assumption, than that a read will return a detectable or “correct” error.

 

Can we live with that view of the convention (and not get into what a read would/could do)?

 

Of course, all this assumes anybody implements this MIB literally, which I doubt.  I think I’m agreeing with Brian’s contemplation about whether we are good enough with a convention that works “in theory.”

 

Mark

 

From: Peter Ecclesine (pecclesi) [mailto:pecclesi@xxxxxxxxx]
Sent: Wednesday, October 08, 2014 6:25 PM
To: Hamilton, Mark; STDS-802-11-ARC@xxxxxxxxxxxxxxxxx
Subject: RE: ARC Teleconference reminder and connection info - Oct 7, 11am ET

 

As discussed on the ARC call, I asked Brian Hart for his opinion on the patterns that involve _both_ a *Implemented and a *Activated attribute for a given feature

 

Brian writes:

 

I’m a strong believer that there are two things going on – what the product implements and what the mgmt. entity chooses to enable. And so conceptually I’m OK with

 

1.       “Activated == 1” => implemented by the product and activated by the mgmt. entity (or activated out of the box)

2.       “Activated == 0” => implemented by the product and deactivated by the mgmt. entity (or deactivated out of the box)

3.       Error on asking for “Activated” => not implemented by the product

 

We definitely would need some language at the start of the MIB annex explaining that this is our convention.

 

I agree ASN.1 talks about errors, but I’d need to do a lot of reading to see if this is the “right” kind of error reporting.

 

Then there are MIB-reader implementations in the wild … how robust is this proposed error reporting mechanism across implementations (in some sense it had better be robust because if you ask an 11a/b/g device if it supports 11n, you’ll need it).

 

Alternatively, do we even need to worry about MIB-reader implementations … is “theoretically good enough” good enough?

 

Basically, I’m willing to be convinced, but I need to see the homework first.

 

B

 

 

From: *** 802.11 Architecture Standing Committee *** [mailto:STDS-802-11-ARC@xxxxxxxx] On Behalf Of Hamilton, Mark
Sent: Monday, October 06, 2014 8:05 AM
To: STDS-802-11-ARC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-ARC] ARC Teleconference reminder and connection info - Oct 7, 11am ET

 

--- This message came from the IEEE 802.11 ARC Reflector ---

Reminder: ARC telecon tomorrow, Tuesday, Oct 7th at 11:00 am Eastern Time, for 1 hour.

 

I have posted an updated 11-14/1281r1 (https://mentor.ieee.org/802.11/dcn/14/11-14-1281-01-0arc-mib-attributes-analysis.docx), and may be able to get a little more done before the call, so look for an e-mail with the latest.

 

Agenda topic, is the MIB attributes Design Patterns, in particular:

- Review proposal for “Pattern A”: Is this the right sort of way to capture the patterns?

- Discuss any patterns that involve _both_ a *Implemented and a *Activated attribute for a given feature

- Any ideas for additional Patterns, or volunteers to take a stab at drafting one/more?

- Discuss what retro-active changes we can make to the MIB, where we think existing usage does not fit a useful pattern

 

Thanks.  Mark

 

From: Hamilton, Mark
Sent: Saturday, September 27, 2014 9:03 PM
To: 'STDS-802-11-ARC@xxxxxxxxxxxxxxxxx'
Subject: ARC Teleconference reminder and connection info - Oct 7, 11am ET

 

All,

 

As agreed in Athens, the ARC SC is holding a teleconference to further work on the MIB Design Pattern effort.

 

The teleconference will be held on Tuesday, Oct 7th at 11:00 am Eastern Time, for 1 hour. Connection information is below.

 

If you have a submission you would like to present, please contact me. Likely we will look at the latest version of 11-14/1281.


See (hear) you there!  Mark

 

--

Note that teleconferences are subject to IEEE policies and procedures, see:

        IEEE Patent Policy

        Patent FAQ

        Letter of Assurance Form

        Affiliation FAQ

        Anti-Trust FAQ

        Ethics

        802 LMSC P&P

        802 LMSC OM

        802 WG P&P

        IEEE802.11 WG OM



Connection information:


Join the meeting: https://join.me/IEEE802.11

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app and enter meeting code: IEEE802.11


Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT   +1.860.970.0010
United States - Los Angeles, CA   +1.213.226.1066
United States - Thousand Oaks, CA   +1.805.309.5900
Australia - Sydney   +61.2.9191.6319
Canada - Toronto   +1.647.977.2648
Finland - Helsinki   +358.9.4259.9698
Germany - Frankfurt   +49.69.3329.6380
Hong Kong - national   +852.5808.1760
Japan - Tokyo   +81.3.4579.5983
Korea, Republic of - South Korea   +82.26.022.2310
Netherlands - Amsterdam   +31.20.808.3218
United Kingdom - London   +44.33.0088.2634
Access Code   808-571-868#

Other international numbers available

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A small download might be required.