Subject: Re: [regext] AD Review: draft-ietf-regext-launchphase-05

From: "Gould, James" <[email-masked]>
Date: Wed, 2 Aug 2017 18:40:53 +0000

Adam,

Thank you for the review and feedback.  I provide a response to your feedback embedded below with a “JG – “ prefix.  I can post draft-ietf-regext-launchphase-06 once there is agreement to the set of changes.

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 7/25/17, 11:18 PM, "Adam Roach" <[email-masked]> wrote:

    EPP Launchphase Authors --
    
    This is my AD review of draft-ietf-regext-launchphase-05.
    
    I have a number of questions and comments about the draft, although I 
    freely admit that many of them may stem from a lack of knowledge on my 
    part about the operational models in which EPP is deployed. Please bear 
    with me on those points. Comments are in document order, and constitute 
    a mix of substantive and minor editorial comments.
    
    As a general comment, I believe the document could benefit from either 
    some introductory text about how claims operate or a pointer to a 
    document that explains how they operate. I skimmed the documents cited 
    in the references section and couldn't easily locate information along 
    these lines.

JG – Section 2.3.1 “Trademark Claims Phase” was added in draft-ietf-regext-launchphase-02 to remove the reference to draft-ietf-regext-tmch-func-spec and briefly describe the trademark claims phase.  Please indicate any information from draft-ietf-regext-tmch-func-spec that would help provide clarity without having to add the reference back to draft-ietf-regext-tmch-func-spec.
    
    The introduction talks about "registrations" and "applications" without 
    defining what these terms mean or citing a definition. As far as I can 
    tell, EPP does not define these terms, and I'm having a hard time 
    figuring out the difference. It's probably worth adding a few words in 
    section 1.1 that talks about these terms (and, in particular, indicates 
    that "application" in this context is very different from how that term 
    is generally used in computer science).
    
JG-An attempt was made to differentiate a Launch Application from a Launch Registration in the Introduction with “…registries often accept multiple application for the same domain name during the “Sunrise” launch phase, referred to as a Launch Application.  A Launch Registration refers to a registration made during a launch phase when the server uses a first-come, first-served model”.  A more formal definition can be added to section 1.1 for a Launch Application and a Launch Registration to clarify it further.  How about the following definitions?
  “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.”
   “A 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 can exist in the server at a time.”

    Section 2.2 indicates that the Validator Identifier and Issuer 
    Identifier must be unique; however, it's not clear how this uniqueness 
    is enforced. Is there a registry somewhere? Are these derived from some 
    previously allocated identifiers? Are UUIDs expected? Or is it expected 
    that the community simply self-organizes to achieve this somehow? I 
    think this document needs to clearly state how this uniqueness is 
    expected to happen.

JG-The uniqueness of the “validatorID” is associated within a specific server (registry), so it is enforced by the servers (registries) that accept them.  For example, if a registry supports the default “tmch” Validator Identifier, it could define the requirement for another validator to be used, where the registry would enforce that the validator identifier of the additional validator is unique.  The server policy would define the accepted set of validators and their associated validator identifiers.  I added some additional language to section 2.2 like “The Validator Identifier is the identifier, that is unique to the server, for …” and “The unique set of Validator Identifier values supported by the server is up to server policy”.  Do you agree with this update?
    
    The sequence diagram in Figure 1 has an unlabeled response (to the left 
    of "Does Domain have Claims?") -- this should  indicate what kind of 
    information is being conveyed to the client.

JG-With both the “No” and “Yes” branch from the “Does Domain have Claims?” decision node, the Domain Claims Check Response is returned.  The Domain Claims Check Response will include a Boolean value of indicating whether claims (trademarks) exist and a claims key if a claims (trademarks) do exist.  Maybe to clarify this, the label for the “No” branch can be set to “Claims Don’t Exist” and the “Yes” branch label can be changed from “Claims Key” to “Claims Exist with Claims Keys”.  Do you believe that is better?  
    
    The <launch:applicationID> and <launch:status> elements on page 13 are 
    indented further than one would normally expect. The same goes for the 
    <launch:status> element on page 14.

JG-Done
    
    The final paragraph of section 2.6 indicates that multiple instances of 
    certain elements MAY be supported by a server, without indicating how 
    such support might be indicated or negotiated. Minimally, I'd expect to 
    see a unique status code here that allows the client to determine that 
    the server does not support such multiplicity, and that the lack of such 
    support is why a message was rejected. Ideally, there would be some 
    proactive indication of support before the message is sent, but I don't 
    know enough about EPP to determine whether this is reasonable.
    
