Subject: [Ipoverib] IPoIB MIBs ready for WG Last Call

From: "bill" <[email-masked]>
Date: Fri, 3 Oct 2003 12:01:57 -0700

Jerry and I would like to issue a WG last call on the following MIB
drafts

http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-03.txt
Textual Conventions MIB

http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibif-mib-05.txt
IPoIB Interfaces MIB

http://www.ietf.org/internet-drafts/draft-ietf-ipoib-subnet-mgmt-agent-m
ib-05.txt Subnet Management Agent MIB

These MIBs must meet the MIB guidelines specified in:

http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines
-02.txt MIB Guidelines

There is also various boilerplate code located at

http://www.ops.ietf.org/

The Last Call will start today 10/3/2003 and end 10/17/2003 - or when
our MIB Doctor finishes his review, which ever is later.  We am hoping
to get these documents in front of the IESG after the Internet Drafts
opens up after the Mn IETF (unless either there are no/few issues - or
Sean does an amazingly FAST job of updating the MIB documents after Last
Call and gets them in under the meeting cutoff times)

I am including our MIB doctor Randy Presuhn, and the Ops area AD Bert
Wijnen.  If there are comments for Bert - he is not subscribed to the
list, so please include him in your TO:/CC: .

We would like to thank Randy for taking the time to review our documents
and giving us his experience in MIB design. 

Thank you
Bill Strahm / Jerry Chu IPoIB WG co-chairs

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 3 Oct 2003 19:57:45 -0700

Hi -

> From: "bill" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Friday, October 03, 2003 12:01 PM
> Subject: IPoIB MIBs ready for WG Last Call
...
> list, so please include him in your TO:/CC: .
...

To reduce the number of CCs, I've subscribed to the [email-masked]
list and will stay on the list until we've completed this review cycle.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 6 Oct 2003 11:50:37 -0700

Hi -

First thing I checked in
http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibif-mib-05.txt
was to see whether it would compile using the handy
[email-masked] tool.  It didn't like this definition:

ibIpoibLinkLayerIndex  OBJECT-TYPE
    SYNTAX       INTEGER(1..65535)
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
       "Index of the IPOIB Link Layer address in the table."
    ::= { ibIpoibLinkLayerAddrEntry 2 }

Fix: replace "INTEGER" here with "Integer32" (or Unsigned32)
Update the SEQUENCE accordingly, and include it in the IMPORTS.
(I'm assuming the 65535 is a architectural limit of the ipoib protocol.
If it isn't, then more work is needed here.)

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 6 Oct 2003 12:12:40 -0700

Hi -

First compilation check using [email-masked] on
 http://www.ietf.org/internet-drafts/draft-ietf-ipoib-subnet-mgmt-agent-mib-05.txt
found several problems.

1) the Gauge32 type is used, but is missing from the IMPORTS.

2) in the SEQUENCE IbSmaSmInfoEntry, it claims the type of ibSmaSmGuid doesn't
match what appears in the OBJECT-TYPE.  The underlying type of the TC is indeed
OCTET STRING, so one might wonder why the tool complains.  I think it may be
unhappy because fixed-length octet strings (like this one) get special treatment
when used as indexes.  Anyway, the complaint can be eliminated by simply using
the TC's name in the SEQUENCE.

3) The tool doesn't like the name chosen for ibGuidInfoEntry in the ibSmaGuidInfoTable.
It (and picky reviewers) would be happy if the entry were called "ibSmaGuidInfoEntry".
Another possibility would ibSmaGuidTable and ibSmaGuidEntry, since "Info" isn't
terribly descriptive.

