Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)
RFC 6494

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

(Jari Arkko; former steering group member) (was Discuss) Yes

Yes ()
No email
send info

(Ralph Droms; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2010-06-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
It looks like the document needs an Informative reference to RFC 5781
(due to use of rsync URIs in the example).

(Dan Romascanu; former steering group member) No Objection

No Objection (2010-05-20 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support the comments about the need to assign the TBS values in the conditions that the document has no IANA actions.

(David Harrington; former steering group member) (was Discuss) No Objection

No Objection (2010-05-18)
No email
send info
1) section 5 is missing a verb, I think - "an end user could local SEND deployment"
2) expand ULA on first use.

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2010-05-16)
No email
send info
In Section 7, there are several to-be-assigned values.  They have
  been assigned:

    id-kp-sendRouter   OBJECT IDENTIFIER ::= { id-kp 23 }
    id-kp-sendProxy    OBJECT IDENTIFIER ::= { id-kp 24 }
    id-kp-sendOwner    OBJECT IDENTIFIER ::= { id-kp 25 }

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection (2010-05-20)
No email
send info
(1) Please review the secdir review in its totality.  I realize this came in late, but I think there
are a number of comments that would improve the document.  The review is available at:

   http://www.ietf.org/mail-archive/web/secdir/current/msg01701.html

(2) In section 4, last sentence:

                    Certified IPv6 address space
   SHOULD be expressed using either addressPrefix or addressesOrRange
   elements.

I re-read the syntax in 3779, and I don't quite understand what is intended here.  I don't
think there is another choice in the end.  Is the point that either a prefix or a range is
acceptable?

(3) Section 4 refers to an earlier version of sidr-res-certs, and the section numbering has
changed.  Specifically, the sections 3.9.10 and 3.9.11 are now 4.9.10 and 4.9.11.  (There may
be others.)  If you are making other edits, updating the version number and section
references might be a good idea.