Extensible Provisioning Protocol (EPP) Domain Name Mapping
RFC 4931

Section 6., paragraph 1:
>    This mapping does not introduce or present any internationalization r
>    localization issues.

  Nit: s/r/or/

==== 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."

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"

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?