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

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

(Allison Mankin; former steering group member) Yes

Reviewed positively for us before Last Call by Eddie Kohler (of the Transport Doctors).

(Bert Wijnen; former steering group member) (was Discuss) Yes

(Margaret Cullen; former steering group member) Yes

(Alex Zinin; former steering group member) No Objection

(David Kessens; former steering group member) No Objection

(Harald Alvestrand; former steering group member) No Objection

(Jon Peterson; former steering group member) No Objection

(Ned Freed; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Steven Bellovin; former steering group member) No Objection

(Ted Hardie; former steering group member) No Objection

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.

(Thomas Narten; former steering group member) (was No Record, Discuss) No Objection

> 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...

(Bill Fenner; former steering group member) Recuse