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> 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 <applewebdata://13890C55-AAE8-4BF3-A6CE- > > >> B4BA42740803/jgo...@verisign.com> > > >> > > >> 703-948-3271 > > >> 12061 Bluemont Way > > >> Reston, VA 20190 > > >> > > >> 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%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 > > > <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 > > <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 > > <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 > <https://www.ietf.org/mailman/listinfo/regext>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
