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

[Vijay Gurbani <[e-mail]>]

Dear Michael: Thank you for your note!  I had to Google to get the "I find
your lack of faith disturbing" reference, and yes, I enjoy Star Wars, but
apparently not enough :-)

More inline.

On Wed, Aug 19, 2020 at 8:34 PM Michael Richardson <[e-mail]>
wrote:

>
> Vijay Gurbani <[e-mail]> wrote:
>     > I think that is rather counter productive.  After all, we standardize
>     > protocols so that others can write programs that implement the
> protocols,
>     > and I see a lot of value in preserving any running code.  In the
> particular
>     > case of the I-D I reviewed, there were two implementations, both from
>     > reputable organizations (APNIC and the Italian National Research
> Council).
>     > By simply deleting the "Implementation Status" section when the I-D
> was
>     > published as an RFC, it seems that good, quality implementations
> that folks
>     > spent time on would be lost, perhaps not irrevocably, but for most
>     > practical purposes, the code would be orphaned.
>
> "I find your lack of faith disturbing" :-)
>
> In the days when code lived at ftp.biguniversity.edu, in a weird
> subdirectory based upon the grant number under with the code was written...
> that was certainly true.  In these days of github, I hardly think the code
> is lost.
>

In the days when code lived at ftp.biguniversity.edu, the Internet had
equivalent tools to find it.  Remember gopher(1), and archie(1), and
veronica(1).  They were the github of their days.

That said, I don't think github is a panacea.  I have established anonymous
github accounts to store datasets and code when I submit papers that are
reviewed double blind.  The conference organizers are not interested in
maintaining links to github once a decision is rendered on a paper.  If the
paper is rejected, the github repository becomes an orphan.  If the paper
is accepted, then the artifacts either get moved to a sanctioned archive,
and the github repository becomes an orphan.  So, no, github is not a
panacea.  A longer term and stable storage is required for certain
scientific output (and RFCs certainly count as scientific output).

Just the opposite seems to happen in my opinion: middle managers are
> reluctant to commit funding to actually do a proper implementation because
> they think they can download some proof of concept from github, compile it,
> and ship it.
>

Just as likely, I have met many managers --- middle or otherwise ---- that
do due diligence and know that what you get from github may still need
scrubbing, and they'd better make sure that the licensing terms allow them
to use the software for their means.  So,  reluctance to funding due to
code being on github is not always the answer.


> If the code gets orphaned, I think that either says something about the
> relevance of the standard, or perhaps more charitably, about the quality of
> the implementation.   or maybe the license was just wrong.
>

I think that is a value judgment that I would rather not participate in.
Clearly not every RFC that we produce becomes a rousing success.  For the
subset that do, why not provide more support?

Sincerely,

- vijay