Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-allocation-token-09: (with COMMENT)

[Kal Feher <[e-mail]>]

Hello Ben,

Please accept the apologies of the authors for not responding earlier.

On 16/8/18 6:12 am, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-regext-allocation-token-09: No Objection
>
> 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-allocation-token/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Substantive Comments:
>
> - General:
>
> As far as I can tell, the document doesn't explain what an Allocation Token
> _is_. It talks about how it is used and what it contains, but I'm not sure what
> one represents semantically, or how it gets created, destroyed, etc. I see
> Section 7 mentions that Allocation Tokens are defined elsewhere; is there
> something that can be referenced? If not, would it be reasonable to add a high
> level summary to the introduction?
KF An allocation token represents the entitlement to exclusively create
a registry object (domain name). Generation and format of allocation
tokens are currently described by the server operators, for use by
clients. These techniques can and do vary by implementation.
> §3.1.1: "Availability of allocation.example and allocation2.example
> domain names are based on the Allocation Token ’abc123’"
>
> I'm confused by this, since the example shows a "mismatch" result for
> allocation.example.
KF I think the confusion stems from two things. Firstly using
unavailable responses in the prior examples, which might not be
intuitive. Second, the use of a multi domain check. We will publish a
revised set of examples and clearer caption text to indicate that
"abc123" matches allocation.example. For the multi domain check it will
match allocation.example, but not allocation2.example. In addition, a
domain check response xml file will now be included in the sample
directory of the github repository.
> §3.2.1, 2nd paragraph:
>
> I'm confused by the idea of a token mismatch for an object that has not yet
> been created. (Please see my general comment; some discussion of the lifecycle
> of allocation tokens would be helpful.)
KF the server may contain a paired list of labels (not objects) for
which tokens are required and predefined. Alternatively the token itself
may be derived from the label via hashing. In either scenario the server
will have policy that expects a token to be supplied with the label in
order to create the object. The policy may apply to all labels (no
object creation without tokens), an enumerated list of labels or the
supply of a token may be entirely optional. If a token is supplied in a
create command, it must match the label, regardless of the mechanism by
which the label and token are paired at the server.
> Editorial Comments:
>
> §1.1, last paragraph: The "REQUIRED" seems like a statement of fact.

KF We have followed the conventions used in previous EPP RFCs (RFC
3915,5730 -5733, 8334).

> §3.1.1: "If an object requires an Allocation Token and the Allocation
>        Token does not apply to the object or an object does not require
>        an Allocation Token..."
> That's hard to parse. Please consider separate cases for "required but does not
> apply" and "not required".
>
KF This has been updated in draft 11, but 2. and 3. overlap in that both
refer to an object that does not require an Allocation Token. We will
make an additional change to remove "or an object does not require an
Allocation" from 2.

KF We will publish draft-ietf-regext-allocation-token-12 with the
changes described in this email.

-- 
Kal Feher
Melbourne, Australia