Mark and Signed Mark Objects Mapping
draft-ietf-eppext-tmch-smd-06

In general I agree with Ben's comments about <mark:treatyOrStatute> and <mark:court>. I don't understand why these elements contain a smattering of the same child elements of <mark:trademark> (holder, contact, etc.), rather than just containing a <mark:trademark> as a child element in its entirety, and then adding in the additional treaty- or court-specific elements that are necessary. The way its specified in the document makes it hard to understand whether the child elements of <mark:treatyOrStatute> and <mark:court> refer to the treaty/court ruling at issue, or to the trademark.

*** Substantive Comments ***

- General: I share Stephen's and Russ's concern about the lack of signature policies either here or in [ICANN-TMCH]. In particular, what does it mean for a mark to be signed?

- 2.1: What is the semantic difference between <mark:name> and <mark:org>? If the latter represents an organization, should we assume the former does not? Or more specifically, does <mark:name> represent a person? Along the same lines,  <mark:addr> is described in terms of an organization address. What is only <mark:name> is present?

- 2.2: <mark:id> must be globally unique in relation to the repository? I _think_ this means that it must uniquely define a mark in relation to a repository. But that can also be interpreted to mean that no two mark elements can contain the same ID/repository combination. (This language occurs several times)

-- <mark:treatyOrStatute>: Can you clarify the meaning of "country of the ruling"? (as opposed to the country of protection)

- 2.3: 
-- <smd:signedMark> is described as the fragment of xml that is signed. But the text suggests the <signature> element is a child of <smd:signedMark>. Is the signature itself expected to be signed? If only part of <smd:signedMark> is signed, which parts?

-- Do <smd:notBefore> and <smd:notAfter> refer to the validity of the signature, or the mark itself?

-- Why is XML canonicalization a SHOULD rather than a MUST? Why might one choose not to use it? What can go wrong if you don't use it? (If the answer is that the signature validation might fail, them maybe this should be a MUST?)

-- Does the reasoning for RSA-SHA256 being a SHOULD rather than a MUST imply that there are algorithms that MUST NOT be used?

*** Editorial Comments ***

- Abstract:
It would be helpful to see a sentence describing what sort of "marks" this draft discusses in the abstract.

-2.2, <mark:treatyOrStatute>, <mark:refNum>:
I am not sure the intent of "number of the mark of the treaty or statute." Does the treaty or statute itself have a mark? A number? Or is just a reference number for the described mark?

-6: Section numbers would be helpful for the references back into the body.

Here is Tim Wicinski's OPS DIR review.
General Summary: Ready with nits

In doing this write up after I wrote my comments, I went and researched the mail archive, and I found Russ Housley's very succinct Gen-Art review:

https://mailarchive.ietf.org/arch/msg/gen-art/jBbrcEzrRlSPWGcjEVdvTO41ckQ

Specifically the Appendix in the wrong place, the insertion of copyrights in Sections 3.1 and 3.2

Additionally, in Section 2 "Object Description" there are elements for the objects that are marked OPTIONAL or MUST. However, there are many which are not defined either way.  The "assumption" is they are a MUST. If this is true perhaps some text at the beginning of the definitions

    "Unless otherwise specified, any element defined is a MUST".

There were some comments in the Gen-ART review from Russ Housley. I have looked at the document as well, looked up the reference, and agree with Russ’ comment that there is something missing. I would have wanted to talk about this issue wrt this document on the IESG telechat, but Stephen Farrell has already raised this point. I am interested in the matter being resolved, however.

Also, Gustavo, did you get a chance to look at Russ’ editorial comments? Those seem worthwhile to be addressed as well.

Tim Wickinski performed the opsdir review

The phrase "Sunrise Period" may be a well-known term of art, but the meaning isn't obvious in the Abstract. It's explained well with one sentence in the Introduction - perhaps that sentence could be included in the abstract as well?

Thanks for clarifying the issues wrt the PKI needed. 

(Old comments below, I didn't check 'em)

- Please see the secdir review [1] which raises a number of
significant points (including the DISCUSS above) and which
hasn't as far as I've seen gotten a response (apologies if I
missed that).

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html

- "precudle" nice:-)