I don't view the need for the concrete report formats to be defined as standards track RFCs, but instead define an IANA registry for the report formats (e.g., common and optionally proprietary) based on a set of underlying RFCs (format and report interfaces(s)). This is similar to what has been done with the EPP Extensions registry.
I'm looking to make the Data Set File Format draft (draft-gould-regext-dataset) more generic to support the definition of an extensible set of CSV files, including initially bulk operations (current format supported) and reports. The goal for reports is to have a separate definition file (.dsf file based on draft-gould-regext-dataset) per CSV report that provides the meta-data about the report (type, sub-type, date or date-range, duration, data scope, client / registrar, etc.), the report file name, report file checksum, and a formal definition of the fields and separator(s). In this case, we leave the meta-data out of the file names, we can support the definition of the existing reports, and define an IANA registry for the registration of the report formats (common and proprietary). A report consumer can look for all .dsf files for processing and leverage the meta-data and the format definition in the .dsf files to automate the consumption of the reports. With the large number and variety of registrar reports, I believe the best strategy is to come up with an approach that helps define what exists today, that can be leveraged for consumption automation, and that supports a lighter-weight mechanism for defining and registering the reports formats (common and optionally proprietary). — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/3/19, 6:01 AM, "regext on behalf of Tobias Sattler" <regext-boun...@ietf.org on behalf of satt...@united-domains.de> wrote: 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
