partial comments on section 5 of ibif

Hi -

Here are my partial review comments on sections 5 and 6 of
draft-ietf-ipoib-ibif-mib-05.txt;  I need some clarification
before I go further in the review.

First, however,a global comment:

Typographical:
The document is inconsistent in use of spaces after period.
The guidelines are clear that there should be TWO spaces
after a period at the end of a sentence.  I recommend fixing
this sooner rather than later, as it can be a very annoying
source of deltas to be reconciled during the AUTH48 period.

Specific comments:
Typographical:

page 4: "portions there of" -> "portions thereof"
page 4: '"physical lanes" .' -> '"physical lanes."'
        (I won't object to the more logical but less correct
        '"physical lanes".')

page 4: this line (also appears elsewhere) looks really odd:
       infiniband(ianaIfType 199)   -- Assigned by IANA

wouldn't it be simpler to just say "IANA has assigned
the ifType value 199 to identify Infiniband media."?
similar changes would be appropriate in the other locations
where this appears.

page 4: bottom: replace ianaIfType-TBD etc. with
       "199"

page 5: "over constraining" -> "over-constraining"

page 5, 5.2.4: "address," -> "address"

page 6 "in affect" -> "in effect"

consistency: section 5.0 says "Thus no exposure to per physical
lane information is defined.", yet 5.2.6 does just that for
ifDescr, though very loosely.

page 6/7: ifSpeed: "should" -> "MUST", and "must" -> "MUST"

page 7: ifAdminStatus: "should" -> "SHOULD"

page 7: ifInOctets: "should" -> "MUST"

pages 7-8: ifInUnkownProtos, ifInMulticastPkts, ifOutMulticastPkts,
ifInBroadcastPkts, ifOutBroadcastPkts, ifHCINBroadcastPkts,
ifHCOutBroadcastPkts, etc.:  The "always 0" isn't appropriate
for a counter type.  It should simply say that they never change
because these events can't occur on this medium.  (If these
events *can* occur, then there's a more serious problem here.
For example, I'd be really surprised if an Unknown Protocol is
impossible.)

page 8: ifOutOctets: "should" -> "MUST"

page 8:  I'm puzzled by the last sentence of this description.
Could someone explain to me why the implementation of a proprietary
counter would affect the behaviour of this counter?
      ifInMulticastPkts          Refer to [RFC2863]. Note, that this
                                 does not include link packets, since
                                 link control packets are consumed by
                                 the interface layer and are not passed
                                 to any higher layer protocol. Always 0
                                 unless proprietary counters are
                                 implemented.

Ditto ifOutMulticastPkts

Page 8:  Something sounds seriously broken here:
      ifHCInUcastPkts            64-bit versions of packet counters.
      ifHCInMulticastPkts        Required for interfaces
      ifHCOutUcastPkts           that are capable of operating at
      ifHCOutMulticastPkts       640Mbit/sec or faster, even if the
                                 interface is currently operating at
                                 less than 640Mbit/sec. Always 0
                                 unless proprietary counters
                                 implemented.

Before I go further into a tarpit of misunderstanding, could
someone tell me what's going on with these objects?

Randy