Subject: Re: [regext] Request for Working Group Last Call for draft-ietf-regext-allocation-token

From: Antoin Verschuren <[email-masked]>
Date: Wed, 13 Dec 2017 14:34:36 +0100

James,

Jim and I were going to send out a formal WGLC on this document, but we didn’t see a reply to this extensive review yet.
What do you want us to do, wait for you to have treated Patrick’s comments, or consider them as part of WLC (Which may have a deadline)?

Jim and Antoin

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392

Op 21 nov. 2017, om 05:40 heeft Patrick Mevzek <[email-masked]> het volgende geschreven:

> Hello James and Kal,
> 
> Please find below my comments on your draft.
> 
> Abstract: remove "or code" in "an allocation token or code", as this is
> not repeated after and does not add value.
> 
> The introduction needs to be rephrased, multiple sentences did not have
> sense to me:
> 
> "This mapping, an
>   extension to EPP object mappings like the EPP domain name mapping
>   [RFC5731], for passing an allocation token one of the EPP transform
>   commands including create, update, and transfer."
> 
> There is no verb at all: This mapping... for passing...
> A "to" is probably missing: an allocation token TO one of the EPP ...
> 
> This sentence seems overly complex to say what it says:
> The allocation
>   token is known to the server to authorize a client that passes a
>   matching allocation token with one of the supported EPP transform
>   commands.
> Why not something simpler like:
> A client must pass an allocation token known to the server to be
> authorized to use one of the supported EPP transform commands.
> 
> This is not clear technically: The allocation token MAY
>   be returned to an authorized client for passing out-of-band to a
>   client that uses it with an EPP transform command.
> 
> Two clients seem defined here, are they the same one or not? If not,
> what is the difference?
> 
> 
> 1. Introduction
> 
> Maybe make more clear if the allocationToken can be used to do
> operations on some existing objects by a registrar not being its current
> sponsor. Is this the goal, or just something possible among other
> things, or not at all?
> 
> 
> In 2.1 Inconsistent case: sometimes "Allocation Token", sometimes
> "allocation token"
> 
> This does not seem clear: 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.
> 
> I believe that you want to say that the allocation token must be checked
> on the server and match the expected value. But no need to overspecify
> things the server may not even have the allocation token stored, it can
> be the hash of the object ID and a secret hence checked dynamically.
> 
> 
> 
> 3.1.1
> There is a gap between the feature here and the introduction.
> The introduction says:
> "authorization to
>   allocate an object using one of the EPP transform commands including
>   create, update, and transfer."
> 
> (and this sentence is not clear by itself, why is an update or a
> transfer
> now an allocation?)
> 
> where in the check command:
> Clients can
>   check if an object can be created using the allocation token.
> 
> So how can clients check if an object could be updated or transfered
> using the given allocation token, besides trying to do it and seeing if
> it fails or not? But since create has a specific command to test the
> allocation token (with check), why not the others?
> Otherwise the introduction will need to be changed to speak only about
> create, which then will make more sense with its name ("allocation") as
> otherwise if it really needs to be generic accross multiple actions I
> would suggest something more like "authorization token" with the risk of
> clashing with EPP core authInfo concept.
> 
> Is there a reason to put the result in the domain:reason node instead
> of having really an allocationToken extension in the domain:check reply
> which will store data specific to it?
> (like it is done for the fees extension, or launchphase, etc.)
> 
> 
> 3.1.2
> I would like more explanation on what the allocationToken there
> represents, especially considering the gap I see between what is in the
> description and the check command as explained above.
> 
> When doing domain:info, is the allocation token returned the one used to
> do the create? Or is it the one to be used to do a transfer or update?
> What if there are not the same?
> What is in fact the use case of providing to a registrar an allocation
> token that way, when it is said at the beginning that such allocation
> tokens are retrieved out of bound?
> This is also related to what we see on the field with some registries
> that never show the authInfo because they store it hashed or something
> like that, so in a one-way destructive method. Shouldn't the allocation
> token be kind of "write only", where you can verify you get the correct
> one before attempting to use it, but never see it if you do not have it
> already (the out of bound of the introduction)
> 
> 
> About the 2303: I am not sure that it is the correct error code to
> return, as an allocation token is not a registry object and this error
> code is more likely tied to the existence or not of the underlying
> domain object.
> 
> 
> 3.2.2 / 3.2.3 why does the allocation token not cover these cases, where
> it covers create, update and transfer?
> 
> Specially since in section 1 you defer to server policy to decide which
> EPP transform commands support the allocation token... but the extension
> does not add support for renew/delete, so this is not bound by server
> policy but by protocol design.
> 
> 3.2.4
> Nitpick: final extra unneeded ":" at end of:
> the server MUST return an EPP error result code of
>   2201.:
> 
> As explained above, I feel uneasy by:
> Example <transfer> request command to allocate the domain object with
>   the allocation token:
> 
> A transfer command does not allocate an object (for me, but maybe it is
> an error in my English understanding, allocate is a synonym to register
> in our context), it transfers it.
> 
> 3.2.5  Same nitpick as previous section, about the extra : at end.
> 
> 
> Your XML example has a:
>  C:      <release:release
>  C:        xmlns:release="urn:ietf:params:xml:ns:release-1.0"/>
> 
> which is probably a copy and paste error.
> 
> 
> 
> 
> General:
> Should there be some guidance somewhere that allocation tokens should be
> unique and not reused accross multiple domains?
> But then domain:check with multiple domains and only one token are less
> useful.
> 
> 
> 
> For implementation status, if you wish you can add the Net::DRI client
> to the list.
> 
> --
>  Patrick Mevzek
>  [email-masked]
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Gould, James" <[email-masked]>
Date: Wed, 13 Dec 2017 20:22:16 +0000

