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

"Linlin Zhou" <zhoulinlin@cnnic.cn> Tue, 06 November 2018 01: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 A169A126DBF; Mon, 5 Nov 2018 17:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 yUSunAFj5XJ6; Mon, 5 Nov 2018 17:18:31 -0800 (PST)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 76A46130FB1; Mon, 5 Nov 2018 17:18:26 -0800 (PST)
Received: from Admin-THINK (unknown [159.226.7.2]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BJUKDV6+BbiD8AAA--.272S2; Tue, 06 Nov 2018 09:18:15 +0800 (CST)
Date: Tue, 6 Nov 2018 09:18:13 +0800
From: "Linlin Zhou" <zhoulinlin@cnnic.cn>
To: jgould <jgould@verisign.com>, "kaduk@mit.edu" <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>, <20181031141945204989108@cnnic.cn>, <20181031124321.GH45914@kduck.kaduk.org>, <2018110111280976085295@cnnic.cn>, <20181101222859.GH45914@kduck.kaduk.org>, <B567C9E4-BF56-4BB0-8081-27264947C1F7@verisign.com>
X-Priority: 3
X-GUID: FD2AE64C-39C2-4CFE-AC40-5F8B775CF908
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 7, 21[cn]
Mime-Version: 1.0
Message-ID: <201811060918110034890@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart762468142063_=----"
X-CM-TRANSID: AQAAf0BJUKDV6+BbiD8AAA--.272S2
X-Coremail-Antispam: 1UD129KBjvJXoWxtw4fKF4xAFWUZryxKw18AFb_yoWxXrWDpF W5Ka47G3WDt3y7Gwn7Aw10vw1Fvr4ftrWUCFs0qw18Kas8G3Z7tFyay3s0qFyUWayFqr1j vrWjgw1Yg3Z8AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmvb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAY j202j2C_Ar0_Cr1l5I8CrVAKz4kIr2xC04v26r1j6r4UMc02F40E42I26xC2a48xMcIj6x IIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_ Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s 07MxkIecxEwVAFwVWkMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I 3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxV WUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8I cVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87 Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUv cSsGvfC2KfnxnUUI43ZEXa7IU0gVy3UUUUU==
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/luyeiQ52Lch2ntmQFoEuH_l0rdg>
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: Tue, 06 Nov 2018 01:18:36 -0000

Hi James,
Thanks for your further suggestions. I'll include them in the updated version.

Regards,
Linlin


zhoulinlin@cnnic.cn
 
From: Gould, James
Date: 2018-11-02 20:25
To: kaduk@mit.edu; zhoulinlin@cnnic.cn
CC: regext-chairs@ietf.org; pieter.vandepitte@dnsbelgium.be; iesg@ietf.org; regext@ietf.org; draft-ietf-regext-org-ext@ietf.org
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
I believe that we need to ensure that the 1-on-1 organization role mapping is consistently defined in the draft.  The definition of the "role" attribute, the possible value can be referenced in section 7.3, and the relationship between the organization id and the role should certainly be defined in section 3.1.  The definition in 3.1 can be referenced in the create (4.2.1) and info (4.1.2), as in "One or more <orgext:id> elements that contain the identifier of the organization, as defined in [section 3.1]."  The update (4.2.5) is a little bit more complex to provide clarity on the behavior of the <orgext:add>, <orgext:rem> and the <orgext:chg>.  The following bullet could be removed from the update (4.2.5):
 
One or more <orgext:id> elements that contain the identifier of
the organization.  The "role" attribute is used to represent the
relationship that the organization has to the object.  See
Section 7.3 in [ID.draft-ietf-regext-org] for a list of values.
 
The reference to the <orgext:id> child elements and the expected behavior can be embedded under the definition of the <orgext:add>, <orgext:rem>, and <orgext:chg> elements, such as:
 
   o  An OPTIONAL <orgext:add> element that contains one or more <orgext:id> elements, as defined in [section 3.1], that add non-existent organization roles to the object.  The <orgext:id> element MUST have a non-empty organization identifier value.  The server SHOULD validate that the <orgext:id> element role does not exist.  
 
   o  An OPTIONAL <orgext:rem> element that contains one or more <orgext:id> elements, as defined in [section 3.1], that remove organization roles from the object.  The <orgext:id> element MAY have an empty organization identifier value.  The server SHOULD validate the existence of the <orgext:id> element role and the organization identifier if provided.  
 
   o  An OPTIONAL <orgext:chg> element that one or more <orgext:id> elements, as defined in [section 3.1], that change organization role identifiers for the object.  The existing organization identifier value will be replaced for the defined role.  The server SHOULD validate the existence of the <orgext:id> element role.     
  
—
JG
 
 
 
James Gould
Distinguished Engineer
jgould@Verisign.com
 
703-948-3271
12061 Bluemont Way
Reston, VA 20190
 
Verisign.com <http://verisigninc.com/> 
 
On 11/1/18, 6:29 PM, "regext on behalf of Benjamin Kaduk" <regext-bounces@ietf.org on behalf of kaduk@mit.edu>; wrote:
 
    On Thu, Nov 01, 2018 at 11:28:10AM +0800, Linlin Zhou wrote:
    > Dear Benjamin,
    > I found that following sections may be the proper place to restrict the 1-to-1 mapping. I think we can have restrictions in section 3.1 only or in 3.1&4.2.1&4.2.5. I've not decided which one is better and hope to have others' suggestions.
    
    I'd be happy to hear others' suggestions as well.  I don't have a strong
    preference, but if forced to choose would put text in all three places.
    (That is, others should feel free to choose "just section 3.1" and not
    force me to choose, if they want.)
    
    Thanks for putting together the proposals,
    
    Benjamin
    
    > 1. In section 3.1 Organization Identifier, add sentences at the end of this paragraph.
    > A "role" attribute is used to represent the relationship that the organization has to the EPP object. Any given object MUST have at most one associated organization ID for any given role value.
    > 
    > 2. In section 4.2.1,
    > One or more <orgext:id> elements that contain the identifier of the organization. The "role" attribute is used to represent the relationship that the organization has to the object. Any given object MUST have at most one associated organization ID for any given role value. See Section 7.3 in [ID.draft-ietf-regext-org] for a list of values.
    > 
    > 3. In section 4.2.5
    > One or more <orgext:id> elements that contain the identifier of the organization. The "role" attribute is used to represent the relationship that the organization has to the object. Any given object MUST have at most one associated organization ID for any given role value. See Section 7.3 in [ID.draft-ietf-regext-org] for a list of values. 
    > 
    > If we have the restrictions, the 1-to-multiple mapping cases are not necessary to be specified in this document.
    > 
    > Regards,
    > Linlin
    > 
    > 
    > Linlin Zhou
    >  
    > From: Benjamin Kaduk
    > Date: 2018-10-31 20:43
    > To: Linlin Zhou
    > CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext
    > Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
    > Dear Linlin,
    >  
    > On Wed, Oct 31, 2018 at 02:19:45PM +0800, Linlin Zhou wrote:
    > > 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.
    >  
    > I won't object to requiring the 1-to-1 mapping, as the impact of the
    > restriction seems minor.  I am not entirely sure where the best place to
    > add some text that clarifies this restriction would be; perhaps in Section
    > 4.2.1 where we describe the <orgext:id> elements in <create>?  (I assume
    > that the formal syntax does not provide for a maxOccurs that applies
    > per-type.)  It may also be worth a (non-normative) reminder in the <update>
    > description that the semantics of <orgext:chg> are well-defined because
    > there is only one entry per role value, but I'm not sure about that.
    >  
    > Thanks,
    >  
    > Benjamin
    >  
    > _______________________________________________
    > 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