Re: [regext] Genart last call review of draft-ietf-regext-epp-eai-10

"Gould, James" <> Tue, 26 July 2022 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEFCCC1C9538; Tue, 26 Jul 2022 11:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.409
X-Spam-Status: No, score=-4.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qs889P0J0Hig; Tue, 26 Jul 2022 11:37:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDAFEC1CD2E1; Tue, 26 Jul 2022 11:37:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; l=7020; q=dns/txt; s=VRSN; t=1658860654; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=8y+e3/Vco/+ZkpiO/lVMCE0jFepR/OnSEHx2ptGmXg4=; b=bCrEoun/Itu/Cvn+MBQMWo0E7APH08hVuRgyibujeEVcZo4NRmPsJ4rn vFIeExOpQ6qI0Q0eDunj5jAArAssllRwUjO1cggG2+Q5fpev2GYS+RKFW F8tsolmVX7xFuFZ+g2Z2E8e1jmeRQhQuJzOYNZigxTYqqbsb/gzKGjFy1 C1Qfkg0d747fu6aDe440dMIE1ybX3OusCnpBcLI8DKb1H3bbV5uMAei73 b+PTSkJI/tHhys4ndjEozr9/PZjvxUvSFJz1jFPP7z4yxgmlduOBObbAc SHWioERvnKTBQQE1xoB/lS362FrWZgs3BEa2el5SjWHiU2jk7+iyVA80p Q==;
IronPort-Data: A9a23:CC8g86vte8E9dCaP/cgTuuS84+fnVFxfMUV32f8akzHdYApBsoF/q tZmKT+DMvnZY2umKNggaN+1/U8BsJXcnIJnTVZkqCg3ECMb9ZOVVN+UEBz9bniYRiHhoOCLz O1FM4Wdc5pkJpP4jk3wWlQ0hSAkjclkfld4YQL9EngZqTVMEU/Nsjo+3b9i6mJUqYLhWVnV5 oms+5S31GKNgFaYDEpFs8pvlzsy5JweiBtA1rDpTakW1LN2vyB94KM3fcldHVOhKmVnNrfSq 9L48V2M1jixEyEFUYr5z+mhIiXmdZaJVeSGoiI+t6GK3EAe9nRqukoxHKJ0hUx/011lkz3to TnkWFPZpQoBZ8XxdOohvxZwEwxxZJBc96b9L2Hh8ue/kRPbXySv3KA7ZK02FdVwFudfK1tor MM+BQBVN1adjOWs2PSyRq9ynN8lasLsOevzuFk5lXeAUq1gGM2YBfmajTNb9G5YasRmH/nZe s4VQSRidhXbYhJJfFwQDfrSmc/x2SWhLWUA9jp5o4IYwTeN/At334LXbtr4VfOEYJ9VhVuH8 zeuE2PRR0ty2Mak4SCI6XStjeznkDv6Q54fEbD+8PN26HWcy2pWAQcKfVq2vff/jVSxM/pTM UUa5m8voLQ8sVamQdTtQ1i1uGbBsxcdHdNUF8U75R2DjK3O7G6xAmEfUntKYdginM47WTJs0 UWG9/vzCDNioKG9SH+B+PGTtzzaBMQOBWUYY3YbSwYVu4Cmu58pyBfOVZNpF+i/lNusXy/q2 DbMpy8771kOsfM2O2yA1Qivq1qRSlLhF2bZOi2/srqZ0z5E
IronPort-HdrOrdr: A9a23:MHohgK0YQiNYK6b4Xvj6RwqjBJYkLtp133Aq2lEZdPUMSL37qy iv9M526fdt4AxhI03I6urwXZVoJkmsj6KdgLNhRYtKMzOHhILFFutfBOjZskDd8k/Fh41gPM 5bGsAUNDSaNzdHZLPBgTVQZOxP/DDoys2VbKzlvhNQpElRGsZdB00SMHf8LqRZfng+OaYE
X-IronPort-AV: E=Sophos;i="5.93,194,1654560000"; d="scan'208";a="17466006"
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.28; Tue, 26 Jul 2022 14:37:18 -0400
Received: from ([]) by ([]) with mapi id 15.01.2375.028; Tue, 26 Jul 2022 14:37:18 -0400
From: "Gould, James" <>
To: "" <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Genart last call review of draft-ietf-regext-epp-eai-10
Thread-Index: AQHYoR67DtXWZdhe4UuTWc1VajdARg==
Date: Tue, 26 Jul 2022 18:37:17 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.62.22061100
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [regext] Genart last call review of draft-ietf-regext-epp-eai-10
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jul 2022 18:37:39 -0000


