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

"Linlin Zhou" <zhoulinlin@cnnic.cn> Wed, 31 October 2018 06:18 UTC

Return-Path: <zhoulinlin@cnnic.cn>
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 169A612777C; Tue, 30 Oct 2018 23:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 o85RFxkCf3hr; Tue, 30 Oct 2018 23:18:41 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id D3968126DBF; Tue, 30 Oct 2018 23:18:37 -0700 (PDT)
Received: from zll (unknown [218.241.111.73]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AZIPw3Sdlb+nUFAA--.4783S2; Wed, 31 Oct 2018 14:18:31 +0800 (CST)
Date: Wed, 31 Oct 2018 14:19:45 +0800
From: "Linlin Zhou" <zhoulinlin@cnnic.cn>
To: "Benjamin Kaduk" <kaduk@mit.edu>
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>
References: <154032201955.31253.2132106938902168352.idtracker@ietfa.amsl.com>, <2018102511294175966596@cnnic.cn>, <20181025172816.GB45914@kduck.kaduk.org>, <2018103010160489184930@cnnic.cn>, <20181031010506.GY45914@kduck.kaduk.org>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <20181031141945204989108@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart256744447784_=----"
X-CM-TRANSID: AQAAf0AZIPw3Sdlb+nUFAA--.4783S2
X-Coremail-Antispam: 1UD129KBjvJXoWxGrWUKF18Jw15urW7KryfWFg_yoWrZw48pF W3G347JF4DXrW7G3s7Cw1UX34UKr97GrW5GFs8Wr1vv3Z8Cw1IqF13tr1ktFyDWryktFyY vrWUtr95Ca4DAFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUHIb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAaz4v2 6cxKscIFY7kG0wAqx4xG6xAIxVCFxsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzxvEb7 x7McIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Y z7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k042 43AVC20s07Mx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_GF1l42xK82IYc2Ij64vI r41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8Gjc xK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0 cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8V AvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF 7I0E14v26r4j6r4UJwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07jw6pPUUU UU=
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/2Hf77zb_jr30rwxfII0wzrLXYyQ>
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 06:18:45 -0000

Dear Benjamin,
Thanks for your input. We believe that relationship between an object and an organization should be 1-to-1, one organization ID with just one role. 1-to-many is an exception for the organization extension. Indeed that is our concern, "the multiple examples may be overkill". Many thanks.
 
Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-31 09:05
To: Linlin Zhou
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext
Subject: Re: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
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