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

Benjamin Kaduk <> Wed, 31 October 2018 12:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6734D130E06; Wed, 31 Oct 2018 05:43:33 -0700 (PDT)
X-Quarantine-ID: <hucU2XMo5NEV>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hucU2XMo5NEV; Wed, 31 Oct 2018 05:43:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC136130E05; Wed, 31 Oct 2018 05:43:30 -0700 (PDT)
X-AuditID: 12074422-de7ff700000025ff-90-5bd9a36f3573
Received: from ( []) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 63.C1.09727.073A9DB5; Wed, 31 Oct 2018 08:43:28 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.14.7/8.9.2) with ESMTP id w9VChQZh017471; Wed, 31 Oct 2018 08:43:26 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby (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 <>
To: Linlin Zhou <>
Cc: regext-chairs <>, Pieter Vandepitte <>, iesg <>, regext <>, draft-ietf-regext-org-ext <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
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: <>
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.