Last Call Review of draft-ietf-eppext-tmch-smd-03
review-ietf-eppext-tmch-smd-03-genart-lc-housley-2015-11-25-00

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.