4) for the notifications, "ibSmaNotificationPrefix" must have been intended
where "ibSmaNotifications" is currently used.  As currently writtem,
ibSmaPortLinkStateChan, ibSmaLinkIntegrityThresReached,
ibSmaExcessBuffOverrunThres, ibSmaFlowCntrlUpdateTimerExpire
ibSmaCapabilityMaskModified, ibSmaSysImageGuidModified,
ibSmaBadManagementKey, ibSmaBadPartitionKey,
ibSmaBadQueueKey, and ibSmaBadPKeyAtSwitchPort don't
have the right OID structure to permit mapping back and for
to SNMPv1.

5) the module IMPORTS "experimental", "TEXTUAL-CONVENTION",
"SnmpAdminString", and InterfaceIndex, but doesn't use them.  These
should be removed.

 Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 6 Oct 2003 16:36:14 -0700

Hi -

Here are my ID-nits comments on
draft-ietf-ipoib-tv-mib-03.txt:

Ultra-trivial formatting:
   trailing blanks make line 88 too long (73 characters)
   trailing blanks make line 302 too long (76 characters)

"." at the end of a sentence is sometimes followed by
a single space, sometimes by two.  Should be two
consistently.  Strongly recommend fixing these before
going to RFC editor; any reformatting of DESCRIPTION texts
is best done by a document's author.

Serious:
Byte-order diagram for IpIpoibClientIdentifier doesn't
use network byte order.  Please take a look at
draft-rfc-editor-rfc2223bis-07.txt section 3.4 for
more details.

Minor:
RFC 2119 is referenced normatively, but is missing from
the list of normative references.

Acronyms should be expanded on first use.  Ones that
jumped out at me were:
 IBA
 LID  (though embedded in DLID)
 IEEE
 HCA
 TCA

Missing "." after the abbreviation "Vol."

The order of sections should be aligned with
draft-rfc-editor-rfc2223bis-07.txt section 4, i.e,
mib definitions (stays in current location)
acknowledgements (currently 9)
security considerations (currently 8)
Normative references (currently 6)
Informative references (currently 7)
Author's address (stays in current locations)

(My *personal* preference is to make the normative and
informative references sections sub-sections of a single
references section, but AFAIK that is merely a personal preference.)

Author's address has no country.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 6 Oct 2003 18:14:29 -0700

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

---

From: "bill" <[email-masked]>
Date: Thu, 16 Oct 2003 12:30:10 -0700

Two weeks ago I asked for last call comments on these drafts.

There has been some comments received - but if anyone is looking at
these drafts and can not get comments back to the list by tomorrow -
please e-mail me and I will delay the end of last call for a reasonable
period of time

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of bill
Sent: Friday, October 03, 2003 12:02 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Ipoverib] IPoIB MIBs ready for WG Last Call

http://www.ops.ietf.org/

Thank you

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 17 Oct 2003 12:09:46 -0700

Hi -

...
...

MIB Doctor status update:

More comments coming; I've been distracted by another document in my
own WG (disman).  I should be able to get everything typed in on Monday
or Tuesday of next week.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Oct 2003 22:32:12 -0700

Hi -

Here are the rest of my review comments on sections 5 and 6 of
draft-ietf-ipoib-ibif-mib-05.txt, resuming with section 5.2.7.
Executive overview: it needs another cycle as an i-d.

Details:

"MTU" should be expanded on first use.

ifInOctets: "should" -> "MUST"

ifInUcastPkts: "Note," -> "Note"

ifInErrors: it looks like the text is what should have been
in the entry for ifInDiscards.  Is this intentional?

ifInUnknownProtos: is an unknown protocol really *impossible*?

ifOutOctets: "should" -> "MUST"

ifOutUcastPkts: "Note," -> "Note"

ifInMulticastPkts:  Remove the sentence "Always 0 unless proprietary
counters are implemented."

ifOutMulticastPkts:  Remove the sentence "Always 0 unless proprietary
counters are implemented."

ifInBroadcastPkts
ifOutBroadcastPkts
ifHCInBroadcastPkts
ifHCOutBroadcastPkts: remove the "always 0" language.  If broadcast
is impossible, say so, and indicate that as a consequence, these
counters have nothing to count.

