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 [id:[email protected]] James Gould Distinguished Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Eric Rescorla <[email protected]> Date: Monday, December 11, 2017 at 6:37 PM To: James Gould <[email protected]> Cc: The IESG <[email protected]>, "[email protected]" <[email protected]>, Ulrich Wisser <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 [cid:[email protected]] James Gould Distinguished Engineer [email protected]<http://[email protected]> 703-948-3271<tel:(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 <[email protected]<mailto:[email protected]>> Date: Tuesday, December 5, 2017 at 4:40 PM To: James Gould <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Ulrich Wisser <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: Eric, My replies are included below. — JG [cid:[email protected]] James Gould Distinguished Engineer [email protected]<http://[email protected]> 703-948-3271<tel:(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 <[email protected]<mailto:[email protected]>> Date: Tuesday, December 5, 2017 at 4:02 PM To: James Gould <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Ulrich Wisser <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: Eric, Thanks again, I provide answers embedded below. — JG [cid:[email protected]] James Gould Distinguished Engineer [email protected]<http://[email protected]> 703-948-3271<tel:(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 <[email protected]<mailto:[email protected]>> Date: Monday, December 4, 2017 at 6:39 PM To: James Gould <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Ulrich Wisser <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: Eric, Thank you for the review. Below are my answers to your feedback. — JG James Gould Distinguished Engineer [email protected] 703-948-3271<tel: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" <[email protected]<mailto:[email protected]>> 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
