Subject: Re: [OPSAWG] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Sep 2020 14:26:48 -0400

[email-masked] wrote:
    > Diff:
    > https://www.ietf.org/rfcdiff?url2=draft-tuexen-opsawg-pcapng-02

Hi, I have converted the xml to markdown.

The results in the diff are okay, but actually the conversion is not complete
as I cheated and left the tables as preformatted figures, and there are many
internal references that I have no yet updated.

The xml file had a long list of URLs as references, many of which were
duplicated.  I will be going through and fixing those in the next week or so.

This work has been discussed on and off in OPSAWG, but at this point I am
going to suggest that the document just go through the Independant Submission
Editor.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 28 Sep 2020 21:06:10 +0200

> On 28. Sep 2020, at 20:26, Michael Richardson <[email-masked]> wrote:
> 
> 
Why? If we want to publish this, it will be published in xmlv3. So
better to use that format earlier...
> going to suggest that the document just go through the Independant Submission
Do we want to finally publish that? Up to now, I think the point was to
find a home where it is substantially discussed and improved...

Best regards
Michael

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Sep 2020 16:30:35 -0400

Michael Tuexen <[email-masked]> wrote:
    >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-tuexen-opsawg-pcapng-02
    >>

    > better to use that format earlier...

It's so so so much easier to maintain and update and get contributions.
github will render it directly....

If you object strongly, we can stick to XML.

    >> The results in the diff are okay, but actually the conversion is not
    >> complete as I cheated and left the tables as preformatted figures, and
    >> there are many internal references that I have no yet updated.
    >>
    >> This work has been discussed on and off in OPSAWG, but at this point I
    >> am going to suggest that the document just go through the Independant
    >> Submission Editor.

    > find a home where it is substantially discussed and improved...

If we can get OPSAWG to adopt it, great.
I'm just not holding my breath.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 28 Sep 2020 22:42:22 +0200

Without OPSWG...
> On 28. Sep 2020, at 22:23, Guy Harris via tcpdump-workers <[email-masked]> wrote:
> 
> 
> From: Guy Harris <[email-masked]>
> Subject: Re: New Version Notification for draft-tuexen-opsawg-pcapng-02.txt
> Date: 28. September 2020 at 22:23:33 CEST
> To: Michael Tuexen <[email-masked]>
> Cc: Michael Richardson <[email-masked]>, [email-masked], [email-masked], Jasper Bongertz <[email-masked]>, [email-masked], Fulvio Risso <[email-masked]>, Gerald Combs <[email-masked]>
> 
> 
> On Sep 28, 2020, at 12:06 PM, Michael Tuexen <[email-masked]> wrote:
> 
> For example, unlike pcap, which is not easily changeable (you *can* change it, but that involves adding new magic numbers), pcapng can have new block types and option types.
> 
> There are extensible protocols with RFCs; that's handled with protocol registries:
> 
> 	https://www.iana.org/protocols
> 
> and with new I-Ds -> RFCs for extensions.  We'd have to set up registries for block and option types if we publish an RFC for pcapng.  We would *also* want a registry for link-layer header types, for both pcap and pcapng.
> 
> See, for example, RFC 1761
> 
> 	https://tools.ietf.org/html/rfc1761
> 
> which specifies the Sun snoop file format, and RFC 3827:
> 
> 	https://tools.ietf.org/html/rfc3827
> 
> which sets up a registry for snoop link-layer header types:
> 
> 	https://www.iana.org/assignments/snoop-datalink-types/snoop-datalink-types.xhtml#snoop-datalink-types-2
> 
> and adds some new entries to it.
So we can make use of IANA. Shouldn't we write up (I can work on an initial version) of
a specification for .pcap. Would you volunteer as a co-author?
Establish there the link layer header type IANA registry?

We can reuse that for the .pcapng spec...

Best regards
Michael
> 
> _______________________________________________
> tcpdump-workers mailing list
> [email-masked]
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Sep 2020 19:28:45 -0400

Guy Harris <[email-masked]> wrote:
    > For 2), I note that

    > 	https://github.com/pcapng/pcapng/blob/master/draft-tuexen-opsawg-pcapng.md

    > has a bunch of stuff that GitHub isn't treating as markup, such as the
    > stuff prior to the "Introduction" heading, and the tags such as
    > "{::boilerplate bcp14}".  Is that an extension of Markdown not
    > supported by GitHub's Markdown renderer but supported by some
    > Markdown-to-RFC XML converter

