Scott, Thanks for the review and feedback. Below are my replies to the feedback prefixed with “JG-“.
— JG James Gould Distinguished Engineer jgo...@verisign.com 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" <regext-boun...@ietf.org on behalf of shollenb...@verisign.com> wrote: 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. 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. 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. 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? My concern is that these unspecified bits might make it more difficult for clients and servers to develop interoperable implementations. Does it matter? Scott > -----Original Message----- > From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin > Sent: Friday, August 18, 2017 9:57 AM > To: Registration Protocols Extensions <regext@ietf.org> > Subject: [EXTERNAL] [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. > > 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 > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