JG-The method for providing more than one <launch:codeMark>, <smd:signedMark> or <smd:encodedSignedMark> is better described in section 3.3.1 “Sunrise Create Form”.  The last paragraph may just add confusion, so my recommendation is to remove it.  The number of code, marks, and signed marks supported is up to server policy and the best mechanism to communicate that policy in a separate server policy object extension.  This is similar to the discussion around communicating the schedule of launch phases.  You can find an example object extension (Registry Mapping) for the purpose of communicating the zones (TLDs) available to the client and the features and policies supported by the server at https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html.  Such a policy object extension can be extended (Launch Phase Policy Extension or Registry Fee Policy Extension) to define the policies of extensions like the Launch Phase extension and the Registry Fee Extension.  A command-response extension like the Launch Phase Extension does not provide the framework to support defining server policy.  Let me know whether removing the last paragraph of section 2.6 makes sense and whether additional language needs to be added to section 3.3.1 for clarification.      

    Section 3.1 has language indicating that the server "SHOULD validate the 
    value against the active server launch phase." Minor comment: shouldn't 
    this be "launch phase(s)"? More substantive comment: If such validation 
    fails, the server presumably rejects the request? I'd like to see this 
    stated explicitly, and to indicate which response code is used for such 
    a rejection.

JG –I assume that you’re referring to the description of the <launch:phase> element in section 3.1.1.  The <launch:phase> element is used across multiple commands, so it may be best to update the expected validation behavior centrally in section 2.3 “Launch Phases”.  There is already a description of the validation in the first paragraph of section 2.3, where a 2306 EPP error result code is returned.  How about updating the first paragraph of section 2.3 to be more generic by not just applying to a create command and using a MUST for returning the 2306 EPP result code if there is a mismatch?  Then update any references to the <launch:phase> element in the commands to state “The server SHOULD validate the value according to section 2.3.“ when comparing against the active launch phases.  Some of the commands like Check Command using the Availability Check Form, the Info Command, the Update Command, and the Delete Command refer to future or past phases, so I explicitly added the text “The server SHOULD validate the value and return an EPP error result code of 2306 if it is invalid.”.  Do you agree with these updates?   
    
    Section 3.1.3 indicates that availability MUST NOT be returned when a 
    trademark check is performed. It's not clear why this restriction is in 
    place, and it would seem to make scaling more difficult (as clients 
    desiring both sets of information need to launch two requests). I'd like 
    to see some explanation in the document why this restriction is desirable.
    
JG-The reason why is that the Trademark Check Form defines a new command called the Trademark Check Command.  Its purpose is separate and distinct from an available check, where the Trademark Check Command is answering the question of whether there is a trademark associated with the domain name independent on the active launch phase and independent on the availability of the domain name.  The language exists for the Claims Check Form in creating a Claims Check Command.  As you’ll notice in both cases (Trademark Check Command and Claims Check Command), the response does not include the <domain:chkData> which greatly simplifies the response.  The language matches the XML schema definition and the examples.  The Availability Check Form in section 3.1.2 does not define a new command and appropriately mixes the domain check command with launch phase logic.  I’m not sure whether additional language is needed to describe why mixing commands with different purposes is not allowed, but I’m open to providing it if needed.       

    Section 3.2: "The Application Identifier (Section 2.1) returned in the 
    <launch:creData> element of the create response (Section 3.3) is used 
    for retrieving information for a Launch Application." This makes such 
    use sound mandatory, which I don't think it is. Would rephrase as 
    "...can be used for retrieving..."
    
JG-Done

    Section 3.2: "<mark:mark>  Zero or more <mark:mark> (Section 2.6.2) 
    elements" -- I would qualify this with "only if 'includeMark' is 
    indicated in the client response" or something similar.

JG – I updated it to read “Zero or more <mark:mark> (Section 2.6.2.) elements only if the “includeMark” attribute is “true” in the command.”  Do you agree with this update?
    
    Section 3.3.1 says the server should validate the "type" attribute in 
    the request. If such validation fails, the server presumably rejects the 
    request? I'd like to see this stated explicitly, and to indicate which 
    response code is used for such a rejection.
    
JG-I modified it to “The server SHOULD validate the "type" attribute, when passed, against the type of object that will be created, and return an EPP error result code of 2306 if the type is incorrect.”  Do you agree with this update?

    Section 3.3.1: How does a client know which of the four different 
    approaches are supported by the server? Minimally, I'd expect to see a 
    unique status code here that allows the client to determine that the 
    model it has selected is not supported by the server, and that the lack 
    of such support is why a message was rejected (preferably with some 
    indication of which model *is* supported). Ideally, there would be some 
    proactive indication of support before the message is sent, but I don't 
    know enough about EPP to determine whether this is reasonable.

