| 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 ---
Apparently Brian Hart’s reply bounced from the ARC list From: Brian Hart (brianh)
Hi Mark –inline -B From: Hamilton, Mark [mailto:Mark.Hamilton@xxxxxxxxxxxxxxx]
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. [At first glance this looks like another viable way to skin the cat. But I propose it may introduce unwanted side effects. In one major use case, the first
thing that an external entity wants is to learn the capabilities and state of the device to be managed, and present that to the sysadmin … i.e. a whole bunch of reads. If the only way to learn whether the mged device supports a feature is to attempt to write
to it, then the mgmt entity learns the capability only – but has just lost the state. And if your mgmt. system takes an unmanaged device from a working-but-not-centrally-known state to a centrally-known-but-unworking state, it’s not a very good mgmt. system.
So I definitely think we need a reliable, non-destructive read mechanism that reports enabled/disabled/not implemented.]
Ø
Can we live with that view of the convention (and not get into what a read would/could do)? [As above, far from my preference …] 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.” [If I heard that at least a few MIB-reader implementations work in my preferred way, that’s probably good enough for “works in theory and is not completely
academic” … I can follow up internally] 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
|