Re: L7 protocol design

Joe Touch <touch@isi.edu> Wed, 04 January 2017 18:46 UTC

Return-Path: <touch@isi.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDCB129A29 for <ietf@ietfa.amsl.com>; Wed, 4 Jan 2017 10:46:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbe29A-RbpZd for <ietf@ietfa.amsl.com>; Wed, 4 Jan 2017 10:46:01 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFBD129A1C for <ietf@ietf.org>; Wed, 4 Jan 2017 10:46:01 -0800 (PST)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (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 <philippe46@netassist.ua>, ietf@ietf.org
References: <8f94c005-e27f-c81f-01e5-8ae4dea66f79@netassist.ua>
From: Joe Touch <touch@isi.edu>
Message-ID: <fb805b07-40ff-07c3-7418-2bea24759c67@isi.edu>
Date: Wed, 04 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: <8f94c005-e27f-c81f-01e5-8ae4dea66f79@netassist.ua>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/G-7uyVGlIZ2S5KBSbR25MiFmhRc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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
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.
>