Patrick,

Sorry about the long delay in my review of your feedback.  Thank you for doing the detailed review.  From a high-level, I need to discuss the extension of the info command / response with Kal.  I include my responses to your feedback embedded below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com <http://verisigninc.com/> 

On 11/20/17, 11:40 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    Hello James and Kal,

Ok, no problem.

    "This mapping, an

Agreed, a “to” is missing so it should read “an allocation token to one of the EPP…”.   

I agree, the reworded sentence is better; although I believe it should use a RFC 2119 “MUST”.  The wording “supporting EPP transform commands” implies that the object (domain name) requires the allocation token, since the allocation token may not be required for all objects (domain names) in the registry.  Also, the wording “allocation token known” does not mean that the value of the allocation token must be pre-defined, since using an allocation token that uses a digital signature that is validated by the server means that the server knows the token format and validates it.  

I agree that is somewhat confusing.  There are two separate clients (authorized client like an auction provider and registrant).  An authorized client (e.g., auction provider) could use the allocation token extension to the info command to retrieve the allocation token that can be passed to another client (registrant) to authorize the registration / allocation of the domain name.  Now that the use case is defined, how does this sentence get cleaned up to be less confusing?   How about modifying it to “The allocation token MAY be returned to an authorized client (e.g., auction provider) for passing out-of-band to another client (e.g., registrant) that uses it with an EPP transform command.”?
    
    1. Introduction

No, that is not the goal.  The goal is around authorizing a registration or allocation of an object based on passing a validate allocation token.  There are no other known uses of the allocation token extension to do things like what is done with the verification code extension (draft-ietf-regext-verificationcode).      

    
    
Yes, I agree that the draft should not be overly restrictive on the format of the allocation token, where the allocation token extension is simply a conduit to pass an allocation token that is known and can be verified by the server.  There are multiple known use cases for allocation tokens that include pre-generated values and digitally signed tokens.  

    3.1.1

It depends on the approach that the registry takes in allocating domain names that may be premium.  One approach is to have them defined in a reference list, which would mean that the create command would be the allocation command.  Another approach is to hold the domain in the domain table and to have the registry or another account be the sponsoring client, which would mean that the update (new command) or transfer commands could be used for allocation.  The protocol supports passing the allocation token to any one of the transform commands, where the most likely use case is use of the create command for allocation.  

    
The fix here would to be change “object can be created” to be “object can be allocated”.  The mechanism for allocation is not restricted to create; although create is the most likely command.  The object is being allocated in any case, but using different commands to do it, so I don’t believe that changing the name will help.

