Subject: [Tools-discuss] Results and analysis of the survey of I-D authors on formats and tools

From: IETF Executive Director <[email-masked]>
Date: Wed, 03 Feb 2021 19:32:42 -0800

In October-November 2020 the IETF Administration LLC ran a survey of I-D authors on the formats and tools that they use.  This survey was issued to a total of 6037 email addresses, with that list built from the addresses of everyone who submitted an I-D, or was listed as an author, in the five years previous.  718 responses were received, giving a margin of error of +/- 3.43%. We wish to thank all of you that took the time to reply to this survey.

The results of this survey are now available as a basic web report:

	https://ql.tc/T0WvDV

Additionally, the IETF Executive Director and Temporary RFC Series Project Manager have produced a detailed report of analysis and recommendations:

	https://www.ietf.org/media/documents/REPORT__Survey_of_I-D_Authors_on_Formats_and_Tools.pdf

I recommend that any discussion on this subject takes place on either [email-masked] or [email-masked] as appropriate.

Please feel free to contact me directly if you have any questions.

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 4 Feb 2021 10:01:42 -0500

Jay and John,

Thanks for this survey and report.

I would like to start a conversation/consensus call on Recommendation 9:

> Recommendation 9: A significant minority want to use Markdown or similar
and a strategic decision is needed on whether or not this should be
“officially” supported either in some stages or in the full end-to-end
authoring process. (see also Q20)

I'm a part of that minority. I love Kramdown and use it a lot, and would
love to see:

1. "Official support" for the Kramdown toolset rather than just appearing
on the experimental tools page.

2. For idnits to support Kramdown source, so you don't have to do a
conversion in order to perform idnits checking. I know that I could script
this, and perhaps will when I start my next draft ... :-), but native
support would be better.

3. Being able to use Kramdown as a draft submission format, rather than
converting to XML and/or plaintext for submission.

I'd be happy with 1, but even happier with 2 and/or 3 as well.

Thanks again,
Andy

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Feb 2021 16:44:02 +0100

> 
> 1. "Official support" for the Kramdown toolset rather than just appearing on the experimental tools page.
> 
> 2. For idnits to support Kramdown source, so you don't have to do a conversion in order to perform idnits checking. I know that I could script this, and perhaps will when I start my next draft ... :-), but native support would be better.
> 
> 3. Being able to use Kramdown as a draft submission format, rather than converting to XML and/or plaintext for submission.
> 

I’m a bit ambiguous about “official support”.  
This is a bit like the transition from an individual draft to a working group draft…

Today, at 10:24 CET, Martin Thomson filed an issue, and he provided a fix at 10:27.
At 11:04, version 1.3.26 with that fix was pushed to rubygems.org so people can `gem update` to that.
I’d like to keep the kramdown-rfc process lightweight enough so we can have these turnaround times.

But sure, making the tool available on the tools/datatracker web presences and via the submission tool would be helpful.

I’m not so sure about (2).  This would require idnits to do some second-guessing of what kramdown—rfc does, and would make it harder to evolve kramdown-rfc.  Why not run the authoring tool and then idnits?  Right now, there isn’t even a way to run idnits on the XML, maybe we could address that first. 
Maybe I should put a simple CLI option for running idnits into the `kdrfc` tool...
Now https://github.com/cabo/kramdown-rfc2629/issues/96

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Feb 2021 17:26:09 +0100

> Now https://github.com/cabo/kramdown-rfc2629/issues/96

1.3.27: Add -i option to kdrfc, run idnits

Grüße, Carsten

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 4 Feb 2021 14:39:12 -0500

Carsten,

Awesome, thanks!

Cheers,
Andy

---

From: Leonard Rosenthol <[email-masked]>
Date: Thu, 4 Feb 2021 21:02:01 +0000

