Organization Extension for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-org-ext-11

[Ballot comment]
Thank you for addressing my Discuss points!

[Original Comment section preserved below]

Section 1

  In the business model of domain registration, we usually have 3 roles
  of entities: a registrant, a registrar and a registry.  There may be
  other roles of entities involved in the domain registration process
  which are not formally defined, such as resellers, DNS service
  operators, privacy proxies, etc.

nit: Perhaps I am misreading, but are we not going to formally define these
entities in the next paragraph (in which case "yet" might be worth adding)?

  An organization mapping object defined in [ID.draft-ietf-regext-org]
  SHOULD be created first.  The organization information specified in
  this document MUST reference the existing organization identifier.

What does "first" refer to?  "prior to the use of that object"?

Section 2

  The XML namespace prefix "orgext" is used, 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.

[This could probably be written more clearly; see my comment on the
companion document]

Section 9

IIRC the authorization model for EPP does not allow arbitrary clients to
retrieve information about arbitrary (unrelated) domains.  If that's not
the case, there would be privacy considerations with respect to exposing
the linkages of the organization mappings (and roles).

[Ballot comment]
If "huh?" was a ballot position, I would have used it. I'm actually too confused to ballot Discuss :-)

I see several subsections of the form

  This extension does not add any elements to the EPP  command
  or  response described in the EPP object mapping.

I see other subsections in the same section that say what the extension DOES, not just what the extension does not do.

Is there anything that can be included in these sections to tell the reader more about what the effect of using the extension actually is?

[Ballot comment]
If "huh?" was a ballot position, I would have used it. I'm actually too confused to ballot DIscuss :-)

I see several subsections of the form

  This extension does not add any elements to the EPP  command
  or  response described in the EPP object mapping.

I see other subsections in the same section that say what the extension DOES, not just what the extension does not do.

Is there anything that can be included in these sections to tell the reader more about what the effect of using the extension actually is?

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3938



COMMENTS
S 4.2.1.
>      C:          fooBAR
>      C:       
>      C:     
>      C:   
>      C:   
>      C:      <orgext:create

FWIW, this would be easier to read if the new fields were decorated in
some way.

[Ballot comment]
Thanks for the work on this. I have a few comments:

*** Substantive Comments ***

§1: "An organization mapping object defined in [ID.draft-ietf-regext-org]
SHOULD be created first."

First before what?

*** Editorial Comments ***

- General:
I'm a little confused by the split in material between draft-ietf-regext-org and draft-ietf-regext-org-ext, especially how the command mapping and related info seems to span both documents. It seems a bit reader-unfriendly. But it's late enough in the process that it's probably not worth changing.

- Abstract: Please expand EPP on first mention both in the abstract and in the body.

§2, 3rd paragraph:  I know we are not consistent about this, but I find the word “conforming” to be a red flag. Standards track RFCs should be about interoperability, not conformance. I suggest striking all after “presented”.

[Ballot discuss]
I have two points that I would like to discuss.  It is more likely than not
that at least one of them merely reflects my confusion and is a non-issue,
but I would like to get these at least clarified.

First, the examples throughout the document use organization identifiers
like "myreseller" or "myproxy".  This seems to me to be highly confusing,
since these IDs are supposed to be server-unique values per organization,
and are highly unlikely to be "my" reseller/proxy/etc. for all the entries
in the registry.  If I understand things correctly, the example IDs should
instead be company-name-like values or "random" numbers or similar (or
combination thereof).

Second, I am unsure of the semantics relating to role types, especially as
they interact with the  command.  Various aspects of the examples
seem to imply that it is only permitted to have at most one organization
mapping of a given role type (i.e., one reseller, one proxy, etc.).  In
particular, the  element seems to be using the  role
attribute to determine which  is being changed (with the new
value being provided in the element body), and the  element is
providing  with only the role attribute and no body to identify
a specific organization to remove.  If this reading of the document is
correct, then I would expect the limitation to be called out more clearly,
especially as it would seem to prevent a domain owner from (e.g.) using
multiple DNS service operators.

[Ballot comment]
Section 1

  In the business model of domain registration, we usually have 3 roles
  of entities: a registrant, a registrar and a registry.  There may be
  other roles of entities involved in the domain registration process
  which are not formally defined, such as resellers, DNS service
  operators, privacy proxies, etc.

nit: Perhaps I am misreading, but are we not going to formally define these
entities in the next paragraph (in which case "yet" might be worth adding)?

  An organization mapping object defined in [ID.draft-ietf-regext-org]
  SHOULD be created first.  The organization information specified in
  this document MUST reference the existing organization identifier.

What does "first" refer to?  "prior to the use of that object"?

Section 2

  The XML namespace prefix "orgext" is used, 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.