ifHCInUcastPkts
ifHCInMulticastPkts
ifHCOutUcastPkts
ifHCOutMulticastPkts: remove the fragment "Always 0 unless proprietary
counters implemented."

If you know that there is a substantial installed based of
systems incapable of counting some of these events, it
might not hurt to put in a "reminder" reference to section
3.1.18 of RFC 2863 or to simply clone that text.

Section 5.3:  expand the VL (virtual Lane) abbreviation on first use.

Section 5.4:
"Note," -> "Note"

Replace this sentence: "Note, that since multicast counters have not been
defined by the IBA specification, IF-MIB multicast counters should
be set to 0 (in the absence of any proprietary IBA multicast
counters)."  Just what you replace it with should probably be
hammered out in the WG.  :-)  My foremost concern is that we do
not violate section 3.1.18 of RFC 2863.

Replace this sentence: "Also, based on the IBA counter definitions,
multicast (packets and bytes) will be part of the IF-MIB unicast counters."
It should be clear that, for example, ifInOctets MUST include the multicast
octets, but ifInUcastPkts MUST NOT include multicast packets.

The mapping .PortRcvPkts = IF-MIB:ifInUcastPkts sounds like it's
not right, since it would incorrectly include non-unicast packets.
(If it *is* right, then the other mappings are suspect.)  Ditto
the formula for IF-MIB:ifOutUcastPkts

What is the rationale behind this note?  "Note: that
PortCounters.PortRcvSwitchRelayErrors is not counted in
either IF-MIB:ifInDiscards or IF-MIB:ifOutDiscards."

Section 5.5:
(the diagram leaves of a lot of interesting stuff, like how
ibIfPortStatInactDiscards fits into the tallies.)

Modify this sentence:
"Again it should be noted that since no multicast
counters are defined by the IBA specification they are not covered here."
I'd be happy with something to the effect that since the IBA specs do not
define the necessary multicast counters, implementation-specific
techniques may be needed to compute those values.

ifOutErrors:
rather than specifying zero, it should just say that it's
impossible for anything to fail in such a way that a packet
would not be able to be transmitted.  Of course, if that's
not true, we have a bigger problem here.

In the case diagram, I think it would be beneficial to tweak
the ASCII art so that labels like PC.PortXmitConstraintErrors
aren't split across lines.  I played around with it a bit, and
it IS possible without too much effort.

More Globals:
Replace "[Infini v1.1]" with "[INFINIV1] to match what's in the
references section.

Section 6.0:
CONTACT-INFO clause MUST include WG mailing list information,
etc.  See <draft-ietf-ops-mib-review-guildelines-02.txt> section 4.5.

Page 13: the REVISIONs and DESCRIPTIONs should be collapsed to a
single pair, in accordance with page 12 of the MIB review guidelines.

Need to add copyright notices to MODULE-IDENTITY per MIB review
guidelines section 3.8.

ibIfPortSymbolErrs (and other counters): The word "total" isn't
quite right, since these are *counters* with no pre-defined
starting value and the potential for wrapping.  This may seem
like an editorial nit, but I think it's good to be mindful of it,
especially since application writers will get themselves into
trouble if they take the word "total" literally.  A more accurate
description would say something to the effect that this counter
is incremented whenever X occurs for some Y.

The DESCRIPTION of ibIfPortStatSwLifetimeDiscards and
ibIfPortStatHOQLifetimeDiscards says:
"Note, applies only to switches."  The MIB conformance
material doesn't mention switches, so I left wanting to know
what a system which is not a switch is supposed to do:
    a) implement this object, but since the associated event
 never happens, its value won't be incremented
    b) not implement this object
I personally prefer (a), but the MIB should clearly state
what you want implementors to do.

HOQ should be expanded on first use. (page 18)

