Just to round things up ;-) We had talked to the registries about our proposals from the beginning. It quickly became clear that they would never implement anything that was not RFC. Which is why we had to make these submissions at all. It would be a real feat to say now that these are still drafts that are not being implemented and, on the other hand, to reject standardization.
Anyway, we will see. Just drop a note if we should pursue another way - I am okay with that, too. Cheers, Tobias > On 3. Jan 2019, at 11:39, Alexander Mayrhofer <alexander.mayrho...@nic.at> > wrote: > > Hello Tobias, > > trying to settle that with a few last words: > >> I think we're more or less on the same page. > > [AM] Good to hear. I do agree that we have the same goal, only our paths > differ :) > >> Just so we don't misunderstand each other: It's not that we or I don't >> appreciate the work on policies or even want to deliberately avoid them. > > [AM] I'm with you that some things (such as file formats) are not (much) > related to policy, and can be agreed on the "more practical" layers. > >> However, they essentially refer to framework conditions only and not to >> explicit technical implementations. Btw. I don’t think it would be a great >> idea >> to create ICANN policies on how things have to be technical implemented in >> every detail. But you never know what's to come. > > [AM] I do definitely agree. Policies should cover the high level > requirements. Implementations are a different story, and happen on a > different "layer". > >> Of course, as a registrar you could also take the view that you are king as a >> customer. However, it is far from my intention to make demands based on a >> possible market position. That's not a good style. This is why the way via >> standardisation should be in the common interest, especially since all >> parties >> can participate in it. > > [AM] As i said, i do believe that if something is good, it will succeed > naturally. Technical specifications can, of course, never overcome market > considerations or practical considerations (such as available resources, or > cost vs. effort considerations). No matter if they're an RFC or any other > kind of specification. But that goes beyond the discussion on here. > >> Be that as it may, I think we could live without IETF standardization, but >> conversely it would not be fair if this were interpreted against us and an >> implementation will only rejected by registries because our proposals are not >> RFC’s. Funny enough that some registries are working with us on these drafts >> and are not implementing them yet due to the non-standardization. > > [AM] Maybe that's because now that's an internet draft (rather than an > specification from somewhere else) the following text from RFC2026, page 7 > applies? > > ******************************************************** > * * > * Under no circumstances should an Internet-Draft * > * be referenced by any paper, report, or Request- * > * for-Proposal, nor should a vendor claim compliance * > * with an Internet-Draft. * > * * > ******************************************************** > >> For me, this is a bit like a vicious circle. > > [AM] Aiming at an RFC does not replace buy-in by the involved parties, i > think that's what it boils down to... > > Best, > Alex > > _______________________________________________ > 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