The allocation token extension is extending the domain check command to drive the avail attribute value in the domain check response.  This is a simple check that does not require additional information other than the Boolean “avail” value and a human readable reason.    
    
    3.1.2

Let me chat this over with Kal, since Neustar added the extension to the info command / response. 

The extension of the info command / response is an alternative mechanism for the “authorized client” (e.g., auction provider) to get the allocation token value.  The most likely scenario is to provide the allocation token values to the “authorized client” out-of-band.   Using a 1-way hash is a more secure option on the server-side; although I’m not sure if a 1-way hash is necessary considering that it’s a short lived, single use token.  The reference to out-of-band in the introduction is associated with the “authorized client” (e.g., auction provider) providing the token value to the client (e.g., registrant).     

The use of 2303 makes sense if the info extension defined an Allocation Token Info Command, where the query is about the allocation token and not the domain information with the addition of the allocation token.  If the allocation token does not exist for an Allocation Token Info Command, then 2303 makes sense if the Allocation Token does not exist.      

Allocation has been handled via create, update (new command), and transfer, but not using delete or renew.

Correct, the server policy would define which of the supported commands the allocation token extension applies to.  
    
    3.2.4

Thanks, the unneeded “:” will be removed. 

Yes, I personally wouldn’t recommend using transfer for allocation, but the allocation of premium domain names has been handled via transfer.  The difference is that the domain exists under sponsorship of the registry or a special premium registrar account that are allocated to a registrar via the transfer command. 

Thanks, the unneeded “:” will be removed.     
    
    Your XML example has a:
      C:      <release:release