ibIfPortStatLinkIntergrityErrs mentions "the LocalPhyErrors threshold"
but doesn't say what it is or how one would set or get it.  Furthermore,
if it's really a counter, then this description is probably incorrect,
since the behaviour described would be more appropriate for a gauge
reporting the change in a counter over some period of time.

ibIfPortStatExcBufOverrunErrs mentions "OverrunErrors" without
describing how one would get or set this attribute.  Also, the
current text is ambiguous.  For example, if OverrunErrors is
two, and errors have occured in three consecutive periods,
would this counter be incremented once or twice?

ibIfPortStatVL15Dropped: what is meant by VL15 here, and why is it
special?

Does the language about packets not included in ibIfVLInPkts also
apply to ibIfVLInOctets?  Ditto ibIfVLOutPkts and ibIfVLOutOctets.

ibIpoibLinkLayerIndex should be Unsigned32 rather than INTEGER,
per the MIB review guidelines (top of page 14).

However, a more fundamental question is whether there's any
need for ipIpoibLinkLayerIndex at all.  It seems to me that
the uniqueness requirements (which aren't at all clear from
the current DESCRIPTION text) could at least be partly expressed
by making ibIpoibLinkLayerAddr the second index of the
ibIpoibLinkLayerAddrTable, which would need to be accessible
since there are no other accessible objects in this table.

In any case, the DESCRIPTION for ibIpoibLinkLayerAddr needs
to be cleaned up; the note appears to start out as a restatement
of the description, but then appears a baffling "in either case".

What is the rationale for defining ibIfVlTrafficIfIndex,
ibIfPortStatIfIndex, and ibIpoibLinkLayerIfIndex as separate
objects?  The MIB review guidelines (page 20) recommend using common
indexes in cases like these.  Indeed, for a "sparse augments"
like this I would read the guidelines as saying one should just
use ifIndex, just as other media specific MIBs have done.

Randy

---

From: "bill" <[email-masked]>
Date: Wed, 22 Oct 2003 17:36:25 -0700

End of Last Call

We have had several issues come up in Last call.  I will summarize them
here
1) Spelling, extra space, consistent nomenclature - These will just be
fixed
2) Objects that aren't supported by IBTA standard interfaces (or
supported well enough)
	- We need a quick discussion on these
3) Ordering of sections in the drafts - These will be fixed
4) Places that we say return 0 if not supported - should say return NO
SUCH OBJECT - any disagreement on this ? I hope not
5) Unless Proprietary counters are added should be removed  - Objections
?

6) Cleaning up from experimental to mib2.  Basically write it putting
the overall tree under mib2 with an assignment of xxx -- assigned by
IANA (make sure the iana considerations section is write to get this
assigned)

7) Compilations problems... To be fixed

So the big discussion item to make sure we get correctly is around issue
2,4,5.  If there are any people that want to disagree please speak now.
I think the typos can "just be fixed" uncontroversially.  I think the
compilation and moving under MIB2 can be done uncontroversially.

Sean - if you can get an update by Monday's cutoff - that would be great
to talk about in Mn.  Otherwise - if you miss, and still update before
the meeting - post it on a website so we can continue the discussion.  I
would like to discuss issues 2,4, and 5 in Minnesota to make sure what
the feedback is.

I would also like to thank our MIB doctor that went through our
documents with a fine tooth comb and found everything from typsetting
issues, through issues with the way the MIB is worded - Thank you Randy

See everyone in Minnesota.

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of bill
Sent: Thursday, October 16, 2003 12:30 PM
To: [email-masked]
Subject: RE: [Ipoverib] IPoIB MIBs ready for WG Last Call

Bill

-----Original Message-----

http://www.ops.ietf.org/

Thank you

_______________________________________________
IPoverIB mailing list
[email-masked] https://www1.ietf.org/mailman/listinfo/ipoverib

_______________________________________________
IPoverIB mailing list
[email-masked] https://www1.ietf.org/mailman/listinfo/ipoverib