John, How about if we change the approach to use the well-understood command-response extension? -- JG James Gould Fellow Engineer jgould@xxxxxxxxxxxx <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@xxxxxxxxxxxx> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/22/22, 10:39 AM, "John C Klensin" <john-ietf@xxxxxxx> wrote: --On Monday, 22 August, 2022 12:00 +0000 "Gould, James" <jgould@xxxxxxxxxxxx> wrote: > John, > > I will address your point (5), based on the prior thread that > we had back in May > (https://secure-web.cisco.com/1FFl2HRtn03OI1uYW4OziM8X04xwiZaDpI6faRMrp_sl_k6uI813q1FID15MuTI_qCAIZCvskSJNkX6vl0E5foP5RDE2qD3XFsqzlhRu5bPMBHMAEVwrJkL4b-tuANrfjDEae41xnlGu989Mjm1TylOs0lVZf1xIX3RrHkxB7tzLKCjLNHB9ftB-gJZTALg1JVE8GL1o7ig4AmEyWQ3MpxOCAQXiAU1S0qYBA1tM4iPywnScxlQOaYrsmD2ur5oe7/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FG08akVkCjnXEPw8k > 7NiCHbeEamo/), where I stated: > > I don't agree that section 2.7 of RFC 5730 defines the only > forms of extensibility that can ever be supported by EPP and > by defining a new form of extensibility to solve a specific > problem in EPP is disallowed or non-compliant with RFC 5730. But, as I pointed out then and in my most recent note, you are arguing against a position that has never (to my knowledge) been taken. 5730 does not says "only ... ever". What it does say is "three". Making that "four" (or even reverting to the longer Informational list in RFC 3735) is a change/ update to 5730. > In this case, the form of extensibility (Functional Extension) > is formerly defined in draft-ietf-regext-epp-eai for clarity > for use in solving the specific problem of EAI in EPP. The > intent is not to define a new form of extensibility to EPP in > RFC 5730 to solve other similar problems. And, again, while I would still believe this is an update/ change to EPP, I would be somewhat less concerned about the issue if draft-ietf-regext-epp-eai explicitly explained why this extension would not ever be needed for anything else. It does not. A strong argument against doing so, as I think you pointed out, is that it is not possible to predict the future. However, at this point, that turns this extension into a possibly general-use one and brings us back to an update to 5730. > I agree if a > Functional Extension is meant to be a new formal form of > extensibility for use in other yet to be defined EPP > extensions, then it would make sense to define it in a draft > by itself, but that is not the case with > draft-ietf-regext-epp-eai. Noting that I did not mention the "separate document" issue in my recent note (although that would be my personal preference), your comment above implies that this is an informal (i.e., not-formal) form of extensibility, I have no idea what that means in a standards track document. Certainly 5730 does not define informal extensions in its section 2.7 (or, AFAICT, anywhere else). Let me see if I can explain why this apparently small issue concerns me enough to want to be sure it is identified on Last Call and considered by the IESG. So as to not be entirely about theorizing, I'm going to use a specific example of which the IESG (at least) is painfully aware. Without getting into the details, there is a proposal to create a new URI type floating around (draft name on request if that would be useful). One of its characteristics is inconsistent with most readings of RFC 3986, an Internet Standard, and there has been considerable pushback as a result. Now, suppose its author borrowed the general outline of Section 4 of draft-ietf-regext-epp-eai-15 and included a section in his specification that said that it provided a syntax extension to 3986 and then proceeded to describe that extension. Then he claimed that he specified that as an informal extension and that there was no proof that anyone would use it for anything else and hence that his URI type could be adopted in spite of what 3986 appears to say and without updating 3986. If your functional extension can really be made without updating or changing 5730, then I don't see any basis for rejecting that other proposal (rewritten that way) simply because it is inconsistent with the 3986 syntax. Now, importantly, I can see an argument for rejecting the "new informal extension" URI proposal and not draft-ietf-regext-epp-eai. It is that the URI extension would probably be disruptive to a large family of web and other applications out there which depend on the existing syntax while draft-ietf-regext-epp-eai affects only the registrar and registry communities and that all of the users of EPP have signed off on its being non-disruptive. However, I have seen no evidence that all users of EPP --presumably including ccTLDs who have chosen to use it, perhaps without consulting the REGEXT WG-- have been consulted about that, much less agreed. That, in turn, brings us, not to RFC 5730 but to RFC 7451. The latter says that a new extension requires only "Specification Required" and expert review. A different way of looking at the question is that you are trying to have it both ways: the IETF endorsement and approval that goes with making the document standards track but on the basis of agreement within a restricted community only (registries and registrars for gTLDs ?). I don't believe the experts should approve this without an update to 5730 but, if it really does not update/change 5730, then it is not clear why you need standards track (and to put up with complaints from the likes of me that, as written, it is not appropriate for that status). thanks, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
