Subject: [regext] Ben Campbell's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Nov 2017 12:30:18 -0800

Ben Campbell 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:
----------------------------------------------------------------------

Substantive Comments:

-2.2, 2nd to last paragraph: "Both the Validator Identifier and the Issuer ot
Identifier used MUST be unique."
At what scope must they be unique? Can you offer guidance on how to ensure
uniqueness?

-2.2, last paragraph:
I don't understand what is meant by this paragraph. Please elaborate.

-2.4, paragraph after definitions: "The OPTIONAL "lang" element MAY be
present..." Why is this only a MAY? Is it really reasonable to leave out the
language tag for non-English languages?

-2.4, 3rd to last paragraph:
Why does the custom status value exist if the server should not use it? Are
there cases where a client uses it?

-3.4, 2nd paragraph, first sentence: Is a client expected to know in advance
whether the server supports launch applications? If so, how?

Editorial Comments:

- There are lowercase instances of 2119 keywords. I assume those are not meant
as normative keywords. If so, please consider using the boilerplate from RFC
8174 instead of 2119.

- General: I urge a pass to check the use of 2119/8174 keywords. I think there
may be some instances where the author typed words in upper case from habit
where the keywords don't make sense.  I point out some of these below, but I
suspect I did not get all of them.

-1-1, 3rd paragraph: "REQUIRED" seems like a statement of fact.

-2.2, first sentence: s/that/which

-2.3, definitions: Please consider avoiding 2119 keywords in definitions? As
written, they read more like statements of fact than normative requirements.
(Please feel free to ignore this, since it is really a style issue.) Also,
please try to add white space between hanging indent list entries. They are
hard to read when run together. (Same for other definition sections.)

-2.3, last paragraph: Please avoid 2119 keywords in examples.

-2.3.1: The "MUST" and "MAY" seem like statements-of-fact.

-2.4, 2nd to last paragraph: 2119 keywords in examples.

-2.6.1, first paragraph: The "that" might should be a "which". But it's not
clear to me whether the word is intended to constrain which codemark elements
are being discussed ("that") , or to just mention that codemark elements are
used in those models. ("which")

---

From: "Gould, James" <[email-masked]>
Date: Thu, 30 Nov 2017 00:17:12 +0000

Ben,

Thank you for the review.  I include the responses to your feedback embedded below.

Thanks,

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On 11/29/17, 12:30 PM, "Ben Campbell" <[email-masked]> wrote:

    
    
    Substantive Comments:

The scope of uniqueness is at the server-level, where “tmch” is reserved.  If a server supports additional validators, the “server MUST define the list of supported validator identifiers and MUST make this information available to clients using a mutually acceptable, out-of-band mechanism.”  Hopefully, this answers you question. 
    
    -2.2, last paragraph:

I assume that you’re referring to “The Validator Identifier MAY define a non-Trademark Validator that supports a form of claims.”.  The concept of claims and a Validator Identifier is based on the use of a Trademark Validator, but it is understood that other forms for validators MAY develop that go beyond trademarks.  

The use of the “lang” attribute is based on what has been done in RFC 5731 (normative).  

The custom status value is defined to support corner cases and is not recommended using SHOULD NOT of RFC 2119?  

The client is expected to know based on either an out-of-band mechanism, or an in-band mechanism that is being discussed now within the REGEXT working group.   
    
    Editorial Comments:

Thanks, this can be reviewed and cleaned up.  

This language is based on the EPP RFC 5730 (1.1) and RFC 5731 (1.2) language.

Thanks, I agree.

Thanks, this can be looked at.

You are referring to the last sentence of 2.3 “For example, the <launch:phase> element SHOULD be <launch:phase name="landrush">claims</launch:phase>.”?  I agree that SHOULD can be lowercase should here. 

You are referring to “The Trademark Claims Phase is when a Claims Notice MUST be displayed to a prospective registrant of a domain name that matches trademarks.”, where MUST can be lowercase must”, and “Claim Notice Information Service (CNIS), which MAY be directly linked to a Trademark Validator.”, where MAY can be lowercase may?  I agree these are more descriptive than directional.  

You are referring to “For example, an application or registration MAY immediately start at the "allocated" status or an application or registration MAY skip the "pendingAllocation" status.”?, where both MAYs can be lowercase mays?  

I believe “that” can be removed from “The <launch:codeMark> element that is used by the "code", "mark", and "code with mark" validation models, has the following child elements:”.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Nov 2017 18:32:59 -0600

Thanks for your quick response. Please see inline:

Thanks!

Ben.

> On Nov 29, 2017, at 6:17 PM, Gould, James <[email-masked]> wrote:
> 
> Ben,
> 

[…]

> The scope of uniqueness is at the server-level, where “tmch” is reserved.  If a server supports additional validators, the “server MUST define the list of supported validator identifiers and MUST m…

Would it be reasonable to say, near the uniqueness requirement, that that the identifiers need to be unique for a particular server? (I assume this means that two servers do not need to use the same ID for the same validator).

> I assume that you’re referring to “The Validator Identifier MAY define a non-Trademark Validator that supports a form of claims.”.  The concept of claims and a Validator Identifier is based on the…

Adding text to that effect would be helpful. (except for the upper case MAY, since I think it’s a statement of fact.)

> The use of the “lang” attribute is based on what has been done in RFC 5731 (normative).

Sure, but do you think it’s reasonable to leave out the tag? Allowing that in 5731 might not have been the best precedent.

> The custom status value is defined to support corner cases and is not recommended using SHOULD NOT of RFC 2119?

