Adam, Thanks for raising the blocking clarification item, since I thought everything was taken care of.
Ben, how about revising the first paragraph of section 2.3 to read: The <changePoll:who> element defines who executed the operation for audit purposes. It is a freeform value that is strictly meant for audit purposes and not meant to drive client-side logic. The scheme used for the possible set of <changePoll:who> element values is up to server policy. The server MAY identify the <changePoll:who> element value based on: Any proposed changes or additional clarification needed? Thanks, — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/3/19, 4:05 PM, "regext on behalf of Adam Roach" <regext-boun...@ietf.org on behalf of a...@nostrum.com> wrote: James -- When I poked Ben about the delta between -10 and -11, he indicated that there were some additional clarifications he was waiting for. Specifically: > I think that James had said: > > % 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. > > which is the main thing that I was waiting to see happen. (Assuming my > brain is functioning correctly, of course.) But maybe I missed some > follow-up about why that was not actually a good idea. It looks like this should be a rather simple matter of adding clarifying text about <changePoll:who> values into the document that explains the same thing as the text above. Benjamin, please correct me if I'm wrong. /a On 12/26/18 9:38 AM, Gould, James wrote: > 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
