Subject: Re: [regext] I-D Action: draft-ietf-regext-allocation-token-06.txt

From: Pieter Vandepitte <[email-masked]>
Date: Fri, 13 Apr 2018 11:05:06 +0200

Hi,

Short question: what's the purpose of an allocation token within a transfer command (and what's the difference with authInfo code)? I understand the purpose in case of create and I can imagine some use cases for update, but even for update, I have my doubts.

I'm sorry if this question has been asked in the past, but Google doesn't appear to be my friend today ;-)

Pieter

> On 29 Jan 2018, at 20:32, Gould, James <[email-masked]> wrote:
> 
> Hi,
> 
> I published the revised draft-ietf-regext-allocation-token based on the feedback received during the WGLC.  Please provide any additional feedback on the list.
> 
> Thanks,
> 
> —
> 
> JG
> 
> 
> 
> James Gould
> Distinguished Engineer
> [email-masked]
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com <http://verisigninc.com/>
> On 1/29/18, 2:30 PM, "regext on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:
> 
> 
>    A New Internet-Draft is available from the on-line Internet-Drafts directories.
>    This draft is a work item of the Registration Protocols Extensions WG of the IETF.
> 
>            Title           : Allocation Token Extension for the Extensible Provisioning Protocol (EPP)
>            Authors         : James Gould
>                              Kal Feher
>    	Filename        : draft-ietf-regext-allocation-token-06.txt
>    	Pages           : 22
>    	Date            : 2018-01-29
> 
>    Abstract:
>       This document describes an Extensible Provisioning Protocol (EPP)
>       extension for including an Allocation Token in query and transform
>       commands.  The Allocation Token is used as a credential that
>       authorizes a client to request the allocation of a specific object
>       from the server, using one of the EPP transform commands including
>       create and transfer.
> 
> 
>    The IETF datatracker status page for this draft is:
>    https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/
> 
>    There are also htmlized versions available at:
>    https://tools.ietf.org/html/draft-ietf-regext-allocation-token-06
>    https://datatracker.ietf.org/doc/html/draft-ietf-regext-allocation-token-06
> 
>    A diff from the previous version is available at:
>    https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-allocation-token-06
> 
> 
>    Please note that it may take a couple of minutes from the time of submission
>    until the htmlized version and diff are available at tools.ietf.org.
> 
>    Internet-Drafts are also available by anonymous FTP at:
>    ftp://ftp.ietf.org/internet-drafts/
> 
>    _______________________________________________
>    regext mailing list
>    [email-masked]
>    https://www.ietf.org/mailman/listinfo/regext
> 
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Gould, James" <[email-masked]>
Date: Fri, 13 Apr 2018 12:42:27 +0000

Pieter,

A reserved domain name may be held in the live domain table and sponsored by an internal server account, where the allocation token on a transfer request may be used to allocate the domain name to the client.  The allocation token is an explicit credential for allocation authorization and it does not replace the authInfo value.  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com <http://verisigninc.com/> 
On 4/13/18, 5:05 AM, "Pieter Vandepitte" <[email-masked]> wrote:

    Hi,

    
    Pieter

---

From: Patrick Mevzek <[email-masked]>
Date: Sat, 14 Apr 2018 04:50:11 +0200

On Fri, Apr 13, 2018, at 11:05, Pieter Vandepitte wrote: 
> Short question: what's the purpose of an allocation token within a 
> transfer command (and what's the difference with authInfo code)? I 
> understand the purpose in case of create and I can imagine some use 
> cases for update, but even for update, I have my doubts.

You are right and I share your surprise and doubts, about both update and transfer. update has been removed, transfer is still in the draft.
 
> doesn't appear to be my friend today ;-)

The same area of concerns were raised at least by Alexander Mayrhofer here:
https://mailarchive.ietf.org/arch/msg/regext/HgPkOGl0rVNwVZ9L8_37U1uS76o

and previously by myself here:
https://mailarchive.ietf.org/arch/msg/regext/LnvUUbjWzdez1MyHKDbPwkoywt0

and the threads following them.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 16 Apr 2018 14:56:57 +0000

Patrick,

This should not come as a surprise to anyone since it has been discussed on the list and there was no request or agreement to remove it.  The two messages that you reference were formally responded to and any agreed upon changes to the draft were incorporated.  This included removing support for use of the allocation token as an extension to the empty update.  

My response to Alex's message:
https://mailarchive.ietf.org/arch/msg/regext/li8PEBXddEWE-OfbC1ViK4TBzTk
  
My response to your message:
https://mailarchive.ietf.org/arch/msg/regext/uS8L-1DC4eQskcSPI-Bs4aSMp0Y

I certainly don't recommend allocation via the transfer, but I'm aware of use cases where it has been done.  It is not the place for the protocol to dictate the policy.  If you feel that it must be removed, please make a formal request to the list for it's removal and the list can discuss it.    

Thanks,

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com <http://verisigninc.com/> 
On 4/13/18, 10:50 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

     

    
    
    -- 
      Patrick Mevzek
      [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 18 Apr 2018 08:33:30 +0200

On Mon, Apr 16, 2018, at 16:56, Gould, James wrote:
> Patrick,
> 
>     You are right and I share your surprise and doubts, about both 
> update and transfer. update has been removed, transfer is still in the 
> draft.

My phrasing was poor/too quick, sorry about that.
Let me try to rephrase: I was surprised and I had doubt when I first read the specification and see the use of transfer and update commands.
I think that any new reader of this specification may have the same surprises and doubts on these points.

We did discuss it, yes, and you removed the update, notably after Alexander review. So the case is closed for me.

> I certainly don't recommend allocation via the transfer, but I'm aware 
> of use cases where it has been done.  

This is all that is needed to support its definition in the specification.

> It is not the place for the 
> protocol to dictate the policy.  If you feel that it must be removed, 
> please make a formal request to the list for it's removal and the list 
> can discuss it.    

I have different views but I also do not have the use cases you see in front of me so in any case my own personal opinion has no weight.

As a shepherd for this document, my goal is to advance it in the IETF path now, and discussions did already take place, so I will not restart them (other participants are of course free to do it if they wish).

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Wed, 18 Apr 2018 17:09:52 +0000

Patrick,

Thanks, I will post draft-ietf-regext-allocation-token-07 that addresses the two items that you had identified in your review:

  ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942)

  ** Downref: Normative reference to an Informational RFC: RFC 7451

Thanks, 
 
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com <http://verisigninc.com/> 
On 4/18/18, 2:33 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    
    -- 
      Patrick Mevzek
      [email-masked]