Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Thu, 25 October 2018 17:28 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064B012D4E7; Thu, 25 Oct 2018 10:28:30 -0700 (PDT)
X-Quarantine-ID: <L8PoloVPumRP>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8PoloVPumRP; Thu, 25 Oct 2018 10:28:28 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A32A126F72; Thu, 25 Oct 2018 10:28:26 -0700 (PDT)
X-AuditID: 12074423-b8bff70000007822-89-5bd1fd37a406
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 27.07.30754.83DF1DB5; Thu, 25 Oct 2018 13:28:25 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id w9PHSLR9007126; Thu, 25 Oct 2018 13:28:22 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (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 <kaduk@mit.edu>
To: Linlin Zhou <zhoulinlin@cnnic.cn>
Cc: iesg <iesg@ietf.org>, regext-chairs <regext-chairs@ietf.org>, Pieter Vandepitte <pieter.vandepitte@dnsbelgium.be>, regext <regext@ietf.org>, draft-ietf-regext-org-ext <draft-ietf-regext-org-ext@ietf.org>
Message-ID: <20181025172816.GB45914@kduck.kaduk.org>
References: <154032201955.31253.2132106938902168352.idtracker@ietfa.amsl.com> <2018102511294175966596@cnnic.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2018102511294175966596@cnnic.cn>
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: <https://mailarchive.ietf.org/arch/msg/regext/1YIW6o-8E9AOLbZfjAabPEwn0DM>
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=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 https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 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. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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. -Benjamin > 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 > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
- [regext] Benjamin Kaduk's Discuss on draft-ietf-r… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Gould, James
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou