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 > > 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. ) 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... 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 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". (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)? Kind regards Pieter > On 13 Apr 2018, at 15:21, James Galvin <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/ > > 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
