Subject: Re: [Rfc-markdown] 1.5.15: Discussion Venues

From: "Martin Thomson" <[email-masked]>
Date: Tue, 02 Nov 2021 10:41:59 +1100

Thanks for doing this Carsten.

This is definitely my preferred approach to including this sort of information; I'll keep the automation, but I recommend following this form.  If you are using the templates, using Carsten's tweak will disable that automated tweak.  I have some updates I'd like to do to make filling this in easier, but that will come later.

On Sat, Oct 30, 2021, at 18:44, Carsten Bormann wrote:
> 1.5.15 has basic support for generating discussion venue notes.
> The details are likely to further improve based on your input, which I 
> hereby request.
>
> Put this in your YAML front:
>
> venue:
>   group: JSON Path
>   mail: [email-masked]
>   github: ietf-wg-jsonpath/draft-ietf-jsonpath-base
>
> And you get right after the abstract (looks nicer in HTML):
>
> Discussion Venues
>
>    This note is to be removed before publishing as an RFC.
>
>    Discussion of this document takes place on the JSON Path Working
>    Group mailing list ([email-masked]), which is archived at
>    https://mailarchive.ietf.org/arch/browse/jsonpath/.
>
>    Source for this draft and an issue tracker can be found at
>    https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base.
>
> You can leave out “group:” if that is identical to the local part of 
> the mail address (here, I liked some extra spacing and capitalization).
> Put in an explicit “type:” if you don’t like the code to infer “Working 
> Group” from @ietf in the mail address, or “Research Group” from @irtf.
> Put in an explicit “arch:” if you don’t like inferring the mail archive 
> name from the mail address (is that ever wrong?).
>
> Todo: add a slash before the period (so the link works in .TXT as well 
> as it does in .HTML), and add in non-github git repos, as soon as 
> somebody tells me they use one :-).
>
>   git: https://gitlab.com/weird-wg/draft-ietf-weird-nonconformance/
>
> And thanks of course to Martin Thomson whose .note.xml function in 
> I-D-Template I stole this from (which gets most of this information in 
> an automated way, but makes the generated draft dependent on its 
> context).
>
> Grüße, Carsten
>
> _______________________________________________
> Rfc-markdown mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rfc-markdown

---

From: Julian Reschke <[email-masked]>
Date: Tue, 2 Nov 2021 06:13:12 +0100

Am 02.11.2021 um 00:41 schrieb Martin Thomson:
> ...

+1

I also believe that draft authors should be encourage more to provide
this kind of information. Maybe something for IDNITS?

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Nov 2021 09:01:03 +0100

> this kind of information. Maybe something for IDNITS?

Sounds good to me!

One issue we occasionally had with idnits was what exactly its target is.

E.g., using the -latest convention for the docname makes idnits generate up to four errors that need to be ignored constantly during authoring.
When I suggested that it should accept that convention (or at least react in a more usable way), the verdict was that since idnits is for checking drafts that are ready for submission, not having a numeric revision number was an error that needed to be flagged.

In this mode of thinking, not having a discussion venues note is not the same as, say, a missing security considerations section, as a draft can be accepted and moved through IESG without it.  (It’s just no longer the way we should do this in 2021.)

We can’t really put the note into 7322bis, as this is for RFCs and not I-Ds.
There are the I-D guidelines; this would be the place to add the strong suggestion for a note and its approximate contents, and idnits could take it from there.

Grüße, Carsten

[1]: https://www.ietf.org/standards/ids/guidelines
[2]: https://github.com/ietf/id-guidelines

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Nov 2021 09:06:20 +0100

> There are the I-D guidelines; this would be the place to add the strong suggestion for a note and its approximate contents, and idnits could take it from there.

https://github.com/ietf/id-guidelines/issues/53

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Nov 2021 12:44:29 -0400

> this kind of information. Maybe something for IDNITS?

I agree!

Given:

%kdrfc -V
kdrfc, from kramdown-rfc2629 1.5.16

https://github.com/anima-wg/anima-brski-prm/commit/397d94e846bcbad5523ce86d1715c3f6540593b2

venue:
   group: ANIMA
   mail: [email-masked]
   github: anima-wg/anima-brski-prm.git

--- abstract

I'm not seeing venue added to the .txt version... or .html version.
Perhaps I'm doing it wrong.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Nov 2021 18:57:42 +0100

> Perhaps I'm doing it wrong.

Yes.

Actually, since the discussion venues note itself does not depend on RFCXMLv2, I could have made a v2 version, emulating the removeInRFC attribute that is new in v3 in some way.

But I figured everybody was on v3 already, so I didn’t put in the time.

Please

sed -i.bak 's/kdrfc/kdrfc -3/' Makefile

(And maybe get rid of the direct call of xml2rfc, because kdrfc knows how to call xml2rfc for v3 processing.  Just use `kdrfc -3h` to do all that.)

Apologies for the lack of an error message…
https://github.com/cabo/kramdown-rfc2629/issues/138

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Nov 2021 14:15:32 -0400

> sed -i.bak 's/kdrfc/kdrfc -3/' Makefile

Ah, I didn't realize that our makefile was non-standard.
(not even my stock makefile)

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