Thanks for the Charter question Andy. As you know, to date the phrase “registration extensions” and the final three bullets in our Charter have been interpreted broadly by Working Group members and our various Area Directors over the years.
Nonetheless, it’s always appropriate to examine scope, and the Chairs have engaged with our Area Director to consider if there’s a straightforward enhancement to our Charter that might resolve the concern. We’ll add a Charter discussion to our Administrative meeting at IETF122 for the working group to have some discussion. Thanks, Antoin and Jim On 11 Feb 2025, at 17:10, Andrew Newton (andy) wrote: > On Tue, Feb 11, 2025 at 2:49 PM Hollenbeck, Scott > <shollenb...@verisign.com> wrote: >> >> [SAH] Andy, I don't believe that the argument cuts against the current RFCs. >> RFC 5734 exists because EPP was designed to be transport-independent. If that >> wasn't the case, TCP transport would have been specified in RFC 5730. >> >> Section 2.1 of 5730 describes considerations for an EPP transport mapping. It >> exists because the design assumption was that additional transport mappings >> would be specified in the future. They're not protocol extensions per se, >> because they're not adding or changing protocol functionality. That's why >> they're not directly addressed in RFC 3735, but the ability to define new >> transport mappings is definitely a feature of EPP. > > There is no disagreement that EPP as defined by RFC 5730 can be used > over new transports. But as you said "They're not protocol extensions, > per se." They are not covered under Section 2.7 of 5730, which is > titled "Protocol Extension Framework". > >> >> Our charter could be interpreted to limit our work to extensions that would >> be >> registered in the IANA extension registry. A new transport mapping wouldn't >> be >> registered in the extension registry, so a strict interpretation of the >> charter might preclude work on these drafts. That's a topic worthy of an AD >> opinion. > > The charter references RFC 7451 which is the document that created the > IANA registry into which EPP extensions are registered. > >> >>> As there does appear to be energy in the group to work on new EPP >>> transports, would the group be willing to recharter to include the scope of >>> I-Ds >>> under discussion? >> >> [SAH] Yes, I'm willing to do that. If our charter precludes work on new >> transport mappings, that's a defect that needs to be fixed. I'm hoping, >> though, that a more liberal interpretation of the charter will recognize >> that EPP was designed to be extended by defining new transport mappings, >> and that design decision means that such mappings are in-scope. > > I think such an interpretation would blatantly ignore the THREE > explicit charter references to RFC 7451, and RFC 7451's explicit > reference to RFC 3735. > > -andy _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
