[regext] AD Review: draft-ietf-regext-allocation-token-08

[Adam Roach <[e-mail]>]

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)

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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"

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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."

---------------------------------------------------------------------------

§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]".

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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."

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

/a