Re: [regext] Eric Rescorla's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)
Eric Rescorla <ekr@rtfm.com> Tue, 12 December 2017 19:26 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB4D129521 for <regext@ietfa.amsl.com>; Tue, 12 Dec 2017 11:26:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYVWFKxYhaHf for <regext@ietfa.amsl.com>; Tue, 12 Dec 2017 11:26:10 -0800 (PST)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E83126FDC for <regext@ietf.org>; Tue, 12 Dec 2017 11:26:09 -0800 (PST)
Received: by mail-yb0-x22c.google.com with SMTP id z11so4436598ybm.1 for <regext@ietf.org>; Tue, 12 Dec 2017 11:26:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vGOCqPOwc82/mSe7mArGp8K9rBd4ZyJVyMDHoWzEJzc=; b=gFvYmoUt+3X6kyuolFS1HrL1VbKTUyKAG2WPSWFdRknFmRWeWxCnWtzW1QBxTYl3zf DoOdaiPt2ycaE7/FX6aeKNqKW2M0wM8nrWDX6i2pp1KAqnJJUdoxfMRe/bSbKCkjnlh8 86dbt5r1Rr069fxcUH+44/uZhMiPk2FXkHHY97CC/2AafSjXvTsRFcn0kkwY/sUKaHIy RLg5SzL00X+3VzjJ0kOXcwVCwNbkLnTUWsRJ3jBKM73ai4Ih1plu54FODOIitaqyTFFX zCOW1BdqlxHPQl9Sp0oA+NYpD/af1Kzz/17N9CookbZyHiy2oRXVxW+p/m9DMXF7xkbh 4k0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vGOCqPOwc82/mSe7mArGp8K9rBd4ZyJVyMDHoWzEJzc=; b=NNR4DDpTjUGXMwJKQNEAjV5A4ymnyCslOe1W8GcU3rP/PBXeo+Rao4INhMt2X2ZHU9 XSDlRvgUopQ4ViOZVHIqhWQj3NamDHouh1/Fffdux4qMCK7C8MAlb/PXdH+hfhlhsEfG 2JfgrLMBHNdVND9KL2ycJ0DxyTT1+9dEZgC/uKjz5PTf7CmPh9bY8J6UsTLYGZ+JaFef BvXIVEWleR9gg3YGD7EgDeHfYKjSkuMt4YLIoEVlzAE8JnIYcVP2W52DFmXRmYuMpLu4 gGb8HDOeDphysNP/EIHbNXKc+xdmzgJe/oXPTBhiz8CLSdRTPFWCFHledTPG1+F9Z2RD qcfw==
X-Gm-Message-State: AKGB3mIz4I95xOJ7fQZi1kF0GpgW3A4Ju0GlLcSxX/2Htgc2kElZtTWH NEosGxJWUSv6DzPCw03RSvl8dsfBRjiMTAGuiMpLiQ==
X-Google-Smtp-Source: ACJfBovgl1tRNplhfC7Ydn+HnssEnyjIUQcLf+Qh+MSWt9EzwnZwp3b+WmFxHNsMIzqKllgaLssHiK2NEuN2FkvpIqg=
X-Received: by 10.37.224.215 with SMTP id x206mr3839536ybg.200.1513106768803; Tue, 12 Dec 2017 11:26:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Tue, 12 Dec 2017 11:25:27 -0800 (PST)
In-Reply-To: <1920908C-88D4-4E1E-9620-029443DE6357@verisign.com>
References: <151198325898.8082.15320595994922982511.idtracker@ietfa.amsl.com> <EFCA46BE-37D3-4524-BEA6-9997AFC321F2@verisign.com> <CABcZeBNfH8AM_jocCw_tFJaAdNCGr2FozbzuP0t2ZCLrAM4U7w@mail.gmail.com> <EB2C3814-5A6C-45DC-96FD-0DC6CD933D97@verisign.com> <CABcZeBN+0PA+oOprPfwO-F51z-LO1uDhCBG2NqtRJRa9WJ6gcA@mail.gmail.com> <EBF99B44-5B85-45A9-B486-B83063A1CDF6@verisign.com> <CABcZeBPB0Z+8z6eWVBn3aKTC4yroumPQQ_TMO72qsXJPVrFOQw@mail.gmail.com> <C4EB2B22-2936-487F-8A72-EEBCAFB89559@verisign.com> <CABcZeBN6K_qfe+VEyAX15Hi_vjQ91oLwbbUh1myDAacEuZmztQ@mail.gmail.com> <599DDE8F-8D04-4AA8-99E6-7675C6A8D46D@verisign.com> <CABcZeBMPfdn+dXDUxUaZnYbRjzjKqYVs-=Tz348fTfW62c6aww@mail.gmail.com> <1920908C-88D4-4E1E-9620-029443DE6357@verisign.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 12 Dec 2017 11:25:27 -0800
Message-ID: <CABcZeBO2Ystt+oV_VXcPCnJ4WAyX3q+cz4BG_So7ipPg7Q29zg@mail.gmail.com>
To: "Gould, James" <jgould@verisign.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-regext-launchphase@ietf.org" <draft-ietf-regext-launchphase@ietf.org>, Ulrich Wisser <ulrich@wisser.se>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" <regext@ietf.org>
Content-Type: multipart/related; boundary="94eb2c086896783f3b0560299f35"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/7Xj7OZldXnXQWunUcNAaRygi82c>
Subject: Re: [regext] Eric Rescorla's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Dec 2017 19:26:14 -0000
Is there a reason you can't say that in the document? -Ekr On Tue, Dec 12, 2017 at 11:19 AM, Gould, James <jgould@verisign.com> wrote: > Eric, > > > > The extension supports multiple launch phases and multiple models to > enable the servers to support their TLD launches. What is supported and > what is validated is up to server policy, is currently communicated > out-of-band, and can be included in a separate in-band policy extension > (e.g., draft-ietf-regext-launchphase-policy) created for that purpose. > > > > Thanks, > > > > — > > > > JG > > > [image: id:image001.png@01D255E2.EB933A30] > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 <(703)%20948-3271> > 12061 Bluemont Way > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *Eric Rescorla <ekr@rtfm.com> > *Date: *Tuesday, December 12, 2017 at 2:10 PM > *To: *James Gould <jgould@verisign.com> > *Cc: *The IESG <iesg@ietf.org>, "draft-ietf-regext-launchphase@ietf.org" < > draft-ietf-regext-launchphase@ietf.org>, Ulrich Wisser <ulrich@wisser.se>, > "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" < > regext@ietf.org> > *Subject: *[EXTERNAL] Re: Eric Rescorla's No Objection on > draft-ietf-regext-launchphase-06: (with COMMENT) > > > > OK, but there's no way to identify "no validation data" and that's > confusing to the reader. > > > > -Ekr > > > > > > On Tue, Dec 12, 2017 at 9:14 AM, Gould, James <jgould@verisign.com> wrote: > > Eric, > > > > >OK. Do you think you could add some text saying that validation is > currently required. It confused me. > > > > I believe attempting to add text saying that validation is required will > add more confusion (who validates, what’s validated) and is out-of-scope > for an extension that passes information between a client and server that > may have been validated by a 3rd party. The extension provides the > capability of passing validated data but it does not require explicit > validation to be performed. > > > > Thanks, > > > > — > > > > JG > > > > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 <(703)%20948-3271> > 12061 Bluemont Way > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *Eric Rescorla <ekr@rtfm.com> > *Date: *Monday, December 11, 2017 at 6:37 PM > *To: *James Gould <jgould@verisign.com> > *Cc: *The IESG <iesg@ietf.org>, "draft-ietf-regext-launchphase@ietf.org" < > draft-ietf-regext-launchphase@ietf.org>, Ulrich Wisser <ulrich@wisser.se>, > "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" < > regext@ietf.org> > *Subject: *[EXTERNAL] Re: Eric Rescorla's No Objection on > draft-ietf-regext-launchphase-06: (with COMMENT) > > > > > > > > On Mon, Dec 11, 2017 at 3:17 PM, Gould, James <jgould@verisign.com> wrote: > > Eric, > > > > In reviewing the threads, I noticed that I missed your open question “How > do you say in the protocol that no validation is wanted.” > > > > I’ll lead with restating that the requirement for validation depends on > the launch phases used by the server and the models chosen by the server > for those launch phases, which is referred to as server policy. The launch > phases and models chosen by the server is currently not defined by the > protocol and currently needs to be communicated out-of-band. The WG is > going to discuss a framework (Registry Mapping and Registry Policy > Extensions) to communicate the server policies in-band to EPP that should > include a policy extension for draft-ietf-regext-launchphase (e.g., > draft-ietf-regext-launchphase-policy). The short answer is that the > protocol may say that no validation is wanted in the future but outside of > draft-ietf-regext-launchphase. > > > > OK. Do you think you could add some text saying that validation is > currently required. It confused me. > > > > -Ekr > > > > > > Thanks, > > > > — > > > > JG > > > > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 <(703)%20948-3271> > 12061 Bluemont Way > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *Eric Rescorla <ekr@rtfm.com> > *Date: *Tuesday, December 5, 2017 at 4:40 PM > *To: *James Gould <jgould@verisign.com> > *Cc: *The IESG <iesg@ietf.org>, "draft-ietf-regext-launchphase@ietf.org" < > draft-ietf-regext-launchphase@ietf.org>, Ulrich Wisser <ulrich@wisser.se>, > "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" < > regext@ietf.org> > *Subject: *[EXTERNAL] Re: Eric Rescorla's No Objection on > draft-ietf-regext-launchphase-06: (with COMMENT) > > > > > > > > On Tue, Dec 5, 2017 at 1:34 PM, Gould, James <jgould@verisign.com> wrote: > > Eric, > > > > My replies are included below. > > > > — > > > > JG > > > > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 <(703)%20948-3271> > 12061 Bluemont Way > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *Eric Rescorla <ekr@rtfm.com> > *Date: *Tuesday, December 5, 2017 at 4:02 PM > *To: *James Gould <jgould@verisign.com> > *Cc: *The IESG <iesg@ietf.org>, "draft-ietf-regext-launchphase@ietf.org" < > draft-ietf-regext-launchphase@ietf.org>, Ulrich Wisser <ulrich@wisser.se>, > "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" < > regext@ietf.org> > *Subject: *[EXTERNAL] Re: Eric Rescorla's No Objection on > draft-ietf-regext-launchphase-06: (with COMMENT) > > > > > > > > On Tue, Dec 5, 2017 at 12:02 PM, Gould, James <jgould@verisign.com> wrote: > > Eric, > > > > Thanks again, I provide answers embedded below. > > > > — > > > > JG > > > > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 <(703)%20948-3271> > 12061 Bluemont Way > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *Eric Rescorla <ekr@rtfm.com> > *Date: *Monday, December 4, 2017 at 6:39 PM > *To: *James Gould <jgould@verisign.com> > *Cc: *The IESG <iesg@ietf.org>, "draft-ietf-regext-launchphase@ietf.org" < > draft-ietf-regext-launchphase@ietf.org>, Ulrich Wisser <ulrich@wisser.se>, > "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" < > regext@ietf.org> > *Subject: *[EXTERNAL] Re: Eric Rescorla's No Objection on > draft-ietf-regext-launchphase-06: (with COMMENT) > > > > > > > > On Mon, Dec 4, 2017 at 3:03 PM, Gould, James <jgould@verisign.com> wrote: > > Eric, > > Thank you for the review. Below are my answers to your feedback. > > — > > JG > > > > James Gould > Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 11/29/17, 2:20 PM, "Eric Rescorla" <ekr@rtfm.com> wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-regext-launchphase-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > qualified by the previously assigned application identifier using > the > <launch:applicationID> element. > Maybe I'm not following, but you say above that launch phase is FCFS, > but then > how do multiple applications work? > > A Launch Registration is a domain name registration during a launch phase > when the server uses a "first-come, first-served" model. Only a single > registration for a domain name can exist in the server at a time. > > Launch Application represents the intent to register a domain name during > a launch phase when the server accepts multiple applications for a domain > name and the server later selects one of the applications to allocate as a > registration. Many Launch Applications for a domain name can exist in the > server at a time. > > The application identifier is used for Launch Applications to different > between the multiple applications for the same domain name. > > > > OK. Thanks. > > > > > > not used or multiple Trademark Validators are used, the Validator > Identifier MUST be defined using the "validatorID" attribute. > Does this mean that you must use some validator? > > The lack of the “validatorID” attribute or the reserved “tmch” > “validatorID” value can be used to indicate that the ICANN TMCH is being > used. A value other than empty or “tmch” is used to specify some custom > validator. Any element that supports the “validatorID” is associated with > a validator whether explicitly or implicitly. > > > > So, what if I don't want to validate at all. > > > > The elements associated with the “validatorID” attribute are related to > performing validation. The elements that support the “validatorID” > attribute include: > > > > 1. <launch:code> - The “validatorID” is used to identify the > Trademark Validator that code originated from. > > 2. <launch:claimKey> - The “validatorID” indicates the Trademark > Validator to query for the Claims Notice information. > > 3. <launch:noticeID> - The “validatorID” indicates which Trademark > Validator is the source of the claims notice. > > > > I'm not sure that this addresses the question I was asking. Namely, is it > necessary to provide some validation? > > > > The requirement for validation depends on the launch phases used by the > server and the models chosen by the server for those launch phases. The > protocol supports multiple launch phases and models that may include > validation. > > > > How do you say in the protocol that no validation is wanted. > > > > > > > > The following launch phase values are defined: > Nit: you say that these are launch phase values but then below define > things as > non-launch phase. > > I don’t see where the launch phase values define things as non-launch > phase. Can you provide a reference to a non-launch phase? > > > > " open A post-launch phase that is also referred to as "steady state". > > Servers MAY require additional trademark protection during this > > phase. > > " > > > > Yes, technically the “open” phase may not be considered as a launch phase, > but it is best to be included since it’s a common final state in launching > a TLD. > > > > Maybe modify the prefatory text? > > > > How about simply changing “A post-launch phase…” to be “A phase…”? There > is really no reason to define it as a post-launch phase, since it is a > launch phase that may be the final launch phase. > > > > This LGTM. > > > > -Ekr > > > > > > > > > > Claims Check Form Claims Check Form (Section 3.1.1) is used to > determine whether or not there are any matching trademarks for a > You seem to have duplication here. > > Thanks, that can be taken care of. > > retrieving the claims information. > Claims Create Form Claims Create Form (Section 3.3.2) is used to > pass the Claims Notice acceptance information in a create > command. > And here. > > Thanks, that can be taken care of. > > schema for the encoded signed mark that has an element that > substitutes for the <smd:encodedSignedMark> element from [RFC7848]. > I know that 7848 defines signedMark, but probably a good idea to say > you have > to validate it. > > The information provided by the client for all elements can be validated > using a namespace-aware XML parser. I don’t believe there is anything > unique with the <smd:encodedSignedMark> to warrant extra validation > language. > > > > I mean "validate the signature". > > > > You mean in section 2.6.3 “Digital Signature” to add the sentence “When > using digital signatures the server SHOULD validate the digital signature.” > to the end of the paragraph? The digital signatures apply to both the > <smd:signedMark>, <smd:encodedSignedMark>, and substitutes of both. > > > > Surely this is a MUST. > > > > Ok, I believe whether it’s a SHOULD or a MUST, it would need to go through > the working group. The proposal would then be to add the sentence “When > using digital signatures the server MUST validate the digital signature.” > to the end of the 2.6.3 “Digital Signature” paragraph. > > > > > > C: xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0"> > C: ... > C: </smd:encodedSignedMark> > I am assuming the base64 goes here. Could you indicate that a bit more > clearly > than ... somehow? > > RFC 7848 can support other encodings other than “base64” using the > “encoding” attribute, and a new encodedSignedMark type can be included by > substituting for the <smd:encodedSignedMark> element. > draft-ietf-regext-launchphase references RFC 7848 to support a concrete > encodedSignedMark and provides the extensibility to define new > encodedSignedMark’s. The “…” is used to allow for the definition of the > encodedSignedMark to be defined in RFC 7848 or a new draft that substitutes > for the <smd:encodedSignedMark> element. I believe that it’s best to > reference RFC 7848 in this case. > > > > OK. I just don't think that "..." is very clear, so I was hoping for some > text or something else to show what goes here. > > > > How about adding the following sentence ‘The use of “…” is used as > shorthand for elements defined outside this document.’ to the “In > examples, …” paragraph of section 1.1 “Conventions Used in This Document”? > > > > LGTM. > > > > -Ekr > > > > > > > > > > > > > > > > > > > > >
- [regext] Eric Rescorla's No Objection on draft-ie… Eric Rescorla
- Re: [regext] Eric Rescorla's No Objection on draf… Gould, James
- Re: [regext] Eric Rescorla's No Objection on draf… Eric Rescorla
- Re: [regext] Eric Rescorla's No Objection on draf… Gould, James
- Re: [regext] Eric Rescorla's No Objection on draf… Eric Rescorla
- Re: [regext] Eric Rescorla's No Objection on draf… Gould, James
- Re: [regext] Eric Rescorla's No Objection on draf… Adam Roach
- Re: [regext] Eric Rescorla's No Objection on draf… Eric Rescorla
- Re: [regext] Eric Rescorla's No Objection on draf… Eric Rescorla
- Re: [regext] Eric Rescorla's No Objection on draf… Gould, James
- Re: [regext] Eric Rescorla's No Objection on draf… Eric Rescorla
- Re: [regext] Eric Rescorla's No Objection on draf… Gould, James
- Re: [regext] Eric Rescorla's No Objection on draf… Eric Rescorla
- Re: [regext] Eric Rescorla's No Objection on draf… Gould, James
- Re: [regext] Eric Rescorla's No Objection on draf… Eric Rescorla
- Re: [regext] Eric Rescorla's No Objection on draf… Gould, James
- Re: [regext] Eric Rescorla's No Objection on draf… Hollenbeck, Scott
- Re: [regext] Eric Rescorla's No Objection on draf… Gould, James
- Re: [regext] Eric Rescorla's No Objection on draf… Eric Rescorla
- Re: [regext] Eric Rescorla's No Objection on draf… Gould, James
- Re: [regext] Eric Rescorla's No Objection on draf… Eric Rescorla
- Re: [regext] Eric Rescorla's No Objection on draf… Gould, James
- Re: [regext] Eric Rescorla's No Objection on draf… Andrew Newton