+1 Even more so: explain (even "pitch") to FOSS contributors what they and their project could gain from supporting the work towards being able to normatively reference it. On Tue, Oct 31, 2017 at 04:48:54PM -0400, Joel M. Halpern wrote: > It seems to me useful to look at it from a somewhat different > perspective. Given that we are trying to work effectively with the > open source communities, it behooves us to be clear about what it > takes for us to normatively reference their work. Whether there > exist artifacts that are open source and meet the requirements or > not, laying out our expectations provides a clearer path forward. > > Yours, > Joel > > On 10/31/17 4:43 PM, Toerless Eckert wrote: > >I was just asking for an example of well documented FOSS software > >that could be accepted for standards track reference by IETF. I can't > >come up with any. > > > >In my unfortunate experience, RTFS is the standard answers when it > >comes to FOSS specifications. > > > >I would like the process where FOSS explores a problem field and > >is used to start standardiation. I just don't think that the standardization > >of interoperability behavior comes for free. > > > >Cheers > > Toerless > > > >On Mon, Oct 30, 2017 at 10:29:45PM +0100, Riccardo Bernardini wrote: > >>On Mon, Oct 30, 2017 at 9:40 PM, Toerless Eckert <tte@xxxxxxxxx> wrote: > >> > >>>On Sun, Oct 29, 2017 at 11:39:34PM -0400, Alia Atlas wrote: > >>>>Personally, I have not seen it work well or be generally perceived as > >>>>anything more than a waste of time to ask well specified and widely > >>>available mature open > >>> > >> > >>^^^^^^^^^^^^* > >> > >>>>source work to come and be republished as an Independent Stream > >>>Informational RFC. > >>> > >>> > >>> > >>I guess that "well specified" is a cornerstone word here: _if_ the OS > >>protocol was well specified (and with this I mean in an unambiguous way, > >>with enough detail to allow interoperability with other implementations and > >>in a stably referenced document), I would agree that re-publishing it is a > >>waste of time and I would have no qualms in using it in an RFC. > >>However, my personal experience with OS software (both as users an -- > >>partly -- as a contributor) is that documentation in some cases can be > >>really lacking and the source code is considered the ultimate documentation > >>(I remembered that few years ago I asked details about the format of > >>octave data files and I was told to look at the source code). > >> > >>One could think about considering a snapshot of a specific version of the > >>source code as the protocol specs; unfortunately source code is not good > >>for that: first, you need to reverse engineer it in order to deduce -- say > >>-- the format of a packet; secondly often is *not* unambiguous, for > >>example: if you declare a packet field as "int" in C, how many bits is? > >>Sure, the code will run smoothly with current processors since int is 32 > >>bits everywhere, but what if you are going to communicate with a processors > >>whose int is 64 (or 16)-bit wide? (and I did not mention "efficiency > >>tricks" that are ill-defined according to the C specs, but work as long as > >>you stick to gcc). > >> > >>One could object that if there is an open source implementation, there is > >>no need for unambiguous specs since one can just use the existing > >>implementation. However, I see this as a very weak solution: someone else > >>could need to create a new implementation, maybe in a different language, > >>maybe for a different architecture not compatible with the current > >>implementation. > >> > >>Summarizing, if the cornerstone condition "well specified" is met, I think > >>that the OS protocol can be considered as a protocol developed by any > >>standard body (this suggest that condition "well specified" is quite > >>demanding), but if the condition is not met, the only solution I can think > >>of is to "snapshot" it (and clean it, if necessary) into an Informational > >>RFC. > >> > >>Riccardo > > -- --- tte@xxxxxxxxx