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

["Joel M. Halpern" <[e-mail]>]

I would be very concerned about the IETF appearing to endorse particular 
implementations by archiving the source.
I would be much more comfortable with Adrian's suggestion of pointers to 
implementations that wish to be listed (open source or otherwise).

In terms of your concern about wiki maintenance, archives of source are 
in my opinion worse, since they will not have any fixes made after the 
archive.

In terms of visibility, I do not see why an archive is better than a 
wiki page.  Neither should be called out in the RFC, since they are 
transient.

Yours,
Joel

On 8/19/2020 12:04 PM, Vijay Gurbani wrote:
> 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] 
> <mailto:[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