Toerless, I understand the benefits of formal definitions and tools reasonably well but assuming that everybody judges the benefits in the same way in every context is in my experience wishful thinking. (Look which problem ASN.1 tried to solve in the 1980s and how many data formats did come and go since then.)
A standard, that is "better" than other solutions and at the end not implemented by key players, is a waste of time and energy. On the other hand, standardizing a format that is backed by existing deployed implementations in order to increase interoperability has a lot of practical value. I think we should welcome people that bring proposals backed by real-world and deployed implementations to the IETF. Standardizing pcapng has a clear value for me and I strongly support the effort. And I think we should trust that those who worked out the pcapng format and implemented it did take proper engineering decisions. It is fine to ask questions like 'did you consider X?' but it feels entirely wrong to tell them 'you should be doing X'. /js On Wed, Nov 11, 2020 at 09:49:59AM +0100, Toerless Eckert wrote: > I am sorry, but i don't think human parsing of ASCII diagrams to write code > for a protocol is appropriate for new designs anymore unless there are good > reasons. What are the good reasons ? > > Is this another case of ready developed code and the ask is "IETF bless it's > spec" ? Do we even know using any of the options (like CBOR) we have wouldnt > work ? > Not even having the discussion seems weird. I for once can't support this > work without having answers to those questions. Ideally written down in > the draft. > > We didn't invest all this effort into formal languages and standardized > encoding rules like CBOR to simply have them be ignored. And we're not asking > for considering their use because "that's what we do", but because of the > benefits > they bring to users and implementers: consistent cross-platform > implementation, > ability to drive code from spec and make exensibilities easier (and i > am sure i am forgetting other benefits). > > > Cheers > Toerless > > On Wed, Nov 11, 2020 at 09:08:17AM +0100, Juergen Schoenwaelder wrote: > > On Wed, Nov 11, 2020 at 03:22:18AM +0100, Toerless Eckert wrote: > > > On Wed, Nov 11, 2020 at 02:12:46AM +0100, Carsten Bormann wrote: > > > > On 2020-11-10, at 22:23, Toerless Eckert <[email protected]> wrote: > > > > > > > > > > Why is the document not using a formal language to define the > > > > > syntax/semantic of its formatting ? Would CBOR/CDDL not be a > > > > > good candidate ? Any other ? > > > > > > > > Well, changing the format to be more regular (e.g., CBOR) is not what > > > > we want. > > > > > > Why not ? Its a new format, its meant to be easily extensible, verifyable, > > > etc. pp .. > > > > > > > Getting a better description might indeed be useful, but in the end > > > > that would have to describe all the warts of the current format, which > > > > is probably more than CDDL can do today (I haven???t checked, though). > > > > > > It seemed this doc was an ask for a new format. I agree that we > > > may not bother about better formal description of an old format. > > > > > > > It might be that they want the format they have written down and not > > CBOR or any other format out there. My experience with telling people > > they should use a "better" format, which is not the format they like > > to use in the first place, is that this leads to specs that are at the > > end not implemented and used. It is surely OK to point developers to > > possible alternatives so that they can take an informed decision but > > if developers then conclude that they prefer to use an ad-hoc format, > > it may be wise to accept this decision. The value of having an > > interoperable format is often higher than the value of making this > > format a well-known format (and taking the risk that at the end there > > is no interoperable format). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > -- > --- > [email protected] > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
