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

Benjamin Kaduk <kaduk@mit.edu> Thu, 01 November 2018 22:29 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 D06371298C5; Thu, 1 Nov 2018 15:29:16 -0700 (PDT)
X-Quarantine-ID: <9_mE3OPZ8afz>
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.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 9_mE3OPZ8afz; Thu, 1 Nov 2018 15:29:14 -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 CB2A712896A; Thu, 1 Nov 2018 15:29:13 -0700 (PDT)
X-AuditID: 12074424-a47ff70000000f83-ce-5bdb7e351a44
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (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 34.42.03971.63E7BDB5; Thu, 1 Nov 2018 18:29:11 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id wA1MT4Va001349; Thu, 1 Nov 2018 18:29:06 -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 wA1MT0KH020313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 1 Nov 2018 18:29:02 -0400
Date: Thu, 1 Nov 2018 17:28:59 -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: <20181101222859.GH45914@kduck.kaduk.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2018110111280976085295@cnnic.cn>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT1zWvux1tsPyMhsWyZTNYLWb8mchs 8XfvLGaLl11PmS2uTjjCaPHr40tGBzaPTdckPb5POs/usWTJT6YA5igum5TUnMyy1CJ9uwSu jK2vigtuSFb07L7A1sD4VqSLkZNDQsBE4vTZo4xdjFwcQgJrmCQ+PfjIAuFsYJTY9n8HO4Rz h0ni1ZSfrCAtLAIqEotOXwOz2YDshu7LzCC2iICqxPdT88FGMQu8YpRY/3Q9WJGwQIHE0iXf mUBsXqB9q8+eZIKYep9J4v7vP4wQCUGJkzOfsIDYzAJaEjf+vQQq4gCypSWW/+MACXMK6EnM OngUbJmogLLE3r5D7BMYBWYh6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuuZ6 uZkleqkppZsYwYHtorKDsbvH+xCjAAejEg9vhOrtaCHWxLLiytxDjJIcTEqivAomQCG+pPyU yozE4oz4otKc1OJDjBIczEoivJezgXK8KYmVValF+TApaQ4WJXHeiS2Lo4UE0hNLUrNTUwtS i2CyMhwcShK8bbVAjYJFqempFWmZOSUIaSYOTpDhPEDDt4PU8BYXJOYWZ6ZD5E8xKkqJ8+qC JARAEhmleXC9oMQjkb2/5hWjONArwrwOIFU8wKQF1w2MIqCPRHi52G+ADC5JREhJNTBqXb3E Prd/XbLnTokss9jfHg2LfJ8zRAQr7uv4aPbj6YXq/IJLRZ4szs9u/ROwM/74YJvT+vO+IpuN 9kh5+s3fPeftOaeV8sa1M25nfEqbu+f3J20t3duRy3967JPIW7z6/zcjLscLpevSNsR9W7mk 4d/F1b7VHHWT1gYGCU9OUFWLOXjseMkPJZbijERDLeai4kQA9/x17RcDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/MdrrPX5z0Ze4RjO57rgE6bPvkNs>
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: Thu, 01 Nov 2018 22:29:17 -0000

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