Re: [regext] Robert Wilton's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

"Gould, James" <jgould@verisign.com> Mon, 19 April 2021 14:52 UTC

Return-Path: <jgould@verisign.com>
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 C8E763A3451; Mon, 19 Apr 2021 07:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 NVpz9W1CVcib; Mon, 19 Apr 2021 07:52:00 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 0DD133A33FE; Mon, 19 Apr 2021 07:51:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4672; q=dns/txt; s=VRSN; t=1618843921; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=OCABHxxvnNb8/o+MifyyRlgkPQltu+NwEfWIQ26YqHw=; b=h080Q00tfcAoIOZ5hUGlZeLe344cHbEo0LMVqteL9smEKbQShjqmdaRX jiVTPclGLvqYyasg6FiBFJrS6gqgXRF7+oPBnncyBadadqnLNQqw4RJLV 5hkUTTnwDb0/+Y7daa75vQPpS/oKpEuBLOd0X59GvUcsgvy3T1mHqQExX zqdWFp5vbIqU+sojYWG3w0BMl5gDCRk+UuJgqEAr+m04/YxPuTQRfZeDm oN/hDef/uqtgxy0V9sOcp9Vb66jNqLyQUX8xvr2Tofy4DnRwwfiadV2OP YEhGuDHUgk+nG92eePPVBjQlmDY2wXKJNrPokNUfhXV2fSqi78BNYK2Af w==;
IronPort-SDR: R1J6n7PHOQuTQaOVnPP1Qs6ZguAJ6wBMKjCJaA7RWaQkcFFYjJBlxzhXlvqwUIlRJx22/GddPF S11wLWihG+icTYbrsOKOJiQsM/IzuoGJXy8yCoB+QUKrbqfO097hOJiEq2pAv12pNtGpp1SJ1H SsvTf9mZiHxWVsCcgneo+IB+p+fnVOEtH1rJuA/myiaSBW1SHmCrHGZp5FImY2Drqnk5QM5Yxi vnT6BfmNF00gzD9IBThjxFjEvYVTCWklUk6bZvBOAWfMoqc/PPd3TorebMV5Ky8ZYphIhx5ZOk l64=
IronPort-HdrOrdr: A9a23:PcukVK8sIqf6O5EKdWFuk+HNdb1zdoIgy1knxilNYDReeMCAio SKlPMUyRf7hF8qKRMdsPqrUZPtfVr385lp7Y4NeZeONTOWw1eABodk8Ifk3nnEEyrx6uZS2c 5bAs1DIff3CkV3itu/3RKxFMwuzMLC3Kejg+rfyHkFd3ARV4hL6QBlBgGHVnBnXQUuP+tAKL Ow7tdKzgDBRV05dcK+b0NuY8Hmh/nm0K3regQHARlP0njysRqN5KThGxaVmjcyOgk/oosKym TOnwzn6qjLiZjSoSP07XPZ7JhdhbLapedrOc2WhsAZbhXqhwq4Db4BZ5S+vSs4qOzq1VAykN OkmXkdFvl0gkm9QkiF5T/WnyjpynIH9mLrw17wuwqGneXJABYBT/dnqa0cWB3D8EYktMx7y8 twrgWknoZMAQiFlCrw4MWgbWANqmOk5Xw4keASiHRDUYwRLL9JxLZvhX9oLA==
X-IronPort-AV: E=Sophos;i="5.82,234,1613433600"; d="scan'208";a="6878331"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Mon, 19 Apr 2021 10:51:58 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2242.008; Mon, 19 Apr 2021 10:51:58 -0400
From: "Gould, James" <jgould@verisign.com>
To: "rwilton@cisco.com" <rwilton@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>
CC: "draft-ietf-regext-secure-authinfo-transfer@ietf.org" <draft-ietf-regext-secure-authinfo-transfer@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" <regext@ietf.org>, "jkolker@godaddy.com" <jkolker@godaddy.com>
Thread-Topic: Robert Wilton's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)
Thread-Index: AQHXNSuMF+Mj+f50eUOiTOdkDnt2nA==
Date: Mon, 19 Apr 2021 14:51:57 +0000
Message-ID: <F707B13D-85AB-4C25-8387-4141C65BDE3F@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.47.21031401
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3239E501BD19C0429A5781F76890E41B@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/iJZj2ZSTZVibe0yFvdzeh9ICBQo>
Subject: Re: [regext] Robert Wilton's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (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: Mon, 19 Apr 2021 14:52:06 -0000

Robert,

Thank you for your review and feedback.  I provide responses to your feedback embedded below.

-- 
 
JG



James Gould
Fellow Engineer
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 4/19/21, 7:57 AM, "Robert Wilton via Datatracker" <noreply@ietf.org> wrote:

    Robert Wilton has entered the following ballot position for
    draft-ietf-regext-secure-authinfo-transfer-06: 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://secure-web.cisco.com/1nRJLRUiDha_wZnJfplBfW_pNR-Lw2xsv9qMMvatXWM3grB7zxr0vzxD0wFabNBjuWMawi8MSGohvoADlPx1luGJbH3vcnfYlia21So3k4RQWhOHzpjz6fGyDooK4AvwdPkg_1StQ_SQ1RdG0jK21rlCoY0tYim3vJcKfKjai0-12IC-P22F_w_JYt-GJxxgcH6bpU03vRvPp_If8O1a1-zuYTlTQDqMBRy6nyw5QqFA0znDRnkYtP4HTW3SlMD-C/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
    for more information about DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://secure-web.cisco.com/1rxr6X1OLj6yHWwZC-H4jTllgY_zX38cAQ0vMpclzgy1DMDjJs0nEThOO9aqx3f8nku40mR9XpzB1drPdbDe8orN31fBmSJquUXXjrwS6SJCWCyiZEHhf1jbEb1PzB0VLVzPLZn-lYpRt5fYSuB_vJWIKdd84JVnJlqF5VMEx8tG5nQPmSN0S4-NWF--scEabNqkCv2uJwvCKWEmUmANnztp_Fzlg5V_Ng5VEmO9RBN3r9xx30EB0UDiE8rOPG_1K/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-secure-authinfo-transfer%2F



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Hi,

    Thanks for this document.

    I found it hard to understand what is actually being transferred in the
    title/abstract.  Perhaps this could be expanded a little to help readers who
    are not familiar with EPP.

JG - EPP supports an extensible set of objects that can be transferred between registrars, but the most important object defined is domain names.  How about extending the first sentence to provide a little bit more clarity as in "The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the use of authorization information to authorize a transfer of an EPP object, such as a domain name, between clients that are referred to as registrars".  Providing what is being transferred and between whom may help things out.  Do you agree and do you have any recommendations to help non-EPP readers?   This could be updated in the abstract and the introduction.    

    I don't feel particularly strongly on this point, but when reviewing this
    document, I was wondering whether this document wouldn't be better published as
    informational rather than stds track, given that it seems to describe an
    operational practice of how an existing protocol (EPP) should be used.

JG - The working group had a thorough discussion around the track of the draft, which started out a BCP and moved to standards track.  The practice is relevant to the protocol, which does include signaling by the client and the server with defined behavior expectations, so standards track is the appropriate track.  

    Regards,
    Rob