Management Information Base for the Internet Protocol (IP)
draft-ietf-ipv6-rfc2011-update-10

[Ballot comment]
> table for multiple address types.  Typically the only two types of
> interest are IPv4 and IPv6 however the table can support other types if
> necessary.

semicolon before "however"?

> This MIB also includes a set of deprecated objects from pervious

spelling

>            wellknown(3) indicates an address constructed from a well-
>            known value, e.g. an IANA-assigned anycast address.

this one seems odd. How will a system know that an address is of this
type?

>            The invalid(3) state indicates that this is not valid
>            address which should not appear as the destination or source
>            address of a packet.

wording awkward. THis is to list an address that is  invalid but _is_
assigned to an interface?

>            The duplicate(7) state indicates the address has been
>            determined to be non-unique on the link and so must not be
>            used.

also odd, as such an address shouldn't be in use or assigned...


>            router on this interface in respect to the forwarding of

s/in respect/with respect/ ??


>            "The number of datagrams which this entity was not their
s/which/for which/?
>            final IP destination and for which it was successful in


>            "The number of datagrams which this entity was not their
s/which/for which/?
>            final IP destination and for which it was successful in


> [8] Draves, R. and R. Hinden, "draft-ietf-ipv6-router-selection-02.txt",
>      June 2002.
>      -- RFC Editor
>      -- Please update this reference as the RFC number is assigned
>      --

Normative reference to long-stalled ID...

[Ballot discuss]
> ipIfStatsInAddrErrors OBJECT-TYPE
>    SYNTAX    Counter32
>    MAX-ACCESS read-only
>    STATUS    current
>    DESCRIPTION
>            "The number of input IP datagrams discarded because the IP
>            address in their IP header's destination field was not a
>            valid address to be received at this entity.  This count
>            includes invalid addresses (e.g., ::0) and unsupported
>            addresses (e.g., addresses with unallocated prefixes).  For
>            entities which are not IP routers and therefore do not
>            forward datagrams, this counter includes datagrams discarded
>            because the destination address was not a local address.

unallocated prefixes should not be treated specially. IF there is a
route, do the right thing. If not, and an error occurs (no route),
just count that way. For IPv6, we were careful not to have a
"reserved" range that software doesn't know what to do with (updated
in more recent addr-arch)


> Ipv6AddressIfIdentifierTC ::= TEXTUAL-CONVENTION
>      DISPLAY-HINT "2x:"
>      STATUS      current
>      DESCRIPTION
>        "This data type is used to model IPv6 address
>        interface identifiers. This is a binary string
>        of up to 8 octets in network byte-order."
>      SYNTAX      OCTET STRING (SIZE (0..8))

Does this need to be a UTF string? I.e., does it contain a displayable
identifier?

> ipv6InterfaceIdentifier OBJECT-TYPE
>    SYNTAX    Ipv6AddressIfIdentifierTC
>    MAX-ACCESS read-only
>    STATUS    current
>    DESCRIPTION
>            "The Interface Identifier for this interface that is (at
>            least) unique on the link this interface is attached to. The
>            Interface Identifier is combined with an address prefix to
>            form an interface address.
>
>            By default, the Interface Identifier is auto-configured
>            according to the rules of the link type this interface is
>            attached to.
>
>            A zero length identifier may be used where appropriate.  One
>            possible example is a loopback interface."
>    ::= { ipv6InterfaceEntry 3 }
>

Interface identifiers do not have to be unique on a link; addresses
do. This is a clarification in the more recent addr arch RFC.

[Ballot comment]
Section 14.  RFC Editor Notes

is a nice idea, but it seems like this particular instance of it either recapitulates
information in the text and doesn't really have enough data to do the work
on its own.  As an example, this text:

  In the reference section of object ipv6ScopeZoneIndexTable the reference
  needs to be updated to refer to the correct document if the address
  architecture document precedes this document as an RFC.

The RFC editor might wish to contemplate an additional "Instruction to Authors" for what to do
when including a section like this.

I just started implementing draft-ietf-ipv6-rfc2011-update-04.txt
and have the following comments:

1)
> inetIcmpOutMsgs OBJECT-TYPE
[...]
>    "The total number of ICMP messages which the entity received.
                                                        ^^^^^^^^
Should be "attempted to send", as in RFC 2011.

2) In the case diagram, InMcastPkts & InBcastPkts are shown before
InHdrErrors.  I believe they need to be shown after it, as the only way
to tell if the packet is IP multicast or broadcast is to look in the
IP header which you can only do if it's valid.

