ENUM Validation Token Format Definition
RFC 5105

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

(Jon Peterson) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2007-07-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 4., paragraph 0:
> 4.  Field Descriptions

  Definitions and descriptions of the elements should use RFC2119
  terminology.

Section 11.2., paragraph 1:
>    [12]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
>          RFC 3730, March 2004.

  Obsoleted by RFC 4930.

(Cullen Jennings) (was Discuss, No Record, Discuss) No Objection

Comment (2007-07-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The idea of the infinite validity seems very scary. I would prefer to see the expirationDate not be optionally. My worry is that, it is very likely that expirationDate will not be implemented at all.

I think it would be better of the XML for civil address information lined up with the XML for civic location in geopriv. 

The signature seem to be computed across all the data meaning that the tokendata information can not be removed. I can't decide if this is a bug or a feature.

(Chris Newman) No Objection

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) No Objection

Comment (2007-07-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
From the PROTO write-up: 

4. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)?
*Not really. Maybe some XML experts could have a look on the final version of this draft.

It would be useful indeed to confirm that some XML expert review happened and record it in the tracker.

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund (was Discuss) No Objection

Comment (2007-07-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 3.

   Validation Entities MUST be able to sign tokens according to XML-
   DSIG, MUST support at least SHA-256 as the digest algorithm and MUST
   be able to embed X.509 [10] certificates. 

I would propose to remove "at least". If one likes to point out that you may also support other algorithms, then add "and MAY support other algorithms". I also think there should be a referene for "SHA-256".