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 <t...@cs.fau.de> 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/>
--
---
t...@cs.fau.de
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
