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

From: Adam Roach <[email-masked]>
Date: Sat, 14 Jul 2018 15:33:54 -0400

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

---

From: "Gould, James" <[email-masked]>
Date: Thu, 19 Jul 2018 15:52:40 +0000

Adam,

Thanks for the review.  I reply to your feedback embedded below.

Thanks,

—

JG

James Gould

Distinguished Engineer

[email-masked]

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-masked] on behalf of [email-masked]> wrote:

    should

    Despite the

    marks)

JG - Addressed

JG - Addressed

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.

    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?

    Nit: "allows"

JG – Addressed

        of 'abc123':

    subject to

    by RFC

    2026 for this purpose.

    including a few

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

    between

    "2302" and "object."

JG – The “object referencing the <allocationToken:info> element” should be removed from the sentence.  I addressed this.

JG - Addressed

    (c) Both

    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?

    Namespace." I

    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?

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-masked]

    https://www.ietf.org/mailman/listinfo/regext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 19 Jul 2018 16:58:54 +0000

Section 5.1: the schema registration URI should be ietf:params:xml:schema:allocationToken-1.0, not ietf:params:xml:ns:allocationToken-1.0. The latter URI is associated with the namespace, not the schema.

Scott

> On Jul 19, 2018, at 11:53 AM, Gould, James <jgould=[email-masked]> wrote:
> 
> draft-ietf-regext-allocation-token

---

From: "Gould, James" <[email-masked]>
Date: Thu, 19 Jul 2018 17:35:36 +0000

Thanks, that change will be addressed as well.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 7/19/18, 12:59 PM, "Hollenbeck, Scott" <shollenbeck=[email-masked]> wrote:

    Scott
    
    > On Jul 19, 2018, at 11:53 AM, Gould, James <jgould=40verisign.com@dmarc..ietf.org> wrote:
    >