Extensible Provisioning Protocol (EPP) Contact Mapping
RFC 4933
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
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/
(Ted Hardie; former steering group member) Yes
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) 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."
(Cullen Jennings; former steering group member) (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"
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (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?
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sam Hartman; former steering group member) (was Discuss) No Objection