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

"Gould, James" <jgould@verisign.com> Fri, 02 November 2018 12:25 UTC

Return-Path: <jgould@verisign.com>
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 7C33C124408; Fri, 2 Nov 2018 05:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 HtZmIrGjhmq9; Fri, 2 Nov 2018 05:25:36 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 AAE00126F72; Fri, 2 Nov 2018 05:25:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=27633; q=dns/txt; s=VRSN; t=1541161536; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=pF4AnRlqgpuNW01JxpoBlpSxcTIPDL60SU18ecXaDzo=; b=PjY8lXeudEm/le4BWiF1zvUk1bOgr0Kbs3BCQr0QMkVriIdiC8bR+QqW Jlef2iGOIozcvqZObIQvv3BUsO+Og4LnD8ayueoNkiu8LZES9u0029c+J o5X5sh/EVSpoRyfmyjwuSn62pWX+oYWN2FJ7Hz/w1Twm5r1Qm/vDe+PUs Ji/IBP2JZh7fGQBtZlVwgsVDUVOK/+l37FUOZTFcm4TbPuveHqt83HLnT 0ZcmdCKyFP37HSxvbm+Zuk92v0r1hCRm63yya31A7NtBKI+GgKXZJSDu6 fwaYARvz41THPMAyXST97gDr8/KA2QMdMPHkwHVGJoaVQqHlHqvajgAKU Q==;
X-IronPort-AV: E=Sophos;i="5.54,455,1534809600"; d="scan'208,217";a="6339811"
IronPort-PHdr: =?us-ascii?q?9a23=3AcwN5rh1HGGH3q/SWsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?sesUIvnxwZ3uMQTl6Ol3ixeRBMOHs60C07KempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9JDffwdFiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?= =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?= =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QLYpUjqg8qhrUgflhi?= =?us-ascii?q?cZOTAk7GHZhM9+jKxZrx2vphxw34HbbZqPO/Zie6PQZ88WSHBDU8tXSidPApm8?= =?us-ascii?q?b4wKD+cZM+pWro79p0YKrRSjHQWnGefhxSVNhnDoxq023fkqHAbE3AwvGNIOrX?= =?us-ascii?q?DUo8juOacMT++11qjIzS7Cb/NZ3zfx8pTHchckofyVW797bMTfyU4qFwzfj1WQ?= =?us-ascii?q?r5ToPy2L2eQXsmib9OtgVe2pi24mrQF+viKjydsrionMno4Vy07L9Tl3wIovIt?= =?us-ascii?q?24UkF7bNi5G5VTryGXL5Z6Tt84T211uis3xKcKtYO7cSUE0pgqyBrSZ+Saf4SU?= =?us-ascii?q?+B7vSeScLStiiH54d7+yhAy+/VWjx+HkWMm7zlVHojZAn9TJrH8A1Bje5dOCR/?= =?us-ascii?q?Zz4EuuxDeC2gXI5exAIE05l6/WJpAvz7Myi5Uet1nIEDXsl0XslqCWc10p+u2v?= =?us-ascii?q?6+v6fLrrvoScN4poigHmNaQuh9C/Dfw4MgcQW2ib/vyx2aD/80PhXblFjuU4nK?= =?us-ascii?q?bYv5zGO8gXvLC5DBNS0oY58xazFS2p38kCkXkZNlJFYxSHg5L1NFHJJfD0Ffa/?= =?us-ascii?q?g1Kynzd33/3KI6HtDo/QInXBnrrtZ6tx5k5SxQYpwt1S44pYCrQbL/LyXk/xus?= =?us-ascii?q?bYDhg8MwGswebnB9J91p4aWW2SGaKZLr3dsUWJ5uI0IumMa4kVtCzhJPgi4v7i?= =?us-ascii?q?lWU5lkMFfam1wZsXb2i1Hvd8LEqEfHrsgcwMEWILvgoiVuDllkCNUSNLbXaoQ6?= =?us-ascii?q?08/i07CJ6hDYrbR4GtgLuB3Dq/Hp1XYGBGDlGMEXHzeoqYXfcMbiOSLdN7njMY?= =?us-ascii?q?U7irU5Uh2g22tA/m17pnKfLZ+jcGupLsytd06PHTmQgu+jx0Fcud0nuNT3pvk2?= =?us-ascii?q?MJWTA2wK5/rVZ6yleZ3qhym+ZYGsBL5/NVTgc6MobRz/R7C9/sRgLOYM2JREy4?= =?us-ascii?q?Qtq8BzE+U8w+w8cPY0ZhB9WtkAvO0DesA78OjLOEGpg08q3d33jsIsZx0W3J27?= =?us-ascii?q?c5hVk8XsRPLXGmhrJ49wXLBo7GjV6Zl6mxeKQdwiHN6GmDwXCJvEFCXw56Sb/F?= =?us-ascii?q?UmwHZkvKsdT54VvPT6WwBrQoLARAxtKCJ7BLatL3kVVGSu3vONPEY2K+g22wHw?= =?us-ascii?q?qHxquQbIr2fGUQxDjSCFIenAAd4XaKLAk+CTm9o2LQFTBuD0zgY0zy/uhxtHO3?= =?us-ascii?q?V0g0zxuFb0F4ybW09QIViOedS/wNwrIEtj0tqzJuHFayjJrqDI/KpANtYaZ0ZN?= =?us-ascii?q?IhplpLyCiR4w90MoGjB6VjmhgTfxkh+wukxRVwF4FBl8wrqlshygxzIuST1hkJ?= =?us-ascii?q?IyGY2o30O7vTK2/a9xapaqWQ0VeIg/iM/aJaots/tlHv+EmLH08v6D8vh9ta1G?= =?us-ascii?q?aY6r3UARATSpP+VAA88B0s9OKSWTU0+46BjS4kCqKzqDKXg98=3D?=
X-IPAS-Result: =?us-ascii?q?A2EHAACDQdxb/zGZrQpiAw4NAQEBAQMBAQEHAwEBAYFRBgE?= =?us-ascii?q?BAQsBgQ2BXYEnCoNsiBiNfyWXLBSBKxcgBAwBGAEKC4N4RgIXg0k0DQ0BAwEBA?= =?us-ascii?q?QEBAQIBAQKBBQyCNiISLxwvCQEFAQEBAQEBJwEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQgCCAc1EgEBGAEBAQECAQEBIUsEBwULAgEIEQMBAiQHA?= =?us-ascii?q?gICJQsdCAIEAQ0FgyEBgR1cF6YugS6KGIwGgUI+gREnDBOBTn6DGwEBgSkgAi0?= =?us-ascii?q?JAR0Jgj0xgiYCinODaoYXijYDBgKGaoo3gVVMiGqFT4lAg0AFihICBAIEBQIUg?= =?us-ascii?q?UOCDnAVOyoBgkEJgkaDNoUUhQQ6bw0kilErgQGBHwEB?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Fri, 2 Nov 2018 08:25:31 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1531.003; Fri, 2 Nov 2018 08:25:31 -0400
From: "Gould, James" <jgould@verisign.com>
To: "kaduk@mit.edu" <kaduk@mit.edu>, "zhoulinlin@cnnic.cn" <zhoulinlin@cnnic.cn>
CC: "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "pieter.vandepitte@dnsbelgium.be" <pieter.vandepitte@dnsbelgium.be>, "iesg@ietf.org" <iesg@ietf.org>, "regext@ietf.org" <regext@ietf.org>, "draft-ietf-regext-org-ext@ietf.org" <draft-ietf-regext-org-ext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
Thread-Index: AQHUcjJbp+Xo1yteRE+kDMdDRWBbiaU8aeWA
Date: Fri, 2 Nov 2018 12:25:31 +0000
Message-ID: <B567C9E4-BF56-4BB0-8081-27264947C1F7@verisign.com>
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>
In-Reply-To: <20181101222859.GH45914@kduck.kaduk.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.f.0.180709
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_B567C9E4BF564BB0808127264947C1F7verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Z2Y-g1KweJgyhmhF-CnIBii_VdI>
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: Fri, 02 Nov 2018 12:25:40 -0000

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