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 jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 12/10/18, 5:37 PM, "Benjamin Kaduk" <ka...@mit.edu> 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 > 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
