Taras, Thank you for your feedback.
It looks like for use case #1 (create command of EAI address with non-EAI supporting server) the preference is for a mix of "Collect ASCII value from registrant" and " Use proxy ASCII value" based on registrar policy, where a valid email address MUST be provided. For use case #2 (info response of EAI address with non-EAI supporting client) the preference is for the registry to return a 2308 “data management policy violation” error to fast-fail for a non-EAI registrar. Based on the above, the definition and use of the predefined placeholder value would be removed from the draft and updated with the preferred approaches to address use case #1 and #2. Are there any other thoughts on how to address these two use cases? Thanks, -- 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://verisigninc.com/> On 8/4/21, 4:18 PM, "Taras Heichenko" <ta...@academ.kiev.ua> wrote: Hi James, all. > On 4 Aug 2021, at 15:38, Gould, James <jgould=40verisign....@dmarc.ietf.org> wrote: > > Thank you for your perspective for use case #2 (info response of EAI address with non-EAI supporting client). Do you have any thoughts related to use case #1 (create command of EAI address with non-EAI supporting server), with the following options: > > • ASCII placeholder value – The current proposal is the use of e...@empty.as112.arpa. The assumption is that using a placeholder value is not the preferred option based on your feedback on use case 2. > • Collect ASCII value from registrant – This is counter to the goal of supporting EAI, so it would only be done to pass a compliant value to a non-EAI supporting server. > • Use proxy ASCII value – The EAI registrar would need to be able to support EAI registrants and mix of EAI-supporting registries by providing a ASCII proxy value to a non-EAI-supporting registry. The proxy value to use would be up to registrar policy. > • A mix of the above options. I think that the main point is registrar must do everything to set an email address that provides the registrant with mail concerning the domain. Placeholder is not the case. All other looks appropriate. The registrar should explain to a registrant that the correct email address is much more important than EAI. If a registrar has good marketing it can make an ASCII proxy email for a registrant (and offer it as an additional but free service :) ). But provide a valid working address in registrant information is a must minimum. > > Thanks, > > -- > > 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-web.cisco.com/1XcmZvNWKvKNxdkB8z9Dw9YSZBqD0qjFxHnTJENRM6aia1UGFckfv2xd1T2taB2RX7Qltk_3csqItb58nEI3a56xblluH6M8_RLGPcslIHCuck5CGMwcwSC6JXoLS2IJDAZPuptkZfsxypIEh-5oBUpz2td7RVUg5RRwNu0NMd0PipYr-0weoOnzSYvXYwLE0vY8Z_C_s2WnErwRrlmj36mKRtYgV1o_QNCS8YjR_bcLALBYhqUDGELAtxzXiSfk9AaikKoMmO5gGwRqUAxGZwQ/http%3A%2F%2Fverisigninc.com%2F> > > On 8/4/21, 2:21 AM, "Taras Heichenko" <ta...@academ.kiev.ua> wrote: > > > > On 2 Aug 2021, at 21:08, Gould, James <jgould=40verisign....@dmarc.ietf.org> wrote: > > > > Thomas, > > > > For use case #2 (info response of EAI address with non-EAI supporting client), your preference is to return a failure. Is 2308 “data management policy violation” the best error code in your opinion? Do others agree that for this use case the server should return an error to a non-EAI supporting client in place of returning a successful response with a predefined placeholder value for the required email element when the value is an EAI address? For this use case the most likely scenario is that the querying client is the non-sponsoring client, since they didn't create the contact. > > Just my 2 cents. There are two kinds of registrar-registry participants in the registration process. The first type tries to keep eye on the changes and go according to fresh standards. The second one once made a system and the system still works. If we propose to use a placeholder we make the domains of clients of second-type organizations in danger (as reasonably stated in some previous letters). The 2308 error will make the second type of organization do something to fix this error. I think it is fairer towards clients. > > > > > For use case #1, what is your proposal for the value that the sponsoring registrar should provide with the create command to a non-EAI supporting server? I see the following options: > > > > • ASCII placeholder value – The current proposal is the use of e...@empty.as112.arpa. The assumption is that using a placeholder value is not the preferred option based on your feedback on use case 2. > > • Collect ASCII value from registrant – This is counter to the goal of supporting EAI, so it would only be done to pass a compliant value to a non-EAI supporting server. > > • Use proxy ASCII value – The EAI registrar would need to be able to support EAI registrants and mix for EAI-supporting registries by providing a ASCII proxy value to a non-EAI-supporting registry. The proxy value to use would be up to registrar policy. > > • A mix of the above options. > > > > Are there other options to consider? Do you have a preference for the options? > > > > Thanks, > > > > -- > > > > 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-web.cisco.com/1PHuclgRnODnxi08jze4h0Fc6ZDfqcf71AxEZJQwD1h-ADa8Fui9DXZeDCapk7W9UO0YsaVHOEocbt0xlvpEzcy1bIaZjrRhsxv5m-uTvMv3KJQ9bccE2avzNV2nquwEiLrhqo5pEYQhFrbHPzdgYW-SPkeWrW0oNO0KiRIQOAlC8-m-aEpz-TxsSK3N8bJRP0JgeZQzX4mt2xsoB6vMATbG5H_DN3unVvgoFh4FdvhnxPtowM_YcsNCcCjnsBDgp/http%3A%2F%2Fverisigninc.com%2F> > > > > On 8/2/21, 11:42 AM, "regext on behalf of Thomas Corte (TANGO support)" <regext-boun...@ietf.org on behalf of thomas.co...@knipp.de> wrote: > > > > Hello, > > > > On 8/2/21 15:50, Gould, James wrote: > > > > > 2. EPP Contact <info> Response > > > (https://secure-web.cisco.com/1FgtS7m-xW-ZevXhWmnVO4Srd-o3ZnXlxd56BLZKCbdGU5qI0hxTWtvLd4sUE43gHtwFpwFZGUHjTdiQysEwr5nt_BCtNz9doKwi9fntdIrIA-c0BaLLhweuIYp6sCPoQsk7eOpDme8ANbDJf1TEXNsr91wlDi4uSjIj_yXdgrWgnC9PwEyVsz7W5uXKw5DmWUwHTTvBRoHg2eGd1PcDa5yzzl7BOcS0X1u0jhWnlWSi2BOhu08sa4CvC82wkjwqz/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5733%23section-3.1.2 > > > <https://secure-web.cisco.com/1FgtS7m-xW-ZevXhWmnVO4Srd-o3ZnXlxd56BLZKCbdGU5qI0hxTWtvLd4sUE43gHtwFpwFZGUHjTdiQysEwr5nt_BCtNz9doKwi9fntdIrIA-c0BaLLhweuIYp6sCPoQsk7eOpDme8ANbDJf1TEXNsr91wlDi4uSjIj_yXdgrWgnC9PwEyVsz7W5uXKw5DmWUwHTTvBRoHg2eGd1PcDa5yzzl7BOcS0X1u0jhWnlWSi2BOhu08sa4CvC82wkjwqz/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5733%23section-3.1.2>) - The > > > <contact:email> element is required, which poses an issue when the > > > registry supports EAI and the querying registrar does not support > > > EAI. The querying registrar could be any registrar and not just the > > > sponsoring registrar, where there is only a single email value in the > > > registry that is an EAI address for this use case. What should the > > > registry return to the non-EAI supporting registrar? This case is > > > even more challenging then case #1 since registry has a single value > > > and there can be a mix of EAI supporting querying registrars. One > > > alternative is to return an error response (e.g., 2308 “data > > > management policy violation”) instead of a successful response with a > > > predefined placeholder value, but that seems harsh to me. > > > > It does seem harsh, but it's (in my opinion) the better option than to > > return a syntactically valid placeholder value for the e-mail, as that > > placeholder value will - for registrars not supporting EAI - most likely > > end up being used as the "real" e-mail address for the contact, causing > > problems down the line, for example when the registrar tries to send > > verification e-mails to the contact for ICANN WAP compliance. These mails > > will bounce, which very often goes unnoticed, and domains may be > > suspended as a result. In this scenario, it's better to "fail fast", i.e. > > let the inquiry of the contact's data fail with the 2308 error, which > > will immediately point the registrar to a systemic problem that needs to > > be addressed. > > > > Best regards, > > > > Thomas > > > > -- > > TANGO REGISTRY SERVICES® is a product of: > > Knipp Medien und Kommunikation GmbH > > Technologiepark Phone: +49 231 9703-222 > > Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 > > D-44227 Dortmund E-Mail: supp...@tango-rs.com > > Germany > > > > _______________________________________________ > > regext mailing list > > regext@ietf.org > > https://secure-web.cisco.com/1KZbdbAPsaLa4OVdLtJihtpwdRk9fr_3G8g2mwx2jxOLL1sJ-eNhJwsOpo6W7ol32J_DzfjBAXa_Cw90o-bJSF0gBmXB6ESXuldajgmC3M50OyC92n_wRtUNo_XZxV-q617Ou591BoL72Nkten6pxWXT59Gx3wDODJPp1wp7OaV-Z6cj2rlRN7NM8UF2_IkjVUpxBNnG1Yxn7iIr2ZZbbgcQT_95-2rVq6WMVlGKV4PAAoyx95sLzddSZb6G18znD/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > _______________________________________________ > > regext mailing list > > regext@ietf.org > > https://secure-web.cisco.com/1-wLqPO0ixnhSnv1bDHgAd4KDuL9XlUf2kLemKcLN1uOGg1Zcxdue7KVINRgsoiqMJLodH1xVHDovABPgsnQ2NWGWNDNEsTE4mEjmJ_1cidAJDGry0Cu-9UTKV6iJSwYj_etvg8wVYXmOFarHFW_9Jk-5Mj47BW0F4-cRfAoaszOvMAC2uMGkyBZ1C6wucOpCAtWYUtdifA9J40SBzM0JxIcF1OA1HvrVSbCnC_UAE6s_bMEBfz_5KWstPbEVOroi/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > -- > Taras Heichenko > ta...@academ.kiev.ua > > > > > > _______________________________________________ > regext mailing list > regext@ietf.org > https://secure-web.cisco.com/1ZLroGD5rLvS_7JbtpLLl1m_Zl3YBt7rskEI7_7UoW-3Yx6zn12XE1rNRYd4qtONsCDr0dcskptt48GGZMVuXs1yc3qdG1RiAGN2rT1g8jt2bwDWEwE9gCXBZoloEX7xvXy_uQjbi3625X2QnVqfiuW8VwK542JPW5YCs0mNx6sMFF5u6tspyM75YcJaco9Zts2ntKUEQnUdqFQgjP9ipXhG-RSawD29XQgNzOkvF1JQJHqIeXbXC09GmVdJKnFr8AkcMDcHapjc65wpvI85wlw/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext -- Taras Heichenko ta...@academ.kiev.ua _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
