On Mon, Oct 29, 2018, at 21:21, Andrew Newton wrote:
> Perhaps priority should be given to those I-Ds with running code.
This is one of the point I mage in my July message:
https://mailarchive.ietf.org/arch/msg/regext/DuitffLvC4Q5RR32AnN1yDEUEYg
Running code is useful/needed but maybe too high a barrier for an I-D to become
a working group document. It can happen during its life I guess, but more
important for me would be to have at least 2 completely separate *registries*
implementation, which then could be a good idea of something that was in my
July message.
In short, not all extensions may become used by more than one registry. As sad
as it may be for registrars (if the extension solves a generic issue that
happens elsewhere or could benefit elsewhere), it is the state we are in.
However in that, how much of working group energy should be devoted to that,
and is the Proposed Standard path really necessary?
Maybe just an addition of the extension in the EPP Extension Registry should be
enough?
There are a lot of extensions out there and discussed, and very few recorded in
the extension registry. Basically only 3 registries took the effort to add
their extensions there.
And as said, sometimes an extension really tailored to one use case and one
registry will need a lot of work to be more generic, and various feedback about
needs of proper specification and taking care of interoperability might not be
so much welcome in fact.
So in summary I could say that I am not in favour of hardcoding any specific
number of IDs to work on, but I would advise that 1) not all extensions need to
become an RFC, being a proper ID with correct structure and registration in the
extension registry is already a very good step and 2) for those wanting to be
an RFC and before that wishing for the working group to work on, then they
should really make sure to both display that the need spans multiple
registries/registrars and that the document is really open to be updated to
take into account more generic cases as needed as well as various
implementation enhancements that are often only discovered when implementations
are done.
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
