Benjamin, Thank you for your review and feedback. I provide responses to your feedback embedded below. — JG
James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 12/7/18, 5:52 AM, "Benjamin Kaduk" <ka...@mit.edu> 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. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
