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