Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-ext-10: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Tue, 04 December 2018 06:57 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 74BE5130DFB; Mon, 3 Dec 2018 22:57:31 -0800 (PST)
X-Quarantine-ID: <ddPuPV4tyO8W>
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.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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 ddPuPV4tyO8W; Mon, 3 Dec 2018 22:57:27 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 70D8F130DF7; Mon, 3 Dec 2018 22:57:23 -0800 (PST)
X-AuditID: 1209190f-5a5ff700000041b1-ae-5c06254eb374
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 76.44.16817.E45260C5; Tue, 4 Dec 2018 01:57:19 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id wB46vCbx006219; Tue, 4 Dec 2018 01:57:14 -0500
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 wB46v7if003006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Dec 2018 01:57:09 -0500
Date: Tue, 4 Dec 2018 00:57:07 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Linlin Zhou <zhoulinlin@cnnic.cn>
Cc: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, 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: <20181204065706.GP54918@kduck.kaduk.org>
References: <154354723384.26034.2425581420972603494.idtracker@ietfa.amsl.com> <2930ead9dfbd43389ea078ab90d738c9@verisign.com> <2018120316415888258024@cnnic.cn> <be8fce1a2c5c4b71b534412c40ad5763@verisign.com> <201812041059217835519@cnnic.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <201812041059217835519@cnnic.cn>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixG6nouuvyhZj8H4Bu8WyZTNYLWb8mchs 8XfvLGaLl11PmS2uTjjCaLF85jlGi18fXzI6sHtsuibpcWLZFVaP75POs3ssWfKTKYAlissm JTUnsyy1SN8ugStj9qEzjAUbtSt2fz/L1sD4U7mLkZNDQsBEonfVIsYuRi4OIYE1TBIb755g gnA2MEq8fveDFcK5wyTxaMt6ti5GDg4WARWJE5csQbrZgMyG7svMILaIgKrE91PzwSYxC2xh kni1eDdYQlggU+LS+cVMIL28QOtmLq+BmPmDUeJs7zF2kBpeAUGJkzOfsIDYzALqEn/mXWIG qWcWkJZY/o8DIiwv0bx1NthITgFdiYaF88DOEQW64fMCgQmMgrOQDJqFZNAshEGzkAxawMiy ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdELzezRC81pXQTIygyOCX5dzDOafA+xCjAwajEwzvD iTVGiDWxrLgy9xCjJAeTkihv20WgEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHegkKWGCHelMTK qtSifJiUNAeLkjjvL5HH0UIC6YklqdmpqQWpRTBZGQ4OJQlefxW2GCHBotT01Iq0zJwShDQT ByfIcB6g4SvkgWp4iwsSc4sz0yHypxgVpcR5/8wCukgAJJFRmgfXC0pcEtn7a14xigO9Isxb rQzUzgNMenDdr4AGMwENztnCBDK4JBEhJdXAKPXpZ8af0q7dzVOOerg+Sj5mVCBnJD1L2/JV 3c0DzxW6P+xotePwdJ6w4Mp0uzcfjhqv3it9nXNRZ9olARbJkIMFb5dfyv80N+l7Relvo3ve VQxxJz4ZmSabzd9zaOX7JjOV8o652W9exrYkHfj964OPnnWYgmFE92XBuDrz2kULjzQm8rwJ U2Ipzkg01GIuKk4EAP55n/43AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Jm-0R82sQO62dNoiQpmw5Tk7Fxg>
Subject: Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-ext-10: (with 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, 04 Dec 2018 06:57:32 -0000

Dear Linlin,

Yes, that looks fine to me.

-Benjamin

On Tue, Dec 04, 2018 at 10:59:22AM +0800, Linlin Zhou wrote:
> Dear Benjamin,
> As some definitions are specified in the draft-ietf-dnsop-terminology-bis, I suggest removing "which are not formally defined" and making following changes in the first section. Does that work for you?
> 
> In the business model of domain registration, we usually have three roles of entities: a registrant, a registrar and a registry, as defined in section 9 of [draft-ietf-dnsop-terminology-bis]. There may be other roles of entities involved in the domain registration process, such as resellers, DNS operators in section 9 of [draft-ietf-dnsop-terminology-bis], privacy proxies, etc. 
> 
> A domain reseller is an individual or a company that acts as an agent for accredited registrars. DNS operator is defined in section 9 of [draft-ietf-dnsop-terminology-bis]. A privacy proxy is an entity used for domain registrations to protect the private information of the individuals and organizations. These kind of entities are defined as "organizations" with different role types in this document.
> 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
>  
> From: Hollenbeck, Scott
> Date: 2018-12-03 21:12
> To: 'zhoulinlin@cnnic.cn';; 'kaduk@mit.edu';; 'iesg@ietf.org';
> CC: 'regext-chairs@ietf.org';; 'pieter.vandepitte@dnsbelgium.be';; 'regext@ietf.org';; 'draft-ietf-regext-org-ext@ietf.org';
> Subject: Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-ext-10: (with COMMENT)
> Works for me if it addresses Ben’s comment.
>  
> Scott
>  
> From: regext <regext-bounces@ietf.org>; On Behalf Of Linlin Zhou
> Sent: Monday, December 03, 2018 3:42 AM
> To: Hollenbeck, Scott <shollenbeck@verisign.com>;; 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>;
> Subject: [EXTERNAL] Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-ext-10: (with COMMENT)
>  
> Dear Scott,
> Thanks for your comments. Please review if the following changes are workable for you.
> 
> 
> In the business model of domain registration, we usually have three roles of entities: a registrant, a registrar and a registry, as defined in section 9 of [draft-ietf-dnsop-terminology-bis]. There may be other roles of entities involved in the domain registration process, such as resellers, DNS operators in section 9 of [draft-ietf-dnsop-terminology-bis], privacy proxies, etc.
> 
> 
> A domain reseller is an individual or a company that acts as an agent for accredited registrars. DNS operator is defined in section 9 of [draft-ietf-dnsop-terminology-bis]. A privacy proxy is an entity used for domain registrations to protect the private information of the individuals and organizations. These kind of entities are defined as "organizations" with different role types in this document.
>  
> Regards,
> Linlin
> 
> 
> Linlin Zhou
>  
> From: Hollenbeck, Scott
> Date: 2018-11-30 20:15
> To: 'kaduk@mit.edu';; 'iesg@ietf.org';
> CC: 'regext-chairs@ietf.org';; 'pieter.vandepitte@dnsbelgium.be';; 'regext@ietf.org';; 'draft-ietf-regext-org-ext@ietf.org';
> Subject: RE: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-ext-10: (with COMMENT)
> > -----Original Message-----
> > From: regext <regext-bounces@ietf.org>; On Behalf Of Benjamin Kaduk
> > Sent: Thursday, November 29, 2018 10:07 PM
> > To: The IESG <iesg@ietf.org>;
> > Cc: regext-chairs@ietf.org; pieter.vandepitte@dnsbelgium.be;
> > regext@ietf.org; draft-ietf-regext-org-ext@ietf.org
> > Subject: [EXTERNAL] [regext] Benjamin Kaduk's No Objection on draft-ietf-
> > regext-org-ext-10: (with COMMENT)
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-regext-org-ext-10: No Objection
> > 
> > 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/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Thank you for addressing my Discuss points!
> > 
> > [Original Comment section preserved below]
> > 
> > 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)?
>  
> If definitions are needed, it may make sense to cite those described in draft-ietf-dnsop-terminology-bis. The Datatracker says it's in the RFC Editor's AUTH48 state, so it should be available as an RFC in a matter of days.
>  
> Scott