Yes, kramdown-rfc2629.  The MT Makefile does all the magic.

    > In addition, the XML version at

    > 	https://github.com/pcapng/pcapng/blob/master/reference-draft-tuexen-opsawg-pcapng.xml

    > has some additional Decryption Secrets Block secret formats.  Those
    > have data formats that *themselves* call for figures, and I'd been
    > trying, at one point, to determine how to do that in RFC XML v2 format
    > - it might require v3 format.  Can that be handled with Markdown?

I left that as reference since I knew that I hadn't gotten all the content right.
Right now, kramdown-rfc2629 generates v2 format, but it will move forward soon.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Sep 2020 01:43:49 +0200

(Trimming CC, I hope not too much.)

> On 2020-09-28, at 20:26, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

Send me the XML and I can give you markdown (including tables).

Grüße, Carsten

---

From: Guy Harris <[email-masked]>
Date: Mon, 28 Sep 2020 13:41:51 -0700

> better to use that format earlier...

There are tools to convert Markdown to v2 or v3 RFC XML:

	https://www.rfc-editor.org/pubprocess/tools/

so:

	1) is it easier to edit Markdown or RFC XML?

	2) is Markdown rich enough to do everything we want to do?

For 2), I note that

has a bunch of stuff that GitHub isn't treating as markup, such as the stuff prior to the "Introduction" heading, and the tags such as "{::boilerplate bcp14}".  Is that an extension of Markdown not supported by GitHub's Markdown renderer but supported by some Markdown-to-RFC XML converter, or incomplete parts of the RFC XML to Markdown conversion?

has some additional Decryption Secrets Block secret formats.  Those have data formats that *themselves* call for figures, and I'd been trying, at one point, to determine how to do that in RFC XML v2 format - it might require v3 format.  Can that be handled with Markdown?

---

From: Guy Harris <[email-masked]>
Date: Mon, 28 Sep 2020 13:48:32 -0700

On Sep 28, 2020, at 1:42 PM, Michael Tuexen <[email-masked]> wrote:

> Shouldn't we write up (I can work on an initial version) of
> a specification for .pcap.

	https://github.com/pcapng/pcapng/blob/master/draft-gharris-opsawg-pcap.xml

	http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/pcapng/pcapng/master/draft-gharris-opsawg-pcap.xml&modeAsFormat=html/ascii&type=ascii

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Sep 2020 14:54:10 +0200

(Keeping CC list, so I’ll probably reach people and not lists.)

> On 2020-09-28, at 22:41, Guy Harris <[email-masked]> wrote:
> 

This is a list of very, very different tools.  Some of these are useful for a “conversion” (as a one-time effort), some are meant to be used in a publishing pipeline where people rarely see the “object file” that happens to be in XML (e.g., mmark and kramdown-rfc).

> 	1) is it easier to edit Markdown or RFC XML?

I wrote kramdown-rfc a decade ago when I had two days to write six drafts.

I gambled that spending one day on the tool and one day on writing markdown would be quicker than spending two days on writing XML.  

I won.

This was meant as a personal tool to get work done (and, boy, did it speed up my work), but it has found some other users; approximately 20 % of all Internet-Drafts are currently being written in kramdown-rfc (approximately 2 % use mmark).

> 	2) is Markdown rich enough to do everything we want to do?

No.  So there are some additions.

> has a bunch of stuff that GitHub isn't treating as markup, such as the stuff prior to the "Introduction" heading, and the tags such as "{::boilerplate bcp14}".  Is that an extension of Markdown not supported by GitHub's Markdown renderer but supported by some Markdown-to-RFC XML converter,

Yes.

(I have since sent Michael an automatically upconverted markdown version of the XML, BTW.)

> has some additional Decryption Secrets Block secret formats.  Those have data formats that *themselves* call for figures, and I'd been trying, at one point, to determine how to do that in RFC XML v…

You can always fall back to XML inside the markdown, but that is rarely needed.

As an example for a slightly automated form of writing, RFC 7400 was written in markdown, with a significant part of the text generated automatically from a Makefile; this text is then included using the {::include …} construct of kramdown-rfc.

Some resources:
http://rfc.space
http://slides.rfc.space
https://www.ietf.org/mailman/listinfo/rfc-markdown

Grüße, Carsten