Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1

[Vijay Gurbani <[e-mail]>]

On Thu, Sep 10, 2020 at 11:40 AM Mirja Kuehlewind <[e-mail]>
wrote:

> Hi Vijay,
>
> Thanks for moving this discussion forward.
>

Dear Mirja: Thank you for your time and your comments.  More inline.


> To focus on the formal bits for a second: RFC7942 doesn’t actually require
> that the section is removed. This says "Authors are requested to” but I
> guess it’s for the authors/wg to decide. Also this is an IETF-consensus
> document which I think was AD-sponsored. So the way to update it is
> “simply” to write a bis-draft and bring it to gendisptach these days.
>

I agree that RFC 7942 only "requests" not "mandates" that the section be
removed.  However, the practical effect of this request is that most
authors will simply ask for the section to be removed.  That was the case
in a particular draft that I was reviewing for Gen-Art (which actually
resulted in the thread I opened up on the WG Chairs list).  Furthermore, to
be frank, before I reviwed the draft in question for Gen-ART, I was not
even aware of RFC 7942.  Certainly, it is fairly new (having been minted in
2016), but none of the I-Ds or RFCs I have read post-2016 even mention an
Implementation Status section.

It certainly does not portend well that we are not eating our own dog
food.  I looked at two active WGs --- quic and httpbis --- to see if an RFC
7942 section is present in any of the active I-Ds.  Of the 24 I-Ds in these
groups, I could not find such a section [1].  Apologies, I am not picking
on these groups, just trying to get some objective data points by looking
at a couple of active WGs.  The irony is that the base protocol document
for QUIC [2] has a "Note to Readers" section that provides the very
information --- where to find the GitHub repository --- that we are seeking
to institutionalise.  I am not sure what will happen to this note when QUIC
becomes an RFC.


> More to the actually point: I understand your motivation about people only
> knowing RFCs but none of the IETF process but I’m not sure putting this
> information in an RFC is the right tool. I bed it’s actually not very hard
> to find some suitable code on GitHub these days, especially as you said if
> this is about larger projects (which in the best case are actively
> maintained). For smaller code snippets we often put pseudo code in the
> document of appendix. So that’s another option.
>

I understand and respect your view that putting this information in an RFC
is not the right thing to do.  I am trying to convince you that it is, and
I hope that I succeed in some measure.

The proposal we are considering --- i.e., putting some text in RFCs to
guide legions of implementers not familiar with "IETF arcana" --- is
already being used loosely as I pointed out above for QUIC.  It seems to me
that we can do better by institutionalising it in some manner that RFC 7942
did not. Perhaps as you suggest, the answer is to simply write a RFC
7942-bis draft.  If you think this is an avenue we should explore, I am
happy to spin up a rfc7942-bis  so to provide more structure to the
conversation.

[1] I will like to point out that of the 24 I-Ds, not all deal with
specific protocol/algorithmic issues, so please account for that reality.
[2] https://www.ietf.org/id/draft-ietf-quic-transport-30.txt

Thanks,

- vijay