Are there corner cases you have in mind? As written, that seems to say “here’s an extension point, but we hope you won’t use it”. Is the point that people SHOULD NOT use it for cases where an existing status value would be appropriate?

> The client is expected to know based on either an out-of-band mechanism, or an in-band mechanism that is being discussed now within the REGEXT working group.

It would help to say something to that effect in the text.

[  I leave resolution of my editorial comments to your discretion.]

---

From: "Gould, James" <[email-masked]>
Date: Thu, 30 Nov 2017 17:15:52 +0000

Ben,

Thanks again, I provide responses to your feedback below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 11/29/17, 4:32 PM, "Ben Campbell" <[email-masked]> wrote:

    Thanks!
    
    Ben.

    […]

Correct, two servers do not need to use the same ID for the same validator.  How about modifying “Both the Validator Identifier and the Issuer Identifier used MUST be unique” to “Both the Validator Identifier and the Issuer Identifier used MUST be unique in the server”?

How about “The Validator Identifier may define a non-Trademark Validator that supports a form of claims, where claims and a Validator Identifier can be used for purposes beyond trademarks.”?

The use of the optional the “lang” attribute with the “en” default is used throughout the EPP RFCs, so I believe that it should follow the precedent of 5731.

We believe that the set of statuses will meet the needs for launching a TLD, but we don’t want to limit the use of the launch phase extension.  It is important to have a concrete set of statuses along with an extension point.  The guidance is that use of the extension point should be avoided if possible.  

I believe the mechanism of communicating the policy of the server is out-of-scope for the launch phase extension.  The extension defines what is expected from the client (MUST NOT) and the server (return a 2102 error) to match the server policy.  This is a slippery slope, since there are other server policy elements (e.g., mark validation models, check forms, create forms) defined in the extension that the client needs to know out-of-band currently and in-band in the future.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 30 Nov 2017 12:59:07 -0600

Hi, more responses inline:

Thanks!

Ben.

> On Nov 30, 2017, at 11:15 AM, Gould, James <[email-masked]> wrote:
> 
> Ben,
> 

That works for me.

> How about “The Validator Identifier may define a non-Trademark Validator that supports a form of claims, where claims and a Validator Identifier can be used for purposes beyond trademarks.”?

That helps, thanks.

> The use of the optional the “lang” attribute with the “en” default is used throughout the EPP RFCs, so I believe that it should follow the precedent of 5731.

Okay. I would prefer a SHOULD to the MAY, but I’m not going to push the point.

> We believe that the set of statuses will meet the needs for launching a TLD, but we don’t want to limit the use of the launch phase extension.  It is important to have a concrete set of statuses al…

I think it woujld be clearer say that you SHOULD use one of the defined statuses if appropriate, rather than SHOULD NOT use the custom status.

> I believe the mechanism of communicating the policy of the server is out-of-scope for the launch phase extension.  The extension defines what is expected from the client (MUST NOT) and the server (…

The problem is that the current text has a MUST NOT that is difficult or impossible to honor without such a mechanism. That effectively implies a requirement to know in advance whether the server supports launch phase.  Would it make sense to soften that to say  MUST NOT (or SHOULD NOT) if it has knowledge that the server does not support the policy?

---

From: "Gould, James" <[email-masked]>
Date: Thu, 30 Nov 2017 23:58:02 +0000

Ben,

Thanks, my replies are below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 11/30/17, 10:59 AM, "Ben Campbell" <[email-masked]> wrote:

    Thanks!
    
    Ben.

    That works for me.

    That helps, thanks.

Thanks, I would like to leave this as is.    

    
Ok, how about changing “The server SHOULD NOT use the "custom" status value.” to “The server SHOULD use one of the non-“custom” status values”?  

Ok, let’s change the MUST NOT to SHOULD NOT, so the sentence in 3.4 will read “A client SHOULD NOT pass the extension on an EPP <update> command to a server that does not support launch applications”.  Does that work for you?

---

From: Ben Campbell <[email-masked]>
Date: Thu, 30 Nov 2017 18:05:23 -0600

Replies inline. I removed sections that don’t seem to need further discussion.

Thanks!

Ben.

> On Nov 30, 2017, at 5:58 PM, Gould, James <[email-masked]> wrote:
> 
> Ben,
> 

[…]

> Ok, how about changing “The server SHOULD NOT use the "custom" status value.” to “The server SHOULD use one of the non-“custom” status values”?

WFM

> Ok, let’s change the MUST NOT to SHOULD NOT, so the sentence in 3.4 will read “A client SHOULD NOT pass the extension on an EPP <update> command to a server that does not support launch application…

It helps—but it still creates an implied requirement, although now at the SHOULD level. If the intent is to create a MUST or SHOULD requirement for the client to have an (out of band or otherwise) mechanism to learn the server’s policies, it would be better to state that explicitly.

OTOH, I’d even be okay with a MUST NOT, as long it was qualified to apply to clients that have that advance knowledge.

---

From: "Gould, James" <[email-masked]>
Date: Fri, 1 Dec 2017 01:34:03 +0000

Ben,

It comes down to one issue with the ”A client (MUST|SHOULD) NOT pass the extension on an EPP <update> command to a server that does not support launch applications”.  How about taking a different approach on this one, since I don’t want to start down the slippery slope of defining server policy discovery in the draft?  

The intend of this sentence is to simply state “An EPP <update> command with the extension sent to a server that does not support launch applications will fail.  A server that …”.  There is no MUST NOT or SHOULD NOT language for the client and it defines the expected behavior in the protocol.  

Thoughts?   

Thanks,

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 11/30/17, 4:05 PM, "Ben Campbell" <[email-masked]> wrote:

    Thanks!
    
    Ben.

    […]

    WFM