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

From: Adam Roach <[email-masked]>
Date: Thu, 3 Jan 2019 15:05:10 -0600

James --

When I poked Ben about the delta between -10 and -11, he indicated that 
there were some additional clarifications he was waiting for. Specifically:

> I think that James had said:
>
> % 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.
>
> which is the main thing that I was waiting to see happen.  (Assuming my
> brain is functioning correctly, of course.)  But maybe I missed some
> follow-up about why that was not actually a good idea.

It looks like this should be a rather simple matter of adding clarifying 
text about <changePoll:who> values into the document that explains the 
same thing as the text above. Benjamin, please correct me if I'm wrong.

/a

On 12/26/18 9:38 AM, Gould, James wrote:
> 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
>
> Verisign.com <http://verisigninc.com/>
>
> On 12/10/18, 5:37 PM, "Benjamin Kaduk" <[email-masked]> wrote:
>
>      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
>      
>      On Mon, Dec 10, 2018 at 04:48:18PM +0000, Gould, James wrote:
>      > 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:
>      >
>      >     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.
>      >
>      > 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.
>      >
>      >     ----------------------------------------------------------------------
>      >     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.
>      >
>      > 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
>      >
>      >     Maybe state explicitly what it's inserted into, for clarity.
>      >
>      > JG - I can update "... MUST be inserted prior to ..." to "... MUST be inserted into the message queue prior to ..."
>      >
>      >     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.
>      >
>      > 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
>      >
>      >     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.
>      >
>      > 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: "Gould, James" <[email-masked]>
Date: Thu, 3 Jan 2019 21:17:41 +0000

Adam,

Thanks for raising the blocking clarification item, since I thought everything was taken care of.  

Ben, how about revising the first paragraph of section 2.3 to read:

The <changePoll:who> element defines who executed the operation for
audit purposes.  It is a freeform value that is strictly meant for audit purposes 
and not meant to drive client-side logic.  The scheme used for the possible 
set of <changePoll:who> element values is up to server policy.  The server
MAY identify the <changePoll:who> element value based on:

Any proposed changes or additional clarification needed?  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 1/3/19, 4:05 PM, "regext on behalf of Adam Roach" <[email-masked] on behalf of [email-masked]> wrote:

    James --

    
    
    /a

    > A new version, draft-ietf-regext-change-poll-11, has been published that incorporates the updates based on your feedback.
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Jan 2019 15:01:04 -0600

Hi James,

That new text works for me.

Sorry for the mixup about whether everything was resolved and the slow
response time -- my holiday break ended up being a long one this year, for
various reasons.

-Benjamin

---

From: "Gould, James" <[email-masked]>
Date: Fri, 4 Jan 2019 21:06:50 +0000

Benjamin,

The change is reflected in draft-ietf-regext-change-poll-12.  Let me know if you find any other items.

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 1/4/19, 4:01 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    Hi James,

    
    -Benjamin