[regext] RFC 8495 on Allocation Token Extension for the Extensible Provisioning Protocol (EPP)

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 8495

Title:  Allocation Token Extension for the 
Extensible Provisioning Protocol (EPP) 
Author: J. Gould,
K. Feher
Status: Standards Track
Stream: IETF
Date:   November 2018
Mailbox:jgo...@verisign.com, 
i...@feherfamily.org
Pages:  17
Characters: 31441
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-regext-allocation-token-12.txt

URL:https://www.rfc-editor.org/info/rfc8495

DOI:10.17487/RFC8495

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

This document is a product of the Registration Protocols Extensions Working 
Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] REGEXT Interim Meeting 2018OCT16

[Gould, James]

Patrick,

Please review the latest version of draft-gould-carney-regext-registry, since I 
believe it has changes that are applicable to your feedback (e.g., batch 
schedule, host attribute support).  I provide my responses to your feedback 
below.  
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 11/26/18, 8:02 PM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Nov 26, 2018, at 13:58, Roger D Carney wrote:
>  * I still don’t like the use of the  elements as a 
> “flexible mechanism to share data between the client and the server”. 

There are many registries going this route, and it is very sad, even
if easy to understand why.
It voids any usefulness of the schema attached to the (XML) documents,
and basically will only need to interoperability problem because this 
content
will not be described in an automated content, and relying on human
documentation is not enough.

I agree that the key, value pair approach is an anti-pattern that has been 
tried before without success.  

> * The schedule format to use with the  
>  element 
> * 
> *Discussion*
>  * This particular topic is not straight forward, since we need a 
> condensed mechanism to define the batch schedules. 

I do not see why "condensed". We are in XML land already, which is not
known for its small size anyway so why would there be a need here to
condense things?

The key is not the word "condensed", but "effective".  Please review the latest 
update to the approach taken for the schedule in 
draft-gould-carney-regext-registry-04.  

> * Ensure that the hostAddr model of RFC 5731 is supported 
> * 
> *Discussion*
>  * In the case of a zone that supports domain:hostAddr instead of 
> domain:hostObj, 

No. It is not "instead".
Have a look at the example on page 19 of some registry documentation
at 
https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf

You will see that both options can cohabit.

Now, I already know that some people will say: this is not allowed per EPP 
specifications.

But besides that it is important to be clear on the purpose of this 
extension:
being as "pure" and perfect as possible, with the hope that non-conforming 
current
cases will then suddenly decide to fix their thing in order to be able to 
use it, or
being as inclusive as possible so that as many registries as possible are 
using it
as is.

I think this extension can be very useful if many registries implement it.
If it is only a few, it will not give registrars a lot of useful data, and 
hence
they will not profit from it.

And I do not think that "not conforming" cases will feel the need to change 
just
to be able to implement this extension.

This is a generic point I may try to raise again later in the past threads 
about
this extension. It is an important question, that is itself tied to the 
amount
of energy devoted to each extension, which extension becomes working group 
documents
and which extensions really solve problem of more than one registry and 
hence
may have the chance to be implemented by a sizeable chunk of current 
players.

The purpose of draft-gould-carney-regext-registry and the policy extensions is 
to define the policies around the SHOULDs, MAYs, and options included in 
extension RFCs, I-Ds, custom extensions, and to define the server-specific 
policies.  If a registry chooses not to follow the MUSTs in the extensions, 
that is their choice.  They can define their custom, non-compliant policies in 
a server-specific policy extension of draft-gould-carney-regext-registry.  
Custom policy extensions can be created that define system-level and zone-level 
policies that don't need to go through the IETF.  There is no need to attempt 
to address non-compliant policies in the standards track I-Ds.  

HTH,

-- 
  Patrick Mevzek

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext