Mark and Signed Mark Objects Mapping
draft-ietf-eppext-tmch-smd-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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 |