Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
"Linlin Zhou" <zhoulinlin@cnnic.cn> Tue, 30 October 2018 02:15 UTC
Return-Path: <zhoulinlin@cnnic.cn>
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 C08DC126DBF; Mon, 29 Oct 2018 19:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36vOj6lKiSz3; Mon, 29 Oct 2018 19:15:02 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBC212008A; Mon, 29 Oct 2018 19:15:00 -0700 (PDT)
Received: from zll (unknown [218.241.111.73]) by ocmail02.zx.nicx.cn (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 <zhoulinlin@cnnic.cn>
To: Benjamin Kaduk <kaduk@mit.edu>
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>
References: <154032201955.31253.2132106938902168352.idtracker@ietfa.amsl.com>, <2018102511294175966596@cnnic.cn>, <20181025172816.GB45914@kduck.kaduk.org>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <2018103010160489184930@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart118032637285_=----"
X-CM-TRANSID: AQAAf0BZYPycvtdbKywFAA--.4480S2
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: <https://mailarchive.ietf.org/arch/msg/regext/lX9x4Pnw-Q2Fx4Q6PtSRcH0_y_E>
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: Tue, 30 Oct 2018 02:15:05 -0000
Dear Benjamin, I've included my feedbacks inline and removed the clarified items. Regards, Linlin Linlin Zhou > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > 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. "
- [regext] Benjamin Kaduk's Discuss on draft-ietf-r… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Gould, James
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Linlin Zhou