Hi Alex, I think we're more or less on the same page.
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. 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. 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. 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. For me, this is a bit like a vicious circle. My two cents Best, Tobias > On 3. Jan 2019, at 10:49, Alexander Mayrhofer <alexander.mayrho...@nic.at> > wrote: > > Tobias, > > Thanks for coming back to my "rant". A few observations inline: > >> However, nowadays most domain registries have withdrawn to the point of >> implementing only their own ideas or approved RFCs. This inevitably leads to >> the situation that proposals for improvement - whoever they come from - >> either have to be solved via approved RFCs, in lengthy bilateral talks / >> negotiations or through policy development. > > [AM] You're unwittingly strengthening my arguments here. You're saying "we > don't bother about what Standards Track implies. We just need that RFC number > so that we can force the industry into doing what we want". Not because of > the higher quality reviews involved in IETF work, the well established and > accepted process to progress an Internet Standard, etc. It's just to "gold > plate" a spec with a "label" that tricks people into believing it's actually > important. > > And secondly, you're actually saying "we're doing this so that we can evade > the policy development and discussions around it". Wow. > >> The goal of the ICANN CPH TechOps Group was and is to address technical >> and operational challenges and as there seems to be no other way we >> decided to go for the standardized way. If the REGEXT Group thinks that an >> individual submission with the status informational is sufficient and this is >> fully supported by the domain registries, then I see no problem doing it this >> way and we can save time and effort here. > > [AM] I don't know what the group thinks, i'm speaking as an individual here, > obviously. Escrow has been implemented widely, and never made it beyond an > individual draft. So, it's possible without an RFC number. Yes, there was > some force involved into that, obviously, but - on the contrary > >> Just let me know how you want to do it. > > [AM] First, I'm not disregarding your (or someone else's) work. I have > written enough specifications to understand the amount of work that goes into > those documents. Ironing out the details once the first implementation is > done, fixing contradictions with other specifications, ironing out late > corner cases.. Tons of very very useful work. > > [AM] Practically, CPH techops could perfectly publish all those file format > specifications as their own documents (CPHT-001... CPHT-002... etc..). If > they are good and beneficial for both registrars and registries, > implementation will follow. I'm the last one to oppose standardization in > that area - quite the contrary, I can think of (and I'm working on) > standardization of more items (Registry Registrar Data Group, Registry Data > Nerds, etc...) - but I wouldn't think of submitting the work there to the > IETF. That's my only point. > > 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
