Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
RFC 5444

Note: This ballot was opened for revision 17 and is now closed.

(Ross Callon) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

Comment (2008-09-24 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Pasi Eronen) No Objection

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) No Objection

(Chris Newman) (was Discuss) No Objection

Comment (2008-03-12)
No email
send info
>   <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

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

(Tim Polk) (was No Record, Discuss, No Record, Discuss) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2008-01-24)
No email
send info

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.

(Mark Townsley) (was Discuss) No Objection

Comment (2008-09-25)
No email
send info
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).

Magnus Westerlund (was Discuss) No Objection

Comment (2008-09-25)
No email
send info
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.

(Lars Eggert) (was Discuss) Abstain

Comment (2008-09-23)
No email
send info
I still disagree with the design philosophy behind this packet format, but since this isn't actionable this late in the game, I'll abstain.

I also don't believe the multiplexing and demultiplexing approach in Appendix A is fully thought through, especially in light of the IANA actions for MANET. If all MANET daemons on one node share a port, and if packets destined to that port can contain messages that need to be delivered to different routing daemons (and some that need to be delivered to multiple daemons), who performs this demultiplexing and how? I'd have MUCH preferred to do the usual thing and assign one port per MANET protocol, but the authors refused.

(David Ward) (was Discuss) Abstain