Op 13 apr. 2018, om 14:13 heeft Pieter Vandepitte 
<pieter.vandepi...@dnsbelgium.be> het volgende geschreven:
> 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...

Hi Pieter,

We’re actually issuing a WGLC today for these documents. So it’s one final 
round of review for 2 weeks, and then when enough WG participants support 
publication, it will be submitted to the IESG.
So if you’re waiting for it, be sure to voice your support during WGLC, and 
volunteer to be the document shepherd ;-).

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392

> kr.
> Pieter
>> On 05 Jan 2018, at 03:47, Linlin Zhou <zhoulin...@cnnic.cn> 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: regext@ietf.org
>> 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 <p...@dotandco.com> 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/regext
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

regext mailing list

Reply via email to