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

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

I am missing something Stephen.  We can establish exactly the 
relationship you describe without the IETF archiving the source code.

So what is the advantage you see in the IETF making a snapshot of a 
project and storing it separately from that project?  For example, I 
work with fd.io.  That implements a lot of IETF RFCs.  Very effectively. 
  In open source.  I can not see any benefit in the IETF making one (or 
worse yet several) copies of fd.io.  I can see benefi, for cases where 
the fd.io developers want it, for the IETF to have pointers to the fd.io 
work with indications of what RFCs it implements (a lot).  If someone 
wants to do the work, that could include pointers to specific versions 
(which will fall out of maintenance), pointers to the most current 
versions, pointers to the whole project so people can get context, and 
pointers to specific sub-projects concerned with specific RFCs.  How 
elaborate it gets probably depends upon both what we want and how much 
work the fd.io developers care to put in.

But if we want to point to OSPF implementations, it would seem very 
strange not to point to the widely used implementations from Cisco and 
Juniper (multiple from each, and ones from a number of other vendors). 
Yes, we should point to the several open source ones (if the 
implementors want us to.)

We do regularly get asked / ask ourselves "who has implemented this". 
Improving and maintaining our ability to answer that question seems very 
useful.  Pretending that the only implementations that matter are the 
open source ones seems counter-productive.

Yours,
Joel

On 8/19/2020 8:22 PM, Stephen Farrell wrote:
> 
> 
> On 20/08/2020 01:01, Acee Lindem (acee) wrote:
>> What is the advantage of the IETF maintaining the repository as
>> opposed to pointing to a GitHub repository/repositories maintained
>> the open source implementor(s)? I see none.
> I do. Linking the RFC to the version of the code that
> claims to implement that is useful. Not depending on
> the kindness of, or lack of bitrot at, git<blah>.<tld>
> is good.
> 
> Doesn't need to be hard, could just be a snapshot
> of a git repo that's tied to the RFC (or I-D) via
> the tracker. (I don't much care exactly how.)
> 
> But claiming that's useless is not something I can
> grok TBH.
> 
> S.
> 
>