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

[Vijay Gurbani <[e-mail]>]

Dear Adrian: Thank you for your engagement as a co-author of RFC 7942 as
well as your individual comment.  Please see inline.

On Wed, Aug 19, 2020 at 10:25 AM Adrian Farrel <[e-mail]> wrote:

> Hi Vijay,
>
>
>
> Responding as a co-author of RFC 7942.
>
>
>
> When we first wrote the draft that became RFC 6982 and then matured into
> RFC 7942 we were conscious that any information about implementation held
> in an RFC is necessarily only true at the time of publication: it may be
> missing important details of implementations that existed at the time of
> publication, and obviously cannot be updated for new implementations.
>
>
>
> We felt that archiving this information in the RFC may be misleading and
> also unfair, and so we suggested removing the implementation status section
> of the document before publication.
>

Those are valid concerns, indeed.  However, I note that the entire RFC
process is an iterative process itself.  When we release an RFC as a PS, we
release it with the knowledge that there may be some design choices that
could be revisited at a later stage.  Ergo, if an implementation tracks the
RFC closely, the underlying assumption would be that the implementation may
well be updated at some later time as the RFC moves through its states from
Proposed to Draft to Internet Standard.  To be sure, I am not saying that
we should simply archive any half-baked or incomplete implementation,
rather rely on the knowledge of the authors of the I-D and the chairs, and
perhaps even the IETF interoperability process for the RFC, to only archive
those implementations that are worthy of being archived.


> However, in Section 3 we note that there are alternative formats, and
> suggest that one reason for publishing the information elsewhere is:
>
>    -  If the working group decides that the information is still
>
>       valuable (and needs to be kept current) after the I-D is published
>
>       as an RFC, and the Implementation Status section had been removed
>
>       from it.
>
> That seems to fit with the idea in your email.
>
>
>
> Although out of scope of our draft, we suggested that working groups might
> like to use their wiki pages to track implementation and keep it up to
> date. We also (rather cheekily, IMHO) floated the idea that the datatracker
> page for a document might also contain a link to the implementation page
> (like it does for IPR disclosures).
>

I think the above choices are sound, but I also note that: (a) Wikis have a
history of starting strong, but subsequent updates wane; (b) the notion of
checking a datatracker will not even occur to the average implementer who
does not participate in the IETF as closely as we do, in fact, I would go
as far as to say that the average implementer who looks at a RFC for
implementation only knows the RFC and the information contained there.  I
doubt that they would even be aware of what the datatracker is.  This
observation is borne out by my individual observations of talking to
company R&D staff who know at a very high level what IETF is, but beyond
knowing that the protocol is specified in a RFC, they do not know the
accoutrements associated with IETF that we take for granted (working
groups, area directors, areas, datatracker, etc.).

Thus, just like we have a link to an errata on top of the RFC, we can
maintain a link to archived programs that implement a certain RFC under
strict assumptions laid out in some document.  (These would include no
guarantee of fitness, etc.)


> With author hat back off, I’m slightly wary about the IETF becoming a
> venue for advertisements, so I would encourage people to be quite careful
> about how this sort of information is collected and maintained.
>

I suspect that you imply advertisements as indicated by the domain name in
an email address of the source code's author.  Indeed, that is a concern,
and we would not like to have half-baked or incomplete implementations
archived simply for perpetuating advertising.  I believe that this can be
mitigated by due diligence of the I-D authors, chair knowledge of the
protocol, and any bakeoffs that the WG has overseen.  (I recall that when
we were developing ALTO, there were multiple implementations of the
protocols and various extensions that could have been useful for
individuals and projects like the Open Daylight SDN controller and its
support for ALTO.)

The law of unintended consequences may yet still strike, I don't claim to
foresee all problems.  But insofar as we seek "rough consensus and running
code", having "running code" from multiple strains of company (or
individual) DNAs seems like a reasonable goal.

Thanks!

- vijay