No, this is by design.  The intent here is that the allocation token would not be used by itself to allocation an object, but as an extension to a new command.  The new command is an extension of an empty update.  In this case the “release:release” is an example of defining a new release command that uses the allocation token to authorize the release.  The release-1.0.xsd includes only the <schema> <element name=”release”/> element, and is only defined as an example.  You can find the “good-domain-release.xml” sample with the referenced “release-1.0.xsd” XML schema in the samples directory of the EPP-Allocation-Token-Specification GitHub project (https://github.com/james-f-gould/EPP-Allocation-Token-Specification.git).             
    
    General:

Yes, that would be applicable for pre-generated allocation tokens.  An allocation token could be a digitally signed by a trusted third party that pre-authorizes the allocation of domain names.  Since the makeup of an allocation token is not formally defined within the draft, I’m not sure whether the draft can put any constraints on it.            

First off thanks for the work on Net::DRI, and we can certainly add Net::DRI to the Implementation Status section.  Can you provide the following key values to add to the draft or you can also submit a pull request to the EPP-Allocation-Token-Specification GitHub project (https://github.com/james-f-gould/EPP-Allocation-Token-Specification.git) if you want to define it yourself?       

1. Organization 
2. Description
3. Level of maturity
4. Coverage
5. Licensing
6. Contact
7. URL

    -- 
      Patrick Mevzek
      [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 20 Dec 2017 06:13:52 +0100

Hello James,

Just following on the remaining points:

> How about
> modifying it to “The allocation token MAY be returned to an authorized
> client (e.g., auction provider) for passing out-of-band to another client
> (e.g., registrant) that uses it with an EPP transform command.”?

I prefer that, indeed.
    
> It depends on the approach that the registry takes in allocating domain
> names that may be premium.  One approach is to have them defined in a
> reference list, which would mean that the create command would be the
> allocation command.  Another approach is to hold the domain in the domain
> table and to have the registry or another account be the sponsoring
> client, which would mean that the update (new command) or transfer
> commands could be used for allocation.  The protocol supports passing the
> allocation token to any one of the transform commands, where the most
> likely use case is use of the create command for allocation.  

Part of the above should be in the document to make things clearer.
I could see things about the transfer, but I am still not convinced
that domain names could spring into existence from an update command.
If this does not reflect existing use cases and if noone presses for it,
it might be better to just drop the part about the update?
    
>>     When doing domain:info, is the allocation token returned the one used
>>     to do the create? Or is it the one to be used to do a transfer or
>>     update?
> 
> The extension of the info command / response is an alternative mechanism
> for the “authorized client” (e.g., auction provider) to get the
> allocation token value.  

This confuses me a little: how can the authorized client being in your sentence the auction provider get the allocation token that way as it would mean it is an EPP client that connects to the registry? Also since you can do a domain:info only on a domain name that exists, how
can you expect to retrieve data there (the allocation token) that would be needed to create the domain name? I see that this could be for the transfer or update cases, but I'm no fan
of those.

I know you said they were used in the past. But then it must be clear I think
if your document is Informational and writes down what happens on the field 
just for historic information or if
your document wishes to become a Standard so showing the "right way" to do things,
irrespective to what already happened (in the sense that it should not bear responsabilities
to necessarily sanction what was done in the past).
In the last case, I would still ask for proponents of the "update" case specifically
to voice themselves.
I could be convinced by transfer, but I really have to force myself :-)

> No, this is by design.  The intent here is that the allocation token
> would not be used by itself to allocation an object, but as an extension
> to a new command.  The new command is an extension of an empty update. 
> In this case the “release:release” is an example of defining a new
> release command that uses the allocation token to authorize the release. 
> The release-1.0.xsd includes only the <schema> <element name=”release”/>
> element, and is only defined as an example.  You can find the
> “good-domain-release.xml” sample with the referenced “release-1.0.xsd”
> XML schema in the samples directory of the
> EPP-Allocation-Token-Specification GitHub project
> (https://github.com/james-f-gould/EPP-Allocation-Token-Specification.git). 

I still think there is a problem with an example. As all the previous discussions
show, transfer in a way but specially update are like edge cases and close
to bending the notion of allocating a domain name. So here you give an example
by just dropping another extension absolutely never explained anywhere in the draft.
I doubt that this could be accepted as an RFC.
You can not just publish it as a standard and say "the extension is defined in github"

There is clearly something to phrase differently here.
And I think, in a way, this clearly shows again that the update case for an allocation
is very strange.  

> First off thanks for the work on Net::DRI, and we can certainly add
> Net::DRI to the Implementation Status section.  Can you provide the
> following key values to add to the draft or you can also submit a pull
> request to the EPP-Allocation-Token-Specification GitHub project
> (https://github.com/james-f-gould/EPP-Allocation-Token-Specification.git)
> if you want to define it yourself?       

Ok, I will follow on that separately, thanks.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Thu, 21 Dec 2017 15:36:45 +0000

Patrick,

Thanks for your review and attention on the draft.  You find my responses embedded below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 12/20/17, 12:13 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    Hello James,

    
    I prefer that, indeed.

It has been incorporated.

Your original comment is associated with section 3.1.1 (check command extension), which is associated with the ability to provision (allocation) an object using the <create> command.  The extension in section 3.1.1 does not define any command (e.g., allocation check), so it is exclusively associated with the create command.  The use of the allocation token extension for the create, update, and transfer commands is covered in the respective sections.  In the case of update, the allocation token is used for an extension of an empty update, which would be used to define a new command (e.g., allocate, release).  The allocation token can be used to allocate an object using multiple transform commands, but the draft does not intend to dictate which one must be used.  The most likely use case is use of the create command, but I want to ensure that the allocation token can be used to meet current and future server policy.  

Forget about my reference to the auction provider, the language as defined in the draft provides the ability to retrieve the allocation token for allocated objects, which would be past tense.  You are correct that the object must exist and the extension of the info command is only meant for an authorized client to retrieve the object information along with the allocation token used.  

I believe you’re viewing the update and an update of an existing object instead of an extension of the update to define a new command like release or allocate.  A server could leverage the create command, transfer command, or define a new command as an extension of the empty update.  The goal of the extension is not to dictate a single way to allocate, but to support the use of an allocation token to authorize an allocation.  

    

There are examples of extending an empty update today in the RGP RFC to define a new command called “restore”.  There is a similar example in the ConsoliDate Extension (https://www.verisign.com/assets/consolidate-mapping.txt) to define a new command called “sync”.  There could be a specific command created for allocation in a similar fashion that can leverage the allocation token for authorizing the allocation.  I don’t see any issue with including a hypothetical empty update extension called “release” in an example.  Extending of an empty update to define a new command has been done in prior extensions (both RFC and proprietary), and the allocation token should support these sorts of extensions.      

Great, thanks.
    
    -- 
      Patrick Mevzek
      [email-masked]