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... 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 <mailto:pieter.vandepi...@dnsbelgium.be> > Date: 2018-01-05 02:22 > To: regext@ietf.org <mailto: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 >> <mailto: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 <mailto:regext@ietf.org> >> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
