Detailed comments on IPOIB TC I-D

Hi -

Here are more comments on
draft-ietf-ipoib-ibmib-tc-mib-03.txt


1) Does the WG *really* want this to hang off
the "experimental" OID ARC?  Section 4.3 of
draft-ietf-ops-mib-review-guidelines-02.txt
REQUIRES that standards track stuff be moved
out of the "experimental" subtree.  If an
appropriate node has not already bee allocated,
you'll need to add a comment to IANA regarding
where you'd like the arc to be allocated, and
to update the IMPORTS statement appropriately.

2) the document lacks the "narrative sections"
required by section 3.2 of
draft-ietf-ops-mib-review-guidelines-02.txt.
I don't think too much is needed here; my main
concern would describing (or providing pointers to)
how this stuff relates to "interfaces" in the usual sense.

3) IbIpoibClientIdentifier has a field reserved
for future use.  Who owns this field?  Will an
IANA considerations section be needed?  The
current text says these bits "MUST" be zero.
This would prevent interoperation with any future
use of those bits.  I think a "SHOULD" would
be more appropriate here.

4) When this document says "interface", does
that have any relationship to "interface" as in
the IF-MIB?  Either way it would probably be
good to be explicit.  For example, how is a
value of IbDataPort associated with an ifIndex?

5)  Should have add a note in the MIB module
copyright like
-- RFC ed.: replace XXXX with actual RFC number & remove this note

6) working group email address MUST go in the
CONTACT-INFO clause.  Page 11 of
draft-ietf-ops-mib-review-guidelines-02.txt

7) REVISION clauses need to be cleaned up so that:
   a) the date is correct
   b) there is just one
   (See page 12 of draft-ietf-ops-mib-review-guidelines-02.txt)
   c) DESCRIPTION should be like the one on page 12 of
   the guidelines

8) telephone number in contact-info lacks country code (+1)

9) typo: "include logical Port 0 that is reserved" ->
   "include logical Port 0, which is reserved"

10) IbDataPortAndInvalid should identify which value is
   used to signal "invalid"

11) What is the rationale for making IbVirtualLane
and ibDataVirtualLane 1-based?  This seems an
unnecessary complication.

12) In the DESCRIPTION of IbDlid, IbUnicastLid, and
IbMulticastLid, it talks about the high-order bit of the first
byte of the integer representation.  Big-endian or little?

13) What is the value of making IbDlid, IbUnicastLid, and
IbMulticastLid one-based?  It seems simpler to keep them
zero-based.

14) the acronym EUI-64 should be expanded.

15) IbSmPortList: when it says "Bit 255 is invalid", what
does this mean?  Proposed: "This bit MUST always be zero."

16) For IbDataPort, IbDataPortAndInvalid, IbVirtualLane,
IbDataVirtualLane, IbDlid, IbUnicastLid, and IbMulticastLid
I would RECOMMEND that they should all be Unsigned32,
per the guidelines in page 14 of
draft-ietf-ops-mib-review-guidelines-02.txt section 4.6.1.1

Randy