Re: AD review of draft-ietf-hubmib-wis-mib-04.txt

On Tue, 10 Dec 2002, C. M. Heard wrote:
> To date, there has been no feedback on my responses to Bert's AD
> review comments.  Before I post an updated WIS MIB draft, it would be
> helpful to hear from the WG, the AD, and (for the proposal to revise
> the author list) from the WG chair and the co-authors of the draft.

Since there has been no feedback, <draft-ietf-hubmib-wis-mib-05.txt>
has been submitted to the I-D repository with comment resolutions
as proposed in my message of Tue, 19 Nov 2002.  Specifically:

On Tue, 19 Nov 2002, C. M. Heard wrote:
> On Sun, 17 Nov 2002, Wijnen, Bert (Bert) wrote:
[ ... ]
> > - SMICng tells me that Gauge32 is being used without being IMPORTED

Fixed:  Gauge32 is now imported from SNMPv2-SMI.

> > - 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?

Fixed:  enum assignments for etherWisDeviceTxTestPatternMode and
etherWisDeviceRxTestPatternMode are now as follows:

   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

> 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.

Fixed:  OBJECT clauses for etherWisDeviceTxTestPatternMode and
etherWisDeviceRxTestPatternMode now state that an implementation
does not have to allow value assignments that the Clause 45 MDIO
registers can't support.  The WG is urged to verify that the
wording is sufficiently clear!

> > - 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 [namely,
> that] the compliance statements are driven by the requirements of
> IEEE Std 802.3ae.

No change:  since there was no feedback, I have assumed that the
rationale provided for keeping the existing compliance scheme was OK.

> > - 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.

No change:  since there was no feedback, I have assumed that the
rationale provided for keeping the existing compliance scheme was OK.

> > -  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)

Fixed:  there is now an OBJECT clause for etherWisDeviceRxTestPatternErrors
which specifies WRITE-SYNTAX Gauge32(0).

> > - In the security section, it would be good to also say someting
> >   about (non-)vulnerability of read-only objects

I'm not aware of any objects that are especially sensitive, but in some
cases it's possible that operators won't want any of the readable
information exposed.  So I added the following paragraph:

   All other managed objects in this MIB module have a MAX-ACCESS clause
   of read-only.  The information contained in those objects may be
   considered sensitive in some network environments.  In such
   environments it is important to control even GET access to those
   objects and possibly to even encrypt the values of these objects when
   sending them over the network via SNMP.

Note that I have also updated the section in accordance with the
latest template posted to the [email protected] mailing list.

> > Editorial/nits
> > - RFC-Editor no longer accepts more [than] 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.

I have NOT (yet) taken any action on this, because I've neither
received concurrence of the co-authors nor guidance from the WG
chair on what is appropriate.  Pending such guidance I've added
this as an action item in the TO-DO list.

Let me briefly state the considerations here.  First, let me
not that http://www.rfc-editor.org/policy.html refers to
<draft-rfc-editor-rfc2223bis-03.txt> for details, and what that
draft actually says is this:

   There is no rigid limit on the size of this set, but there is
   likely to be a discussion if the set exceeds five authors, in
   which case the right answer is probably to list one editor.

   The RFC Editor will hold all the people listed on the front
   page equally responsible for the final form and content of
   the published RFC.  In particular, the "Author's 48 Hours"
   final approval period will require signoff from all listed
   authors.

The alternatives to listing the members of the WIS design team
on the front page would be to include them in a Contributors
section or in the Acknowledgments section:

   An RFC may include a Contributors section, listing those
   contributors who deserve significant credit for the document
   contents.  The Contributors section is intended to provide a
   level of recognition greater than an acknowledgment and
   nearly equal to listing on the front page.  The choice of
   either, both, or none of Contributor and Acknowledgment
   sections in a particular RFC depends upon the circumstance.

   At the discretion of the author(s), contact addresses may
   also be included in the Contributors section for those
   contributors whose knowledge makes them useful future
   contacts for information about the RFC.

I would very much like to have some guidance on how to proceed
here:  (i) leave the WIS MIB design team members in author list;
(ii) list design team members in Contributors section, with
contact information;  (iii)  list design team members in
Contributors section, without contact information;  (iv) mention
design team members in the Acknowledgements section.

I'm happy with any of these alternatives, subject to one caveat:
alternative (i) is acceptable only if all design team members
provide assurance that they will be able to provide a prompt
response to the RFC Editor's request for "Author's 48 Hours"
final approval signoff.

> > - Not sure RFC-Editor will accept WAN as acronym in title
> >   see: http://www.rfc-editor.org/policy.html

No change:  the RFC Editor has responded to off-line e-mail
indicating that the existing title is OK.

> > - pls expand acronyms when they are first used. For example sect
> >   3 PCS, PMA, PHY
> >   see: http://www.rfc-editor.org/policy.html

Done.

> > - 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.]

No change:  since there was no feedback on my rationale for just
providing the link, I have assumed that what's there is OK.

> > - You talk in various MIB objects about ifAdminState, but I think the
> >   correct descriptor is ifAdminStatus

Fixed.

> > - 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.

Fixed:  the DESCRIPTION clauses now have "transmitted" in place
of "to be transmitted".

> > 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 ??

Fixed:  SHALLs changed to MUSTs.

> > - Do we know if/when the IEEE normative document will be final
> >   so that the normative reference can be resolved?

Reference [P802.3ae] pointing to the IEEE draft has been
changed to [802.3ae] pointing to IEEE Std 802.3ae-2002,
which was published on August 30, 2002.

Some other (hopefully uncontroversial) changes have also been made:

- RFC 2119 was moved from the informative reference list to the
normative reference list, in accordance with current IESG and RFC
Editor policy.

- The MIB boilerplate in Section 2 and the SMI/SNMP-related
references were updated to conform to the latest template posted
to the [email protected] mailing list.

- The document pagination was changed to match that expected
upon publication as an RFC.

If anyone requires a copy of the document before it appears in
the I-D repository, let me know (off-list, please) and I will
e-mail you a copy.

NOTE:  I expect that resolution of the author list issue will require
another update to the draft.  If there are any other issues, please
bring them up ASAP on the WG mailing list.

Regards,

Mike Heard