IPv6 Node Requirements
RFC 4294

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

(Margaret Cullen) Yes

(Steven Bellovin) (was Discuss) No Objection

Comment (2004-05-26)
No email
send info
While I'm still unhappy with the IPsec text, my comments are handled by Russ's suggested text; accordingly, I'll let him hold the DISCUSS.  My other issues have been resolved satisfactorily.

(Bill Fenner) No Objection

(Ned Freed) No Objection

Comment (2003-12-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Nit: No copyright boilerplate
Comment: Checking all the references is sure going to be fun...

(Ted Hardie) (was Discuss) No Objection

Comment (2004-05-25)
No email
send info
I'm still not thrilled with the DNS language, but it *does* indicate that DNS should be
generally available, since applications rely on it, so I have cleared my discuss.  If
there are later revisions, though, one more pass through the language would be valuable.

(Scott Hollenbeck) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2004-08-16)
No email
send info
  The first paragraph of the Introduction says: "... all IPv6 nodes can be
  expected to implement the mandatory requirements listed in this document."
  How can this be true unless it is published on the Standards Track or as
  a BCP?  Perhaps it out to say that it summarizes the requirements from
  other published Standards Track documents to put them all in one place.

  The second paragraph of the Introduction does not sound like something
  that ought to be said in an Informational RFC.

  Section 4.5 requires all hosts to support IPv6 Stateless Address
  Autoconfiguration as defined in RFC 2462.  It ought so say that support
  for static addresses is okay too.

  There are fprmatting errors in the last paragraph of section 8.3 and in
  the last paragraph of section 8.4.

(David Kessens) No Objection

(Allison Mankin) (was Discuss) No Objection

Comment (2004-03-20)
No email
send info
I cleared my Discuss which had to do with thinking the section on redirect functionality wasn't clear enough and there could be harm due to this document replacing
the actual specs (which is why this could possibly be IESG's purview to comment).
But on a second read, this spec is quite accurate.

(Bert Wijnen) (was Discuss) No Objection

Comment (2003-12-18)
No email
send info
From OPS Directorate (Pekka):

I've reviewed this along the line, and it's pretty good stuff.

I've sent 3 editorial typos to the author directly.

One bigger issue, which may not be worth a Discuss, but something that 
IMHO should be discussed in some forum:

        All nodes that need to resolve names SHOULD implement stub-
   resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
   support for:
                                                                                                                                       
    - AAAA type Resource Records [RFC-3596];
    - reverse addressing in ip6.arpa using PTR records [RFC-3152];
    - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
      octets.

.. I'm operationally concerned about the last SHOULD.  As far as I 
know, EDNS0 is not really implemented.   It does not seem to include a 
SHOULD to something that hasn't seen practical, wide-spread deployment 
already.  I'd recommend removing this or rewording it to a MAY.