JG-The approach supported by the server is defined by registry policy. The launch phase extension provides the interface to support the various launch phases and registry policies, and the policies are either defined out-of-band of EPP or in an EPP extension designed for that purpose like the Registry Mapping ( https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html ).  
    
    Page 31 contains an example that uses an unsigned <mark:mark> section 
    containing Trademark information without any unique identification. How 
    does this work? For example: who is allowed to claim what? This would 
    seem to require some explanation and possibly some text in section 7.

JG- In section 2.6 “Mark Validation Models”, it states “The mark information is passed without any other validation element.  The server will use some custom form of validation to validate that the mark information is authentic.”  The launch phase extension simply enables the passing of the mark without dictating the method that the server validates it (validate directly, validate via API or data feed from an external validator, etc.).     Do you want to add something like this in section 7?   
    
    Section 3.3.2: Same question about type validation as for Section 3.3.1, 
    above.
    
JG-I added “, and return an EPP error result code of 2306 if the type is incorrect” to the end of the sentence like 3.3.1.  Do you agree with this update?

    Section 3.3.3: Same question about phase validation as for section 3.1, 
    above.
    
JG-I added “, and return an EPP error result code of 2306 if the type is incorrect” to the end of the sentence like 3.3.1.  Do you agree with this update?

    Section 3.3.4: If the server does not support Mixed Create forms, how 
    does the client determine this? Minimally, I'd expect to see a unique 
    status code here that allows the client to determine that the server 
    does not support this form, and that the lack of such support is why a 
    message was rejected. Ideally, there would be some proactive indication 
    of support before the message is sent, but I don't know enough about EPP 
    to determine whether this is reasonable.
    
JG-The approach supported by the server is defined by registry policy. The launch phase extension provides the interface to support the various launch phases and registry policies, and the policies are either defined out-of-band of EPP or in an EPP extension designed for that purpose like the Registry Mapping ( https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html ).  

    Section 3.3.5: It is easy to read "...MAY reply with..." as saying that 
    a reply is optional. I don't get the impression that this is the 
    intention, however; I suspect the intention is that the addition of a 
    <launch:creData> to the (required) reply is optional. Suggest rephrasing 
    along the lines of "...server MAY add a <launch:creData> element to the 
    regular EPP <resData>..."
    
JG-Done

    Page 46 contains literal &qt; and &gt; strings. Comment 1: shouldn't 
    these just be < and > or quotes? Comment 2: If not, I'll point out that 
    &qt; is not an XML escape sequence: you probably either mean &quot; (and 
    want the &gt; to be &quot;) or you mean &lt;.

JG-Done, this had to be changed to just use “.
    
    Section 5.1: Please set the registrant information to the IESG.

JG-Done
    
    Section 7: The first paragraph appears to start with an extraneous "As".

JG-I believe you meant the last paragraph.  I changed “As information” to “Information” to start the last paragraph of section 7.  
    
    Thanks!
    
    /a

---

From: Adam Roach <[email-masked]>
Date: Wed, 2 Aug 2017 13:50:35 -0500

James --

Thank you for your detailed response. I am occupied through the end of 
the week, and plan to read through your proposed changes in depth next week.

/a

On 8/2/17 1:40 PM, Gould, James wrote:
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Aug 2017 18:22:15 -0500

Sorry for taking a while to get back to this. Responses inline.

> Thank you for the review and feedback.  I provide a response to your feedback embedded below with a “JG – “ prefix.  I can post draft-ietf-regext-launchphase-06 once there is agreement to the set o…

I see that the reference in -01 was normative, and I assume it was 
removed to avoid any unnecessary dependencies. Is there any reason you 
couldn't add a statement in section 2.3.1 along the lines of "See 
[I-D.ietf-regext-launchphase] for additional details of trademark claims 
handling"? That would make it an informative reference, and wouldn't 
create a publication dependency.

>     “A 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 t…

That would be great. Thanks.

> JG-The uniqueness of the “validatorID” is associated within a specific server (registry), so it is enforced by the servers (registries) that accept them.  For example, if a registry supports the de…

Ah, it was the scoping here that I didn't understand. Yes, that makes it 
clearer.

> JG-With both the “No” and “Yes” branch from the “Does Domain have Claims?” decision node, the Domain Claims Check Response is returned.  The Domain Claims Check Response will include a Boolean valu…

Yes, thanks.

> JG-The method for providing more than one <launch:codeMark>, <smd:signedMark> or <smd:encodedSignedMark> is better described in section 3.3.1 “Sunrise Create Form”.  The last paragraph may just add…

Your explanation makes sense, and I suspect this is one of the areas 
that falls into the lack of my knowledge around the operational models 
EPP is deployed in. If the use of these policy objects is generally well 
known by anyone who will be using EPP, then I think the existing text is 
fine.

> JG –I assume that you’re referring to the description of the <launch:phase> element in section 3.1.1.  The <launch:phase> element is used across multiple commands, so it may be best to update the e…

