Re: letting IETF build on top of Open Source technology

[Miles Fidelman <[e-mail]>]

Meant to reply earlier - on a trip...

On 11/3/17 5:07 AM, Phillip Hallam-Baker wrote:

> On Thu, Nov 2, 2017 at 1:01 PM, Miles Fidelman
> <[e-mail]> wrote:
>> On 11/1/17 10:35 PM, Phillip Hallam-Baker wrote:
>>
>>> My specifications are my code.
>>>
>>> If you look at any of the protocol specifications for the Mesh, you
>>> will find a reference section in the back that is generated directly
>>> from the schema and examples taken from running code generated from
>>> the same schema. And the running code used to generate the examples is
>>> the same as the reference code.
>>>
>> That's a little bit disingenuous, isn't it - particularly since you've
>> written quite a bit of documentation beyond your code.
> I did not say my code is my specification. Which is what a lot of
> people have done in the past.
>
> I develop the documentation and the code at the same time. Of course
> there are parts of the documentation that are not code, the user
> guide, requirements, etc. But every specification has normative and
> non-normative sections.

More precisely, can you elaborate just a tad on HOW your "specifications 
are your code?"

I've taken a look at some of the documentation you've pointed at, but 
have yet to find any that have "a reference section in the back that is 
generated directly from the schema and examples taken from running code 
generated from the same schema" - can you perhaps give a specific reference?

And can you say just a tad more about the representation of the schema, 
your tool chain, and process?  (Without taking a really deep dive, what 
I surmise is that the Goedel tools can ingest ASN and generate code - am 
I reading that correctly?)


>
>> Beyond that, the point of a specification is to DRIVE implementation &
>> testing of multiple, interoperable implementations.  A reference
>> implementation is one thing, but as soon as one specific piece of code
>> (warts & all) becomes the "spec" - it's not really a specification anymore.
> Reference code is not necessarily the same as production. Production
> code should be conservative in what it sends and liberal in what it
> accepts. Reference code should be the other way round. It should
> complain when the sender fails to abide by the strict specification.

Now that is a very good point - well worth remembering.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra