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

Benjamin Kaduk <kaduk@mit.edu> Wed, 31 October 2018 01:05 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 DC5DD1277CC; Tue, 30 Oct 2018 18:05:20 -0700 (PDT)
X-Quarantine-ID: <h-nh8c77-OT2>
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.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 h-nh8c77-OT2; Tue, 30 Oct 2018 18:05:19 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 2EF01130DCB; Tue, 30 Oct 2018 18:05:17 -0700 (PDT)
X-AuditID: 12074424-399ff700000060f3-95-5bd8ffcb076f
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-7.mit.edu (Symantec Messaging Gateway) with SMTP id AD.92.24819.BCFF8DB5; Tue, 30 Oct 2018 21:05:16 -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 w9V15DoB006847; Tue, 30 Oct 2018 21:05:14 -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 w9V157vw012812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Oct 2018 21:05:10 -0400
Date: Tue, 30 Oct 2018 20:05:07 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Linlin Zhou <zhoulinlin@cnnic.cn>
Cc: regext-chairs <regext-chairs@ietf.org>, Pieter Vandepitte <pieter.vandepitte@dnsbelgium.be>, iesg <iesg@ietf.org>, regext <regext@ietf.org>, draft-ietf-regext-org-ext <draft-ietf-regext-org-ext@ietf.org>
Message-ID: <20181031010506.GY45914@kduck.kaduk.org>
References: <154032201955.31253.2132106938902168352.idtracker@ietfa.amsl.com> <2018102511294175966596@cnnic.cn> <20181025172816.GB45914@kduck.kaduk.org> <2018103010160489184930@cnnic.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2018103010160489184930@cnnic.cn>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hRV1j3z/0a0QdcqLotly2awWsz4M5HZ 4u/eWcwWL7ueMltcnXCE0eLXx5eMDmwem65JenyfdJ7dY8mSn0wBzFFcNimpOZllqUX6dglc Gc/n8hccU6g4uNqggXGVVBcjJ4eEgInEnQ27mbsYuTiEBNYwSXxevIkJwtnIKPG19x07hHOX SWL/yb9AGQ4OFgFVifuPy0C62QRUJBq6LzOD2CJA4e+n5jOC1DMLvGKUWP90PStIQligQGLp ku9MIDYv0Lotey6B2UICBxglHu5Tg4gLSpyc+YQFxGYW0JK48e8l2C5mAWmJ5f84QMKcAnoS e1ddBhspKqAssbfvEPsERoFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka65 Xm5miV5qSukmRlBIs7uo7GDs7vE+xCjAwajEw/sg+Ua0EGtiWXFl7iFGSQ4mJVHe8x+vRwvx JeWnVGYkFmfEF5XmpBYfYpTgYFYS4Z1aAVTOm5JYWZValA+TkuZgURLnndiyOFpIID2xJDU7 NbUgtQgmK8PBoSTBu+EfUKNgUWp6akVaZk4JQpqJgxNkOA/Q8EkgNbzFBYm5xZnpEPlTjIpS 4ryNIAkBkERGaR5cLyjlSGTvr3nFKA70ijDvCZAqHmC6gusGxhDQRyK8XOxgg0sSEVJSDYx1 bxilb6So3Ho+zU4mZIfgtARbMWNuh+jEp1OPLf0zRdjp+jarzc/FJk6qZ+n9+062Uk8+bYPz 1KU5TtXFKz8Xf3b66Msz4+rT0qrcg3/V45TTL8Zu6Eya386zJu7QUm7vJ/Uv12X83RZz/eTk E4c+vC2VDrXyu5pvc93BNcjyyMorzWZ8y2uUWIozEg21mIuKEwF4rEWdFAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/2I9liKV21fJ7eZAL2HHQ2sYrDs4>
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: Wed, 31 Oct 2018 01:05:21 -0000

On Tue, Oct 30, 2018 at 10:16:05AM +0800, Linlin Zhou wrote:
> Dear Benjamin,
> I've included my feedbacks inline and removed the clarified items.
> 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
> 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
>  
> > 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.
>  [Linlin] We have discussed the error cases, but may lack of this situation.
> If there are already multiple IDs exist with a particular role, I suggest not changing the object and returning an error code 2305 which means "Object association prohibits operation".

That seems reasonable to me, given that we expect this situation to be
uncommon, and a combination of <orgext:add> and <orgext:rem> should allow
the desired changes to be made more precisely.

> Maybe some words like "An attempt to change an organization ID with a particular role value, when multiple IDs exist with the same role value, does not change the object at all. A server SHOULD notify clients that object relationships need to be checked by sending a 2305 error response code. "
> 
> 

I would suggest a little more lead-in text, maybe like:

It is expected to generally be the case that any given object will have at
most one associated organization ID for any given role value, though the
registry semantics do permit two or more associated organizations for a
given role.  In such cases, certain <orgext:chg> and <orgext:rem>
elements may not uniquely specify an operation to perform (e.g., which of
two organizations to replace via <orgext:chg>, or which of two
organizations to remove via an <orgext:rem> with empty body).  An attempt
to change an organization ID with a particular role value, when multiple
IDs exist with the same role value, does not change the object at all. A
server SHOULD notify clients that object relationships need to be checked
by sending a 2305 error response code.

Feel free to edit as you see fit; my only concern is that the expected
behavior is specified, not how it is written.  (In particular, given how
uncommon this situation is expected to be, the multiple examples may be
overkill.)

-Benjamin