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

Benjamin Kaduk <kaduk@mit.edu> Wed, 31 October 2018 12:43 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 6734D130E06; Wed, 31 Oct 2018 05:43:33 -0700 (PDT)
X-Quarantine-ID: <hucU2XMo5NEV>
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.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hucU2XMo5NEV; Wed, 31 Oct 2018 05:43:31 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 EC136130E05; Wed, 31 Oct 2018 05:43:30 -0700 (PDT)
X-AuditID: 12074422-de7ff700000025ff-90-5bd9a36f3573
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 63.C1.09727.073A9DB5; Wed, 31 Oct 2018 08:43:28 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id w9VChQZh017471; Wed, 31 Oct 2018 08:43:26 -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 w9VChL64008967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Oct 2018 08:43:24 -0400
Date: Wed, 31 Oct 2018 07:43:21 -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: <20181031124321.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181031141945204989108@cnnic.cn>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hTV1i1YfDPaYMJCK4tly2awWsz4M5HZ 4u/eWcwWL7ueMltcnXCE0eLXx5eMDmwem65JenyfdJ7dY8mSn0wBzFFcNimpOZllqUX6dglc GbeerGcqeMJeMW/2JuYGxtVsXYycHBICJhKL1q1n7WLk4hASWMMk8ePuY2YIZyOjRMfVLkYI 5y6TxPI5b5lAWlgEVCV6J95kBbHZBFQkGrovM4PYIkDx76fmgzUwC7xilFj/dD1YkbBAgcTS Jd/BmnmB9n04+4ERxBYSmMAksXm7JURcUOLkzCcsIDazgJbEjX8vgeo5gGxpieX/OEDCnAL6 EtPmzQRrFRVQltjbd4h9AqPALCTds5B0z0LoXsDIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjX VC83s0QvNaV0EyMosNldlHYwTvzndYhRgINRiYf3QfKNaCHWxLLiytxDjJIcTEqivCfrbkYL 8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuH1WASU401JrKxKLcqHSUlzsCiJ805sWRwtJJCeWJKa nZpakFoEk5Xh4FCS4G0CaRQsSk1PrUjLzClBSDNxcIIM5wEaPnchyPDigsTc4sx0iPwpRkUp cV4rkGYBkERGaR5cLyjxSGTvr3nFKA70ijDvc5B2HmDSgusGxhDQRyK8XOw3QAaXJCKkpBoY 43/fktDVLRWemD4h4d0UxiXCst+8n9/67HAwcH9YTL14zYpzvLzKR0N1NO7msrxv3aXBlVX7 +H6c+F+j6O54f017v756Qx1/n2n7cm7Zm5T07kuZ9jBynWDZm7XnuXW66jmd270cfZ8cbn08 Y9KVni/XVA5avPr2Xp9/R4yowJJpNzxCqz8psRRnJBpqMRcVJwIAp9nVKRcDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/McN5sql5S0IM_n1OZnBPeNX0PKQ>
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 12:43:33 -0000

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