I support. Thanks Rick
From: regext <regext-boun...@ietf.org> on behalf of Antoin Verschuren <ietf=40antoin...@dmarc.ietf.org> Date: Monday, December 20, 2021 at 8:55 AM To: regext@ietf.org <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04 CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting. ________________________________ Dear WG, This WGLC will end tonight, and so far we only have 2 explicit voices of support. This is a bit low to declare consensus. Could more people voice their support? Scott, can you confirm that the changes in version 05 address your initial concerns? - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 19 dec. 2021, om 19:11 heeft Dmitry Belyavsky <beld...@gmail.com<mailto:beld...@gmail.com>> het volgende geschreven: On Sat, Dec 18, 2021 at 2:53 PM Taras Heichenko <ta...@academ.kiev.ua<mailto:ta...@academ.kiev.ua>> wrote: > On 15 Dec 2021, at 16:14, Dmitry Belyavsky > <beld...@gmail.com<mailto:beld...@gmail.com>> wrote: > > Dear Taras. Dear Dmitry > > On Tue, Dec 14, 2021 at 8:13 PM Taras Heichenko > <ta...@academ.kiev.ua<mailto:ta...@academ.kiev.ua>> wrote: > The comment is in body. > > > On 13 Dec 2021, at 15:15, Hollenbeck, Scott > > <shollenbeck=40verisign....@dmarc.ietf.org<mailto:40verisign....@dmarc.ietf.org>> > > wrote: > > > >> -----Original Message----- > >> From: Gould, James > >> <jgould=40verisign....@dmarc.ietf.org<mailto:40verisign....@dmarc.ietf.org>> > >> Sent: Thursday, December 9, 2021 11:59 AM > >> To: Hollenbeck, Scott > >> <shollenb...@verisign.com<mailto:shollenb...@verisign.com>>; > >> ietf=40antoin...@dmarc.ietf.org<mailto:40antoin...@dmarc.ietf.org> > >> <i...@antoin.nl<mailto:i...@antoin.nl>>; > >> regext@ietf.org<mailto:regext@ietf.org> > >> Subject: [EXTERNAL] Re: Re: [regext] WG LAST CALL: draft-ietf-regext-epp- > >> eai-04 > >> > >> 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. > >> > >> Scott, > >> > >> Thanks for the review and feedback. I provide responses to your feedback > >> embedded below. > >> > >> -- > >> > >> JG > >> > >> > >> > >> James Gould > >> Fellow Engineer > >> jgo...@verisign.com<mailto:jgo...@verisign.com> > >> <applewebdata://13890C55-AAE8-4BF3-A6CE- > >> B4BA42740803/jgo...@verisign.com<mailto:B4BA42740803/jgo...@verisign.com>> > >> > >> 703-948-3271 > >> 12061 Bluemont Way > >> Reston, VA 20190 > >> > >> Verisign.com<http://Verisign.com> <http://secure-<http://secure-/> > >> web.cisco.com/1bUEhaRz5CoSQPd4colm8eTGE5D6zPQvtrYPAzQf9pUSXnqD<http://web.cisco.com/1bUEhaRz5CoSQPd4colm8eTGE5D6zPQvtrYPAzQf9pUSXnqD> > >> Nq7mmnlZ8At92joPzY5DkJdQiiPe1mlyvgzDAdDz_shcqHzSugkfXA2qX9z7aQp0 > >> 6ld- > >> LnwMzxo2VGkwqFH5gLrI7qSYQlgj4Unll4AIUd6ALSZ38i2kjYqgA0AnBBjaJEVg7 > >> yUIN- > >> P8bpFGxQgN__tWour_sxUBBx2vUcVpmrR7SUG6UsUo5U3gb_YbWCYcRn8b > >> 4Rl06BQIL8B8k/http%3A%2F%2Fverisigninc.com<http://2Fverisigninc.com>%2F> > >> > >> On 12/6/21, 9:18 AM, "regext on behalf of Hollenbeck, Scott" <regext- > >> boun...@ietf.org<mailto:boun...@ietf.org> on behalf of > >> shollenbeck=40verisign....@dmarc.ietf.org<mailto:40verisign....@dmarc.ietf.org>> > >> wrote: > >> > >> > >> A few questions/comments: > >> > >> Section 6: We need to provide the rationale for that SHOULD (Registries > >> SHOULD validate the domain names in the provided email addresses). What > >> does "validate" mean? For syntax? For reachability? > >> > >> JG - This is associated with validating the syntax. The goal is to ensure > >> that > >> the domain name, whether an ASCII or IDN domain name is a syntactic valid > >> domain name the may be reachable. Would it help to modify this to read > >> "Registries SHOULD validate the syntax of the domain names in the provided > >> email addresses so they may be reachable."? > > > > [SAH] Syntax validity is no guarantee of reachability. The only way to > > confirm > > that an email address "works" is to send email to that address and confirm > > that it's delivered. I don't think we want to suggest that registries should > > start sending out email delivery tests, so maybe something like this > > instead: > > > > " Registries SHOULD ensure that the provided email addresses are > > syntactically > > valid to reduce the risk of future usability errors." > > The check of existing of the domain (MX or at least A/AAAA record) from the > email address may be added. I am not sure that it should be there but it also > raises the probability that the email address is valid. > > Personally I don't think it is feasible to reject the contact > registration/change if these records don't exist. > And anyway, it's out of scope for this document. I just wanted to say that there are different ways to check the validity of an email address. If some registry does such a check will it be contrary to the RFC? May we need a phrase that allows wider Interpretation? I don't see it will be contrary, and so I don't think we need to specify this in this document. BTW, I've already removed the phrases about extra email limitations. > > > > > >> Section 7: What's significant about "eai-0.3"? The "0.3" part doesn't > >> track to > >> the current version of the draft; perhaps "1.0" would be better now. See > >> also > >> Section 5.2. > >> > >> JG - Yes, the namespace will be changed to "eai-1.0" once it passes WGLC > >> similar to what has happened in past EPP extensions with pointed > >> namespaces. > > > > [SAH] OK. > > > >> Section 8: It might be helpful to add more text to explain why > >> "Registries > >> MAY apply extra limitation to the email address syntax". Why might they > >> want to do that? It seems a little unusual to say that they MAY do > >> something, > >> but in the next sentence say, "These limitations are out of scope of this > >> document". > >> > >> JG - Agreed, this does not look to add value. Do you believe the > >> Implementation Considerations section should be removed, since the > >> contents really don't provide any material considerations? > > > > [SAH] Yes, that's probably a good idea. > > > > Scott > > _______________________________________________ > > regext mailing list > > regext@ietf.org<mailto:regext@ietf.org> > > https://www.ietf.org/mailman/listinfo/regext > > -- > Taras Heichenko > ta...@academ.kiev.ua<mailto:ta...@academ.kiev.ua> > > > > > > _______________________________________________ > regext mailing list > regext@ietf.org<mailto:regext@ietf.org> > https://www.ietf.org/mailman/listinfo/regext > > > -- > SY, Dmitry Belyavsky > _______________________________________________ > regext mailing list > regext@ietf.org<mailto:regext@ietf.org> > https://www.ietf.org/mailman/listinfo/regext -- Taras Heichenko ta...@academ.kiev.ua<mailto:ta...@academ.kiev.ua> -- SY, Dmitry Belyavsky _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
