Cryptographically Generated Addresses (CGA) Extension Field Format
RFC 4581

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

(Margaret Cullen) Yes

(Brian Carpenter) No Objection

Comment (2006-03-13 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I assume that RFC 1958 point 3.9 applies, since nothing is
said about what to do with unknown extensions.

Margaret, can you quickly give us a recommendation for Expert Reviewer
for this?

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2006-03-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I agree with Scott that:

  "Initial  values for the CGA Extension Type field are given below; future
   assignments are to be made through RFC Required, Expert Review or
   IESG approval [2]. "

is confusing.  Picking one mechanism seems to be the right way to resolve this.

(Sam Hartman) (was Discuss) No Objection

Comment (2006-03-15)
No email
send info
I agree with those who prefer only one IANA approval mechanism rather
than three.

(Scott Hollenbeck) No Objection

Comment (2006-03-13 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
"Initial values for the CGA Extension Type field are given below; future assignments are to be made through RFC Required, Expert Review or IESG approval [2]."

Any one of the three may be used?

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

Comment (2006-03-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
These are probably just comments - if any AD wants to hold
some/all of them, versus authors just considering
them without any blocking, that can be decided:

Should put in the IANA Considerations:  this document,
updates the IANA Considerations of RFC 3972, which required
Standards Action for registration of values for the Extensions field.


Should put in the Abstract: this document updates RFC 3972.

Concerning the Security Considerations - someone could specify and
register an extension that compromises the security of RFC 3972 CGA.
The review policies of extensions are weaker than CGA's original
review.  I think the Security Considerations have to warn about this
possibility and encourage caution about it.  Imaginary example: the
extension could be an RFC publication (independent submission to the
RFC Editor, no stringent security review) of a SEND variant that is
easy to break but also easy to implement.  If it becomes widely
deployed, that extra risk is consequence of the extensibility provided 
here.

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection