Skip to main content

ENUM Validation Token Format Definition
draft-ietf-enum-validation-token-04

Yes

(Jon Peterson)

No Objection

(Chris Newman)
(David Ward)
(Jari Arkko)
(Lisa Dusseault)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Tim Polk)

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

Jon Peterson Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
(was Discuss, No Record, Discuss) No Objection
No Objection (2007-07-05) Unknown
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.
Dan Romascanu Former IESG member
No Objection
No Objection (2007-07-02) Unknown
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.
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection (2007-07-02) Unknown
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.
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2007-07-02) Unknown
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".
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
(was Discuss) No Objection
No Objection () Unknown