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

[Stephen Farrell <[e-mail]>]

Hiya,

On 19/08/2020 23:51, Joel M. Halpern wrote:
> There is different value in open and closed source implementations.  But
> bother are valuable.

I maintain that, for implementers of RFCs, the existence of
open-source code is valuable in a way that closed-source
can never match. ISTM, that means OSS is inherently better
for the purpose we're discussing here.

> There is as far as I can tell no benefit in the IETF actually storing
> the source for these projects.

I disagree. Finding the commit that matches the time at
which the RFC was written can be non-trivial and will
sometimes be useful/needed.

>  Either they are being maintained or they
> aren't.  If they aren't, the source has much less value. 

I disagree. For an implementer of an RFC, there is still a
lot of value in looking at someone else's code that matches
the RFC (or nearly does).

>  If they are,
> the maintained one is what people should look at.

Not necessarily. The not-very-good but easy to read code
that existed at the time the RFC was written might well be
the most useful thing for an implementer.

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

Given the above, I fail to see how you can think closed-
source can be as useful there, regardless of the mechanism
for de-referencing a pointer.

Cheers,
S.


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