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

"Linlin Zhou" <> Tue, 30 October 2018 02:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C08DC126DBF; Mon, 29 Oct 2018 19:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 36vOj6lKiSz3; Mon, 29 Oct 2018 19:15:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7EBC212008A; Mon, 29 Oct 2018 19:15:00 -0700 (PDT)
Received: from zll (unknown []) by (Coremail) with SMTP id AQAAf0BZYPycvtdbKywFAA--.4480S2; Tue, 30 Oct 2018 10:14:52 +0800 (CST)
Date: Tue, 30 Oct 2018 10:16:05 +0800
From: "Linlin Zhou" <>
To: "Benjamin Kaduk" <>
Cc: regext-chairs <>, "Pieter Vandepitte" <>, iesg <>, regext <>, draft-ietf-regext-org-ext <>
References: <>, <>, <>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart118032637285_=----"
X-Coremail-Antispam: 1UD129KBjvJXoWxJw1fWr15Zw4UWrWUuF4fGrg_yoW5Xr1kpF W3G3srA3WUZrW7W34kCw1UX34UtrykGrW5GFs8Ww1kA3Z8Cw10qF13trn5tFyUury8JFyY vrW3Kr15C3srAFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUHIb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAa z4v26cxKscIFY7kG0wAqx4xG6xAIxVCFxsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzx vEb7x7McIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC 6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67 k04243AVC20s07MxkF7I0En4kS14v26r126r1DMxkIecxEwVAFwVW8JwCF04k20xvY0x0E wIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E74 80Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0 I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04 k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY 1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07j2hFxUUU UU=
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
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: Tue, 30 Oct 2018 02:15:05 -0000

Dear Benjamin,
I've included my feedbacks inline and removed the clarified items.


Linlin Zhou

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Second, I am unsure of the semantics relating to role types, especially as
> they interact with the <update> command.  Various aspects of the examples
> seem to imply that it is only permitted to have at most one organization
> mapping of a given role type (i.e., one reseller, one proxy, etc.).  In
> particular, the <orgext:chg> element seems to be using the <orgext:id> role
> attribute to determine which <orgext:id> is being changed (with the new
> value being provided in the element body), and the <orgext:rem> element is
> providing <orgext:id> with only the role attribute and no body to identify
> a specific organization to remove.  If this reading of the document is
> correct, then I would expect the limitation to be called out more clearly,
> especially as it would seem to prevent a domain owner from (e.g.) using
> multiple DNS service operators.
> [Linlin] In the normal business model, for example a domain should have one reseller, one registrar etc.  How about adding some text like "One <orgext:id> element is suggested for each role type." in the element description.
I don't think that addresses my core concern (though it is probably worth
doing in its own right).
In particular, if it is allowed by the protocol/registry to have more than
one <orgext:id> element of a given role type, then several of the protocol
exchanges this document defines within <update> are not fully defined in an
interoperable fashion.  For example, what if I receive a
<orgext:chg><orgext:id role="dns-operator>dns872</orgext:id></orgext:chg>
and there are currently two dns-operators defined?  Do I remove both
existing entries and add the one new one?  Do I remove just one existing
entry and replace it with the new one?  If the latter, how do I pick which
one is to be removed?  I just don't see how the operation is fully
specified for these cases.
 [Linlin] We have discussed the error cases, but may lack of this situation.
If there are already multiple IDs exist with a particular role, I suggest not changing the object and returning an error code 2305 which means "Object association prohibits operation".
Maybe some words like "An attempt to change an organization ID with a particular role value, when multiple IDs exist with the same role value, does not change the object at all. A server SHOULD notify clients that object relationships need to be checked by sending a 2305 error response code. "