Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
draft-ietf-manet-packetbb-17

>   <msg-hop-count>  is omitted if the mnohopcount bit is set ('1'),
>      otherwise is an 8 bit field, which contains the number of logical
>      hops that the message has traveled. (<msg-hop-count> SHOULD be
>      incremented if the message is forwarded.)

If msg-hop-count is missing, should it be added if the message is
forwarded?

>   A protocol using this specification, or any future version (i.e.
>   where pkt-version or msg-version are different from zero) of this
>   specification MUST specify appropriate behavior in the case where an
>   incoming packet or message indicates a pkt-version or msg-version
>   different from the one used by that protocol, e.g. by discarding the
>   packet or message.

To help both consumers of this format and reviewers of proposals
consuming this format, it would be good to collect or summarize
requirements like this into a separate section listing requirements for
consumers of the format.  This was one of the problems we had to fix
when updating RFC 2222 to 4422, for example.

>   A new registry for message types must be created with initial
>   assignments as specified in Table 6.

This should state the title of the IANA registry, for example: "MANET
Message Types".

>   values 0-7  - MUST NOT be assigned except when a documented need

You might want to apply equivalent rules to values 120-127 for things
that best appear at the end (e.g. a signature).


Some design issues that concern me:

* The format has lots of options.  Take the packet header, for example. 
Excluding the optional TLV block, there are more than 9 different packet
header encoding options (including optional padding and omitting the
entire packet header).  It seems to me that 3 encoding options would
suffice (omit, 32-bit, 64-bit) and the result would be simpler and might
remove the need for optional padding.  Similar analysis could be
performed for the message header format.

* Creating two different ways to encode the same thing is always risky. 
I can omit the size field or I can have a zero size field and they mean
the same thing.  Padding can be variable.  This can have a negative
impact on security filters, signatures and other
canoncialization-sensitive operations.  It can also create
interoperability problems.

* The TLV index feature is really a layering violation in the encoding
as it's only meaningful in one of the TLV contexts.  A better design
would include the index numbers as an additional layer for addr-block
TLVs rather than embed them in the otherwise generic TLV syntax.

* I'm concerned that limiting the sequence number to 16 bits is choosing
conciseness over reality.  I believe we've found 32-bit sequence numbers
for TCP problematic for high-speed scenarios.  And the security
implications of sequence numbers at lower levels of the network stack
are non-trivial.

Given that I dislike most of the proposal for excessive complexity,
I'll mention the things I like: clear separation between packet
header/content and message header/content (reminds me of email
envelope/header/body), a TLV model for extensibility is fine, the
TLV ordering compromise seems reasonable to me, and I can see
benefits to the multi-message and address block approaches.  Most of
the other complexity seems excessive and unjustified.

I am actually wondering whether it would not be better that documents that a Gen-ART (or security, or other) review declare non-fit for IESG discussion first address the review issues and only then be placed on an  IESG telechat agenda.

The document has been improved since I made the below comments but not all are resolved so I will leave them. 

This document has so many bugs related its design that it really should go back to the WG for rehashing. Some issue to consider that are evident:
- Lack of default values for optional fields that in fact seems mandatory
- Version extension rules lacks requirement on what fields may not be changed when changing version. 
- Unnecessary complexities from lack of willingness to determine what is important and what is not.
- Message Sequence number with unclear definition where part of the text allows any generation, but with uniqueness and the other talks about wrapping. In other words non combinable properties.

1. As a general comment, I appreciate the thought and hard work that obviously went into abstracting this "framework" for a MANET protocol. However, I question if the pendulum has been swung too far in that direction. There are a number of cases where MANETs are called out as a fairly "special" application in terms of being often low-power, concerned about time intervals, odd MTU sizes, etc. As such I think a simpler, very targeted, protocol would have been more useful to the community, and your application space. Even if that meant that you had two or three different protocols that didn't share a common "protocol framework" between the 3 as specified in this document. This is a judgment call, somewhat subjective, and easy to say in hindsight... Which is why I only register it as a "comment."

2. In your ASCII art of packet formats (which I personally prefer over the 'language' version in the document body), when you have optional fields you could get rid of a lot of pages by simply listing the version with all fields present, and an "opt" by those which are in fact optional. So, Section D.2 would become simply something like:


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |W|X|Y|Z|C| Rsv |         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Originator Address (opt)                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Hop Limit (opt)| Hop Count(opt)| Message Sequence Number (opt) |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And then stating that the field is present based on the named bit-fields (WXYZ in my case, but could be anything).

I support Lars' comment about multiplexing, but don't think that it is a big enough issue to motivate an abstention. The multiplexing strategy described in Appendix A makes the MANET difficult to implement, but I don't think that it does any real harm to the Internet.