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-03 Reviewer: Russ Housley Review Date: 2015-11-25 IETF LC End Date: 2015-12-04 IESG Telechat date: unknown Summary: Not Ready Major Concerns: Section 1 needs to be expanded; it needs to provide the answers to the following questions. Does the presence or absence of a digital signature on the mark impact its handling? What is the purpose of the digital signature? Who is applying the signature? Why are they signing? In section 2.1, the document says: "A <mark:name> MUST be specified in case <mark:org> is not specified." I see two possible ways to interpret this statement. One way is that <mark:name> must always be included. The other way is that <mark:name> must be include if <mark:org> is not. I think you mean the second interpretation. Please clarify. In Section 2.1. the document says: "A <mark:org> MUST be specified in case <mark:name> is not specified." As above, there are two possible ways to interpret this sentence. Please clarify. In Section 2.3, there is not enough information provided to validate the digital signature. It seems to me that the digital signature can be validated using the public key of a trust anchor or the public key obtained from a valid X.509 certification path originating with a trust anchor. If I have understood that properly, then RFC 5280 is needed as a normative reference. In addition, most protocols that make use of certificates perform some checks on the certificate subject name. If any certificate that chains to the trust anchor is as good as any other, then this should be stated explicitly. Otherwise the checks the determine that this is an appropriate certificate for this mark need to be specified. In the IANA Considerations, the authors are listed as the contacts for the name space and schema registrations. Since this is a standards track document, is the IESG a better point of contact for these entries in the IANA registry? Minor Concerns: Section 2.5 has this heading: "Appendix A. base64 encoded signedMark". If it is intended to be an Appendix, then it should be moved to the end of the document. Sections 3.1 and 3.2 include "Copyright (c) 2012 ...". Is this the correct year for the copyright? The Security Considerations might make suggestions about canonicalization to avoid breaking the XML digital signature. Other Editorial Comments: Section 5 talks about "special suggestions". I have no idea what that means.