Roger, The expiration of the acknowledgment and TCN (48 hours) was the result of consultations with the community. In hindsight, those values (i.e. expiration of the acknowledgment and TCN) should probably been defined in a different document, but they ended in this draft. Modifying those values would require the involvement of the ICANN community, because there may be different points of view (some may want the values to be larger and others shorter). My suggestion is to update the Internet-Draft in order to say that 48 hours is the default, but the values used by implementations may be different based on policy.
Regards, Gustavo From: regext <regext-boun...@ietf.org> on behalf of Roger D Carney <rcar...@godaddy.com> Date: Monday, June 6, 2016 at 14:13 To: "regext@ietf.org" <regext@ietf.org> Subject: Re: [regext] I-D Action: draft-ietf-regext-tmch-func-spec-00.txt > Good Afternoon, > > In addition to those items that Patrik mentioned, we have been discussing, off > list with several people, a couple issues around: the 48 hour timing > requirement/reference, the use of <tmNotice:notAfter> for expiring, TCNs being > generated twice daily and the verifications/validations required by registries > and registrars. > > Ideally a TCN would be valid indefinitely and only change if claims on a label > have changed, I am not sure why the TMCH is updating these every 12 hours > (twice daily) maybe there are good reasons and I just don't know them:). > Additionally the old TCN should remain valid for a certain amount of time > (e.g. 7 days) so that a customer that has seen and accepted a claim can > process their registration over a reasonable amount of time (many domains are > registered after sitting in a shopping cart for days). I think this could > remove some of the registry checks as well. Current setup makes pre-orders > very inefficient (possibly requiring multiple registrant acceptances of the > same claim information) and results in frustrated customers and dramatically > lower go-live GA registration numbers. > > It is a bit hard to say what to do with this wording in this RFC. I would say > that these details should be extracted and referenced by this RFC, but what > would we reference today? Is there a way to document these things external to > the RFC and have the Claims review of the RPM PDP review that document and > update/approve it (or consume into another document) on their findings? Except > for moving these items to an external document I think until the RPM PDP > discusses these issues, the current values should stay (just in another > document) as almost everyone (Registries and Registrars) already follows these > details today, we can just make it better. > > > Thanks > Roger > > > -----Original Message----- > From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin > Sent: Friday, June 03, 2016 1:50 PM > To: Patrik Fältström <p...@frobbit.se>; Gustavo Lozano > <gustavo.loz...@icann.org> > Cc: regext@ietf.org > Subject: Re: [regext] I-D Action: draft-ietf-regext-tmch-func-spec-00.txt > > I want to remind the working group that we have the following unresolved > comments regarding draft-ietf-regext-tmch-func-spec. We need to address these > comments before this document can move forward. > > And please note that draft-ietf-regext-launchphase is dependent on this > document. It is ready for publication but can not move forward until we can > move both it and tmch-func-spec together. > > Thanks, > > Jim > > > > On 23 Apr 2016, at 1:53, Patrik Fältström wrote: > >> > Comments (some of this can also be fund in SSAC document SAC-060 23 >> > July 2013): >> > >> > 1. It is not clear how permutations of strings are to be calculated >> > (by whom, and how) in the case confusability risks might arise. For >> > example by the use of language tables or other mechanisms like LGRs. >> > >> > 2. The term "leftmost" is a bit confusing when talking about labels in >> > DNS. I propose using "first" as in logical order. >> > >> > 3. The matching algorithm is not described, who is implementing it >> > etc. >> > >> > 4. There are no instructions on how to handle cases where the matching >> > algorithm in TMCH is different from matching algorithm one "expect" >> > ("one" as in the trademark holder). >> > >> > Patrik >> > >> > On 22 Apr 2016, at 22:39, internet-dra...@ietf.org >> <mailto:internet-dra...@ietf.org> wrote: >> > >>> >> A New Internet-Draft is available from the on-line Internet-Drafts >>> >> directories. >>> >> This draft is a work item of the Registration Protocols Extensions of >>> >> the IETF. >>> >> >>> >> Title : ICANN TMCH functional specifications >>> >> Author : Gustavo Lozano >>> >> Filename : draft-ietf-regext-tmch-func-spec-00.txt >>> >> Pages : 60 >>> >> Date : 2016-04-22 >>> >> >>> >> Abstract: >>> >> This document describes the requirements, the architecture and the >>> >> interfaces between the ICANN Trademark Clearinghouse (TMCH) and >>> >> Domain Name Registries as well as between the ICANN TMCH and Domain >>> >> Name Registrars for the provisioning and management of domain names >>> >> during Sunrise and Trademark Claims Periods. >>> >> >>> >> >>> >> The IETF datatracker status page for this draft is: >>> >> https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/ >>> <https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/> >>> >> >>> >> There's also a htmlized version available at: >>> >> https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec-00 >>> <https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec-00> >>> >> >>> >> >>> >> Please note that it may take a couple of minutes from the time of >>> >> submission until the htmlized version and diff are available at >>> >> tools.ietf.org. >>> >> >>> >> Internet-Drafts are also available by anonymous FTP at: >>> >> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> >>> >> >>> >> _______________________________________________ >>> >> I-D-Announce mailing list >>> >> i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> >>> >> https://www.ietf.org/mailman/listinfo/i-d-announce >>> <https://www.ietf.org/mailman/listinfo/i-d-announce> >>> >> Internet-Draft directories: http://www.ietf.org/shadow.html >>> <http://www.ietf.org/shadow.html> or >>> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt> >> > _______________________________________________ >> > regext mailing list >> > regext@ietf.org <mailto:regext@ietf.org> >> > https://www.ietf.org/mailman/listinfo/regext >> <https://www.ietf.org/mailman/listinfo/regext> > > _______________________________________________ > regext mailing list > regext@ietf.org <mailto:regext@ietf.org> > https://www.ietf.org/mailman/listinfo/regext > <https://www.ietf.org/mailman/listinfo/regext>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
