Desultory comments on draft-ietf-hubmib-efm-cu-01

"C. M. Heard" <[email protected]>
Newsgroups gmane.ietf.hubmib
Message-ID <[email protected]>
On Wed, 4 Aug 2004, Romascanu, Dan (Dan) wrote:
> (of course Mike, it would be great if you can have a look at the
> current set of Internet-Drafts now in WG Last Call and submit a
> full set comments).

Some comments on the ifSpeed, ifStackTable diagram, and MAU-MIB
usage issues that have already been discussed on this list to some
extent will appear in a forthcoming message.  In the meantime here
are some things that caught my eye when when looking at the docment
this weekend.

- On page 6 there is a typo:

   The SNMP Agent builds efmCuStackTable according to the information
   contained in the Clause 45 PME_Available_register (see [802.3ah]
   61.1.5.3 and 45.2.3.20).

The text should read:

   The SNMP Agent builds efmCuAvailableStackTable according to the
   information contained in the Clause 45 PME_Available_register
   (see [802.3ah] 61.1.5.3 and 45.2.3.20).

- On page 16, the DESCRIPTION clause of efmCuPAFAdminState says:

   PCS ports incapable of supporting PAF SHALL return a value of
   'disabled'. Attempts to 'enable' such ports SHALL be ignored.
________________________________________________________^^^^^^^

This will almost certainly raise a red flag during MIB Doctor review,
since the usual behaviour is to reject unacceptable values with an
SNMP error, not to ignore them.  I would recommend changing "ignored"
to "rejected".  There are other places where this is done, and they
should be changed, too.  I would also recommend that the compliance
statement include an OBJECT clause for this object with a WRITE-SYNTAX
clause specifying that values other than disabled need not be accepted.

- I see several places with Editor's Notes indicating that there are
open issues (e.g., text to be added, technical decisions to be made,
etc.)  These need to be closed off before we make a publication request.

Mike
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.