Extensible Provisioning Protocol (EPP) Contact Mapping
draft-hollenbeck-epp-rfc3733bis-06
Yes
(Ted Hardie)
No Objection
(Bill Fenner)
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Mark Townsley)
(Ross Callon)
(Russ Housley)
(Sam Hartman)
Note: This ballot was opened for revision 06 and is now closed.
Ted Hardie Former IESG member
Yes
Yes
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2006-11-27)
Unknown
==== draft-hollenbeck-epp-rfc3732bis (Based on Gen-ART review by Joel Halpern) > 2.3. Status Values > > A host object MUST always have at least one associated status value. > Status values MAY be set only by the client that sponsors a host > object and by the server on which the object resides. It seems the second sentence should be changed to use RFC 2119 terminology correctly: Status values MUST be set only by the client that sponsors a host object or by the server on which the object resides. ==== draft-hollenbeck-epp-rfc3733bis Discussion between Gen-ART reviewer (Pasi Eronen) and author: >How about replacing this (in Section 5): >> >> "[...] use of UTF-8 is RECOMMENDED in environments where parser >> encoding support incompatibility exists." >> >> with >> >> "[...] use of UTF-8 is REQUIRED with this specification." >> >> (Because RFC2119 "RECOMMENDED" clearly means other alternatives >> are acceptable.) Fine. > The reference to E.164 is still not quite right: the current > title/date refer are of E.164.1, while the right document to cite > here would be (AFAIK) E.164. Its title would be "The international > public telecommunication numbering plan" and date 02/2005. The correct reference should read like this: [ITU.E164.2005] International Telephone and Telegraph Consultative Committee, "The international public telecommunication numbering plan", ITU Recommendation E.164, February 2005. The citations should change from "[ITU.E164.2006]" to "[ITU.E164.2005]". ==== draft-hollenbeck-epp-rfc3734bis Agreeing violently with Ted after discussion of Gen-ART review by David Black: "I think we can and probably should add language which notes that updated versions of TLS now exist and that new or updated implementations should consider those, given that they allow backwards compatibility."
Cullen Jennings Former IESG member
(was Discuss)
No Objection
No Objection
(2006-11-27)
Unknown
The TCP draft has Implementations of TLS often contain a US-exportable cryptographic mode that SHOULD NOT be used to protect EPP. Given the things like AES and SHA-256 are us exportable, could you change "us-exportable" to "weak"
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2006-11-28)
Unknown
Section 6., paragraph 1: > This mapping does not introduce or present any internationalization r > localization issues. Nit: s/r/or/
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
(2006-11-29)
Unknown
draft-hollenbeck-epp-rfc3730bis-04.txt: Normative Reference to RFC 3066 should be updated to: Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. draft-hollenbeck-epp-rfc3734bis-04.txt Are there a reason why RFC 2246 is referenced rather than RFC 4346?
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown