This call for adoption has ended with no objections. The chairs therefor accepted this document as a Working Group Document.
For the WG: We still need a volunteer for this document to be the document shepherd. This is an excellent opportunity to get to know the IETF processes for new working group members, so please volunteer! No real technical insight about this draft is needed to volunteer, so don’t be shy. The only thing that you will need to do is to verify that all comments during WGLC and IESG review are attended to once the document reaches that state, and fill in a template about that process. This and all other things the chairs will help you with, but we need an independent document shepherd to state that the correct process was followed. For the authors: Please resubmit the latest version of your draft with the following name: draft-ietf-regext-unhandled-namespaces We have pre-approved the publication of this draft as a WG document. Regards, Jim and Antoin > Op 7 feb. 2020, om 15:59 heeft James Galvin <gal...@elistx.com> het volgende > geschreven: > > With chair hat on: > > As the CALL FOR ADOPTION comes to a close, the chairs want to thank you for > your comments and let you know we’re leaning towards interpreting your > message as a no objection. > > Would you like to clarify your position? > > Thanks, > > Antoin and Jim > > > > On 28 Jan 2020, at 2:10, Patrick Mevzek 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). >> >> 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. >> >> -- >> 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
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
