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
