Skip to main content

Mark and Signed Mark Objects Mapping
RFC 7848

Revision differences

Document history

Date Rev. By Action
2018-12-20
06 (System)
Received changes through RFC Editor sync (changed abstract to 'Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark …
Received changes through RFC Editor sync (changed abstract to 'Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark holders to protect their rights during the introduction of a Top-Level Domain (TLD).

One of those special modes of operation is the Sunrise Period. The Sunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public.

This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the Sunrise Period of generic Top-Level Domains (gTLDs). Three types of Mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty.')
2017-07-07
06 (System) Received changes through RFC Editor sync (added Errata tag)
2016-06-09
06 Jean Mahoney Closed request for Telechat review by GENART with state 'No Response'
2016-06-08
06 (System) RFC published
2016-06-06
06 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-06-01
06 (System) RFC Editor state changed to AUTH48 from AUTH48-DONE
2016-06-01
06 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-05-02
06 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2016-03-28
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2016-03-25
06 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2016-03-25
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2016-03-25
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2016-03-23
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2016-03-22
06 (System) IANA Action state changed to In Progress from On Hold
2016-03-14
06 (System) IANA Action state changed to On Hold
2016-03-14
06 (System) RFC Editor state changed to EDIT
2016-03-14
06 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-03-14
06 (System) Announcement was received by RFC Editor
2016-03-14
06 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2016-03-14
06 Amy Vezza IESG has approved the document
2016-03-14
06 Amy Vezza Closed "Approve" ballot
2016-03-14
06 Amy Vezza Ballot approval text was generated
2016-03-13
06 Barry Leiba IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2016-03-10
06 Stephen Farrell
[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] …
[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:-)
2016-03-10
06 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2016-03-10
06 Gustavo Lozano New version available: draft-ietf-eppext-tmch-smd-06.txt
2016-03-04
05 Stephen Farrell
[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 …
[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.
2016-03-04
05 Stephen Farrell Ballot discuss text updated for Stephen Farrell
2016-02-25
05 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2016-02-19
05 Gustavo Lozano IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2016-02-19
05 Gustavo Lozano New version available: draft-ietf-eppext-tmch-smd-05.txt
2016-02-18
04 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2016-02-18
04 Jari Arkko
[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, …
[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.
2016-02-18
04 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-02-17
04 Benoît Claise
[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 …
[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".
2016-02-17
04 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2016-02-17
04 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-02-17
04 Alissa Cooper
[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 …
[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.
2016-02-17
04 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2016-02-17
04 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2016-02-16
04 Ben Campbell
[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]. …
[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.
2016-02-16
04 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2016-02-16
04 Joel Jaeggli [Ballot comment]
Tim Wickinski performed the opsdir review
2016-02-16
04 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-02-16
04 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-02-16
04 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-02-15
04 Stephen Farrell
[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 …
[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.
2016-02-15
04 Stephen Farrell
[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 …
[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:-)
2016-02-15
04 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2016-02-15
04 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2016-02-11
04 Jean Mahoney Request for Telechat review by GENART is assigned to Russ Housley
2016-02-11
04 Jean Mahoney Request for Telechat review by GENART is assigned to Russ Housley
2016-02-09
04 Spencer Dawkins
[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 …
[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?
2016-02-09
04 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2016-02-04
04 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2016-02-04
04 Tero Kivinen Request for Telechat review by SECDIR is assigned to Simon Josefsson
2016-02-04
04 Tero Kivinen Request for Telechat review by SECDIR is assigned to Simon Josefsson
2016-02-03
04 Barry Leiba Ballot has been issued
2016-02-03
04 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2016-02-03
04 Barry Leiba Created "Approve" ballot
2016-02-03
04 Barry Leiba Placed on agenda for telechat - 2016-02-18
2016-02-03
04 Barry Leiba Changed consensus to Yes from Yes
2016-02-03
04 Barry Leiba Changed consensus to Yes from Unknown
2016-02-03
04 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2016-01-04
04 Gustavo Lozano IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2016-01-04
04 Gustavo Lozano New version available: draft-ietf-eppext-tmch-smd-04.txt
2015-12-10
03 Tero Kivinen Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Simon Josefsson.
2015-12-07
03 Barry Leiba Remaining in "waiting" state pending responses to Gen-ART and SecDir reviews.
Gen-ART: http://www.ietf.org/mail-archive/web/gen-art/current/msg12584.html
SecDir: http://www.ietf.org/mail-archive/web/secdir/current/msg06248.html
2015-12-07
03 Barry Leiba IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for AD Go-Ahead
2015-12-04
03 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tim Wicinski.
2015-12-04
03 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2015-12-01
03 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2015-12-01
03 Sabrina Tanamal
(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 …
(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
2015-11-29
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2015-11-29
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2015-11-26
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Simon Josefsson
2015-11-26
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Simon Josefsson
2015-11-23
03 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2015-11-23
03 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2015-11-20
03 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-11-20
03 Amy Vezza
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 …
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.


2015-11-20
03 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-11-20
03 Barry Leiba Last call was requested
2015-11-20
03 Barry Leiba Last call announcement was generated
2015-11-20
03 Barry Leiba Ballot approval text was generated
2015-11-20
03 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation
2015-10-15
03 Barry Leiba Ballot writeup was changed
2015-10-15
03 Barry Leiba
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 …
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.
2015-10-15
03 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2015-10-15
03 Barry Leiba Ballot writeup was generated
2015-10-14
03 (System) Notify list changed from draft-ietf-eppext-tmch-smd@ietf.org, eppext-chairs@ietf.org, draft-ietf-eppext-tmch-smd.ad@ietf.org, draft-ietf-eppext-tmch-smd.shepherd@ietf.org, nkong@cnnic.cn to (None)
2015-10-09
03 James Galvin
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 …
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.)
2015-10-09
03 James Galvin Responsible AD changed to Barry Leiba
2015-10-09
03 James Galvin IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2015-10-09
03 James Galvin IESG state changed to Publication Requested
2015-10-09
03 James Galvin IESG process started in state Publication Requested
2015-10-09
03 James Galvin IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2015-09-28
03 Gustavo Lozano New version available: draft-ietf-eppext-tmch-smd-03.txt
2015-09-20
02 Ning Kong Changed document writeup
2015-09-18
02 Antoin Verschuren Intended Status changed to Proposed Standard from None
2015-07-29
02 Antoin Verschuren Notification list changed to draft-ietf-eppext-tmch-smd@ietf.org, eppext-chairs@ietf.org, draft-ietf-eppext-tmch-smd.ad@ietf.org, draft-ietf-eppext-tmch-smd.shepherd@ietf.org, nkong@cnnic.cn from "Ning Kong" <nkong@cnnic.cn>
2015-07-29
02 Antoin Verschuren Notification list changed to "Ning Kong" <nkong@cnnic.cn>
2015-07-29
02 Antoin Verschuren Document shepherd changed to Ning Kong
2015-07-24
02 Gustavo Lozano New version available: draft-ietf-eppext-tmch-smd-02.txt
2015-07-20
01 Antoin Verschuren Waiting on a document shepherd.
2015-07-20
01 Antoin Verschuren IETF WG state changed to In WG Last Call from WG Document
2015-02-26
01 Gustavo Lozano New version available: draft-ietf-eppext-tmch-smd-01.txt
2014-03-06
00 Antoin Verschuren This document now replaces draft-lozano-tmch-smd instead of None
2014-01-27
00 Gustavo Lozano New version available: draft-ietf-eppext-tmch-smd-00.txt