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

[Ballot comment]

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:-)

[Ballot discuss]

(same holds, for -05, checked on March 4th)

Section 7 points to [ICANN-TMCH] for signature validation policy
(I think, not quite sure). I did a quick scan (so I might have
missed it) of that document and did not find any mention of
security or signature validation, so what is an implementer
supposed to do, over and above just checking the cryptographic
correctness of the XMLDSIG? Note1: I'm not asking that all of
the details of how to construct a PKI for this functionality be
documented here, somewhere else is fine, but it doesn't seem to
be in [ICANN-TMCH] that I can see, so I don't know what I'd have
to implement, that'd get interop. Note2: I'm also not asking for
a US-DoD-scale super-huge PKI or RPKI to be specified here,
something simpler should work.

[Ballot comment]
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.

[Ballot comment]
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".

[Ballot comment]
In general I agree with Ben's comments about  and . I don't understand why these elements contain a smattering of the same child elements of  (holder, contact, etc.), rather than just containing a  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  and  refer to the treaty/court ruling at issue, or to the trademark.

[Ballot comment]
*** 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  and ? If the latter represents an organization, should we assume the former does not? Or more specifically, does  represent a person? Along the same lines,  is described in terms of an organization address. What is only  is present?

- 2.2:  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)

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

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

-- Do  and  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, , :
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.

[Ballot discuss]

Section 7 points to [ICANN-TMCH] for signature validation policy
(I think, not quite sure). I did a quick scan (so I might have
missed it) of that document and did not find any mention of
security or signature validation, so what is an implementer
supposed to do, over and above just checking the cryptographic
correctness of the XMLDSIG? Note1: I'm not asking that all of
the details of how to construct a PKI for this functionality be
documented here, somewhere else is fine, but it doesn't seem to
be in [ICANN-TMCH] that I can see, so I don't know what I'd have
to implement, that'd get interop. Note2: I'm also not asking for
a US-DoD-scale super-huge PKI or RPKI to be specified here,
something simpler should work.

[Ballot comment]

- 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:-)

[Ballot comment]
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?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-eppext-tmch-smd-03.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the ns section of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/

two new registrations will be added as follows:

ID: signedMark-1.0
URI: urn:ietf:params:xml:ns:signedMark-1.0
Filename: none
Reference: [ RFC-to-be ]

ID: mark-1.0
URI: urn:ietf:params:xml:ns:mark-1.0
Filename: none
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the schema section of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/

two new registrations will be added as follows

ID: signedMark-1.0
URI: urn:ietf:params:xml:schema:signedMark-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: mark-1.0
URI: urn:ietf:params:xml:schema:mark-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

This request also requires Expert Review as defined by RFC 5226. We will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that these two actions are the only ones required to be completed upon approval of this document.


Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-eppext-tmch-smd@ietf.org, eppext-chairs@ietf.org, eppext@ietf.org, barryleiba@gmail.com, nkong@cnnic.cn
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Mark and Signed Mark Objects Mapping) to Proposed Standard


The IESG has received a request from the Extensible Provisioning Protocol
Extensions WG (eppext) to consider the following document:
- 'Mark and Signed Mark Objects Mapping'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the format of a mark and a digitally signed
  mark used by trademark holders for registering domain names during
  the sunrise phase of generic Top Level Domains (gTLDs).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Technical Summary

This document describes the format of a mark and a digitally signed mark
used by trademark holders for registering domain names during the
sunrise phase of generic Top Level Domains (gTLDs).

Ning Kong is the Document Shepherd. Barry Leiba is the responsible Area
Director.

2. Review and Consensus

This document received the WG's attention and some comments throughout
the life of the WG. One of the major comments is that this document
should include the EPP extension registration in the section of IANA
consideration. Another one is some recommended signing algorithms should
be mentioned in the security section.  None of the consensuses were
tough to reach. Thus there is no disagreement about this document.

The Document Shepherd did a thorough editorial and technical review of
the document, and resolved any issues brought up during WGLC. The
Document Shepherd does not have any concerns about the depth or breath
of the reviews. This document has also had a number of discussions in
tmch-tech working group of ICANN. Some SMD file tests were carried out
during discussion and full examples are listed in the document. The
document has support of the WG. There are at least four known
implementations of production level and one implementation in test.

3. IPR

The document authors have confirmed conformance with BCP 78 and BCP 79.
There is no known IPR related to this document.

Technical Summary

This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the sunrise phase of generic Top Level Domains (gTLDs).

Working Group Summary

This document received the WG's attention and some comments throughout the life of the WG. One of the major comments is that this document should include the EPP extension registration in the section of IANA consideration. Another one is some recommended signing algorithms should be mentioned in the security section.  None of the consensuses were tough to reach. Thus there is no disagreement about this document.

Document Quality

The Document Shepherd did a thorough editorial and technical review of the document, and resolved any issues brought up during WGLC.
The Document Shepherd does not have any concerns about the depth or breath of the reviews.
This document has also had a number of discussions in tmch-tech working group of ICANN. Some SMD file tests were carried out during discussion and full examples are listed in the document. The document has support of the WG. There are at least four known implementations of production level and one implementation in test.

Personnel

Ning Kong is the Document Shepherd. (Barry Leiba is the responsible Area Director.)