RE: REVISED Last Call: 'Management Information Base for the Internet Protocol (IP)' to Proposed Standard

["Dave Thaler" <[e-mail]>]

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"

-Dave

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------