Adam,
Thanks for the review. I reply to your feedback embedded below. Thanks, — JG James Gould Distinguished Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/14/18, 3:34 PM, "regext on behalf of Adam Roach" <[email protected] on behalf of [email protected]> wrote: This is my AD review for draft-ietf-regext-allocation-token. Based on what I see, this document is ready to go to IETF last call. The comments below should be handled at the same time as any IETF last call comments. I'd like to start by thanking everyone who worked on this document. Despite the relatively large number of comments, the document is in good shape. --------------------------------------------------------------------------- Abstract: > This document describes an Extensible Provisioning Protocol (EPP) > extension for including an Allocation Token in query and transform > commands. Nit: set "query" and "transform" off in some way (e.g., using quotation marks) JG - Addressed --------------------------------------------------------------------------- §1.1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. Please update to use the boilerplate from RFC 8174. JG - Addressed --------------------------------------------------------------------------- §1.1: > "allocationToken-1.0" is used as an abbreviation for > "urn:ietf:params:xml:ns:allocationToken-1.0". This doesn't appear to be true. I would suggest removing this sentence. JG - Addressed, where I changed the paragraph to read: The XML namespace prefix "allocationToken" is used for the namespace "urn:ietf:params:xml:ns:allocationToken-1.0", but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. --------------------------------------------------------------------------- §2.1: > The Allocation Token is a simple XML "token" type. The exact format > of the Allocation Token is up to server policy. The server MUST have > the Allocation Token for each object to match against the Allocation > Token passed by the client to authorize the allocation of the object. "...server MUST have..." is a bit confusing here. It seems that the token could itself be a signed assertion that the server could simply validate, rather than keeping a local copy, which is what "MUST have" would seem to imply. JG – Good catch. You are correct that the token is an assertion and that the server does not need to have it for each object to validate against what the client passed. I propose changing the MUST to a MAY, since having predefined tokens is an option but not a requirement. Do you agree with this change? --------------------------------------------------------------------------- §3.1.1: > This extension allow clients to check the availability of an object > with an Allocation Token, as described in Section 2.1. Nit: "allows" JG – Addressed --------------------------------------------------------------------------- §3.1.1: > Example <check> command for the example.tld domain name using the > <allocationToken:allocationToken> extension with the allocation token of 'abc123': The domain "example.tld" is not reserved for use in examples and is subject to allocation for use in the future. Please use one of the domains reserved by RFC 2026 for this purpose. This comment applies to several other locations in the document, including a few that use "example2.tld". I would suggest using "example.org" and "example.net" for these purposes. JG – Addressed. I decided to use the .example tld with the domain labels “allocation” or “allocation2”, resulting in “allocation.example” and “allocation2.example”. --------------------------------------------------------------------------- §3.1.2: > If the client is authorized to receive the > Allocation Token, but there is no Allocation Token associated with > the object, the server MUST return an EPP error result code of 2303 > object referencing the <allocationToken:info> element. I can't parse this sentence -- I think there must be some words missing between "2302" and "object." JG – The “object referencing the <allocationToken:info> element” should be removed from the sentence. I addressed this. --------------------------------------------------------------------------- §3.1.3: > This extension does not add any elements to the EPP <transfer> query > command or <transfer> query response described in the [RFC5730]. Nit: remove "the" before "[RFC5730]". JG - Addressed --------------------------------------------------------------------------- §3.2.4: > If the Allocation Token does not apply > to the object, the server MUST return an EPP error result code of > 2201. I'm not certain whether this is intended to apply when: (a) The object requires a Token, but this is the wrong one, (b) The object does not require a Token, but one has been supplied, or (c) Both Please update the text to make it clear which case(s) this is intended to cover. JG – It is really both, where the Allocation Token is not valid or is it not needed. I can change it to “If the Allocation Token is invalid or not required for the object, the server...” to provide clarity. Do you agree with this change? --------------------------------------------------------------------------- §5.1 (XML Namespace): > Registration request for the allocationToken XML schema: It's a bit confusing to register a schema in a section titled "XML Namespace." I suggest splitting this off into its own section titled something like "XML Schema." JG - My recommendation is to match the XML Namespace section in RFC 8334, which would exactly match by removing the “The following URI assignment is requested of IANA:”. Do you agree? --------------------------------------------------------------------------- §7: > 6. An Allocation Token should is signed XML should be encoded (e.g., > base64) to mitigate server validation issues. I'm having a hard time parsing this sentence. Please rephrase to be clearer. Also, please informatively cite RFC 4648 for Base 64. JG – I believe this can be fixed by changing “An Allocation Token should is signed XML” to “An Allocation Token that is signed XML”. I will informatively cite RFC 4648 for base64. --------------------------------------------------------------------------- /a _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
