Re: [irsg] An IETF repository for working code in our protocols?

[Vijay Gurbani <[e-mail]>]

On Fri, Aug 21, 2020 at 11:56 AM Jane Coffin <[e-mail]> wrote:

> I hope I do not sound too clueless, but is the objective in creating a
> repository to educate future coders?
> If yes, wouldn’t they see that already in running/operational code? Or, is
> the idea to show how code changed over time/got better?
> If no, what would the repository do to educate folks new to the IETF
> protocols.
>
> I ask these questions sincerely and with apologies if this is super clear
> and I missed the context.
>

Dear Jane: Good evening, and thank you for your note, and your interest.

So, let me start off by saying that the intent of what I proposed is *not*
to educate future coders.  That is the job of universities and bootcamps.

The genesis of what I am trying to affect is simple: We produce standards
that describe protocols.  As a protocol is being defined in an I-D, there
are often implementers implementing the protocol or portions of it.  These
implementations are important, enough that RFC 7942 [1] recognizes the
import of these implementations and exhorts I-D authors to create an
"Implementation Section" to document these implementations.  RFC 7942 also
asks I-D authors to remove this section before the I-D becomes an RFC.  My
question is if there are implementations that are worthy of being mentioned
in an "Implementation Section" of a I-D, why don't we preserve these
implementations in an IETF repository and link the repository in the RFC.
This way, new implementers of the protocol can quickly bootstrap their
implementations, leading to a diversity of implementations, which can only
be good for a protocol that is trying to find its footing.

Why is this important?  Simple: Reaching out to developers outside of those
of us who are already in the IETF is my biggest incentive.  They are the
ultimate consumers of what we produce.

When I talk to developers at companies and students at universities, if
they have heard of IETF at all, it is mostly through knowing that some
organization called IETF produces these things called RFCs.  That's it.
Perhaps for them that is enough.  And if you buy that argument, then the
corollary is that we should do everything in our power to make sure that
they have all of the information they need to implement the protocol from
the RFC itself.   Consider the errata we maintain in an RFC.  Imagine
instead of us providing the errata, we simply told implementers that it is
out there, go find it.  The errata is important, so we list it in an RFC.
When a protocol is finding its footing, early implementations that allow
other developers to understand its behaviour and derive their own
implementations from it is also important.  So why not formalize the
process of archiving implementations that are worthy of being listed as per
RFC 7942?

People have pointed out that we have WG pages, Wikis, datatrackers, and
other such accoutrements for this purpose?  WG pages, WG Wiki pages,
datatrackers, all make sense to you and me.  Not to many people who will
like to implement our protocols without burying themselves deep into IETF
to know the difference between a WG page and datatracker.  Their visibility
into the IETF is through the RFC.  So, put as much information in there
that will make a developer productive.

I don't claim that this will be easy; the length of this thread indicates
the passion of the participants around the issue.  However, I don't think
that the issues raised are insurmountable.

My initial email that started this thread is in [3].  It has more
information and context, including how organizations like IEEE and ACM have
dealt with similar issues.

If you have further questions, I am happy to answer them.

[1] https://tools.ietf.org/html/rfc7942
[2]
https://mailarchive.ietf.org/arch/msg/wgchairs/AGHRTKsDoSF3GJVhB4K2bKYjdWU/
[3]
https://mailarchive.ietf.org/arch/msg/wgchairs/8_Or3U-Wwjw35VmLy_uTPID9sTU/

Thanks,

- vijay