| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Thanks, Edward.
The cite you mention (Annex C.2 and hence to IETF RFC 4181, then to http://www.ops.ietf.org/mib-boilerplate.html, and then to RFCs 3410, 2578, 2579, 2580):
- Is talking about references in the references section of an RFC. We can generalize that to one of the references sections of our Standard, including the references in the “overview section” of C.3. I’ll claim that is the front matter, up to the first object definition (the first OBJECT-TYPE macro, i.e., dot11StationConfigTable). After that, you’re into the body of the MIB, and not the “overview section” anymore.
- Even if RFC 4181 does apply, it only says that all normative references should point to the most recent version of a specification. It doesn’t say that such normative references are needed in object definitions, or anything about when they are needed/desired.
- The only hint about the usage of REFERENCE, is this (clause 7.6 of RFC2578 for the OBJECT-TYPE macro, repeated verbatim for other macros as well, and in RFCs 2579 and 2580):
7.6. Mapping of the REFERENCE clause
The REFERENCE clause, which need not be present, contains a textual cross-reference to some other document, either another information module which defines a related assignment, or some other document which provides additional information relevant to this definition.
- I note that this pretty clearly says the purpose of the REFFENCE clause is to provide a reference into _some other document_.
And, separately, I’ll claim that the vast majority of our MIB attributes don’t have one, and nobody has ever complained (or even noticed) about the missing ones. I think this is evidence that they are not really needed, and this is not how people really understand/locate how the attribute is used in the body text.
Given all that, I see no compelling reason to have these REFERENCE clauses within our MIB object definitions. In fact, I see a pretty compelling argument that they should be removed.
Mark
From: Edward Au <edward.ks.au@xxxxxxxxx>
Sent: Thursday, April 16, 2020 5:30 PM
To: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Cc: IEEE802.11 TGmc <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGM] Resolution for CIDs 4005 through 4012
Hi Mark,
For MIB, we follow the recommendation in Annex C.2 to draft it based on IETF RFC 4181 (http://www.rfc-editor.org/rfc/rfc4181.txt). In Section 3, there is a requirement that "In general, each normative reference SHOULD point to the most recent version of the specification in question".
In Annex C.3,
[1] We have approximately 50 MIB variables that cite a particular subclause (or subclauses) of the latest version of the IEEE 802.11 standards as a normative reference, whereas the remaining MIB variables do not.
[2] There are also a few MIB modules that talks about an object (or objects) of an OBJECT-GROUP is deprecated in the latest version of the IEEE 802.11 standards, and therefore the OBJECT-GROUP is superseded by a new group.
It would be a good discussion during the CRC call on April 22.
Regards,
Edward
On Thu, Apr 16, 2020 at 7:04 PM <mark.hamilton2152@xxxxxxxxx> wrote:
All,
I’ll repeat a comment I made previously (maybe on the same call where we did 4184, 4185, and 4186?): Why are we fixing these REFERENCEs instead of just removing them? Is there a rule/suggestion that they are helpful (in some Editor’s Guide, etc.)? Given that the vast majority of our MIB attributes don’t have one, and nobody has ever complained (or even noticed) about the missing ones, I would just remove them all.
Mark
From: ***** 802.11 REVm - Revision Maintainance List ***** <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx> On Behalf Of Edward Au
Sent: Thursday, April 16, 2020 4:32 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Resolution for CIDs 4005 through 4012
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Acknowledged, Dorothy, and Jon.
DCN is 20/0629r0, Proposed resolutions for CIDs related to the date of publication of the references in MIB.
Regards,
Edward
On Thu, Apr 16, 2020 at 6:32 PM Dorothy Stanley <dstanley1389@xxxxxxxxx> wrote:
Thank you very much Edward.
Will add you to the April 22nd agenda.
Dorothy
----------------------
Dorothy Stanley
IEEE 802.11 WG Chair, dstanley@xxxxxxxx
Hewlett Packard Enterprise
dorothy.stanley@xxxxxxx
dstanley1389@xxxxxxxxx
+1 630-363-1389
On Thu, Apr 16, 2020 at 3:25 PM Edward Au <edward.ks.au@xxxxxxxxx> wrote:
Hi Dorothy,
Please assign these CIDs to me. Because of the proposed change suggested, especially in CID 4012, I believe I need to update the approved resolution of CIDs 4184, 4185, and 4186 (which was assigned to EDITOR2 ad-hoc) to make sure that the resolution of these comments are consistent.
Would you also allocate about 30 minutes to me to present the proposed resolutions of these CIDs on April 22?
Regards,
Edward
On Thu, Apr 16, 2020 at 6:05 PM Dorothy Stanley <dstanley1389@xxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Jon, Emily, Edward,
While these CIDs are appropriately assigned to GEN, they are largely editorial in nature as we discussed on a prior teleconference.
Emily and Edward, would either or both of you be able to prepare a comment resolution document for CIDs 4005 through 4012?
Thank you,
Dorothy
===================
REVmd WG CC Comments
4005
4175.00
C.3
dot11EDCATable refers to IEEE Std 802.11-2012
Replace "IEEE Std 802.11-2012, 10.2.3.2 (HCF contention based channel access
(EDCA))" with "IEEE Std 802.11-2020, 10.2.3.2 (HCF contention based channel access
(EDCA))"4006
4178.00
C.3
dot11QAPEDCATable refers to IEEE Std 802.11-2012
Replace "IEEE Std 802.11-2012, 10.2.3.2 (HCF contention based channel access
(EDCA))" with "IEEE Std 802.11-2020, 10.2.3.2 (HCF contention based channel access
(EDCA))"4007
4179.00
C.3
dot11QAPEDCATableTXOPLimit refers to 802.11-2016
Replace "REFERENCE IEEE Std 802.11-2016, 9.4.2.28 (EDCA Parameter Set element)" with "REFERENCE IEEE Std 802.11-2020, 9.4.2.28 (EDCA Parameter Set element)"
4008
4192.00
C.3
dot11BSSLoadAvailableAdmissionCapacity refers to 802.11-2016
Replace " REFERENCE "IEEE Std 802.11-2016, 9.4.2.27 (BSS Load element) "" with " REFERENCE "IEEE Std 802.11-2020, 9.4.2.27 (BSS Load element) ""
4009
4195.00
C.3
dot11TempType refers to 802.11-2016
Replace "The use of dot11TempType is deprecated because no associated behavior is described in IEEE Std 802.11-2016" with "The use of dot11TempType is deprecated because no associated behavior is described in IEEE Std 802.11-2020"
4010
4212.00
C.3
dot11HoppingPatternTable refers to 802.11-2016
Replace 802.11-2016 with 802.11-2020
4011
4212.00
C.3
dot11HoppingPatternEntry refers to 802.11-2016
Replace 802.11-2016 with 802.11-2020
4012
3811.00
C.3
Within C.3 there are several occurrences of references to 802.11-2012 or 802.11-2016. These references need to be updated
In clause C.3, replace 802.11-2012 or 802.11-2016 with 802.11-2020 resp. 802.11-2021 when this draft standard will be published.
----------------------
Dorothy Stanley
IEEE 802.11 WG Chair, dstanley@xxxxxxxx
Hewlett Packard Enterprise
dorothy.stanley@xxxxxxx
dstanley1389@xxxxxxxxx
+1 630-363-1389To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
--
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1