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

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

For IETF purposes, the existence of implementations is very important.
For some purposes, open source code is useful.
Depending upon the license, for many purposes looking at open source 
code can actually be harmful to the implementation work.

If we want to make available pointers to specific versions of open 
source, as well as pointers to the information about the implementation, 
that is fine.  For many uses, it is as or more important to be able to 
look at the implementors summary of what they actually support than it 
is to look at the code.  For other purposes, looking at the code is 
clearly useful.

I am not asking that the IETF not point to such available code.
I am asking that if we are going to identify implementations that we 
identify implementations regardless of their status.

I presume even for open source we will not attempt to verify the code 
correctness, operability, or quality.  We are not talking about 
reference implementations.  For different consumers of this information, 
different implementations will have different value.  We do not 
currently second-guess implementation or interoperability reports, and I 
do not suggest we start.

As just one example, if I am looking for things to interoeprate with, I 
may well be just as happy with commercial implementations as with open 
source.  Maybe happier as I do not have to figure out how to build 
someone else's structures.

Archiving the soruce has many complications.  And very little value I 
can understand.  After all, if it is open soruce, then it is available 
somewhere else.  if the people making it available do not want to 
continue to do so, it is not the IETF's job to take care of their code 
for them.  Conversely, if they are interested in their work being 
pointed to by the IETF, I am happy to see us do so.

Yours,
Joel

On 8/19/2020 7:09 PM, Stephen Farrell wrote:
> 
> 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
>>>>>
>>>>
>>