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