Does anyone have an idea what the chances are that the org extension will 
become a standard? Time frame? Big changes meanwhile likely?

We're currently evaluating whether we should implement the draft, or just 
implement a custom extension...



> On 05 Jan 2018, at 03:47, Linlin Zhou <> wrote:
> Dear Pierter,
> Thanks for your comments. Please find my feedback below.
> Regards,
> Linlin Zhou
> From: Pieter Vandepitte <>
> Date: 2018-01-05 02:22
> To: <>
> Subject: Re: [regext] My review of draft-ietf-regext-org and 
> draft-ietf-regext-org-ext
> Hi all,
> In general, I share the same vision as Patrick. For me, the organization role 
> thing is still unclear to me. Especially its relation with the orgext:id 
> links from other entities to the organization.
> I think this needs further explanation in the draft, if necessary with some 
> ascii art drawings to explain the model.
> Maybe a bit late as I only very recently started following the list, but if I 
> would have to come up with an organization model:
> Organisations are entities:
> linked to 1 or multiple contacts. I would remove the org:postalInfo in favour 
> of a list of contacts, which is already in the current model. The 
> org:postaInfo is also a contact, so redundant and could be moved to the list 
> of contacts. Moreover, it is useful to describe the type of contact, which is 
> not possible to explicitly describe with the org:postalInfo element (is it 
> the internal contact, tech contact, public contact?)
> having zero, one or multiple relations with other organizations. In my 
> opinion a role is a property of the relation an organization has with another 
> organization. E.g. X could be reseller of Y and at the same time registrar of 
> Z (yes, I would even create an object for the current registry Z, which 
> allows to exchange registry contact information with the registrar using 
> org:info). So I would remove the parentId and the role thing in favour of a 
> new multi-occurence "link" element of organization, having a role and an 
> orgid attribute.
> On the other hand, other entities like domains, contacts, hosts can also have 
> 0 or more relations with an organization (which is basically what's in the 
> other draft)
> [Linlin] 1. We take an organization as a entity that may have some contacts 
> and have its own postal information. Contacts have a "type" attribute. The 
> type values include "admin", "tech", "billing", "abuse", and "custom".
> 2. Until now, there seems no explicit need to create a "registry" 
> organization. I can undrerstand your thought, but it's hard to say whether 
> this is a proper solution. 
> 3. Yes.
> Maybe not related to the review of the draft (but related to the draft 
> itself): What is the purpose of this draft? It seems that it aims to build a 
> model for all organisations involved in the domain name registration 
> business, which I doubt there is a need for... But correct me if I'm wrong :-)
> I think there is a need to link more contact information to a registration 
> (and to a greater extent any EPP object). Contact information like reseller, 
> proxy services, ...
> So why not stick to that purpose and simply extend the contactAttrType for 
> contact role with values like "reseller", "proxy", ... and link a domain to a 
> contact using these new values? 
> [Linlin] The org drafts have been discussed for a long period of time. From 
> the very beggining, our requirements was to have a reseller extension for the 
> existing objects to show the whois information of some resellers. Then we 
> found that reseller may have its own contacts and hierarchy. So the 
> reseller-ext and a new reseller object drafts were submitted. WG had many 
> voices, reuse contacts, reseller object, generic object, etc.. Creating a 
> generic organization object was finally selected as the WG direction. So the 
> authors modified the whole reseller object to organization object. Making 
> extensions for EPP is a mechanism according to RFC3735. Revising the RFC5733 
> seems not to be a very practical way.
> Kind regards
> Pieter
>> On 27 Dec 2017, at 07:02, Patrick Mevzek < 
>> <>> wrote:
>> Hello authors,
>> Please find my review of your two drafts.
>> I do not think they are ready for WG last call yet.
>> =================================================================================
>> draft-ietf-regext-org
>> =================================================================================
>> * Abstract: "provisioning and management of organization object"
>> I would says objects in plural is more logical.
>> * 1. Introduction
>> Same remark about the plural.
>> "There are many domain entities" : maybe drop domain here?
>> Like: There are many entities 
>> Also I have mixed feelings on "These kind of entities have not been formally
>>   defined in EPP"
>> This is not true for registrar, for example, it is clearly defined in 
>> RFC3375.
>> So you will need to rephrase your paragraph.
>> * 3) I do not understand "can be viewed and modified by the sponsoring 
>> client or the server."
>> Why do you specify "or the server." ?
>> The fact that the registry can view the data seem quite obvious but what
>> are you trying to infer by speaking about server modifications?
>> I think it would be far simpler to just remove "or the server."
>> "This section describes each attribute type in detail."
>> You can remove "type" I think.
>> * 3.1
>> "Organization identifiers are character strings with a specific
>>   minimum length, a specified maximum length, and a specified format.
>>   Organization identifiers use the "clIDType" client identifier syntax
>>   described in [RFC5730]."
>> The clIDType in RFC5730 specifies a minimum and maximum length but no format,
>> just that it is a token. So the sentence is kind of wrong.
>> * 3.2
>> This does not seem clear enough to me.
>> I have to wait for further examples down below to better understand this
>> But did not found enough examples or further explanations,
>> so all of this is confusing to me.
>> * 3.2.1
>> "Its corresponding element is <org:type> with an
>>   "roleStatus" attribute."
>> => a instead of an I think
>> In fact the whole of 3.2 / 3.2.1 / 3.2.2 feels very complicated and not 
>> clear to me.
>> * 3.3 what does this section has to do with the rest of the document?
>> * 3.4
>> "terminated: The organization has been terminated MUST NOT be
>>      linked."
>> => and is missing before MUST NOT?
>> * 3.6 "the parent identifier is
>>   not defined for the top level reseller, namely the registrar of the
>>   registry."
>> I am not absolutely sure that registrars would be happy to be depicted as 
>> just resellers of the registry, and also I am not sure what this sentence
>> adds to the protocol.
>> * also in section 3 somewhere you should speak about timestamps
>> since you have crDate, etc.
>> See ยง2.4.  Dates and Times for example in RFC5731.
>> * 4.1
>> "EPP provides two commands" 
>> It is instead 3 if you add the <transfer> case, so you should rephrase that
>> paragraph.
>> * 4.1.2
>> "A <org:status> element"
>> Only one status available here?
>> If multiple allowed, you have to fix this sentence and the associated XML 
>> schema.
>> "   Example <info> response for "Example Registrar Inc." registrar object
>>   with registrar identifier "1362":"
>> Maybe instead to be more inline with the rest of the document:
>>   Example <info> response for "Example Registrar Inc." organization object
>>   with organization identifier "1362":
>> And then below the example has:
>> <org:id>registrar1362</org:id>
>> So the text above should probably more be:
>> with organization identifier "registrar1362"
>> Same kind of changes for the later examples which follow a similar 
>> introducing
>> sentence.
>> * 4.2.
>> Why don't you count the renew command as one transform command?
>> (even if you speak about it further down)
>> * 4.2.1
>> A <org:status> element
>> Same remark/question as above in 4.1.2
>> "A <org:crDate> element that contains the date and time of
>>      organization-object creation."
>> => organization object instead of organization-object
>> * 4.2.5
>> I have the same issue as above related to your handling of status.
>> You again seem to imply it can appear once, and hence be handled through 
>> <chg>
>> However rereading 3.4 it seems totally legit for me for example to have
>> clientLinkProhibited
>> clientUpdateProhibited
>> clientDeleteProhibited
>> if the sponsoring registrar so wish.
>> So you either need to specify somewhere that only one status value can exist
>> at any time (and then you will have multiple other problems) or you will
>> need to update all your documents as reviewed earlier to allow multiple
>> status values at the same time, and then also change it to be handled through
>> add/rem and not with chg.
>> You also have a "bullet" problem as your document renders as:
>> o
>>      *  A <org:name> 
>> So, something missing after the o, or an indentation problem.
>> Your example is not clear, with:
>> <org:status>ok</org:status>
>> since in 3.4 you say that the ok value is put or removed by the server
>> (implying it is not handled by the client).
>> * 7.3
>> "The entity object instance represents a third-party who
>>      could help to register a domain without exposing their private
>>      information."
>> This is not clear, what does "their" reference in this sentence?
>> * 8 Implementation status
>> Net::DRI implements a previous version of your drafts. If interested I could 
>> try to update it so that you can add it there. Please let me know what you 
>> think and if you do reference it please use the software name instead of my 
>> own personal name.
>> =================================================================================
>> draft-ietf-regext-org-ext
>> =================================================================================
>> * The abstract seem wrong: "this
>>   extended mapping is applied to provide additional features required
>>   for the provisioning of organizations."
>> This document deals with "linking" specific organization IDs to other 
>> objects,
>> not provisioning it. It seems a sentence copied from the other document but
>> it has no sense here. On the contrary you should more specifically link to 
>> the
>> other document to clearly explain how they interoperate.
>> * A organization mapping object defined in
>> => An organization
>> * 4.1.2 "However, additional elements are
>>   defined for the <info> response."
>> => you should specify if this is for domain, host or contact since just in 
>> the previous
>> sentence you took care to specify that you do not add anything to the domain 
>> contact and host
>> info commands.
>> * 4.1.2 "if the object has data associated with this
>>   extension and based on its service policy."
>> Do you mean *registry* service policy? The its seem to refer to the object.
>> * 4.1.2 "A <orgext:id> element that contains"
>> This is not consistent where the example below where you have 2 elements.
>> So the text should say something like "One or more <orgext:id> element..."
>> The related schema is also wrong since you have minOccurs=0
>> It is doubly inconsistent since having no id at all makes an empty extension
>> so no use; and on the contrary you want to have more than one.
>> So please make text, example and schema consistent from each other.
>> Are you sure in fact that the schema is correct? Does the role attribute
>> really apply to the id element, I am not sure this is what I read from the 
>> schema,
>> there it seems to apply to the outermost enclosing element.
>> You should have a look in RFC5730 for example on how domain:contact are 
>> defined
>> in a domain:create or domain:info
>> * 4.2.1 You should specify if you speak about domain, contact or host 
>> objects.
>> You have the same problem I think than in 4.1.2. The schema (maybe wrong, 
>> see same
>> remark above) seems to allow only one id element, is this really what you 
>> want?
>> * 4.2.4 I was not sure to understand what you say in:
>> "the handling of the assigned organization is dependent
>>   on the organization roles and server policy." can you elaborate?
>> Also you speak about "an assigned organization" so you do not consider more 
>> than one?
>> * 4.2.5 I am not sure to understand the difference between add+rem and chg, 
>> except that
>> it seems you allow only one id per type, hence the chg case. If that is so,
>> please explicitely say so, even before in the document. If not, please 
>> explain the difference
>> between doing an add or rem and doing a chg.
>> In light of what I reiterated above, please specify what is happening if 
>> there
>> are already more than one id attached to the object, and even more if there 
>> are more
>> than one per role.
>> The schema specification for update has the same problem as above regarding
>> the cardinality of the id element and the position of the role attribute. 
>> Please
>> double check that. Explain what minOccurs=0 could do as this could result 
>> into
>> an empty <add> or empty <rem> or empty <chg>
>> * 6 Internationalization Considerations
>> I do not understand this section. How does this document add anything related
>> to this from what is already in core EPP? You seem to have copied what is 
>> there
>> which does not add value.
>> This sentence has a problem also:
>> "As an extension of the EPP domain name mapping, the elements, element
>>   content described in this document MUST inherit..."
>> * 8 Implementation status
>> Net::DRI implements a previous version of your drafts. If interested I could 
>> try to update it so that you can add it there. Please let me know what you 
>> think and if you do reference it please use the software name instead of my 
>> own personal name.
>> Other generic points:
>> - please specify what is happening if the client uses a value for the role 
>> attribute that is not supported by server policy, how should it react?
>> - same if client uses an organization ID during create/update that does not 
>> exist at registry side
>> - in the schema the role value is just an XML token whereas in your text you 
>> refer to section 7.3 of the other document for the list of values. I expect 
>> the XML schema to also reflect that. You should probably define it in the 
>> schema of the "org" element and have the XML schema in the "orgext" document 
>> refer to the one in the "org" document. Like EPP has "epp" and "eppcom" 
>> schema, and "eppcom" is refered from various domain/host/contact XML schema.
>> - "Organization Extension", and associated "orgext" short name do not seem 
>> specific enough
>> for me. Maybe you could try to find something more precise? In fact same 
>> problem for the other document.
>> - maybe explain if organization ID are global inside the registry or per 
>> registrar; so what happens if registrar X creates an orgnization and 
>> registrar Y uses it for domains it manages.
>> ===================================================================
>> comments related to both
>> ===================================================================
>> I am more than a little fuzy about your "role" uses.
>> When you create an organization you specify a role,
>> and then when you create/update a domain to add an organization you again 
>> specifcy a role.
>> Are they the same or different? Why do they need to be repeated?
>> This whole idea of "role" will need to be seriously improved in both 
>> documents.
>> -- 
>>  Patrick Mevzek
>> _______________________________________________
>> regext mailing list
>> <>

regext mailing list

Reply via email to