Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-regext-epp-eai-10
Dmitry Belyavsky <beldmit@gmail.com> Sun, 05 June 2022 11:31 UTC
Return-Path: <beldmit@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CBEC14F747; Sun, 5 Jun 2022 04:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StG94Ybf7X4X; Sun, 5 Jun 2022 04:31:22 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4A2C14F730; Sun, 5 Jun 2022 04:31:21 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id t25so19297494lfg.7; Sun, 05 Jun 2022 04:31:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=onNiol6tXPku6oQ8uIFz5HNmkvYTa3gAAUsN2QY0rQ0=; b=L1PQ/ZvPjPYW07cl2AzxefHOLqVBqqJmhbUc+KmltaA6zBqrac4rmo8CKL+XrtqaEl WahcG6mhYFFXj5eSeg4z/si8IgJT883RQWAdJ7aidX5O9nylJusLbo0oslIGaindFL4Y 7PAoUfFRmHq1BvTEwgQjlkhKjX4G41de0RfLGHsS/OhEJYRreAm3rvENc/sUZ1KD7bWE oExmP47xbiOrnuhU5FoHCxWBRfsC0DMt6ZUkKPw5us4x1QGTvURii3lzPnyCJv47NTCC XRe4LMAyK1DRNlSE9vRTWKdN/i09/gyqqOXpsY6nsndI4+TP3lKklYaVIzEJUxiWMyLG XpAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=onNiol6tXPku6oQ8uIFz5HNmkvYTa3gAAUsN2QY0rQ0=; b=GjSpsnw65RhTkRykzKp0YrnLyuGQaov9NhkwAR/+S+umMAwbNbxHo+gxIQmw+r6cg5 1pag8uVsuVz5keS+x4YmMNPF+LwPIAorceSItTNaN5HBc7nBai/AwCoY27ykn0zREvT4 8nl0NlzJ4HRbc0zaLnJ4Q+a3Kra/wK6ITCUfVHe1xIZEmpLSu9tm2wjYGnd3WITJZxqH q+VzgreU3sC1IVoTeUgmyzL7D4v1vy0znv6rjf2CfQF1zb7KC/DTSIMH4b02+/LVe9uX mQV41gIVwT4paOorGYjI3v8oGme4qKlvSBFDyTNfbZN/T3l4xkIbdP8WIqC+9+1/7ffS vq6w==
X-Gm-Message-State: AOAM5309WHthF5Jaj6fKmA343IKFG3wL/mqWYOWcSE+XysSaVWcxVERn EfNfeExl/QfuNlZAHyIBYPnUSUzfEuyP0jI5Vgo=
X-Google-Smtp-Source: ABdhPJyih5NnLCIU7vzYeAG9UtVejL9nV1bZaNgFBJBgy5ixef++bvy5oBMO6xhgnama4I9RBMWFXPBkVUX9zL6BFqM=
X-Received: by 2002:a05:6512:4024:b0:477:b981:de5f with SMTP id br36-20020a056512402400b00477b981de5fmr12577286lfb.350.1654428679708; Sun, 05 Jun 2022 04:31:19 -0700 (PDT)
MIME-Version: 1.0
References: <165410367843.9432.758562996445667068@ietfa.amsl.com> <342ADE07-655E-4132-8254-4E3AB2511E57@verisign.com> <71B4B28036B5BE0E80796F67@PSB>
In-Reply-To: <71B4B28036B5BE0E80796F67@PSB>
From: Dmitry Belyavsky <beldmit@gmail.com>
Date: Sun, 05 Jun 2022 13:31:06 +0200
Message-ID: <CADqLbzLkYwoh-sc4VgNVFJDLCOZoGR9-74C1AkT41UzmkB9cvA@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>, resnick@episteme.net, Yoshiro Yoneya <yoshiro.yoneya@jprs.co.jp>, i18ndir@ietf.org, gen-art@ietf.org, draft-ietf-regext-epp-eai.all@ietf.org, last-call@ietf.org, regext <regext@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c2a25905e0b1b1f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/STAtisi7DdGKfBvN5ArILlT4PTg>
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-regext-epp-eai-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Jun 2022 11:31:24 -0000
Dear John, First, please apologize me for not participating in the original discussion On Thu, Jun 2, 2022 at 9:06 AM John C Klensin <john-ietf@jck.com> wrote: > Pete and James, > > Let me add one thing to Pete's (and Yoshiro Yoneya's) > comments/concerns. I tried to raise this earlier, but obviously > did not explain it well: > > > --On Wednesday, June 1, 2022 20:23 +0000 "Gould, James" > <jgould=40verisign.com@dmarc.ietf.org> wrote: > > > Pete, > > > > Thanks for the review and feedback. My responses are embedded > > below prefixed with "JG - ". > >... > > On 6/1/22, 1:14 PM, "Pete Resnick via Datatracker" > > <noreply@ietf.org> wrote: > >... > > Reviewer: Pete Resnick > > Review result: On the Right Track > > > >... > > 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 > > > > Summary: > > > > 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. > > Unless I don't understand the use cases for the information > being handled by EPP and this proposed extension, there are > actually three "sides" / "parties" for the data and their use. > One is the registrar or equivalent, in software normally the EPP > client. The second is the registry or equivalent, in software > normally the EPP server. If those were the only two actors, one > could be quite relaxed about the server being ready to handle > non-ASCII email addresses because the decision to accept > non-ASCII email addresses or not could be a contractual matter. > >From a contractual perspective, a registrar/client who sent a > non-ASCII contact address to a registry/server who would nor or > could not accept such things would be a much worse problem that > questions of how the protocol dealt with that behavior. > > However, in many, probably most, registry arrangements, there is > also a requirement for registry databases that contain, among > other things, contact information for registrants, etc. While > circumstances and regulations may impose conditions for third > parties to access those data, such access must always be > possible. That is probably the important case for alternate > ASCII addresses. Not only are those third parties typically not > part of the EPP transaction itself, but the registry faces the > same issues that motivated the EAI WG to generate RFC 6857 and > 6858: it cannot know, at the time information is placed in the > database, what the capabilities of those authorized to access > the data later will be. > I agree. We have government regulations and ICANN rules for these cases. But all these requirements are out of scope of this document. I agree that it puts an extra burden on the 3rd parties - but the relationship between registry data and 3rd parties are definitely beyond the IETF scope. > Against that backdrop... > > > 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. > > While I understand you are speaking informally here, to increase > the odds that the text will be correct, please note that there > are no such things as "supporting EAI" or "EAI addresses". EAI > is simply the name/acronym for the working group that produced a > set of specifications. Those specifications indicate that, if > you are looking for a generic term, you should use the name of > the SMTP extension, i.e., "SMTPUTF8". > > Now, when I read the above paragraph in the context of those > registry databases and third parties accessing them (and assume > that, when you wrote "EAI", you meant "addresses with non-ASCII > local parts" or "SMTPUTF8"). Those EAI WG-developed specs, > reinforced by operational experience since they were developed, > make it very clear that, unless it is known that those who will > be using --not just transferring-- the addresses are able to > handle and utilize email addresses with non-ASCII local parts, > that either there must be a reliable way to obtain an all-ASCII > alternate address or not being able to use the contact address > much be acceptable. Absent a directory structure somewhere that > records addresses with non-ASCII local parts and the all-ASCII > fallbacks for each -- a directory that, in a registry type of > environment, would need to be populated somehow, presumably by > EPP -- the only reliable way to have those all-ASCII addresses > available is to provide for (and probably require) them in the > EPP extension and store them in the registry database. And, > unlike the situation contemplated by RFC 6858, registry > databases are typically required to contain contact information > that is both usable and accurate, more or less eliminating the > option of simply recording an address that cannot be used. > In normal situations registries don't use its database for contacts with domain administrators. If a registry supports non-ASCII email addresses in EPP, it should also support it in case of emergency contact. But again, it's out of scope of registry-registrar protocol (EPP) definition. > So, coming back to your paragraph, one of my concerns (and I > think at least part of Pete's) is that, if one option is "the > use of an ASCII proxy email address", then you need to spell out > where that address is going to come from. Or, if the registry > cannot guarantee that anyone who might legitimately have access > to the registry database will be able to properly process and > use contact information that contains email addresses that > require SMTPUTF8, they must insist on being given all-ASCII > addresses (presumably starting by insisting that the registrar > collect them). That, in turn, would make this extension very > nearly useless except, perhaps, for a subset of ccTLDs who could > impose just that requirement as a condition of legitimate > access. > > In addition, you say > > "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." > > I don't know what that sentence means. This extension does not > appear to allow the registrar/client to transmit two addresses > over EPP to the registry. So, if an all-ASCII address MUST be > provided, it is the only one and then there is no need for the > extension (at least as I read the spec). If the "optional > property" is not used for all-ASCII addresses, then is then, at > best meaningless and I don't understand the SHOULD". The same > situation would apply if the registrar collected only an ASCII > address: the SHOULD does not appear to make sense. And, if the > registrar collected only an SMTPUTF8 address, then the only way > to transmit it is using this optional property. > > >... > > 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. > > It seems to me that what you just said is that the "SHOULD"s > were in error and that they really should have been "MUST"s. If > that is the case, the affected bullet points would, at least, be > much more clear. > > I replaced these SHOULDs with MUSTs. > > >... > > 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. > > FWIW, note that issue was raised in my Last Call comments on May > 26 [1] and, so far, not responded to. If you (and that should > mean with approval of the WG, not just you and/or Dmitry) are > not going to change it, some explanation would be, at least IMO, > appropriate. > > thanks, > john > > > [1] > < > https://mailarchive.ietf.org/arch/msg/last-call/pDEjCW75nLxnd-NbNcPR3E7VKfE > > > > Thank you, I picked this change and it will appear in next version of the document -- SY, Dmitry Belyavsky
- [Gen-art] Genart last call review of draft-ietf-r… Pete Resnick via Datatracker
- Re: [Gen-art] Genart last call review of draft-ie… Gould, James
- Re: [Gen-art] [Last-Call] Genart last call review… John C Klensin
- Re: [Gen-art] Genart last call review of draft-ie… Dmitry Belyavsky
- Re: [Gen-art] [Last-Call] Genart last call review… Dmitry Belyavsky
- Re: [Gen-art] Genart last call review of draft-ie… Gould, James
- Re: [Gen-art] [Last-Call] Genart last call review… John C Klensin
- Re: [Gen-art] [Last-Call] Genart last call review… Gould, James
- Re: [Gen-art] Genart last call review of draft-ie… Gould, James