Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

Benjamin Kaduk <> Thu, 25 October 2018 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 064B012D4E7; Thu, 25 Oct 2018 10:28:30 -0700 (PDT)
X-Quarantine-ID: <L8PoloVPumRP>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by[...]
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L8PoloVPumRP; Thu, 25 Oct 2018 10:28:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A32A126F72; Thu, 25 Oct 2018 10:28:26 -0700 (PDT)
X-AuditID: 12074423-b8bff70000007822-89-5bd1fd37a406
Received: from ( []) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 27.07.30754.83DF1DB5; Thu, 25 Oct 2018 13:28:25 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.14.7/8.9.2) with ESMTP id w9PHSLR9007126; Thu, 25 Oct 2018 13:28:22 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby (8.14.7/8.12.4) with ESMTP id w9PHSGQv024508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Oct 2018 13:28:19 -0400
Date: Thu, 25 Oct 2018 12:28:16 -0500
From: Benjamin Kaduk <>
To: Linlin Zhou <>
Cc: iesg <>, regext-chairs <>, Pieter Vandepitte <>, regext <>, draft-ietf-regext-org-ext <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hRV1rX8ezHaoOcKs8WyZTNYLWb8mchs 8XfvLGaLl11PmS2uTjjCaPHr40tGBzaPTdckPb5POs/usWTJT6YA5igum5TUnMyy1CJ9uwSu jOl7lrMV3DSsWH+vk6WBcZVGFyMnh4SAiUT3tOvMXYxcHEICa5gkNl9qgnI2Mkos/PmABcK5 yyTx8OJfJpAWFgFViabmdYwgNpuAikRD92VmEFsEKP791HxGkAZmgVeMEhv3rwFrEBbIkTiz 4DAbiM0LtO/F3GYWEFtIoFDi3tVHUHFBiZMzn4DFmQW0JG78ewnUywFkS0ss/8cBEuYU0JOY +28dWLmogLLE3r5D7BMYBWYh6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFumZ6 uZkleqkppZsYQYHN7qK8g/Fln/chRgEORiUe3gnfLkYLsSaWFVfmHmKU5GBSEuVNTAEK8SXl p1RmJBZnxBeV5qQWH2KU4GBWEuHdexsox5uSWFmVWpQPk5LmYFES553YsjhaSCA9sSQ1OzW1 ILUIJivDwaEkwXvyN1CjYFFqempFWmZOCUKaiYMTZDgP0PCDIDW8xQWJucWZ6RD5U4yKUuK8 vH+AEgIgiYzSPLheUOKRyN5f84pRHOgVYd6jIO08wKQF1w2MIaCPRHhnKFwAGVySiJCSamAs mlvglfRU0SrZQ23rq1VlopJ8R6NkvUNK6+Z9NhfsWO94yybc+q0oJ//DHdN3tWwpqE7htGjx SmhwElxnfUtyOZPuN7Xis4pV+wv63pxc+qKg/ZTcr5+G9gn1nM+PxFhv6stLv+l4dc/GF6qc m7alqzMlFM9MPTirl18usO5V2qmZk9kypiqxFGckGmoxFxUnAgCgUu9hFwMAAA==
Archived-At: <>
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Oct 2018 17:28:30 -0000

On Thu, Oct 25, 2018 at 11:29:41AM +0800, Linlin Zhou wrote:
> Dear Benjamin,
> Thanks for your review. Please see my feedbacks below.
> Regards,
> Linlin
> Linlin Zhou
> From: Benjamin Kaduk
> Date: 2018-10-24 03:13
> To: The IESG
> CC: regext-chairs; pieter.vandepitte; regext; draft-ietf-regext-org-ext
> Subject: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-regext-org-ext-09: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I have two points that I would like to discuss.  It is more likely than not
> that at least one of them merely reflects my confusion and is a non-issue,
> but I would like to get these at least clarified.
> First, the examples throughout the document use organization identifiers
> like "myreseller" or "myproxy".  This seems to me to be highly confusing,
> since these IDs are supposed to be server-unique values per organization,
> and are highly unlikely to be "my" reseller/proxy/etc. for all the entries
> in the registry.  If I understand things correctly, the example IDs should
> instead be company-name-like values or "random" numbers or similar (or
> combination thereof).
> [Linlin]  Thank you for pointing out this. To be more consistent with the draft-ietf-regext-org draft, I suggest using the IDs defined in the "org" draft, like "reseller1523" , "registrar1362" or "proxy2935".

Excellent; thank you!

> Second, I am unsure of the semantics relating to role types, especially as
> they interact with the <update> command.  Various aspects of the examples
> seem to imply that it is only permitted to have at most one organization
> mapping of a given role type (i.e., one reseller, one proxy, etc.).  In
> particular, the <orgext:chg> element seems to be using the <orgext:id> role
> attribute to determine which <orgext:id> is being changed (with the new
> value being provided in the element body), and the <orgext:rem> element is
> providing <orgext:id> with only the role attribute and no body to identify
> a specific organization to remove.  If this reading of the document is
> correct, then I would expect the limitation to be called out more clearly,
> especially as it would seem to prevent a domain owner from (e.g.) using
> multiple DNS service operators.
> [Linlin] In the normal business model, for example a domain should have one reseller, one registrar etc.  How about adding some text like "One <orgext:id> element is suggested for each role type." in the element description.

I don't think that addresses my core concern (though it is probably worth
doing in its own right).

In particular, if it is allowed by the protocol/registry to have more than
one <orgext:id> element of a given role type, then several of the protocol
exchanges this document defines within <update> are not fully defined in an
interoperable fashion.  For example, what if I receive a
<orgext:chg><orgext:id role="dns-operator>dns872</orgext:id></orgext:chg>
and there are currently two dns-operators defined?  Do I remove both
existing entries and add the one new one?  Do I remove just one existing
entry and replace it with the new one?  If the latter, how do I pick which
one is to be removed?  I just don't see how the operation is fully
specified for these cases.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Section 1
>    In the business model of domain registration, we usually have 3 roles
>    of entities: a registrant, a registrar and a registry.  There may be
>    other roles of entities involved in the domain registration process
>    which are not formally defined, such as resellers, DNS service
>    operators, privacy proxies, etc.
> nit: Perhaps I am misreading, but are we not going to formally define these
> entities in the next paragraph (in which case "yet" might be worth adding)?
> [Linlin] Yes. "...which are not formally defined yet..."
>    An organization mapping object defined in [ID.draft-ietf-regext-org]
>    SHOULD be created first.  The organization information specified in
>    this document MUST reference the existing organization identifier.
> What does "first" refer to?  "prior to the use of that object"?
> [Linlin] Yes. The organizations object should be created prior to using the organization ID for the extension. Maybe I can change the words to be more clear, "Organization object identifiers MUST be known to the server before the organization object can be associated with the EPP object."

I think that helps; thank you.


> Section 2
>    The XML namespace prefix "orgext" is used, but implementations MUST
>    NOT depend on it and instead employ a proper namespace-aware XML
>    parser and serializer to interpret and output the XML documents.
> [This could probably be written more clearly; see my comment on the
> companion document]
>  [Linlin] I'll update it to use the full namespace.
> Section 9
> IIRC the authorization model for EPP does not allow arbitrary clients to
> retrieve information about arbitrary (unrelated) domains.  If that's not
> the case, there would be privacy considerations with respect to exposing
> the linkages of the organization mappings (and roles).
> [Linlin] Yes. EPP provides a authentication mechanism which is mentioned in RFC5730.
> _______________________________________________
> regext mailing list