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

Shawn A. Routhier writes:
> I've snipped the sections I agree with and don't have questions about
> I will update the specification to match them if there are no other
> comments or discussion.
> 
> >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.
> 
> I think this would make the most sense and will make this update if
there
> are no complaints.
> 
> I'll point out that at least one current implementation doesn't
operate
> in this fashion.  It lumps frames that are too short for the header in
> with frames that are too short for the packet.

I agree that would be a valid implementation.
Not sure how to express that in the case diagram though.
I think I'd just add a note at the bottom of it.

> >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?
> 
> I believe it is possible that inDiscards or outDiscards could be
> incremented.
> 
> Also in note that in the interface specific case the interface may
have
> changed.
> The ipIfStatsOutForwDatagrams counts packets on the outbound
interface,
> while
> the ipIfStatsInForwDatagrams counts packets on the inbound interface.
> 
> Potentially we could try and remove one of these objects from the
system
> group
> but it doesn't seem worthwhile to do so.

Agree.

[...]
> >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.
> 
> I agree with setting the object to TRUE if it is performing routing on
> any interfaces.
> 
> I don't have an opinion on having a per-interface forwarding object.
Any
> comments from the mailing list?

We could add it but not make it mandatory.

> Note: if we do add a per-interface forwarding object I'd suggest that
the
> system
> forwarding object (ip6Forwarding) override the per-interface objects.
So
> I could configure the interfaces properly and then toggle the device
to
> forward
> or not based on a single object.

Agree, that is what I implemented.

> >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?
> 
> There was some discussion on this object and the result was a belief
that
> it
> was useful for v6.  I suppose the same arguments could be made for v4,
but
> I
> haven't heard anybody make them.  Possibly people felt that it was
useful
> enough
> to include in new (v6) code but not worthwhile to add to already
existing
> v4
> code?
> 
> Any comments from the list?

I am unhappy with its existence for IPv6 only.
I would like to see it either removed, or made available for both v4 and
v6.
The v4 version may be optional though so as to not cause a burden on
prior implementations.

My reasoning is that I don't want to have separate code for IPv4 and
IPv6
if I can help it.

> >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.
> 
> Again, I suppose we could add it.  I think this also falls into the
> category above,
> it might be useful to implement for new code but may not be worth
> retrofitting old
> code.  (And do remember that this object refers to suggested times and
not
> max times.)

Making the v4 object optional would be fine with me.

> >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?
> 
> As I recall my general assumptions were that the two tables would have
> different
> objects and might have new different objects added in the future.  We
> could collapse
> the two tables and simply define appropriate not available values or
> suggest that an
> agent return no such instance.

Yes collapsing them would be my preference, for code simplicity.

> ><snip>
> >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.
> 
> That seems to be correct.
> 
> 
> >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.
> 
> I would think that to be consistent I would actually need to
> point the router list entries to inetnetToMediaTable entries.
> However I don't like that at all and find adding
ipDefaultRouterIfIndex
> to the indexing to be better.
> 
> An alternative is to decide that the router list shouldn't contain the
> IF contact information at all and should simply be a list of the
default
> routers.
> 
> As I think the IF information is useful I intend to leave it in and
add
> it to the index.

Agree.

> >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.
> 
> I think I understand your first example (forwarded and then locally
> destined)
> I don't think I understand your second.  Can you elaborate somewhat?

The second example would be where you are running an app on a machine
with either forwarding enabled, or that implements the weak host model.
The app chooses a specific source address (e.g. with a bind) and then
sends a packet to a specific destination address.  The routing table
lookup decides the packet should go out another interface than the
one the source address is on.  Because forwarding is enabled, this
is allowed.  The packets come down from the app, logically go through
a forwarding path, and then go out the outgoing interface.

There are multiple ways to implement this, but the one I have in mind
is the one where the interface context changes as you go down the send
path (just like how note (3) says the interface can change on the
receive path). So OutRequests is incremented on the address's interface
and OutTransmits is incremented on the outgoing interface.  The current
description of InForwDatagrams implies it would be incremented,
since it says nothing about whether the packet was locally- or
remotely-originated.  The current description of OutForwDatagrams
implies it would not be incremented since it says "received".
I believe the wording should not be different.

So either both should say "received" or both should say
"attempted to forward".  At this point, I have no strong 
preference either way.

> Also in the first example I could see this being treated as being sent
out
> one
> interface and received on another even if the packet never went to the
> wire.  In
> this scheme I believe the counters would be correct, however I don't
know
> if
> that's what you have in mind.
> 
> I'm willing to add text as necessary but need some more specifics to
> understand
> what you think I should add (and where).

I think we should not try to make the case diagram any more complicated,

but I think the DESCRIPTION clauses should be updated as noted above,
and it would be good to add a note under the case diagram which depends 
on the answer to whether In/OutForwDatagrams should be incremented.

> >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
> 
> I think this should be informative, do you agree?

Agree.

> >>   REFERENCE "draft-ietf-ipv6-router-selection-02.txt, section 2.1"
> >
> >The reference is missing from the References section.
> 
> I think this one needs to be normative, do you agree?

Agree.

-Dave

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------