Patrick, My feedback to your comments are included below.
-- JG James Gould Distinguished 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 1/28/20, 2:11 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Fri, Jan 24, 2020, at 09:50, Antoin Verschuren wrote: > This is a formal adoption request for Extensible Provisioning Protocol > (EPP) Unhandled Namespaces: > https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/ > > Please review this draft to see if you think it is suitable for > adoption by REGEXT, and comment to the list, clearly stating your view. The subject can be interesting to the working group and might warrant an RFC (although registries and registrars worked for 20 years without trouble in handling this case, so one might imagine it is maybe too late or not a big enough problem). JG - This topic came up with the introduction of a new poll message with the Change Poll Message in https://tools.ietf.org/html/rfc8590. It's primarily an issue associated with the poll queue, where it's unclear how the server can introduce a new poll message without breaking the protocol. I don't believe anyone can make the case that this is not a protocol issue. The practice outlined in draft-gould-casanova-regext-unhandled-namespaces provides a concrete solution. However, as discussed previously, in its current form this draft will introduce interoperability problems[1], so this just exchanges one problem with another. So I am mildly convinced work is required, and mildly unconvinced that the draft as it stands completely address the issue. [1] TL;DR: a registrar has no way to automatically discover a registry is using the mechanism outlined in this document, as not announced in the greeting part. JG - draft-gould-casanova-regext-unhandled-namespaces addresses a protocol and subsequently an interoperability issue, since the server will be capable of fully honoring the services the client includes in the login command. I'm not sure how a practice that fully follows the EPP RFCs and fully honors the client login services will introduce an interoperability problem based on the lack of discoverability of the practice in the greeting. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
