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

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

There is different value in open and closed source implementations.  But 
bother are valuable.
There is as far as I can tell no benefit in the IETF actually storing 
the source for these projects.  Either they are being maintained or they 
aren't.  If they aren't, the source has much less value.  If they are, 
the maintained one is what people should look at.

So again, having an easily findable and easily maintained set of 
pointers to any implementations that folks want to list, with whatever 
terms those folks like (whether that be creative commons open source, 
GPL, or descriptions of proprietary implementations) seems very useful. 
The problem of findability is real, but is not different for an archive 
compared with a set of pointers.

A set of input / output vectors along the lines Erik suggested also 
sounds useful.  For some protocols.  (I don't quite know how one would 
do that for something like OSPF.)

Yours,
Joel

On 8/19/2020 6:33 PM, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 19/08/2020 23:22, Joel M. Halpern wrote:
>> One of the advantages of pointers to implementations is that it can
>> include equally pointers to open source and pointers to closed source of
>> various forms.  The IETF doesn't take a stance among implementations.
> 
> Entirely surmountable problem IMO. Add caveats to avoid
> misperceptions wrt stance.
> 
> That said, open source implementations are plainly more
> useful for people who want to implement RFCs, compared to
> equivalent closed-source implementations. It'd be folly
> to ignore that reality.
> 
> I just now discovered that what I thought ought be a
> compressed-point representation of a DH shared secret is
> supposed to use the uncompressed format thanks to being
> able to add more trace lines to someone else's code. That's
> the kind of thing could suck up many more hours of effort,
> or that might lead to non-interop, (as it only affects some
> groups), if no open-source code were available.
> 
> S.
> 
>>
>> Yours,
>> Joel
>>
>> On 8/19/2020 2:46 PM, Vijay Gurbani wrote:
>>> Dear Glenn: Thank you very much for your note.  More inline.
>>>
>>> On Wed, Aug 19, 2020 at 1:19 PM Deen, Glenn (NBCUniversal)
>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>      Hi Vijay,
>>>
>>>        In additional to the points others have made, I’ll add that an
>>>      IETF code repository would need to carefully work out license issues
>>>      and also how it fits into the IETF’s Intellectual Property set up
>>>      that is managed by the IETF  Trust.
>>>
>>>      [...]
>>>
>>>      There may be more that pop up once the topic was looked at deeper.
>>>
>>>      I’m not saying that any of these are show stoppers, but there’s a
>>>      lot of legal elements that would be need to worked out before any
>>>      bits got checked into a repository.
>>>
>>>
>>> Yes, absolutely.  All of what you listed are important and weighty
>>> concerns.  But none of them appear to be insurmountable if we decided
>>> to do this.  Clearly, the precedent set by IEEE and ACM in similar
>>> areas seems to point to the possible existence of a happy medium,
>>> should we go this route.
>>>
>>> Cheers,
>>>
>>> - vijay
>>>
>>