Re: Observations on (non-technical) changes affecting IETF operations

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Mar 9, 2016 at 5:16 AM, Dirk Kutscher <[e-mail]> wrote:
> Hi,
>
> good discussion starter.
>
> Two comments:
>
> 1) Open Source / Hackathon:
>
> The objective of the IETF should IMO be to develop open, high-quality specifications (in a timely manner...). We have been working with running code for ensuring implementability and interoperability. That's still a good thing, however, we could think about how we can make better use of Open Source for the specification process. (Following up on Dave Ward's lunch presentation some IETF meetings back.)
>
> For example, some IRTF RGs are working with reference implementations (of their core protocols) to promote experimentation, more research, future adoption.
>
> Would it make sense to promote similar models for the protocol specification process in IETF WGs (beyond the Hackathon concept)?


Over the past few years, I have been assembling tools that allow me to
automate different part of the standards writing process.

Last week, I used them to produce a first draft for a proposal for a
LURK protocol. In three days, I produced:

1) A draft describing the protocol
   a) Text describing protocol
   b) Examples from running code
   c) Reference section
2) Reference implementation

The code generator I use targets C# by default as it has many
advantages when using code generation tools over Java. But it can also
generate C code for production use.

The tools are all on GitHub and SourceForge under PHB Build Tools. The
draft is here:

https://tools.ietf.org/html/draft-hallambaker-lurk-00


One important side effect of this work is that the specs are a lot
more consistent and a lot more flexible than those created the hard
way, by hand. If someone wants to have the protocol in XML rather than
JSON, I can do that. Or I can do ASN.1 or TLS Schema or CBOR. If
someone wants a code library in PHP or a particular flavor of C++, no
problem, just write your own output scripts.

Another advantage is that it encourages you to factor out pieces that
can be used as common modules in other application layer protocols.

This is what WS-* should have been. All the functionality but without
the complexity.