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

"Linlin Zhou" <zhoulinlin@cnnic.cn> Thu, 25 October 2018 03:28 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 762A9130DCD; Wed, 24 Oct 2018 20:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 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, URIBL_BLOCKED=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 ip-dX_I3SIY8; Wed, 24 Oct 2018 20:28:51 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9803612F18C; Wed, 24 Oct 2018 20:28:44 -0700 (PDT)
Received: from zll (unknown [218.241.111.73]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BJUPBjONFbDmECAA--.2888S2; Thu, 25 Oct 2018 11:28:35 +0800 (CST)
Date: Thu, 25 Oct 2018 11:29:41 +0800
From: "Linlin Zhou" <zhoulinlin@cnnic.cn>
To: "Benjamin Kaduk" <kaduk@mit.edu>, iesg <iesg@ietf.org>
Cc: regext-chairs <regext-chairs@ietf.org>, "Pieter Vandepitte" <pieter.vandepitte@dnsbelgium.be>, regext <regext@ietf.org>, draft-ietf-regext-org-ext <draft-ietf-regext-org-ext@ietf.org>
References: <154032201955.31253.2132106938902168352.idtracker@ietfa.amsl.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <2018102511294175966596@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart387670581758_=----"
X-CM-TRANSID: AQAAf0BJUPBjONFbDmECAA--.2888S2
X-Coremail-Antispam: 1UD129KBjvJXoWxGrWUtrWfAw4kKFWruF17ZFb_yoW7JF1xpF Wft34xKw4DJry7Gw1kCw18Xw1jvr1fJrWUJFs8Wr1kAFn8CF10gr13tw1FyFyUCF9Yq34j qr1jkr1UGw1UAFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUHab7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40En4AK xVAvwIkv4cxYr24l5I8CrVCF0I0E4I0vr24l5I8CrVC2j2CEjI02ccxYII8I67AEr4CY67 k08wAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCj c4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjx AxZF0Ex2IqxwCjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK67AK6r48MxAIw28IcxkI7VAK I48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7 xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xII jxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw2 0EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY 1x0267AKxVW8JVW8Jr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUy3EfDU UUU
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/J4OgeyQSTEwpe6mVPSjPVq6NxpY>
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, 25 Oct 2018 03:28:55 -0000

Dear Benjamin,
Thanks for your review. Please see my feedbacks below.

Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-24 03:13
To: The IESG
CC: regext-chairs; pieter.vandepitte; regext; draft-ietf-regext-org-ext
Subject: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-org-ext-09: Discuss
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/
 
 
 
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
 
I have two points that I would like to discuss.  It is more likely than not
that at least one of them merely reflects my confusion and is a non-issue,
but I would like to get these at least clarified.
 
First, the examples throughout the document use organization identifiers
like "myreseller" or "myproxy".  This seems to me to be highly confusing,
since these IDs are supposed to be server-unique values per organization,
and are highly unlikely to be "my" reseller/proxy/etc. for all the entries
in the registry.  If I understand things correctly, the example IDs should
instead be company-name-like values or "random" numbers or similar (or
combination thereof).
[Linlin]  Thank you for pointing out this. To be more consistent with the draft-ietf-regext-org draft, I suggest using the IDs defined in the "org" draft, like "reseller1523" , "registrar1362" or "proxy2935".

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.
 
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
Section 1
 
   In the business model of domain registration, we usually have 3 roles
   of entities: a registrant, a registrar and a registry.  There may be
   other roles of entities involved in the domain registration process
   which are not formally defined, such as resellers, DNS service
   operators, privacy proxies, etc.
 
nit: Perhaps I am misreading, but are we not going to formally define these
entities in the next paragraph (in which case "yet" might be worth adding)?
[Linlin] Yes. "...which are not formally defined yet..."
 
   An organization mapping object defined in [ID.draft-ietf-regext-org]
   SHOULD be created first.  The organization information specified in
   this document MUST reference the existing organization identifier.
 
What does "first" refer to?  "prior to the use of that object"?
[Linlin] Yes. The organizations object should be created prior to using the organization ID for the extension. Maybe I can change the words to be more clear, "Organization object identifiers MUST be known to the server before the organization object can be associated with the EPP object."
 
Section 2
 
   The XML namespace prefix "orgext" is used, but implementations MUST
   NOT depend on it and instead employ a proper namespace-aware XML
   parser and serializer to interpret and output the XML documents.
 
[This could probably be written more clearly; see my comment on the
companion document]
 [Linlin] I'll update it to use the full namespace.

Section 9
 
IIRC the authorization model for EPP does not allow arbitrary clients to
retrieve information about arbitrary (unrelated) domains.  If that's not
the case, there would be privacy considerations with respect to exposing
the linkages of the organization mappings (and roles).
[Linlin] Yes. EPP provides a authentication mechanism which is mentioned in RFC5730.
 
 
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext