Subject: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-change-poll-10: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 07 Dec 2018 02:52:10 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-change-poll-10: Discuss

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-change-poll/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a fairly minor point, but the text of Section 2.3 implies that there is
a distinct list of identifier types that the server MAY use (and thus that there would
be a protocol element to convey such an identifier type), but the actual schema in
Section 4.1 is clear that the <changePoll:who> element is just a freeform token with
some modest length restrictions (i.e., no place for internal structure).  I'd like to
hear from others on the IESG whether the text about the schema used being up
to server policy is enough to make this clear, or we think there is some level of
internal inconsistency in the document to be rectified.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the generally well-written document!

There are several places in the document where we read about a "list of [...]
values includes" that is in fact required to be one of a fixed enumerated set
of values.  In such cases I would suggest "comprises" or "is" rather than "includes",
which could be taken to indicate the possibility of additional values being defined
at a later time.  Section 2.1 has multiple instances of this, and Section 3.12. as well.

Section 2.2

Maybe state explicitly what it's inserted into, for clarity.

Section 2.3

"CSR" could expand to either "Customer Support Representative" or
"Certificate Signing Request" for some people.  I don't know if there's
better name to suggest.

Section 2.4

I don't know if it's worth saying anything that would remind recipients of
their (non-?)obligation to accept time values that correspond to leap
seconds, but IIRC we've seen cases in the past of software that chokes when
presented with leap-second timestamps.

---

From: "Gould, James" <[email-masked]>
Date: Mon, 10 Dec 2018 16:48:18 +0000

Benjamin,

Thank you for your review and feedback.  I provide responses to your feedback embedded below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On 12/7/18, 5:52 AM, "Benjamin Kaduk" <[email-masked]> wrote:

    

JG - I'll provide a little bit more clarification around the basis for the use of a freeform token for the <changePoll:who> element.  The <changePoll:who> element is meant for audit purposes and is not meant for driving client-side logic, so use of a freeform token based on server policy is the best fit.  This is similar to the use of the <domain:crID> and <domain:upID> elements in RFC 5731, where identifying who created the domain name or updated the domain name is returned for audit purposes using a freeform token.         

    

JG - Thanks, I see your point that using "include" can mean that there may be more.  I like the option of "is".  I'll make that change in the following places:
Section 2.1: "The enumerated list of <changePoll:operation> values include:" to "The enumerated list of <changePoll:operation> values is:"
Section 3.1.2: "The enumerated list of case types include:" to " The enumerated list of case types is:"
    
    Section 2.2

JG - I can update "... MUST be inserted prior to ..." to "... MUST be inserted into the message queue prior to ..."
    
    Section 2.3

JG - I believe the reference to "CSR" as "Customer Support Representative" is pretty standard in the domain name industry with no confusion to a "CSR" in the digital certificate industry.  
    
    Section 2.4

JG - This is standard boilerplate text in the EPP RFCs (RFC 5731 - 5733) that include timestamps, and I'm not aware of any EPP software issues associated with leap-second timestamps that warrants a reminder in this EPP draft.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 10 Dec 2018 16:32:29 -0600

Thanks; this sounds like a good path forward.  I'll note that I'm on PTO
this week, so I may be slow to respond to a new rev being issued.

-Benjamin

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 11 Dec 2018 01:35:24 -0500

On Mon, Dec 10, 2018, at 11:48, Gould, James wrote:
> JG - I believe the reference to "CSR" as "Customer Support 
> Representative" is pretty standard in the domain name industry with no 
> confusion to a "CSR" in the digital certificate industry.  

I kind of disagree but it is a minor point and I believe that the context
provides enough disambiguitation.
There is in general possible confusion as there is overlap between the domain name business and the digital certificate issuance business at least for two reasons: many certificates are DV so they directly depend on domain names and multiple domain name registries and registrars are also Certificate Authorities.

However I really do not see also what we gain by the acronym we could as well put
Customer Service Representative
or
Support Agent
or
Customer Care
or whatever, in full, instead of an acronym there, so that the example is complete.

> JG - This is standard boilerplate text in the EPP RFCs (RFC 5731 - 
> 5733) that include timestamps, and I'm not aware of any EPP software 
> issues associated with leap-second timestamps that warrants a reminder 
> in this EPP draft.      

I agree with James, for better or worse, no other EPP documents go into such territories
as leap-second and this specification is no more "time" oriented than the others
so it makes no specific sense to start here talking about leap seconds.

-- 
  Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Tue, 11 Dec 2018 13:36:16 +0000

Patrick,

> There is in general possible confusion as there is overlap between the domain name business and the digital certificate issuance business at least for two reasons: many certificates are DV so they…

I don't believe there is any overlap or confusion when it comes to the EPP interface between the registrar an registry.  The reference to "CSR" is simply an example of a "Role"-based value for the <changePoll:who> element, which includes the expanded name Customer Support Representative for clarity.  There is no normative language related to the use of the acronym "CSR", so an implementation can choose how best to represent the corresponding "Role"-based value.       
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 12/11/18, 1:35 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    -- 
      Patrick Mevzek
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: "Gould, James" <[email-masked]>
Date: Wed, 26 Dec 2018 15:38:54 +0000

Benjamin,

A new version, draft-ietf-regext-change-poll-11, has been published that incorporates the updates based on your feedback. 

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 12/10/18, 5:37 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    -Benjamin