Re: L7 protocol design

Joe Touch <> Wed, 04 January 2017 18:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDDCB129A29 for <>; Wed, 4 Jan 2017 10:46:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10
X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xbe29A-RbpZd for <>; Wed, 4 Jan 2017 10:46:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FFBD129A1C for <>; Wed, 4 Jan 2017 10:46:01 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v04Iivm0005784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Jan 2017 10:44:58 -0800 (PST)
Subject: Re: L7 protocol design
To: Philippe Duke <>,
References: <>
From: Joe Touch <>
Message-ID: <>
Date: Wed, 4 Jan 2017 10:44:58 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Jan 2017 18:46:03 -0000

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

        -- 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

        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.


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.