Re: AD review of draft-ietf-hubmib-wis-mib-04.txt
"C. M. Heard" <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
On Sun, 17 Nov 2002, Wijnen, Bert (Bert) wrote:
> Sorry that this took so long
My apologies for the delay in this response.
> - SMICng tells me that Gauge32 is being used without being IMPORTED
That's right, and it is already on my private errata list. I noticed it
(by accident) early in September. I had used the book version (2.2.07)
of SMICng and versions 0.3.1 and 0.4.0 of smilint to check the MIB; none
of them flagged this omission. I have informed Frank Strauss of the
smilint problem, and he informs me that the next version of smilint will
have a fix for this. As for SMICng, I probably need to upgrade to the
newest version. However, it's possible that I am using the wrong switches,
so I'd appreciate it if you'd send me (off-list) your SMICng include file.
In any case, this error will be fixed in the next draft.
> - object etherWisDeviceTxTestPatternMode starts ENUM at zero.
> I see the other INTEGER based ENUM does too
> I know it is a CLR, but if it is no problem, then why not start
> at 1 as recommended by RFC2578?
My recollection is that I assigned the enumeration values starting at
zero so that the value assigned to a given mode would correspond to
the 802.3ae subclause number in which that mode is described. This
admittedly is not a particularly compelling reason, and I'm willing
to change the values as requested. The new assignments would be
value | meaning | comments
------------------+-----------------------------------+----------
none(1) | normal operating mode | TX + RX
| | mandatory
| |
squareWave(2) | square wave test pattern mode | TX only
| described subclause 50.3.8.1 | mandatory
| |
prbs31(3) | PRBS31 test pattern mode | TX + RX
| described in subclause 50.3.8.2 | optional
| |
mixedFrequency(4) | mixed frequency test pattern mode | TX + RX
| described in subclause 50.3.8.3 | mandatory
This would affect the SYNTAX and DESCRIPTION clauses of the
OBJECT-TYPE invocation and the OBJECT clauses associated with
etherWisDeviceTxTestPatternMode and etherWisDeviceRxTestPatternMode.
Would anyone object to my making these changes?
Mike Heard comment:
% While going over this stuff I notice that the MIB as presently
% written requires that a conformant implementation allow any
% combination of values for etherWisDeviceTxTestPatternMode and
% etherWisDeviceRxTestPatternMode, but in fact hardware that is
% based on the 802.3ae Clause 45 MDIO registers won't allow all
% combinations to be set.
After thinking about this for a while, I've concluded that the
best fix is probably to modify the OBJECT clauses associated with
etherWisDeviceTxTestPatternMode and etherWisDeviceRxTestPatternMode.
Here is what I propose:
OBJECT etherWisDeviceTxTestPatternMode
SYNTAX INTEGER {
none(1),
squareWave(2),
mixedFrequency(4)
}
DESCRIPTION
"Support for values other than none(1),
squareWave(2), and mixedFrequency(4)
is not required. Furthermore, an
implementation is not required to allow
assignment of a value other than none(1)
if that assignment would result in this
object and etherWisDeviceRxTestPatternMode
having values other than none(1) that are
not the same."
OBJECT etherWisDeviceRxTestPatternMode
SYNTAX INTEGER {
none(1),
mixedFrequency(4)
}
DESCRIPTION
"Support for values other than none(1)
and mixedFrequency(4) is not required.
Furthermore, an implementation is not
required to allow assignment of a value
other than none(1) if that assignment
would result in this object and
etherWisDeviceTxTestPatternMode having
values other than none(1) that are
not the same."
Are the proposed changes sufficiently clear? Does anyone wish to
propose different wording or a different fix?
> - thinking aloud: would it be good to do 2 MODULE COMPLIANCES?
> - one etherWisReadOnlyCompliance which is basically the one you now
> have
> - one etherWisFullCompliance that does not specify the min-access to
> read-only
> But I am not sure, cause we do not allow just read-only to the writable
> objects in this MIB module, while we do allow sonet objects to be
> read-only. Maybe I do not understand exactly why?
The last paragraph of Section 3 gives the reasons why we do not allow
just read-only to the writable objects in this MIB module:
The objects presented here -- along with those incorporated by
reference from the Interfaces Group MIB, the SONET/SDH Interface MIB,
and the 802.3 MAU MIB -- are intended to provide exact
representations of the mandatory attributes in the oWIS managed
object class (i.e., the members of the pWISBasic package) defined in
Clause 30 and Annex 30A of [P802.3ae]. They are also intended to
provide approximate representations of the optional attributes (i.e.,
the members of the pWISOptional package). Some objects with no
analogues in oWIS are defined to support WIS testing features
required by Clause 50 of [P802.3ae].
In other words, the compliance statements are driven by the
requirements of IEEE Std 802.3ae. Here are some specifics.
The reason for not having a MIN-ACCESS of read-only
for the objects etherWisDeviceTxTestPatternMode and
etherWisDeviceRxTestPatternMode is that support for the
square wave and mixed frequency test modes is REQUIRED
by Clause 50 of IEEE Std 802.3ae. Similarly, the reason
for not having a MIN-ACCESS of read-only for the objects
etherWisSectionCurrentJ0Transmitted and
etherWisPathCurrentJ1Transmitted is that support
for writeable section and path trace messages is
REQUIRED by Clause 50 of IEEE Std 802.3ae.
The reason for not requiring write access to certain SONET-MIB
configuration objects is that IEEE Std 802.3ae does not require
configurable values for those objects (e.g., sonetMediumLineCoding
is always sonetMediumNRZ(4) for a 10GBASE-W interface that fully
complies with IEEE Std 802.3ae).
Since the ETHER-WIS MIB module exists specifically to support
10GBASE-w interfaces, I believe that it would be inappropriate
to make another compliance statement requiring write access to
all of the SONET-MIB configuration objects. Whether or not
one should have a relaxed compliance statement that allows
read-only access to certain things that need to be writeable
in order to satisfy IEEE Std 802.3ae is another question.
If the consensus is that it is desirable to have "full"
and "read-only" compliance statements, then my position
is that the existing compliance statement should be
etherWisFullCompliance and that etherWisReadOnlyCompliance
should differ from it by (a) giving the objects
etherWisDeviceTxTestPatternMode and
etherWisDeviceRxTestPatternMode a MIN-ACCESS of read-only
and specifying that only the value 'none' is required,
(b) making etherWisDeviceRxTestPatternErrors completely
optional, and (c) making etherWisSectionCurrentJ0Transmitted
and etherWisPathCurrentJ1Transmitted read-only.
Frankly, I don't see much need for a "read-only" compliance
statement, since (1) any 10GBASE-W PHY that complies with all
requirements of IEEE Std 802.3ae clause 50 will provide the
underlying hardware support needed to support read-write
access to the objects and (2) I don't think anyone is going to
manufacture a 10GBASE-W PHY that does not comply with 802.3ae.
Before taking action on this suggestion I'd like to hear what
the other WG members think about this. If it's not actually
necessary to have a read-only compliance statement then I'd rather
not add one because of the maintenance burden that it would entail.
> - Sections 3.1, 3.2 and 3.3 talk about requirements to implement pieces
> of other MIB modules. I see some of it (from sonet mib) back in the
> MODULE-COMPLIANCE. Should we not just include all of the required
> objects from other MIB modules in the MODULE-COMPLIANCE?
This subject was discussed at some length on the WG mailing list. The
resolution was that we prefer, wherever possible, simply to reference
an existing compliance statement. That was possible for the
EtherLike-MIB (we point to dot3Compliance2) and and the MAU-MIB (we
point to mauModIfCompl3). It was not possible for the SONET-MIB,
however, because we needed to make some objects from its sonetCompliance2
mandatory for WIS applications. This is summarized in the Revision
History section as follows:
The following changes were made to <draft-ietf-hubmib-wis-mib-01.txt>
to produce <draft-ietf-hubmib-wis-mib-02.txt>:
1.) Section 3.1 was updated as agreed in "WIS MIB compliance
statement issue" e-mail thread, specifically to explain that the
ETHER-WIS compliance statement requires all objects that required
by sonetCompliance2 as well as some that it leaves optional.
If we add the stuff related to the EtherLike-MIB and MAU-MIB (and
also the IF-MIB) into the compliance section, we'd end up with verbatim
copies of a lot of stuff from those MIB modules. It is generally
agreed that copying material from one standard into another is a bad
practice; one should, in general, reference such material instead.
Based on this explanation, can you accept a resolution of "no change"?
> - etherWisDeviceRxTestPatternErrors is a read-write Gauge32
> If I understand it correctly, then you can only SET a value of zero
> If this is a correct understanding, then I would expect to see that
> specified in the MODULE-COMPLIANCE with a WRITE-SYNTAX Gauge32(0)
I don't remember whether the 802.3ae Clause 45 MDIO register actually
supports writing arbitrary values, but it's certainly true that there
is no need to write any value other than zero. So adding an OBJECT
clause with a WRITE-SYNTAX Gauge32(0) is eminently reasonable, and I
will do so unless someone provides a good reason not to.
> - In the security section, it would be good to also say someting
> about (non-)vulnerability of read-only objects
OK.
> Editorial/nits
> - RFC-Editor no longer accepts more taht 5 authors on front page
> see http://www.rfc-editor.org/policy.html
I could not find a specific limit in that document. The authors
listed on the front page of the draft are the members of the WIS
MIB design team, and I would prefer to leave the author list as is.
However, it is true that I have done most of the editing, so if
you, the WG chair, and my current co-authors all agree, I will
list myself as editor and list the design team members in the
acknowledgement section. Co-authors: please indicate consent
or objection to the WG mailing list.
> - Not sure RFC-Editor will accept WAN as acronym in title
> see: http://www.rfc-editor.org/policy.html
First, looking at bullet 1 of the section entitled "Abbreviations",
I see that exceptions are made for acronyms that are "so firmly
established in modern computer communication and in IETF usage
that their use is very unlikely to cause uncertainty or ambiguity."
Surely "WAN" qualifies as one of these.
Second, bullet 4 of the section "Abbreviations" says:
The same general principle applies to the title of the RFC,
although some latitude will be given to keep titles from
excessive length or complexity.
My position is that the title should be left as is.
> - pls expand acronyms when they are first used. For example sect
> 3 PCS, PMA, PHY
> see: http://www.rfc-editor.org/policy.html
OK.
> - It would be good to add the wg mailinglist info to the DESCRIPTION
> clause of the MODULE-IDENTITY
I want to push back on this. The link to the WG web page provides
that information (including subscription information and the location
of the mailing list archive) and more. Providing a link, rather than
repeating the information, directs the user to the most current
information (mailing lists do move sometines). [Incidentally, I intend
to propose having a link to the WG web page in the MODULE-IDENTITY
description as an official MIB reviewer's guideline, and I guess this
will be discussed at more length on the MIB reviewer's list.]
> - You talk in various MIB objects about ifAdminState, but I think the
> correct descriptor is ifAdminStatus
Oops, sorry about that. Those errors will be fixed in the next draft.
> - etherWisSectionCurrentJ0Transmitted
> While it is a value "to be transmitted"
> WOuld it be good to reflect that in the descriptor, maybe
> etherWisSectionCurrentJ0ToBeTransmitted
> You have a few more of those
I'd rather change the DESCRIPTION clauses
for etherWisSectionCurrentJ0Transmitted
and etherWisPathCurrentJ1Transmitted.
For the latter how about:
"This is the 16-octet path trace message that is
transmitted in the J1 byte. The value SHOULD
be '89'h followed by fifteen octets of '00'h
(or some cyclic shift thereof) when the path
trace function is not used, and the implementation
SHOULD use that value (or a cyclic shift thereof)
as a default if no other value has been set."
A similar change would apply to etherWisSectionCurrentJ0Transmitted.
These changes will appear in the next draft unless someone objects.
> Questions:
> - Can you explain why in sections 3.8.1, 3.8.2, 3.8.3 and 3.8.4
> you use SHALL and not MUST ??
It sounded better to my ear when I originally wrote it, but that is
a very subjective thing. Changing each SHALL to a MUST would sound
fine too, and I shall do so unless someone objects.
> - Do we know if/when the IEEE normative document will be final
> so that the normative reference can be resolved?
On Sun, 17 Nov 2002, Romascanu, Dan (Dan) wrote:
% The IEEE normative document was approved as a standard in
% June 2002 - thus the normative reference is now resolved.
The document has, in fact, been published; its designation is
IEEE Std 802.3ae-2002. If someone knows the actual publication
date, please tell me what it is; according to the status document
at http://grouper.ieee.org/groups/802/3/status/0702_state_of_std.pdf
publication was "expected in July 2002", and it is possible to
order it in both PDF and hard copy from the IEEE web site, but I'm
not sure what the official publication date was.
A word on the schedule: I am currently away from home, and I will
be gone until approximately 8 Dec 2002. I will start working on
an updated draft at that time (assuming, of course, that we achieve
consensus on the AD review comment resolutions by then).
Regards,
Mike Heard