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

"Linlin Zhou" <zhoulinlin@cnnic.cn> Mon, 12 November 2018 03:14 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 D6000127133; Sun, 11 Nov 2018 19:14:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 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, 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 mz7I_096EVxR; Sun, 11 Nov 2018 19:14:07 -0800 (PST)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id C70D012008A; Sun, 11 Nov 2018 19:14:03 -0800 (PST)
Received: from zll (unknown [218.241.111.73]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5pq3x7+hbzF4CAA--.1736S2; Mon, 12 Nov 2018 11:13:53 +0800 (CST)
Date: Mon, 12 Nov 2018 11:15:24 +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>, <20181031141945204989108@cnnic.cn>, <20181031124321.GH45914@kduck.kaduk.org>, <2018110111280976085295@cnnic.cn>, <20181101222859.GH45914@kduck.kaduk.org>, <B567C9E4-BF56-4BB0-8081-27264947C1F7@verisign.com>, <201811060918110034890@cnnic.cn>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <2018111211152341848066@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart526732348057_=----"
X-CM-TRANSID: AQAAf0B5pq3x7+hbzF4CAA--.1736S2
X-Coremail-Antispam: 1UD129KBjvJXoW3Aw18JFWkXF13JF4fuw47CFg_yoW3CFyUpF W5K347Ga1DJ3y7Wwn7Aw1vvw1Fvrs3trWUCFs8Xw18Ka98G3Z7tFyay3s0qFyUWayFqr1j v34jgw1Yg3Z8CFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUlEb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k0 8I80eVWrJVW7JwAqx4xG62kEwI0EY4vaYxAvb48xMc02F40Ew4AK048IF2xKxVWUJVW8Jw Aqx4xG6xAIxVCFxsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzxvEb7x7McIj6xIIjxv2 0xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7 xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07Mx8G jcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_Gr4l42xK82IYc2Ij64vIr41l4I8I3I0E4I kC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWU WwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr 0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWr Jr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r 4UJwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07jgnYcUUUUU=
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/JsHz6z2CUDl3r080viA4VBD1U4g>
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: Mon, 12 Nov 2018 03:14:11 -0000

Dear Benjamin,
James provided his suggestions and I'd like to include them in the updated text. I think this is the last issue we have and please see if these changes workable for you.

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.1.2,
Zero or more <orgext:id> elements are allowed that contain the identifier of the organization, as defined in [section 3.1]. 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.

3. In section 4.2.1, 
One or more <orgext:id> elements that contain the identifier of the organization, as defined in [section 3.1]. 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. 

4. In section 4.2.5,
 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. 

At least one <orgext:add>, <orgext:rem> or <orgext:chg> element MUST be provided. The <orgext:add>, <orgext:rem> and <orgext:chg> elements contain the following child element:

o 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.

Regards,
Linlin


Linlin Zhou
 
From: Linlin Zhou
Date: 2018-11-06 09:18
To: jgould; kaduk@mit.edu
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)
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