Extensible Provisioning Protocol (EPP)
Note: This ballot was opened for revision 04 and is now closed.
(Ted Hardie) Yes
(Jari Arkko) No Objection
(Ross Callon) No Objection
(Brian Carpenter) No Objection
==== 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."
(Lisa Dusseault) No Objection
(Lars Eggert) (was Discuss) No Objection
Section 6., paragraph 1: > This mapping does not introduce or present any internationalization r > localization issues. Nit: s/r/or/
(Bill Fenner) No Objection
(Sam Hartman) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
(Cullen Jennings) (was Discuss) No Objection
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"
(David Kessens) No Objection
(Jon Peterson) No Objection
(Dan Romascanu) No Objection
(Mark Townsley) No Objection
Magnus Westerlund (was Discuss) No Objection
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?