Subject: [regext] review draft-ietf-regext-change-poll

From: "James Galvin" <[email-masked]>
Date: Fri, 18 Aug 2017 09:56:34 -0400

As the working group discussed at the last IETF meeting, the authors 
believe the following document is stable and ready for final review.

https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/

The chairs would like to ask for at least 3 people (other than the 
authors) to indicate they have read this document and agree that it is 
ready for publication.

Please reply to this message if you have any comments or questions, or 
if you agree the document is ready for publication.

Thanks,

Antoin and Jim

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 21 Aug 2017 18:01:29 +0000

I'm reviewing the document again now. I'll send comments after I have a chance to talk to Mr. Gould.

Scott

> -----Original Message-----
> From: regext [mailto:[email-masked]] On Behalf Of James Galvin
> Sent: Friday, August 18, 2017 9:57 AM
> To: Registration Protocols Extensions <[email-masked]>
> Subject: [EXTERNAL] [regext] review draft-ietf-regext-change-poll
>
> Please reply to this message if you have any comments or questions, or if
> you agree the document is ready for publication.
>
> Thanks,
>
> Antoin and Jim
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 22 Aug 2017 11:05:56 +0000

I talked to Jim Gould about this feedback yesterday. We didn't reach a conclusion, so I'm throwing this to the list to see if anyone else cares and might have a preference for a change proposal.

In Section 2.1 there's a description of the "custom" operation and how it uses an attribute named "op", but I can't find anything that describes the possible values for the attribute.

Section 2.2 talks about "Who" values, and it describes three different forms that MAY be used. The document says that "the possible set of Who values is up to server policy", and the Schema data type for the value is a length-restricted normalizedString. That all means that there's really no way to determine if a value is an Identifier, a Name, a Role or anything else (if it matters) and there's no way for a client to determine which is being used by a server. There's also no text I can find that explains how the value for this field is set.

My concern is that these unspecified bits might make it more difficult for clients and servers to develop interoperable implementations. Does it matter?

Scott

---

From: Jacques Latour <[email-masked]>
Date: Tue, 22 Aug 2017 15:30:35 +0000

I like this, reading for the first time, this is what we need to notify the registrar when DNSSEC information is changed for a domain at the registry by the DNS Operator or the registry itself.

Type: Create/Delete DNSSEC DS or DNSKEY 
Who: DNS Operator Name or the Registry itself.
Reason:  CDS or CDNSKEY instructions

Should the document have notification examples of adding or deleting a DS/DNSKEY records?

Jack

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Hollenbeck, Scott
Sent: Tuesday, August 22, 2017 7:06 AM
To: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [regext] review draft-ietf-regext-change-poll

Scott

---

From: "Gould, James" <[email-masked]>
Date: Tue, 22 Aug 2017 18:13:02 +0000

Scott,

Thanks for the review and feedback.  Below are my replies to the feedback prefixed with “JG-“. 

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On 8/22/17, 7:05 AM, "regext on behalf of Hollenbeck, Scott" <[email-masked] on behalf of [email-masked]> wrote:

JG-the “op” attribute of the <changePoll:operation> element follows the pattern of the “name” attribute of the  <launch:phase> element in draft-ietf-regext-launchphase and the newly added “customName” attribute of the <fee:command> element in draft-ietf-regext-epp-fees.  The pattern is to define an enumerated list of the known values (operations, launch phases, commands) along with extensibility to define a custom value or sub-value.  The “op” attribute in draft-ietf-regext-change-poll is not meant to be pre-defined, since clients can choose to key off the set of enumerated values but may choose to look at the sub-operations or custom operation value if needed.  The alternative to this pattern is to either set a static enumerated list that is too inflexible or define a free form string that is too undefined.  I view this pattern as providing a good middle ground in defining the known set of values with extensibility to cover future values.  Imagine that draft-ietf-regext-change-poll became an RFC prior to the RGP RFC 3915, which added the restore command / operation.  Servers could notify clients of a restore operation using the <changePoll:operation op=”restore”>custom</changePoll> element without having to revise draft-ietf-regext-change-poll to support a new operation.  Since RGP RFC 3915 does exist we can formally support “restore” in the enumerated list of operations.  Clients would be able to code to the existence of the “custom” <changePoll:operation> value and record the ”op” value or later leverage the “op” value to support additional processing.  We have seen the definition of new EPP commands, we can foresee the definition of new server-side operations, and we can support the 90 – 95% of the operations formally in the draft with extensibility to cover the 5 – 10% of the operations that are yet to be defined with use of the “op” attribute.    

JG-The <changePoll:who> value is always set by the server in the case of draft-ietf-regext-change-poll, since it’s the server that is created the change poll message.  The reason for the flexibility of the <changePoll:who> value is to cover different use cases of who may have caused the change.  It may be a CSR making a manual change, that would lend itself well to an “Identifier” or “Name”.  It may be a server-side software component like a batch, that would lend itself to a “Role”; although a batch may authenticate and have an “Identifier”.  Maybe this is too open and the <changePoll:who> element can be updated to match the language of the upID field in the EPP RFC’s, as being the identifier of the client that changed the object.  Alternatively if the openness is desired and it’s important for the client to know which type of client made the change, we could add an optional “type” attribute (e.g., “id”, “name”, “role”) with a reasonable default value (e.g., “id”) to the <changePoll:who> element.  I believe it would be straight forward to match the language of the EPP RFCs in place of adding a new optional “type” attribute.  Any thoughts?    

    Scott

---

From: Jody Kolker <[email-masked]>
Date: Fri, 25 Aug 2017 14:58:00 +0000

I have read the document and would like to see it move forward.  This is a change that we would like to see implemented in the future.

Thanks,
Jody Kolker
319-294-3933 (office)

This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of James Galvin
Sent: Friday, August 18, 2017 8:57 AM
To: Registration Protocols Extensions <[email-masked]>
Subject: [regext] review draft-ietf-regext-change-poll

As the working group discussed at the last IETF meeting, the authors believe the following document is stable and ready for final review.

The chairs would like to ask for at least 3 people (other than the
authors) to indicate they have read this document and agree that it is ready for publication.

Please reply to this message if you have any comments or questions, or if you agree the document is ready for publication.

Thanks,

Antoin and Jim