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

"Gould, James" <> Wed, 01 June 2022 20:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A543C14CF17; Wed, 1 Jun 2022 13:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Status: No, score=-2.106 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 WBGszVmS2_nD; Wed, 1 Jun 2022 13:24:21 -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 5509FC14F6E7; Wed, 1 Jun 2022 13:24:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; l=5900; q=dns/txt; s=VRSN; t=1654115061; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=AZ/qLyegWIf4rQ75VzewOmQAaMiW7Lej85Y9DU5f3L0=; b=VzIqiNVsGTlLHvKqx0+7AdwU4xVtv15QMXX4ymY2mHxtmpTcLl0mImkS BnAyNpSYUVPF/fbwztF4aESn7EwWmB54QyqCx5D6eJa4Xms2im/tQ6fQ2 nYdnCc0Jw+zJVRxfhmSvDFz45KJhYlVgdb1x3nknnTYNEO1NRrMJv15OV gIBRzoZKOY1azPVzlUl4ItnL9K7GwrtKnicnozmD7FednL3HkUSsyuf+a +e7ZaJ/cBSJMJzKL+xhiIvgdbJQgrQs9KS/bJMXAhyT6HiTOYh4i/DuZB epxA1oVC974OceodX6mt+0uAyyiZ0iz0hU4mXfmxv87u12RN9lN149HCs Q==;
IronPort-Data: A9a23:GY/hAqkN5ItM4EXBaUi/Y8Do5gyLJ0RdPkR7XQ2eYbSJt1+Wr1Gzt xJKDWiDaKmLNGPxeY9yaY+z/U8Pv5bdmtFgTVA9qy5kRC4T+ZvOCOrCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZllwtMQMcacUsxLbVYMpBwJ1FQywobVvqYy2YLjW13V4 IupyyHiEATNNwBcYzp8B52r9UsHUMTa4Fv0aXRnOJinFHeH/5UkJMp3yZOZdhMUcaENdgKOf Nsv+Znilo/v10x0Vo76yOaTnnoiGdY+NSDW4pZfc/b63kga/kTe2I5jXBYXQR8/ZzlkA7mdY TiC3HC9YV5BA0HCpAgSewh1OT5nZrx3wq3OCl3ltM+u4xPnc3S5lp2CDGluVWEZ0sxNJzhx0 9EocGpLcBuEnfrwyb79VPN3gIIoK8yD0IE34ykmlG6CS697GtafEs0m5vcBtNs0rsJBGuvaa +IHZCBudxXPZVtEPVJ/5JcWxbv32SSkI2cwRFS9nvE3zXqN1B5K4rG3DOf6QeCjSoYLgRPNz o7B1yGjav0AD/SFxCGD83mvruLXnDjnVYcfUru16pZCj1CVg2UJFDUXWEe15/6jhSaWV8hWJ VBR+ycyo+0o+UOmXsW4UgWg5XONv1gVX954EuAm5keK0KW8ywKQHXRBRTdFbPQnudM4Azsw2 Tehhd7mCCxzmLyYVXzb8a2bxQ5eIgAfN2lbeikJXVNfpsL9usc2jwmKRNElGrSz15vrAyr2h TuNqUDSmokusCLC7I3jlXivvt5mjsGhotIdjukPYl+Y0w==
IronPort-HdrOrdr: A9a23:B6QP264RhWYBvkFWDwPXwBjXdLJyesId70hD6qkoc20wTiSZ// rDoByCvSWE9Qr5K0tQ/uxoX5PwPU80lKQFm7X5Uo3DYOCLggGVxcRZnO7fKl7balLDH4xmpM RdmsFFYbWaMbE5t7eZ3ODSKbkdKay8kZxA8t2x854Cd2xXgupbnmFE406gYzRLrEMtP+tAKH Oz3Ls9mwad
X-IronPort-AV: E=Sophos;i="5.91,269,1647316800"; d="scan'208";a="14775382"
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Wed, 1 Jun 2022 16:24:15 -0400
Received: from ([]) by ([]) with mapi id 15.01.2375.024; Wed, 1 Jun 2022 16:23:49 -0400
From: "Gould, James" <>
To: "" <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: [EXTERNAL] Genart last call review of draft-ietf-regext-epp-eai-10
Thread-Index: AQHYddsVJqvztoSvwUSZTDGrSW1fYa06/0iA
Date: Wed, 01 Jun 2022 20:23:49 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.59.22031300
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-regext-epp-eai-10
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jun 2022 20:24:25 -0000


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:

    Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 

    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.