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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
