Thanks Linlin!

Seems OK for me

> Zero or more OPTIONAL org:status elements

Optional here is not necessary, since it's zero, imo, but maybe sometimes you 
can't be explicit enough i think ;-)

Kind regards


> On 16 Apr 2018, at 11:52, Linlin Zhou <> wrote:
> Dear Pieter,
> Thanks for your support. I'll update the text according to your comments. 
> Please see some my feedbacks inline.
> Regards,
> Linlin
> <>
> 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
> Typos/errors
>> 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 
> instance...
> [Linlin]  I'd like to change the text to "Zero or more OPTIONAL org:status 
> elements".
> 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 
> simpler
> [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 
> "iana". 
> [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
> Pieter
>> 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.
>> Thanks,
>> Antoin and Jim
>> WG Co-Chairs
>> _______________________________________________
>> regext mailing list

regext mailing list

Reply via email to