3) ipMIBCompliance2 has ipSystemStatsGroup in MANDATORY-GROUPS
ipSystemStatsGroup includes ipSystemStatsInBcastPkts and
ipSystemStatsOutBcastPkts.  However, an IPv6-only device has
no need for these since there is no broadcast in IPv6.  I believe
the objects for broadcast should be in an IPv4 conformance group
which IPv6-only devices need not implement.

4)
> ipSystemStatsInTruncatedPkts OBJECT-TYPE
[...]
>  "The number of input IP datagrams discarded because datagram
>    frame didn't carry enough data.

This is unclear.  If the frame didn't carry enough data to hold an IP
header,
is this counter incremented or ipSystemStatsInHdrErrors, or both?
As the case diagram implies, I think this counter should only be
incremented
if the IP header is valid.

5) Are all three of InForwDatagrams, InNoRoutes, and OutForwDatagrams
needed?  Per the case diagram, is it always the case that
    InForwDatagrams = InNoRoutes + OutForwDatagrams
or it it legal for InDiscards or OutDiscards to be incremented
in between InForwDatagrams and OutForwDatagrams?

There's currently the note
"(2) The discard counters may increment at any time in the processing
path."
but it isn't clear which processing path.  Obviously it should not be
legal for InDiscards to be incremented in the send path, or for
OutDiscards to be incremented in the receive path.  But with the
forward path line, it's not clear where the legal "InDiscards" section
ends and the legal "OutDiscards" section begins.

One simple fix would be to just specify that InDiscards applies anywhere
left of the InNoRoutes junction, and OutDiscards applies anywhere
right of it.

6) 4.1
> ignored.  If you decide to implement it you may wish to use the
previous
> instrumentation and arrange for the system statistics table to
aggregate
> the new interface level statistics.

This is unclear.  If you mean to suggest that one can compute a global
value but adding all the per-interface values, then you should point
out that this can only be done without causing counter discontinuities
if the set of interfaces is static.  (That is removing an interface
would make the global counter value drop, which is a discontinuity.)

7) the ip6Forwarding object is described as
>  "The indication of whether this entity is acting as an IPv6
>  router in respect to the forwarding of datagrams received
>  by, but not addressed to, this entity.  IPv6 routers forward
>  datagrams.  [...]

However, forwarding is actually a per-interface attribute in general.
If a device is acting as a router on some interfaces and as a host
on others, what value should it report here?  In my opinion it should
report true here (if this object is kept at all) and there should be
a per-interface Forwarding object.

8) ipv6InterfacePhysicalAddress OBJECT-TYPE

If this object is needed (as opposed to just using ifPhysAddress)
why does the same reason not apply to IPv4 also?

9) ipv6InterfaceReasmMaxSize OBJECT-TYPE   
        SYNTAX    Unsigned32 (0..65535)

From RFC 2460 sec 5:
>  A node must be able to accept a fragmented packet that, after
>  reassembly, is as large as 1500 octets.  A node is permitted to
>  accept fragmented packets that reassemble to more than 1500 octets.

So shouldn't the range be (1500..65535)?

10) ipv6InterfaceRetransmitTime OBJECT-TYPE
Is there a reason this doesn't apply to IPv4?
RFC 1122 says regarding ARP:
>  [...]  The recommended maximum rate is 1 per second per
>  destination.

It would seem that all objects in the ipv{4,6}InterfaceTables
should be the same except for ipv6InterfaceIdentifier. 
Is there a reason they are not merged as was done with the
ipSystemStatsTable?

11)
>    SYNTAX    INTEGER {                   
>                medium (0),
>                high (1),
>                reserved (2),                   
>                low (3)                   
>              }

Can this be changed to:
                reserved (-2),
                low (-1),
                medium (0),
                high (1)
Or just use a signed Integer32 (-2..1), since the
object instrumented is a 2-bit signed integer.

12) The ipDefaultRouterTable is indexed as
>  INDEX {ipDefaultRouterAFType, ipDefaultRouterAddress}

The current indexing requires the agent to report only one row when
the link zone id is the same for both interfaces (i.e. indicating
multiple interfaces are attached to the same physical link) and
the same router is reachable on both interfaces.

Per RFC 2461:
> Router list entries point to entries in the
> Neighbor Cache; [...]

The inetNetToMediaTable instruments the neighbor cache and contains
the ifIndex in the INDEX.  As a result, the MIB does not follow the
RFC 2461 model.  To be consistent, ipDefaultRouterIfIndex must be
in the INDEX clause to allow an entry to point to a specific
inetNetToMediaEntry.

13) ipv6ScopeZoneIndexSubnetLocal

