Patrick, Thank you for your viewpoint on this. I agree with you in theory but I disagree with you in practice. The EPP RFCs that exist today don't include any form of epp scoping, so the inflight extensions are simply following that pattern. The request from IANA to scope the namespaces, that was first raised with draft-ietf-regext-launchphase, should be and is being incorporated. Examples include draft-ietf-regext-org, draft-ietf-regext-orgext, draft-ietf-regext-epp-fees, draft-ietf-regext-allocation-token, draft-ietf-regext-bundling-registration, and the new extensions, that now include the epp namespace scoping. We do need to be careful to also consider the impact of making a change against following a new scheme. In the case of draft-ietf-regext-launchphase that became RFC 8334, draft-ietf-regext-change-poll, and in the future draft-ietf-regext-verificationcode, the operational impact was and is too high in making the namespace change. I believe that there needs to be a compelling reason to make the change, such as an IANA namespace conflict, to justify making the namespace change on extensions that will have operational impact. I understand the method for supporting namespace changes on the client-side and the server-side, but the production and interoperability impacts need to be considered when incorporating a new scheme. — JG
James Gould Distinguished Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/6/18, 12:17 PM, "regext on behalf of Patrick Mevzek" <[email protected] on behalf of [email protected]> wrote: On Mon, Nov 5, 2018, at 06:29, Gould, James wrote: > Yes, there are Production systems in place that use this namespace. > Scoping the namespace at this stage would cause Production > interoperability issues. Let me know if you need any additional > information. I completely disagree with this reasoning, irrespective of the specific document as I would say the same thing for the same case. This is only a draft, implementations are bound to change. As a developer myself, I implemented a lot of drafts in their early versions, for "free" and it would have been the same thing for "just" namespaces changes. So I can totally understand the difficulty to change things at the last time, but then it is the game to play if we want global standards, their limits and edge cases appear when they are really implemented (hence the Implementation Status section in documents), and hence implementations are bound to need updates when the standard "matures" and gets input from other parties. Current deployments should not forbid making the document better and hence creating at the end a better standard for everyone. If we do otherwise we just re-inforce something that I am seeing more and more which is converting this working group as a pure rubberstamping "authority" were documents come already finished or close to finished or not really open to changes because it won't suit the original author. It would be then too easy for anyone to come and then just refuse changes because it is already deployed as is. Also, it was always sold that the greeting+login exchange enables client and server to autonegiotate extensions, including those that change the namespace (like the fee one with many different namespaces - even if just different on the version part - and many registries today exposing more than one). Now what I can agree on is why setting the line at this document instead of any other one? As soon as we have identified a problem regarding the namespaces used, I think all documents not yet being an RFC should be modified to adhere to the new convention. I see no sensible reason to say to do it for some but not others. So my opinion is to change the namespace everywhere and not let any new extenson become an RFC without this change. -- Patrick Mevzek [email protected] _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
