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

[Vijay Gurbani <[e-mail]>]

Dear Brian: Thank you for your comments!  Having co-authored one RFC with
you, I value your experience and judgment.

Please see inline.

On Thu, Sep 10, 2020 at 3:45 PM Brian E Carpenter <
[e-mail]> wrote:

> Hi,
>
> I too think that RFC7942 is sadly under-used; it's very rare that I see it
> during Gen-ART reviews and I would like to see more. I have used it myself
> in a few drafts.
>
> However, I think it would be a serious mistake to include such information
> in RFCs. RFCs are archival documents with an infinite lifetime. Do we
> really want them to contain URLs for GitHub repositories of prototype
> implementations?
>

Indeed, RFCs are archival documents with an infinite lifetime, but RFCs are
also scientific documents, and as any scientific document, sometimes their
content is absolute (Shannon's "Mathematical Theory of Communications"
paper, for instance), and sometimes their content can be updated (the
hundreds of documents the scientific community is producing now on
Covid-19).  IEEE and ACM are encouraging scientific papers to contain links
to datasets and experiments that are hosted for archival by these
institutions.  Why can't we?

In the extreme case, if you read a peer-reviewed scientific publication in
a top quality journal and click on an expired link in that journal, the act
of not finding the contents at the end of the link likely should not
invalidate the entire research. I think that we are doing a disservice to
the future readers (and implementers) of RFCs by assuming that they will
not pay attention to the "caveat emptor" text associated with any GitHub
repositories, especially if these warnings are in a section that screams
that the contents of the GitHub repository were current as of the
publication date of this RFC and that no endorsement of the GitHub
repository is made by the IETF beyond the publication date of the RFC.  I
really see no harm, I see a lot of benefit.

Or what amounts to advertising for specific products? Should RFC 2460
> include a pointer to the first commercial IPv6 implementation (IBM AIX 4.3)?
>

These are good questions; they have answers that would require us to come
to consensus on.  I will certainly give you my answer to this and hope that
it changes your mind, or if not, at least incentivize you to explore the
issue from a different angle.  In my association with the IETF, I have come
to appreciate the communal way in which we develop our protocols.  This is
inspite of the fact that each one of us --- at least a majority --- work
for corporations that fund us to attend the meetings and conduct the work.
If because of this prevelant communal zeitgeist in the IETF, we don't have
a "Company-X version of Procol P", or a "Company-Y version of Protocol P",
why do we assume the community will tacitly endorse implementations that
amount to advertising for specific products?  Surely, we have come beyond
that, no?  We have guardrails in place (WG chairs, AD, IESG, perhaps ISOC
and IAB) to make sure that this does not happen.  So what are we reticient
about?

Regarding whether RFC 2460 should have included a pointer to the first
commercial implementation of IPv6 from IBM, well sure, with a constraint:
as long as IBM was willing to make the code available openly (as happens in
GitHubs now), and allows others to experiment with it and make it better, I
don't see the harm.  Of course, if IBM was not willing to make the code
available publicly, then this line of thinking is moot.

Thank you much!

Cheers,

- vijay