Re: [fdt] Proposed charter text & meeting

[Stephen McQuistin <[e-mail]>]

Hi,

> On 28 Aug 2020, at 15:19, Carsten Bormann <[e-mail]> wrote:
> 
> On 2020-08-28, at 15:37, Stephen McQuistin <[e-mail]> wrote:
>> 
>> The meeting is to discuss the next steps for proposing an FDT group, and specifically, this draft charter text:
>> 	https://hackmd.io/@fdt/S1wTyI-fv
> 
> I expect we will be live-editing that at the meeting?

Yes — I think that’s a good plan.

> I made one minor change, but I wasn’t sure how to mark this as my proposed change (I used italics and a [cabo] mark).
> If you like that change, maybe you can “accept” it.

Done.

> Not that it is necessary to do that now, but moving to codimd.ietf.org would have the advantage that you can see who added some text.
> (Properly integrating codimd with git or github is still an unsolved problem AFAIK.)

I wasn’t aware of codimd.ietf.org <http://codimd.ietf.org/>, but I’ll take a look, and perhaps migrate before the meeting.

> Re agenda: I think we could keep the side meeting focused on the administrative part, and (assuming we can pull it off) schedule an actual PRG meeting soon for the actual technical presentations and discussions.

This makes sense: if we can agree the broad objectives/goals and organisation in this meeting, it would be easier to then schedule a meeting that fits around that.

> We could also discuss setting up a (possibly wiki-like) structure where we could collect pointers to relevant work and maybe get some taxonomy work started so we have a way to group those pointers into meaningful clusters.

Also a good idea: not sure where this could be hosted, but grouping this together would be good.

> (One think I’d like to understand in the long run is how we will build entire specifications that make use of one or more FDT techniques, in the sense of literate programming — literate specification :-)  Making the specification techniques directly applicable to this like Augmented Packet Header Diagrams is certainly one way, but it also would be good to have a standard way to author specs with in-line ABNF or CDDL and have both readable text and processable specification at the end.  Add references between specifications in various stages of evolution to this if you think that alone is too easy.)

Perhaps an xml2rfc element for processable specifications, that would be processed by the tooling to produce the text? Many problems follow from that of course..

Stephen