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 Pieter > On 16 Apr 2018, at 11:52, Linlin Zhou <zhoulin...@cnnic.cn> wrote: > > Dear Pieter, > Thanks for your support. I'll update the text according to your comments. > Please see some my feedbacks inline. > > Regards, > Linlin > zhoulin...@cnnic.cn <mailto:zhoulin...@cnnic.cn> > > From: Pieter Vandepitte <mailto:pieter.vandepi...@dnsbelgium.be> > Date: 2018-04-13 22:06 > To: James Galvin <mailto:gal...@elistx.com> > CC: Registration Protocols Extensions <mailto:regext@ietf.org> > 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 >> <https://tools.ietf.org/html/draft-ietf-regext-org-02#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 <gal...@elistx.com >> <mailto:gal...@elistx.com>> 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 >> https://datatracker.ietf.org/doc/draft-ietf-regext-org/ >> <https://datatracker.ietf.org/doc/draft-ietf-regext-org/> >> >> 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@ietf.org >> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
