Dear Pieter,
Thanks for your support. I'll update the text according to your comments. 
Please see some my feedbacks inline.

From: Pieter Vandepitte
Date: 2018-04-13 22:06
To: James Galvin
CC: Registration Protocols Extensions
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
I don't want to delay the publication, and I support it, but there are still 
some issues/concerns


EPP provides two commands to retrieve domain information
Should be: "EPP provides two commands to retrieve organization information". 

   This document does not define a mapping
   for the EPP <transfer> command to retrieve domain-object transfer
   status information..

change domain-object to organization-object
[Linlin] These typos will be modified.

   EPP provides four commands to transform organization object
   information: <create> to create an instance of an organization
   object, <delete> to delete an instance of an organization object,
   <transfer> to manage organization-object sponsorship changes, and
   <update> to change information associated with an organization
   object.  This document does not define a mapping for the EPP
   <transfer> and <renew> command.

It should be three commands. (Also remove the part " <transfer> to manage 
organization-object sponsorship changes,"). 
(I'm even not sure that the draft should not support transfer. )

[Linlin] Yes. Words will be updated.

In 4.2.1:

   o  A <org:status> element that contains the operational status of the
      organization, as defined in Section 3.4.

I think it's zero, one or more org:status elements. It can be 
clientUpdateProhibited and clientDeleteProhibited at the same time for 
[Linlin]  I'd like to change the text to "Zero or more OPTIONAL org:status 

Food for thought:

Postal Info

(1) Why do we still stick to the original model of contacts as the new model 
for organization, with postal info is required (and within the postalInfo, name 
and address is required)? I think, we should be very cautious when making 
attributes required. If it's required for the protocol, I agree, but this is 
not the case. It's more a policy thing, which must be described in other 
documents (like ICANN policy documents). E.g. at .be, we are considering to 
model resellers, but we don't need the address, only the URL. Moreover, this 
original contact model can potentially become problematic in the context of 
GDPR (although i don't see a lot of issues with reseller contact data)

(2) I would not define a postalInfo type. The sole purpose as far as I can 
think of, is to make the postal info legible for people that use ascii script 
in their language (transliteration). If transliteration would be the use case, 
I would not restrict that to transliterations between ascii and "the rest", but 
then I would define a "script" or "lang" tag, which defines the script of the 
postal info, and allow zero to infinite postalInfo elements to allow multiple 
transliterations (not only to us-ascii).
( As a side note: I always struggled with the "int" type. For me, "Int" = 
"international" = any script / character set allowed, which is the opposite)

(3) As mentioned in a previous post, I still doubt the need for different 
contact types within an organization, but let's make abstraction of that... 
Can't the organization's postalInfo data be modeled as a linked contact? Much 
[Linlin] As I expalined before, our requirements was to have a reseller 
extension with its own contacts and hierarchy. So we keep the postInfo part of 
RFC5733 to store the address information. For most of the registries and 
registrars, this structure is more familiar with them. 

Organization Roles

(1) Although I doubt the need for a roleid, I think we should either remove it, 
or extend it. The role id is the id of the organization in a third party source 
(e.g. in case of a Registrar, IANA is a third party source, and id is "the 
IANA-id"). It is IMO possible that an object is known in different sources with 
different "IDs"
So, for completeness, the org:roleid should have an attribute indicating the 
authoritative source of the id, in case of a Registrar IANA id, it could be 
[Linlin] Until now, the optional is only used for the IANA-id. I am not sure 
what are other sources to get the roleid? 

(2) As I understand, organization roles can be used in links. But what if a 
link exists for a specific role, and the organization role is removed 
afterwards from the organization? As I understand from James in a previous 
reply to Patrick, this should match (in fact it's a MUST). This is not 
described as far as I can see. Wouldn't it be a good idea, in order to have a 
unambiguous understanding, to describe that in draft-ietf-regext-org-ext 
(create, update) and in draft-ietf-regext-org (update, delete)? 
[Linlin] There are some words in section 4.2.2 "An organization object MUST NOT 
be deleted if it is associated with other known objects.  An associated 
organization MUST NOT be deleted until associations with other known objects 
have been broken." I am not sure if this is ok for you.

Kind regards


On 13 Apr 2018, at 15:21, James Galvin <> wrote:

The document editors have indicated that the following document is ready for 
submission to the IESG to be considered for publication as a Proposed Standard:

Extensible Provisioning Protocol (EPP) Organization Mapping

Please indicate your support for the publication of this document.

If any working group member objects to the publication of this document please 
respond on the list by close of business everywhere, Friday, 27 April 2018.  If 
there are no objections the document will be submitted to the IESG.

During the last call the chairs are looking for a document shepherd for this 
document.  If you are interested in being the document shepherd please let the 
chairs know.  The document editors cannot be the document shepherd.

If you’ve never been a document shepherd before don’t worry.  It’s a great way 
to understand the IETF process and your chairs would be delighted to help you 
through it.


Antoin and Jim
WG Co-Chairs

regext mailing list

regext mailing list

Reply via email to