ietf
[Top] [All Lists]

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

2016-03-20 13:52:20
On Wed, Mar 9, 2016 at 5:16 AM, Dirk Kutscher 
<Dirk(_dot_)Kutscher(_at_)neclab(_dot_)eu> 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.


<Prev in Thread] Current Thread [Next in Thread>