We addressed some of your feedback (Minor issues and Nits/editorial comments) in draft-ietf-regext-epp-eai-13 and I responded to your Major issues below.  Do the updates made in draft-ietf-regext-epp-eai-13 and the explanation for your Major issues address your feedback or is more needed?  There was a follow-on thread with John C Klensin, Martin J. Dürst, and Dmitry Belyavsky that didn't look to result in any needed changes to the draft.  



James Gould
Fellow Engineer <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/>

12061 Bluemont Way
Reston, VA 20190 <>

On 6/1/22, 4:23 PM, "Gould, James" <> wrote:


    Thanks for the review and feedback.  My responses are embedded below prefixed with "JG - ".  



    James Gould
    Fellow Engineer <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/>

    12061 Bluemont Way
    Reston, VA 20190 <>

    On 6/1/22, 1:14 PM, "Pete Resnick via Datatracker" <> wrote:

        Reviewer: Pete Resnick
        Review result: On the Right Track

        I am the assigned Gen-ART reviewer for this draft. The General Area
        Review Team (Gen-ART) reviews all IETF documents being processed
        by the IESG for the IETF Chair.  Please treat these comments just
        like any other last call comments.

        For more information, please see the FAQ at


        Document: draft-ietf-regext-epp-eai-10
        Reviewer: Pete Resnick
        Review Date: 2022-06-01
        IETF LC End Date: 2022-06-09
        IESG Telechat date: Not scheduled for a telechat


        I think this proposal is reasonable, but I don't think enough explanation has
        been given regarding the case where one side supports the protocol but the
        other side doesn't.

        Major issues:

        The last bullet item in section 5.3.2 talks about "alternative ASCII address",
        but I don't see anywhere in the document which defines how to provide an
        alternative ASCII address in the data. For example, RFC 5733 implies that there
        will be only one email address in the Contact Mapping; can an implementation
        simply add a second? Does the server then need to distinguish these by the
        presence or absence of non-ASCII characters to determine which is an EAI and
        which is an alternative ASCII address? At the very least, some discussion of
        this seems necessary in the document.

    JG - The reference to the "alternative ASCII email address" is for the client (registrar) when it's recognized that the server does not support EAI.  If the registrar collected an EAI address and an ASCII address, then the ASCII address MUST be provided; otherwise, the optional property SHOULD be omitted.  The use of an ASCII proxy email address can be used as well.  In this case, the server does not support EAI addresses, so it's up to the EAI-supporting client to handle it.  Most likely the server validates that the address is only an ASCII address, but there is no guarantee of it.   

        Minor issues:

        In the bullets in section 5.3.2, there are quite a few SHOULDs with no
        explanation of why one might choose to violate these. Why are these not MUSTs?
        I can't think of any reason, for example, that the server would not validate
        the email property, and it seems like a really bad idea not to.

    JG - I cover each of the SHOULDs below:

    1. For the required email property with a client that doesn't signal support for EAI, the server needs to satisfy the negotiated services . This should be a MUST to comply with the negotiated namespaces, since the downside is that the client will receive an error response with an info command if they still don't support EAI in the login services.   The error response is a MUST in the third bullet.
    2. For the optional email property falls the same case as the required email property, since the info response will result in an error.  It should be a MUST as well.  The error response is a MUST in the fourth bullet.

        Nits/editorial comments:

        Abstract: Strike the word "appearing"

    JG - Yes, that can be removed.

        Section 3: Change "By applying the syntax rules of [RFC5322]" to "By applying
        the syntax rules of [RFC6532]"

    JG - I'll leave this one for Dmitry to respond to, but changing RFC5322 to RFC6532 looks correct to me.