Rename to ipv6ScopeZoneIndex3 for consistency with scoped address
architecture changes, and update DESCRIPTION.

14) ipv6RouterAdvertDefaultLifetime
>  SYNTAX    Unsigned32 (0..65535)   
>  UNITS "seconds"   
>  "[...] This value           
>  MUST be either 0 or between ipv6RouterAdvertMaxInterval and
>  9000 seconds. [...]"

So why does the SYNTAX allow values > 9000?
Sounds like it should be (0 | 4..9000).

15) Shouldn't there be 64-bit versions of
        ipSystemStatsInForwDatagrams    Counter32,
        ipSystemStatsOutForwDatagrams  Counter32,
        ipSystemStatsInDelivers        Counter32,
        ipSystemStatsOutRequests        Counter32,
    ?

    If InReceives can wrap in an hour, the packets have to go somewhere,
    and if OutTransmits can wrap in an hour, the packets have to come
    from somewhere...

16) The case diagram accounts for the case where the IF changes on the
    receive path, but what about on the send path?  The same thing
happens
    in the weak host model. 

    Similarly, on a router, a packet could be forwarded and then be
    locally destined.  Or it could be locally sourced and then
    forwarded.  In these cases, should InForwDatagrams and
OutForwDatagrams
    be incremented?  I would say yes, although the case diagram doesn't
    allow for it.  It would be nice to add a note to at least add a note
    to this effect.
   

Missing references
------------------

> ipv6RouteTable) has been removed from this MIB.  The replacements or
> updates for this information is in the update to the IP Forwarding
Table
> MIB.

add a reference to that document so the reader can find them

>  REFERENCE "draft-ietf-ipv6-router-selection-02.txt, section 2.1"

The reference is missing from the References section.

Typos
-----

3.2.1
> Each of group of objects is required when implementing their
respective
      ^^
delete extra "of"

3.2.3
> discontinuity event which would invalidate the management entities
> understanding of the counters has occurred.  The system being re-

"entities" should be "entity's"

3.2.10
> set of counter to track the number of ICMP messages and errors
processed
        ^^^^^^^
should be "counters"

4.2
> The ipAddressTable is loosely based on the ipv6AddrTable but has
changed
> considerable with the addition of several new objects and the removal
of
  ^^^^^^^^^^^^
should be "considerably"

>    REVISION      "9411010000Z"

Update the pre-2000 revision dates to use 4-digit years

> ipSystemStatsInTruncatedPkts OBJECT-TYPE
[...]
>    "The number of input IP datagrams discarded because datagram
>    frame didn't carry enough data.

insert "the" before "datagram"

> ipRoutingDiscards OBJECT-TYPE
[...]
>    and a similar, but more thourghly clarified, object has been
                            ^^^^^^^^^
Should be "thoroughly"

> ipv6RouterAdvertOtherConfigFlag OBJECT-TYPE   
>    "The true/false value to be placed int the 'other stateful
                                        ^^^
should be "in" or "into"

Chair write-up:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

I have reviewed this version as a chair and as a contributing author.
I feel that it is ready to go to the IESG.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

The primary editor for this document (Shawn Routhier) is a very
knowledgeable MIB author and is a MIB Doctor for the Management
Area.  In addition, several members of the IPv6 working group and
the ipv6mib Design Team have contributed reviews of this document.

I have no concerns on the reviews that have been done.  I am quite
happy with the support this document has received.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?
 
No concerns.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.
 
There is an open issue with the use of InetAddressType without a
corresponding InetAddress.  In this particular document, that
approach is used in the statistics table.  Shawn and I consider it
to be a "slight" hack, but there is some concern from Juergen
Schoenwaelder that it is a more grevious hack.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

My perception is that there is strong support from the small number
of people in the working group who are MIB-literate.  I have asked
others for their opinion and most state they trust those members
who are MIB-literate.

There is a strong consensus on the ipv6mib mailing list which has
strong representation from the management area.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.
 
No.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

    This memo defines a portion of the Management Information Base (MIB) for
    use with network management protocols in the Internet community.  In
    particular, it describes managed objects used for implementations of the
    Internet Protocol (IP) in an IP version independent manner.  This memo
    obsoletes RFCs 2011, 2465 and 2466.

    It accomplishes this by utilizing the InetAddress TC to provide
    IP address-independence on the management objects.  This allows
    a single MIB to provide the same level of management for IPv4
    and IPv6.

  - Working Group Summary

    There was strong WG consensus for this document in both the IPv6
    working group and the IPv6 MIB design team.

  - Protocol Quality

    This document has undergone significant review by management
    experts.  In particular, Juergen Schoenwaelder has provided several
    significant comments.