FW: Comment on Copper and EPON MIBs

Please take into account the following comment from David Law. Regards, Dan


-----Original Message-----
From: David Law [mailto:[email protected]]
Sent: 22 December, 2003 4:20 PM
To: Romascanu, Dan (Dan)
Cc: [email protected]; [email protected]; [email protected]; Howard Frazier; [email protected]
Subject: Comment on Copper and EPON MIBs




Hi Dan,

Can I please submit a comment against both the Copper [
http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu-mib-00.txt ] and
PONs [ http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon-mib-00.txt
] drafts to request that they reference IEEE P802.3 Clause 30 attributes where
possible. This has, as far as I am aware, always been the policy in the past
which I wholeheartedly support - it certainly seems to have been done in the
case of the OAM draft. I believe that in the case of IEEE P802.3ah Ethernet in
the First Mile it is even more important due to the new OAM protocol as is
described below.

There are two reasons I ask for this. The first reason is that in number of
cases the object description text in the IETF draft is a duplication, or a near
duplications, of the equivalent attribute's behaviour text found in IEEE
P802.3ah draft. I personally believe that it is a better idea to cross-reference
rather than duplicate text otherwise we have problems where the two documents
may diverge - I have included an example of this issue related to the
aMPCPDiscoveryWindowsSent object below.

The second, and in my opinion more important reason, relates to the OAM protocol
defined in Clause 57 of IEEE P802.3ah. This protocol provides a mechanism
whereby the value of attributes can be accessed from a far end device through
the OAM protocol. The Variable Request OAMPDU (see IEEE P802.3ah D3.0 subclause
57.4.3.3) is used to request one or more MIB variables from the remote DTE, the
Variable Response OAMPDU (see IEEE P802.3ah D3.0 subclause 57.4.3.4) is used to
return one or more MIB variables. Since this protocol utilizes the MIB defined
in Clause 30, and the related arcs defined in Annex 30A, to ensure maximum
applicability in SNMP systems I believe that these IETF drafts should be aligned
to, and reference, the IEEE P802.3ah draft to the maximum extent possible. In
the cases of IETF objects that do not have a IEEE Clause 30 equivalents, the OAM
protocol Variable Request OAMPDU and Variable Response OAMPDU will be unable to
access that object from the far end device.

Now please don't get me wrong, I am not saying there is anything incorrect in
these IETF drafts, all I want to do is ensure consistency between them and
Clause 30 for the reasons described above. I wholly accept that in a number of
cases where the IETF draft differs from the IEEE P802.3ah draft, it is the IEEE
P802.3ah draft that may need correction.

Best regards,
  David Law


---- Draft MIB text ----

aMPCPDiscoveryWindowsSent OBJECT-TYPE
SYNTAX  Counter32
MAX-ACCESS  read only
STATUS  current
DESCRIPTION
"A count of discovery windows generated. Increment the counter by one for each
discovery windows generated."

---- ============== ----

When the text from IEEE P802.3ah draft D2.0 is examined the text reads:

---- IEEE P802.3ah draft D2.0 text ----

30.3.5.1.11 aMPCPDiscoveryWindowsSent
ATTRIBUTE
APPROPRIATE SYNTAX:
Generalized nonresettable counter. This counter has a maximum increment rate of
10 000 counts per second at 1000 Mb/s
BEHAVIOUR DEFINED AS:
A count of discovery windows generated. Increment the counter by one for each
discovery windows generated.;

---- ============================= ----

As can be seen the Description text provided in the draft MIB exactly matches
the Behavior text provided in IEEE P802.3ah draft D2.0. If however the text from
IEEE P802.3ah draft D3.0 is examined it reads:

---- IEEE P802.3ah draft D3.0 text ----

30.3.5.1.11 aMPCPDiscoveryWindowsSent
ATTRIBUTE
APPROPRIATE SYNTAX:
Generalized nonresettable counter. This counter has a maximum increment rate of
10 000 counts per second at 1000 Mb/s
BEHAVIOUR DEFINED AS:
A count of discovery windows generated. The counter is incremented by one for
each generated discovery window.;

---- ============================= ----

As can be seen the description of the behavior has been refined in D3.0 and the
typo of '... each discovery windows ..' corrected. Since in the draft MIB the
text has been copied from Clause 30, rather than being referenced, the error
still exists in the draft MIB and will need to be correct. A cross reference to
Clause 30 behavior text would have avoided this issue.