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

[Stephen Farrell <[e-mail]>]

Hiya,

On 20/08/2020 01:50, Joel M. Halpern wrote:
> I am missing something Stephen.  We can establish exactly the
> relationship you describe without the IETF archiving the source code.

I don't believe I made any suggestion as to who would
claim/establish that some code maps to an RFC/I-D. I'd
imagine authors/chairs are far more likely to do that
than "the IETF."

> 
> So what is the advantage you see in the IETF making a snapshot of a
> project and storing it separately from that project? 

I believe I already said that. See my example wrt EC points. I could wax
lyrical but not sure that'd help
more;-)

> 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.

That all sounds good. I also already said why I do think
there's value in an IETF-archived copy. As another point,
fd.io (hadn't heard of 'em btw), was registered in 2013.
I've seen various excellent industry efforts come and go
over the years and would be more confident that ietf.org
might have the same function in 10 years than such well
meaning but likely more short-lived domains.

> 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.)

I'd have no objection to that, assuming all the same
caveats as ought apply to a pointer to any implementation.
All I claimed was that having the overall set of pointers
include some reasonable OSS adds value that is inherently
missing for closed-source.

> 
> 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.

I don't believe I advocated for "pretending" of any kind.

Cheers,
S.

> 
> 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.
>>
>>