Yes, those sound good. Thanks.

> JG-The reason why is that the Trademark Check Form defines a new command called the Trademark Check Command.  Its purpose is separate and distinct from an available check, where the Trademark Check…

The simplicity argument makes sense to me. I'm happy if you elect not to 
add text here.

> JG – I updated it to read “Zero or more <mark:mark> (Section 2.6.2.) elements only if the “includeMark” attribute is “true” in the command.”  Do you agree with this update?

Sound good. Thanks.

> JG-I modified it to “The server SHOULD validate the "type" attribute, when passed, against the type of object that will be created, and return an EPP error result code of 2306 if the type is incorr…

Sounds good. Thanks.

> JG-The approach supported by the server is defined by registry policy. The launch phase extension provides the interface to support the various launch phases and registry policies, and the policies…

Thanks -- seems like the same question regarding allowed ordinality of 
elements, above. No change is needed.

> JG- In section 2.6 “Mark Validation Models”, it states “The mark information is passed without any other validation element.  The server will use some custom form of validation to validate that the…

No, I had simply missed the "custom form of validation." Given that this 
is effectively saying it's out of scope of this document, I'm not sure 
what section 7 could say other than "the custom forms of validation need 
to be secure," but that's so general as to be useless.

> JG-I added “, and return an EPP error result code of 2306 if the type is incorrect” to the end of the sentence like 3.3.1.  Do you agree with this update?

Sounds good.

> JG-I added “, and return an EPP error result code of 2306 if the type is incorrect” to the end of the sentence like 3.3.1.  Do you agree with this update?

Sounds good.

> JG-The approach supported by the server is defined by registry policy. The launch phase extension provides the interface to support the various launch phases and registry policies, and the policies…

Thanks. No change is needed here.

Go ahead and submit a -06 version with your proposed changes, and I'll 
get into IETF last call. Thanks!

/a

---

From: "Gould, James" <[email-masked]>
Date: Mon, 21 Aug 2017 16:00:29 +0000

Adam,

My responses to your feedback is embedded below with a “JG-“ prefix.  I highlight which items are addressed in the soon to be published draft-ietf-regext-launchphase-06.  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 8/18/17, 7:22 PM, "Adam Roach" <[email-masked]> wrote:

    
    
JG-Addressed in draft-ietf-regext-launchphase-06 with ‘Added an informative reference to draft-ietf-regext-tmch-func-spec in section 2.3.1 "Trademark Claims Phase". ‘.   I don’t have an issue adding the reference back if it doesn’t create a dependency issue for publication.  We did pull some information from draft-ietf-regext-tmch-func-spec into draft-ietf-regext-launchphase to remove the dependency.  I assume that we keep the pulled in information and simply add the reference to draft-ietf-regext-tmch-func-spec back to the draft as an informative reference.  

JG-Addressed in draft-ietf-regext-launchphase-06 with “Added formal definition of a Launch Registration and Launch Application to section 1.1.”. 

JG-Addressed in draft-ietf-regext-launchphase-06 with “Updated the description of the Validator Identifier to indicate that the uniqueness is based on server policy.”.

    Yes, thanks.

JG-Addressed in draft-ietf-regext-launchphase-06 with ‘Updated "Does Domain have Claims?" "No" and "Yes" branch labels in Figure 1.’.  

    
JG-No action for draft-ietf-regext-launchphase-06.

JG- Addressed in draft-ietf-regext-launchphase-06 with “Updated the description of the <launch:phase> element in the commands to explicitly specify the return of a 2306 EPP error result when invalid or referring to section 2.3 for validation”.

JG-No action for draft-ietf-regext-launchphase-06.

    Sound good. Thanks.

JG- Addressed in draft-ietf-regext-launchphase-06 with “Updated the description of the <mark:mark> element in the info response.”. 

    Sounds good. Thanks.

JG- Addressed in draft-ietf-regext-launchphase-06 with “Added returning an EPP error result code of 2306 if the "type" attribute is incorrect in section 3.3.1, 3.3.2, and 3.3.3.”    

JG-No action for draft-ietf-regext-launchphase-06.    

JG-No action for draft-ietf-regext-launchphase-06.

    Sounds good.

JG- Addressed in draft-ietf-regext-launchphase-06 with “Added returning an EPP error result code of 2306 if the "type" attribute is incorrect in section 3.3.1, 3.3.2, and 3.3.3.”    
    
    Sounds good.

JG- Addressed in draft-ietf-regext-launchphase-06 with “Added returning an EPP error result code of 2306 if the "type" attribute is incorrect in section 3.3.1, 3.3.2, and 3.3.3.”        

JG-No action for draft-ietf-regext-launchphase-06.

    /a