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

[Vijay Gurbani <[e-mail]>]

Dear Adrian: Thank you for the follow up.  More inline.

On Wed, Aug 19, 2020 at 12:24 PM Adrian Farrel <[e-mail]> wrote:

> 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.
>
>
>
> AF> You capture an important aspect, but I was concerned about the other
> side of it. It one company has implemented at the time the RFC is
> published, but others have not yet then the RFC stands forever (or at least
> until it is replaced or updated) without mentioning all of the other
> companies that implemented just a week to late to be documented. That is
> not very fair on the new companies and a little misleading for readers of
> the RFC.
>

I understand your concern, and it is a valid one.  However, note that the
archival process for the code can be, and indeed should be, limited to the
code that has tracked the I-D.  The intent is to provide some bootstrap
code to implementers from the get go.  If someone chooses to wait until a
RFC has been released before they produce code, that is certainly their
prerogative.  But I hardly think that they can make a case that their
post-RFC implementation is now a candidate for archival.  That would be
stretching the idea too far and in directions it is not intended.  (One way
to tamp down on the unintended consequences.)

> 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.
>
>
>
> AF> Ah, no. I meant (possibly as suggested by Joel) commercial
> advertisements (as in “promotional material”). In many cases,
> implementation is described as “Company X’s implementation of this
> specification” and includes product names and release numbers. We do want
> that information but we don’t want this to be used as a way of saying that
> Company X makes splendid boxes and Company Y produces rubbish.
>

I agree, we do not need "promotional material" of the sort you outline
above.  And we can include such exhortations in the process we define.
That said, I don't think that the RFCs we produce are touted as "Company
X's implementation of this specification", despite the author's affiliation
on the RFC masthead.  Thus I think that this particular concern may be
mitigated by the normal social mores that have evolved in the IETF to
accord more credence to individuals rather than their particular
affiliations.


> AF> In our RFC, we were looking at how information about running code may
> influence the standardisation process. You are looking at something
> slightly different, and that is a good thing. Engaging with Tommy on this
> sounds like a sound idea.
>

Yes, thank you for that note.  I appreciate it, especially coming from a
constituent who started to even think of defining this process!

Cheers,

- vijay