I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-eppext-tmch-smd-04 Reviewer: Russ Housley Review Date: 2016-02-12 IETF LC End Date: 2015-12-04 IESG Telechat date: 2016-02-18 Summary: Not Ready Major Concerns: The Security Considerations include this paragraph: Signed Marks are used primarily for sunrise domain name registrations in gTLDs, but other third-parties might be using them. A party using Signed Marks should verify that the digital signature is valid based on local policy. In the case of gTLDs, the RPM Requirements document [ICANN-TMCH] defines such policy. The RPM Requirements document [ICANN-TMCH] does not seem to say anything at all about validating a digital signature. Protocols that make use of certificates perform some checks on the certificate subject name to ensure that it represents an appropriate signer. That is missing from this document, and it is not contained in [ICANN-TMCH] either. Minor Concerns: Section 2, second paragraph, I think that use of the phrase "in the appropriate objects" ass ambiguity. I suggest: This section defines some elements as OPTIONAL. If an elements is not defined as OPTIONAL, then it MUST be included in the object. The NOTE at the end of Section 2.3 about choosing an algorithm other that RSA-SHA256 is better suited for the Security Considerations. It would be helpful to say something more about the needed security strength. Why is RFC5730 a normative reference? I do not see a dependency. Other Editorial Comments: Section 1: s/nothing precudle/nothing precludes/