Subject: Re: L7 protocol design

From: Joe Touch <[email-masked]>
Date: Wed, 4 Jan 2017 10:44:58 -0800

Hi, Phillipe (et al.),

I'm not aware of a recommended approach, but I tend to follow that of
TCP (RFC793), e.g., define as follows:

    - the upper layer API in *abstract* terms (not as a Unix socket
interface)

        -- this includes both events initiated by the "user" above as
well as events initiated by this service

    - the internal states

    - the messages and their formats (e.g., headers, etc.)

    - the lower layer API expected by this service, e.g., a set of
requirements for L6 (or L4if there are no L6 or L5)

    - a state transition matrix, e.g., mapping:

        [internal state, input event] -> [new internal state, output
event(s)]

        where input events can be receipt of a message from L6, an
action of the upper layer (user), and/or a timer expires

        and output events can be sending a message to L6, signalling the
upper layer (user), and/or setting a timer

Some of the items you mention below are part of this description, e.g.,
transport (UDP/TCP) would be part of the L6 or L4 description, sequence
control is the state transition matrix, and some of the other issues are
part of the API.

I'm wondering if this sort of "what defines a protocol" description
would be useful - if so, I can prepare it in more detail.

Joe

On 12/28/2016 1:57 AM, Philippe Duke wrote:
> Hello, dear IETF community. I would like to develop L7 protocol for my
> application and public documentation about it. Good protocol development
> is quite difficult stage, but not a problem. But at the same time, I
> don't have any experience writing protocol documentations (RFC's).
>
> What guidelines do you have?
>
> Is the RFC 4253 (SSH) good example of document design? Should I follow
> same principle?
>
>
> Please give me some examples how to make it correct. Even examples of
> very simple protocols.
>
> What I need as requirements:
>
>     TCP/UDP transport
>
>     Authentication
>
>     Encryption
>
>     Sequence control
>
> My protocol would carry small status messages like (10-20 bytes with
> timestamps and some sort of sequence synchronization).
>
>
> Thank you very much for your answers. Sorry for posting into the general
> list.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Jan 2017 14:08:30 -0500

The documentation is not yet complete and it is not yet capable of
supporting the new RFC format but you might be interested in the ProtoGen
toolset I developed to develop the Mathematical Mesh.

http://prismproof.org/

The tools and support libraries are all open source and available from the
following GitHub repository

https://github.com/hallambaker/PHB-Build-Tools

My preferred development environment is Visual Studio on Windows. But the
tools automate the generation of Makefiles for Linux from the Visual Studio
project which allows for cross platform code generation. To cross develop
from other IDEs or from a Linux box is possible if you extend the tool.

ProtoGen takes an abstract definition of a Web Service and converts it into
documentation and running code. The code is currently intended for use as
reference code and to generate examples and test cases. It could be used in
production but has not been optimized for that environment yet.

At present, the synthesizer generates code for a HTTP/HTTPS Web Service
using JSON encoding and conforms to at least some definitions of 'REST'.
The support libraries also support ASN.1, TLS Schema and XML but the synth
is not currently configured to support alternative encodings.

The current language target is C# but a previous iteration did support C.

On Wed, Dec 28, 2016 at 4:57 AM, Philippe Duke <[email-masked]>
wrote:

> --
> Philippe Duke
> Network software engineer
> System-level developer
>
> NetAssist LLC
> Ukraine
> Khreshchatyk Street, 10B, office 8
> AS29632
>
> http://netassist.ua
> Our GitHub Repository:
> https://github.com/netassist-ua
>
>
>