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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Vijay,

On Sun, Sep 6, 2020 at 6:52 PM Vijay Gurbani <[e-mail]>
wrote:

> 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.
>

ISTM that it's worth considering what's possible without revising RFC 7942.

Everyone may already know this, but the RFC Editor now has a way of
inlining errata - for example, check
https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html. *

If we can figure out how to track "what's worth pointing to", perhaps the
RFC editor could also inline pointers, rather than dorking with the RFC
text itself.

Best,

Spencer

* I believe Adam Roach did the heavy lifting on proving this was feasible
when he was on the IESG. I'm not sure where the actual code used today came
from, but I do want to give credit when I can.


> 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
> --
> Edm mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/edm
>