Management Information Base for the Internet Protocol (IP)
RFC 4293

Note: This ballot was opened for revision 10 and is now closed.

(Margaret Cullen) Yes

(Allison Mankin) Yes

Comment (2004-02-19 for -)
No email
send info
Reviewed positively for us before Last Call by Eddie Kohler (of the Transport Doctors).

(Bert Wijnen) (was Discuss) Yes

(Harald Alvestrand) No Objection

(Steven Bellovin) No Objection

(Ned Freed) No Objection

(Ted Hardie) No Objection

Comment (2004-02-17 for -)
No email
send info
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.

(Russ Housley) No Objection

(David Kessens) No Objection

(Thomas Narten) (was No Record, Discuss) No Objection

Comment (2004-02-19)
No email
send info
> 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...

(Jon Peterson) No Objection

(Alex Zinin) No Objection

(Bill Fenner) Recuse