Supporting Markdown as an input option is a good idea - but why would you support a non-standard version of it?   CommonMark (https://commonmark.org/) is the relevant "specification" for markdown.  Kramdown, on the other hand, is a specific tool that promotes its own flavor...

Leonard

    I’m not so sure about (2).  This would require idnits to do some second-guessing of what kramdown—rfc does, and would make it harder to evolve kramdown-rfc.  Why not run the authoring tool and then idnits?  Right now, there isn’t even a way to run idnits on the XML, maybe we could address that first. 
    Maybe I should put a simple CLI option for running idnits into the `kdrfc` tool...
    Now https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabo%2Fkramdown-rfc2629%2Fissues%2F96&amp;data=04%7C01%7Clrosenth%40adobe.com%7C4293cd49aa87480921fb08d8c923b894%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637480502571422936%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ZHizYml%2FsK%2FQIkc%2B0usb77P0pjnwrkBMqVKGXU%2BwweU%3D&amp;reserved=0

    Grüße, Carsten

    _______________________________________________
    rfc-interest mailing list
    [email-masked]
    https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fmailman%2Flistinfo%2Frfc-interest&amp;data=04%7C01%7Clrosenth%40adobe.com%7C4293cd49aa87480921fb08d8c923b894%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637480502571422936%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=mYAWpv%2BttqaFFCSACEwdpCC9lSDhxPN9gDm8HXYK9bg%3D&amp;reserved=0

---

From: "John Levine" <[email-masked]>
Date: 4 Feb 2021 16:28:40 -0500

In article <[email-masked]> you write:
>Supporting Markdown as an input option is a good idea - but why would you support a non-standard version of it?   CommonMark
>(https://commonmark.org/) is the relevant "specification" for markdown.  Kramdown, on the other hand, is a specific tool that promotes its own
>flavor...

People are using at least two slightly incompatible markdown tools to prepare I-D's, kramdown and mmark.

If we're going to adopt markdown, we need at least to decide what we mean by markdown.  I don't
have any strong opnions about how to get to that point.

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Feb 2021 13:31:29 -0800

On Thu, Feb 4, 2021 at 1:28 PM John Levine <[email-masked]> wrote:

> >Supporting Markdown as an input option is a good idea - but why would you
> support a non-standard version of it?   CommonMark
> >(https://commonmark.org/) is the relevant "specification" for markdown.
> Kramdown, on the other hand, is a specific tool that promotes its own
> >flavor...
>

+1

-Ekr

---

From: Jay Daley <[email-masked]>
Date: Fri, 5 Feb 2021 10:51:15 +1300

> On 5/02/2021, at 10:28 AM, John Levine <[email-masked]> wrote:
> 

I'm concerned that we might be in a position where we can only adopt markdown by extending it so far beyond common usage that we create a unique IETF markup language.  We’re probably not too far from that position already.

Jay

> 
> R's,
> John
> 
> ___________________________________________________________
> Tools-discuss mailing list - [email-masked]
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: [email-masked]
> * Report tools.ietf.org bugs to: [email-masked]
> * Report all other bugs or issues to: [email-masked]
> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Feb 2021 13:58:44 -0800

On Thu, Feb 4, 2021 at 1:51 PM Jay Daley <[email-masked]> wrote:

> I'm concerned that we might be in a position where we can only adopt
> markdown by extending it so far beyond common usage that we create a unique
> IETF markup language.  We’re probably not too far from that position
> already.
>

I've done quite a bit of writing in kramdown (for RFCs) plus a number of
other flavors of markdown. There are a few things that we would probably
need that are not in CommonMark:

- Metadata at the top
- Figure captions
- Named section references (I think)
- Special syntax for bibliography entries.

The good news is that things will mostly render correctly with standard
parsers even if you invent special syntax for these. We might also be able
to borrow from existing markdown extensions.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Feb 2021 17:19:30 -0500

On Feb 4, 2021, at 4:58 PM, Eric Rescorla <[email-masked]> wrote:
> I've done quite a bit of writing in kramdown (for RFCs) plus a number of other flavors of markdown. There are a few things that we would probably need that are not in CommonMark:
> 
> - Metadata at the top
> - Figure captions
> The good news is that things will mostly render correctly with standard parsers even if you invent special syntax for these. We might also be able to borrow from existing markdown extensions.

IIRC from looking recently, CommonMark lacks definition lists. I’m not a big fan of either CommonMark or Kramdown, but if I had to pick, I’d pick kramdown.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 4 Feb 2021 17:23:05 -0500

Leonard,

Can you use CommonMark to easily generate idnits-compatible drafts,
including ToC, references, boilerplate, and the rest? If so, is that
documented anywhere?

Unless and until that's in place, Kramdown is in place and works great. And
has awesome support!

Cheers,
Andy

On Thu, Feb 4, 2021 at 4:02 PM Leonard Rosenthol <[email-masked]> wrote:

> support a non-standard version of it?   CommonMark (
> https://commonmark.org/) is the relevant "specification" for markdown.
> On 2/4/21, 10:44 AM, "rfc-interest on behalf of Carsten Bormann" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     >
>     > 1. "Official support" for the Kramdown toolset rather than just
> appearing on the experimental tools page.
>     >
>     > 3. Being able to use Kramdown as a draft submission format, rather
> than converting to XML and/or plaintext for submission.
>     >
>     But sure, making the tool available on the tools/datatracker web
> presences and via the submission tool would be helpful.
>
>     I’m not so sure about (2).  This would require idnits to do some
> second-guessing of what kramdown—rfc does, and would make it harder to
> evolve kramdown-rfc.  Why not run the authoring tool and then idnits?
> Right now, there isn’t even a way to run idnits on the XML, maybe we could
> address that first.
>     Now
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabo%2Fkramdown-rfc2629%2Fissues%2F96&amp;data=04%7C01%7Clrosenth%40adobe.com%7C4293cd49aa87480921fb08d8c923b894%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637480502571422936%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ZHizYml%2FsK%2FQIkc%2B0usb77P0pjnwrkBMqVKGXU%2BwweU%3D&amp;reserved=0
>
>     Grüße, Carsten
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 5 Feb 2021 01:57:44 +0100

On 4. Feb 2021, at 22:02, Leonard Rosenthol <lrosenth=[email-masked]> wrote:
> 
> Supporting Markdown as an input option is a good idea - but why would you support a non-standard version of it?   CommonMark (https://commonmark.org/ <https://commonmark.org/>) is the relevant "specification" for markdown.  Kramdown, on the other hand, is a specific tool that promotes its own flavor…

Hi Leonard,

the short answer is that in 2010, when kramdown-rfc was created, commonmark wasn’t even on the horizon.

From my point of view, the most important requirement for an authoring language to be used in the IETF is that it remains stable.
Drafts often have a 3-5 year lifetime before they finally get published as an RFC.  People are working on, and text is moving back and forth between, drafts in various of these stages.
So compatibility timelines on the order of a decade or more are required.

Of course, we could decide to “upgrade” to commonmark after kramdown-rfc now has been around for a decade.
With migration aids, this could be palatable (if enough development resources are poured into those; maybe we want to use those for completing the RFXMLv3 migration instead).
But what would be the upside?

Let’s ignore for the moment that commonmark is missing tables, definition lists, anchors, attributes, and a few more things that I forget because one might take them for granted.
A move to commonmark would not be addressing the larger problem with markdown interoperability, which is that RFCXML needs more from an authoring language than markdown provides.
Few of the various features that needed to be invented for kramdown-rfc [1] are provided by commonmark.
One of the most important contributions by kramdown-rfc, painless reference management in the context of IETF documents, is situated to our usage.
I would also chalk up the input of structured data (“metadata”) using YAML as one of the successes.

The underlying kramdown library is run by a developer that shares the goal of compatibility for decades.
Only recently, a mild cleanup was made in the form of kramdown 2.x (adoption of which is still on the to-do list for kramdown-rfc because kramdown recently dropped PI support).
This of course meant that the author couldn’t wholesale adopt the changes made to markdown’s core by commonmark.
But, in reality, kramdown syntax is rather close to commonmark, outside of pathological cases (and the cases where commonmark is just missing needed functionality).

One of the less obvious sources of strength of kramdown-rfc is that it is implemented in less than 1800 lines of code.
This was possible because the kramdown library (an about an order of magnitude larger effort) is doing the heavy lifting.
(The first version of kramdown-rfc was done in less than a day.)
This means kramdown-rfc can be a community project, without the need for support staff.
This is something we might want to change at some point, but not without a really good reason.

Grüße, Carsten

[1]: https://github.com/cabo/kramdown-rfc2629/wiki/Syntax

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 05 Feb 2021 22:03:30 +1100

> > have any strong opnions about how to get to that point.

I think that it depends on what "support" means.  If it means providing support for conversion and upload (and nits and whatever other processes we might choose to support), that's relatively easy.  That can be done with minimal official backing for both formats, not just one (drop .txt at the same time).  I support both mmark and kramdown variants; it costs ~5 lines of code that I last touched years ago.  And both get enough use to justify that code.  They are trivially distinguishable and both formats reduce to XML nicely, for which we can build common tooling.

The support Carsten and Miek provide is excellent, so unless we are forced to choose, I'd say that we don't have to.  If that support were to end and there was a need for the IETF to step in, then we might want to consider resourcing only one of the two, but I'm OK with two until we're forced to choose.

One would be better, but I don't see a need to force a choice.

---

From: Leonard Rosenthol <[email-masked]>
Date: Fri, 5 Feb 2021 14:35:01 +0000

Thanks for the history, Carsten – very helpful.

So then kramdown-rfc is *both* a piece of software *and* an extension specification for Markdown.  Yes?    If so, does there exist a document that describes those extensions and their behavior?   Because, to me as a standards guy, that is the important thing.   Making sure that there is a formal specification which *anyone* can use to develop their own tooling.

NOTE: I read the README at https://github.com/cabo/kramdown-rfc2629 (which I assume is the software we are referring to below) which seems like a great starting point for a language specification.

Leonard

From: Carsten Bormann <[email-masked]>
Date: Thursday, February 4, 2021 at 7:57 PM
To: Leonard Rosenthol <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, tools-discuss <[email-masked]>
Subject: Re: [Tools-discuss] [rfc-i] Recommendation 9 from Results and analysis of the survey of I-D authors on formats and tools

On 4. Feb 2021, at 22:02, Leonard Rosenthol <lrosenth=[email-masked]<mailto:lrosenth=[email-masked]>> wrote:

Supporting Markdown as an input option is a good idea - but why would you support a non-standard version of it?   CommonMark (https://commonmark.org/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommonmark.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7Ceb0a5ba25d4f442de8e108d8c97111bd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637480834764385146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ph5Th2uC3p7MN2RUoOGFm6r8D4UquZE31HvizTRljus%3D&reserved=0>) is the relevant "specification" for markdown.  Kramdown, on the other hand, is a specific tool that promotes its own flavor…

Hi Leonard,

Grüße, Carsten

[1]: https://github.com/cabo/kramdown-rfc2629/wiki/Syntax<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabo%2Fkramdown-rfc2629%2Fwiki%2FSyntax&data=04%7C01%7Clrosenth%40adobe.com%7Ceb0a5ba25d4f442de8e108d8c97111bd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637480834764385146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=32q5amTwOJ6HCU3pVKiDfZWCnUBekCF8CMKu27CEx4M%3D&reserved=0>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 5 Feb 2021 18:02:40 +0100

Hi Leonard,

On 2021-02-05, at 15:35, Leonard Rosenthol <[email-masked]> wrote:
> So then kramdown-rfc is *both* a piece of software *and* an extension specification for Markdown.  Yes?    

Well, no.  It is a piece of software.  There is no specification, just some documentation.  (Well, that property is only different in magnitude from RFCXMLv3 at this point…)  Note that, as it is based on kramdown, there might be a need to specify that as well in some more detail than it is now.

> If so, does there exist a document that describes those extensions and their behavior?   Because, to me as a standards guy, that is the important thing.   Making sure that there is a formal specification which *anyone* can use to develop their own tooling.

The narrow waist of the RFC authoring process is RFCXMLv3, so I would hope that we build our tooling around that.  That is (supposed to be) more stable than a specific authoring tool.

> NOTE: I read the README at https://github.com/cabo/kramdown-rfc2629 (which I assume is the software we are referring to below) which seems like a great starting point for a language specification.

Indeed, but that would be work that still needs to be completed.  
(See also https://github.com/cabo/kramdown-rfc2629/wiki/Syntax .)
For some reason, there are always other I-Ds that need to be written...

Grüße, Carsten

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 6 Feb 2021 13:24:17 +1100

> On 6 Feb 2021, at 1:35 am, Leonard Rosenthol <[email-masked]> wrote:
> 

If only we held the XML format to such a high bar...

(I'll show myself out.)

--
Mark Nottingham   https://www.mnot.net/

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 16:44:30 -0500

I am agnostic about commonmark vs kramdown.
I want to address the question of accepting markdown on the DT.

There are three aspects which mis-recommends this to me:
1) DT would have to be able to communicate errors back to the submitter well.
   Running the formatting, including the xml2rfc pass locally means that
   errors are communicating locally.
   So, my opinion is that accepting kramdown does not reduce any local complexity.

2) {::include }
   One of the things I like about kramdown, is the {:include} directive.
   This lets us keep the ascii art and other example diagrams in other files.
   This significantly reduces errors in updating example content.

   If we supported upload in kramdown, then we'd have to support upload
   of entire sets of files to be useful.

3) {::include } is insufficient.
   We have a bunch of other content: code examples, yang modules,  etc.
   which have so far been rather annoying to get in, and I wrote a perl
   script to insert the right <CODE BEGINS>, <figure><artwork>, and
   also to pick the right YANG version YYYYMMDD stuff.

   I think that getting all this right in whatever markdown format would
   take several iteration of tool improvements, and we have only just
   gotten to XMLv3.
   XMLv3 gets this all 'right' now, but I think that we aren't even close
   to 100% submission as XML.

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

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 6 Feb 2021 16:53:16 -0500

mmark is much more flexible on what one can include.

https://mmark.miek.nl/

On Sat, Feb 6, 2021 at 4:44 PM Michael Richardson <[email-masked]>
wrote:

> List info (including how to Unsubscribe):
> https://www.ietf.org/mailman/listinfo/tools-discuss
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 6 Feb 2021 17:51:48 -0500

Michael,

You make some good points, thanks.

But also, I'm happy with Carsten's new idnits option, so this has been a
useful discussion.

Cheers,
Andy

On Sat, Feb 6, 2021 at 4:44 PM Michael Richardson <[email-masked]>
wrote:

> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 21:07:37 -0500

> https://mmark.miek.nl/

That actually is less helpful, if you haven't uploaded all the required files
to the DT.

The CELLAR WG, of which I'm co-chair, uses mmark, btw.
Our use is probably overly complicated, but I didn't set it up :-)

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 7 Feb 2021 04:10:53 +0100

> That actually is less helpful, if you haven't uploaded all the required files

Right.  So an include feature probably should include a preparation feature that allows you to create a combined version to upload.

But why not include the conversion to XML with that preparation round?

Actually, when you use kramdown-rfc to create XML, the original source (combined!) is included in the XML as a comment (extract with kramdown-rfc-extract-markdown), so we already have the best of both worlds.

Re the {::include fn} feature:  I used to create documents like RFC 7400 (which is mostly generated text) from a script.
But then I found it easier to edit the text around the generated snippets with the {::include fn} feature.
Of course, there still needs to be a Makefile and the generation scripts for the snippets themselves.
(Including those in the markdown isn’t advisable for security reasons.)

While there is a bit of redundancy in ...

~~~~
<CODE BEGINS> file "[email-masked]"
{::include [email-masked]}
<CODE ENDS>
~~~~

…, I’m not sure avoiding that warrants a Perl script by itself.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 23:31:14 -0500

> …, I’m not sure avoiding that warrants a Perl script by itself.

Well, it started in XML days.

And there were several yang files, and they got generated/processed with
today's date inserted.  Being sure to use the latest one was error prone at one point.
Edit one, but update the other reference... oops.

And then sid files and tree files.
I could probably submit an "::include-yang" patch to do the right thing, and
maybe I should.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 9 Feb 2021 17:59:54 +0000

In looking through the survey results and reading through the comments on the tools-discuss list (which I just now joined to participate in this conversation), I think it would be useful to know how many of the people who use one of the 2 markdown formats prefer using markdown over all other formats. 

I nearly wept with tears of joy when Carsten helped me switch a draft from XML to MD and I no longer had to do battle with XML for it. It was so, so much easier. I'm just always forgetting to put in the closing XML tags. And finding those can sometimes be challenging and frustrating for me. And I'm always looking up the more obscure tags. The kramdown conventions were so much easier to learn/remember. I'm wondering what people who have been primary author on fewer than 5 XML-written drafts would prefer if they were to try MD. The people with extensive XML drafting experience are a group of people I have no wish to join, now that I've seen the MD light. 

I'm also one of the people who participates in a lot of other orgs and thought my IETF experience was worse. But that wasn't because the others use MS Word. 2 of them use (Pandoc-suitable) MD. If the IETF MD format(s) had a centralized place to go for getting tools and templates and instructions (rather than going to Martin's GH and Carsten's GH and Lars' GH etc.) and MD was "officially" supported, then I'd be happy. Even if the centralized IETF place just had links to their GH sites or was a mirror. But with somewhat improved instructions.

And I don't care about what flavor of MD -- I use Atlassian, GH, Pandoc, kramdown, etc. Whatever. As long as it's documented.

Barbara