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
