| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- 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]
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 --- 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
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.
-- Note that teleconferences are subject to IEEE policies and procedures, see: –
Ethics
|