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

"Gould, James" <jgould@verisign.com> Mon, 19 April 2021 15:33 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 84F2A3A35CE; Mon, 19 Apr 2021 08:33:42 -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 Z9m5FkC_0WFc; Mon, 19 Apr 2021 08:33:37 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 9F4133A35CC; Mon, 19 Apr 2021 08:33:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3572; q=dns/txt; s=VRSN; t=1618846418; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=iiFUs0E1APjpzlwvxgcguDs3I1+NwIW6rUUpPZkkQVs=; b=FbIrmK3XGxT1VsDhsHSHFpHvtWVHOKK0Sxsx5Vg4veBluaypKLOtYCSj /XjjRbhBCFQEfVbvj3t8zBTE3PD1b2ayNiMn1Aga7uYzZZSGiF3ztX0hG +1S6JK9GogNkt0lXZhcUFBwr3nfMubBuzp/5hf9o+mdTv0lCn1TbdFWkA eSvw0dmk9OelPLBZdIyLWI6jl62zdRu+/QM1sOzwFE2zzmXblBK8H6xkp yMz77LhtYJ3BZjW5bhctpqWCriPJOxK50qpiDWkkWnJgai9LYXImuGBOs 09FJCnwcKZBRhXdpbwgcNBVRknueydY6LlxppDp2GXMURPN2hPRwrbZB+ g==;
IronPort-SDR: il6ybiyuzhVLqXQfgb48a/SKgEl4IZrbbEAiQ87Zfef2I3SEAS15BYVKToLYB/jGmTfF6XmuiF ceibEIEXa+ySbwUwRn6dLLZVi6AH31zy80rzfWoZRZ5+5DPOYy5BO5e5RQ3dTKS/xxYSXLrNkm 9uVZLCufCgTtin5GsGsKooVvqfo3W8gYf5iXO4IHtZ2+8XJYjO/2c4109IYwsHqsJfwun6R4ly ehz84fq0nXCipz/5gFFWv9Sfvt/BGdb3b1jcuQhjSiHDX1WilIlIE/3E/QjqYY6JqkzuyXst4F 7s4=
IronPort-HdrOrdr: A9a23:AILIi6tM4bk7Sn40MaWmY9oX7skCY4Mji2hD6mlwRA09T+Wxnc qjhele8BfyhioYVn1Io6HjBICraxrnmaJdy48XILukQU3HlQKTXfpfxKHlxCDtHDC70+Zb27 tpfaQWMqyUMXFRi8Hm7A6kV+s6yN6c/6yywcvYxXFhTQZlApsQlTtRIACdD0FwWU16FYM0fa DsnvZvijK8dR0sDviTKWICW4H4zeHjsLLDTVo4CwU86A+I5AnYlYLSNxSDxB8RX3du7N4ZgA v4ujf07KmirP23oyW0vwTuxq5Lk9jswMYrPqOxo/UVMTnlh0KJY4lsStS53QwdneC15F4m1O TLuhcrVv4c11rteAiOzCfF6k3F6nIO42Wn4UKEiXHjyPaJIA4SOo5kv8ZlVTf3r2Anp8px1a pX2XnxjesxMTrdhijno9DHWxZ2/3DEx0YKgKoUlHxQUYwXdb9Xo8ge5SpuYe49IB4=
X-IronPort-AV: E=Sophos;i="5.82,234,1613433600"; d="scan'208";a="7436542"
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 11:33:34 -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 11:33:34 -0400
From: "Gould, James" <jgould@verisign.com>
To: "martin.h.duke@gmail.com" <martin.h.duke@gmail.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: Martin Duke's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)
Thread-Index: AQHXNTFcqPFqD+wJ9UC17Dz3mGNGyA==
Date: Mon, 19 Apr 2021 15:33:34 +0000
Message-ID: <B8C17844-512E-4DFB-9C6B-D8801D5614C7@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: <854BF157B005944C9AAC2984C1EA9193@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/ihIr9HvIf_x03rECZBa-o-39WmM>
Subject: Re: [regext] Martin Duke'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 15:33:43 -0000

Martin,

Thank you for the review and feedback.  

-- 
 
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/9/21, 8:17 PM, "Martin Duke via Datatracker" <noreply@ietf.org> wrote:

    Martin Duke 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/1494LouXp6bnWPFFb6b5w8o2N6PBUWORrjKHj7DaJ1fIpki6yYVATnUosU_eR__hWijPM6aZrt4vX-R70aY_Ve_217eTqq4T3H1p3S5Jmr8L0THnw_Vx6y04g1mtiIN_2y01sFHCguCYGtz1gEUVkFYy73r5m6vh-lXVKBt7OCUB2Ptb7_Cf5ajuHaeu2_LbG6VMiYAyLuS2AaWhRknr2RYBYFb_b2wh-BeAmqodQNRX1Xfl_LAXAa8LlKnXEMIKT/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://secure-web.cisco.com/1tY59lQ76IHNrNSCIANCtv_U3SJiFbCWPeNsk4IQ4UyZpg9VaGurEaU4pEsj5bPBvSOY8M4-8dwJR04JEHaz7xQxWqYnKBw8V-IYqayrShT4hPYDmk-Rs-o9w5cW0z_QABUGhNHzN7zCR8S9j0EdScfgTBC072IFBPGEPBFMjIZr-w_yfRbb_VYwghXmTt60IFtBBPMRul1biaf2rUeCcO3Uh65Boc76I86PYBa-IikrXpA8chtAHSjMPSlYsHcFG/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-secure-authinfo-transfer%2F



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

    In the third paragraph of (5.3) there is a roundabout way of saying how the
    registry responds to a valid info request by saying that it MUST NOT send no
    authorization value, or a non-empty authorization value. It would be more
    straightforward to say something like

    "the registry MUST respond to a valid info request by the non-sponsoring
    registrar with an empty authorization value".

JG - The third paragraph needs to be as explicit as possible to cover never including the authorization information value, but with the support of an optional existence indication of an authorization value only to the sponsoring registrar.  Considering the combination of non-empty elements, empty elements, and two different types of clients (registrars), I believe the paragraph needs to stay as is.