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

[Vijay Gurbani <[e-mail]>]

Dear Tommy, Mirja, all: Thank you for organizing the virtual meeting on
Tue, Sep 1.

As the instigator of the IETF WG Chairs list thread on archiving
implementations [1], I have some thoughts, but unfortunately due to a
conflict with meetings on my calendar, I had to leave early before the
second half of the meeting on last Tue when this issue was discussed.
Thank you for considering this thread of enough interest to put it on the
EDM agenda.

My main question in the IETF Working Group Chair thread was simple: How do
the larger set of R&D folks who use the protocols we create find relevant
code and other accoutrements that are of interest to them without wading
into the IETF arcana?  (As a definition, "IETF arcana" is the collective
knowledge we, on this list, have gathered from participating in the
organization for a sustained period.  We know what a datatracker is, what
the difference between an individual submission versus a WG submission is,
we know where Wikis related to WG pages are, we know what WG deliverables
are, etc.  This collected knowledge is not readily available to the many
people who want to use our protocols, and it is not clear to me that this
knowledge would be of use to them unless they want to participate in the
IETF to the extent that we do.  They need to implement a standardized
protocol, for the most part, that is their primary concern.)

What is the most visible output of the IETF?  Perhaps unarguably, it is an
RFC.  Even someone who has at best, a foggy idea of what the IETF is, knows
what a RFC does.  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 that we can to
make sure that the implementers have all of the information they need to
implement the protocol from the RFC itself.

The primary artifact of the protocol is the code that implements it.  Not
all code is equal.  Some, like a SIP server, a QUIC implementation, a HTTP
Server, a TLS implementation are complex and it is a foregone conclusion
that we can simply park some code in an archive that implements such
complex protocols.  However, we also produce routing protocols, hashing
functions, best practices on how to handle dual IP stacks, ALTO entities
that use HTTP and JSON to converse with each other, and so on.  Such code
is small, perhaps modular, stand-alone and often can easily be made
available in a repository much more readily than complex systems like QUIC,
SIP, TLS, or HTTP.

For the more complex protocols and their implementations, wikis and GitHub
repositories that point the new implementer to the community of interest is
sufficient.  For the less complex protocols that do not need a large
community of interest, a simple code archival mechanism appears to be
reasonable.  To the extent that the archive should be IETF owned, it makes
sense to home the archive under ietf.org, as some of the IETF wikis are.

So, the next question is how to let the implementer know of these resources
when they read a RFC or an I-D?  RFC 7942 is an excellent start.  It
suggests having an Implementation Section in an I-D, but requests the
removal of such a section from an RFC-to-be.  This implementation section
can be used to document the datatrackers, wikis, and GitHub repositories
for the more complex code and a link to the archival area for the less
complex code.  (I realize that IETF does not have authority over links like
GitHub that are not under the ietf.org administrative domain, but perhaps
for large projects, it is adequate that they stay in repositories like
GitHub.) Perhaps RFC 7942 can be updated so that the Implementation Section
is not removed when the I-D becomes an RFC, and perhaps verbiage can be
added to it during the update that essentially says "caveat emptor", but in
more words and with appropriate constraints.  But the basic concern of
making an RFC self contained such that it has links to implementations is
adequately accomplished by an updated RFC 7492.

Thank you for reading so far, and thank you again for considering this of
enough interest to put it on the EDM agenda.  I look forward to your
thoughts on this.

[1] A quick recap and restatement of the need for a stable archival area
controlled by the IETF is in
https://mailarchive.ietf.org/arch/msg/wgchairs/He68KsKijRg2FAIpxRFi5MyJGis/
 That link contains other links to the original thread for those of you who
want to catch up with the discussion.

Cheers,

- vijay