[This could probably be written more clearly; see my comment on the
companion document]

Section 9

IIRC the authorization model for EPP does not allow arbitrary clients to
retrieve information about arbitrary (unrelated) domains.  If that's not
the case, there would be privacy considerations with respect to exposing
the linkages of the organization mappings (and roles).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-org-ext-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new registration will be made as follows:

ID: epp:orgext-1.0
URI: urn:ietf:params:xml:ns:epp:orgext-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the schema registry also on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new registration will be made as follows:

ID: epp:orgext-1.0
URI: urn:ietf:params:xml:schema:epp:orgext-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this request also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the Extensions for the Extensible Provisioning Protocol (EPP) registry located at:

https://www.iana.org/assignments/epp-extensions/

a single, new registration will be made as follows:

Name of Extension: Organization Extension for the Extensible Provisioning Protocol (EPP)
Document Status: [ To be taken from the published document ]
Reference: [ RFC-to-be ]
Registrant: IESG [ iesg@ietf.org ]
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None

As this request also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-10-08):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, draft-ietf-regext-org-ext@ietf.org, regext-chairs@ietf.org, pieter.vandepitte@dnsbelgium.be, Pieter Vandepitte , regext@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Organization Extension for the Extensible Provisioning Protocol (EPP)) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Organization Extension for
the Extensible Provisioning Protocol (EPP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-10-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes an extension to EPP object mappings, which is
  designed to support assigning an organization to any existing object
  (domain, host, contact) as well as any future objects.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/ballot/


No IPR declarations have been submitted directly on this I-D.

This is a write-up for the draft-ietf-regext-org-08 and draft-ietf-regext-org-ext-07
documents as they belong together and were reviewed and treated as one work item.

1. Summary
 
The document shepherd is Pieter Vandepitte, pieter.vandepitte@dnsbelgium.be
The responsible Area Director is Adam Roach, adam@nostrum.com
 
The documents are submitted for consideration as a Proposed Standard:
they have received community review and are of interest to multiple parties as
they cover a basic need among domain name registrars and registries.

Original work for the documents started as a need to register resellers for
domain names to be represented in Whois and RDAP. The working group concluded
that the objective was too limited to justify the introduction of a new EPP
object, as they remarked that future organization roles other than resellers
would each require their own EPP object. Furthermore, if each role would be
represented by its own object, it would lead to a proliferation of different
objects, some of them representing the same organization. This would make it
hard to maintain and potentially lead to errors. Therefore, these Internet drafts
define an organization object which can be assigned multiple roles, and
role types are standardized in an IANA registry to prevent a proliferation of role
types across registries.

The draft-ietf-regext-org-08 document describes an
Extensible Provisioning Protocol (EPP) mapping for provisioning and management
of organization objects stored in a shared central repository.  Specified in
Extensible Markup Language (XML), this extended mapping is applied to provide
additional features required for the provisioning of organizations.
 
The draft-ietf-regext-org-ext-07 document describes an extension to EPP object
mappings, which is designed to support assigning an organization to any existing
object (domain, host, contact) as well as any future objects.

Both documents are an extension of the core EPP specifications
in STD 69. They use the framework outlined in RFC 3735
"Guidelines for Extending the Extensible Provisioning Protocol (EPP)",
to extend some EPP operations by exchanging a new piece of information,
the organization object. 
 
Both documents written with the usual set of sections in the expected order like
other documents extending EPP, in order to make its reading simpler for future
implementors.
 
The documents follow the RFC style described in RFC 7322 and do not introduce
new security considerations besides the new existing in the core EPP RFCs.
 
All references have been identified as either normative or informative.
There are no normative references on documents with unclear state and no
downward normative references.
 
2. Review and Consensus
 
Both documents have been discussed on the mailing lists and various IETF meetings
of the regext working group. The authors have addressed all comments and changes
have been incorporated in the documents. The documents have been updated several
times during the WGLC due to several thorough reviews.
 
Verisign and CNNIC have working implementations of the specifications and at least
2 other Registry operators have plans or are interested in implementing the
specifications.
 
3. Intellectual Property
 
The author has confirmed following BCP 78 and BCP 79 in the document header.
No IPR disclosures have been submitted for the documents.
 
4. Other Points
 
All EPP XML examples have been validated against the XML schema provided
in the drafts by the Document Shepherd.
 
Each document requests IANA to register a new XML namespace URI and the
XML schemas for the namespace definitions. Additionally it requests IANA
to insert the document in the EPP Extension Registry, per RFC 7451.
 
The draft-ietf-regext-org-08 document requests IANA to create a new protocol registry to
manage organization roles.  All requirements for such a request have been
met.  A detailed review by IANA is suggested.