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

[Ballot discuss]
The WG did not incorporate my comments that I gave them during earlier review. This discussion goes back to pre-Vancouver IETF:

Section 5.4.2 has to be one of the most confusing sections of a document that I've written. I know there has been infinite debate but, there just aren't enough words to understand what the point of all the shenanigans is all about. There is a strong whiff of implementation specifics that has no real bearing on what is required for interoperable implementations. Either make it mandatory and explain yourself or relax it massively and suggest that there are good implementation reasons to do it "this way." Note that I work with a lot of TLV based protocols and TLV parsing HW, I know exactly how expensive it is and isn't :-)

I know it is painful to revisit that section but, fresh eyes and pens need to be put on it.

Section 5.5 is incomplete. You have to say that Malformed elements can or cannot be discarded and TLVs beyond the malformed element should or must be discarded (imagine if the length was wrong in a TLV ... you are hosed). Is retrans to be expected? Can you get into an infinite loop? You need more here.

[Ballot comment]
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.

[Ballot comment]
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).

[Ballot discuss]
"All addresses within a message are assumed to be of the same size, deduced from the IP header."

I see two problems with this. First, an implementation must know when it is building the protocol message whether it is actually going to be transmitted on an IPv6 link. Second, that after receipt of a protocol packet, the receiving interface (which of course may be physical or virtual) must pass up to the routing application what IP version the packet arrived on.

In general, the IPv4 to IPv6 transition is not going to be clean. We are evaluating proposals that translate IPv4 packets into IPv6 packets and vice-versa, and others that "munge" IPv4 headers alone into IPv6 headers stuck on what are otherwise IPv4 packets. Even in cases of simple tunneling of IPv4/IPv6 or vice-versa, if the tunnel endpoint and the router are the same entity, the implementation will have to be *very* careful to use the most recent virtual interface in the decapsulation process to pass the version number up to the application rather than that received from the interface driver (which in a well-architected tunnel implementation where virtual interfaces are just as "real" as physical interfaces to the various APIs above this would be OK, but my experience is that this is not always the case in the real world).

This being the case, and given that the overall goal of this protocol framework is to be rather generic and extensible to a variety of applications, I'd say that this decision will not help with creating interoperable implementations in mixed IP version environments. Further, so many other parts of this specification are written with such  attention at generality and extensibility, it seems odd that you wouldn't leave the door open to using the protocol for address formats other than IPv4 and IPv6. In general, all of these problems would be solved if the address block would simply have a version associated with it (explicitly, or as part of a TLV wrapper, it doesn't really matter much - just that the parsing code can know, relatively "nearby" to the address block itself, what is actually contained in that address block).

What you have will obviously work, but I suspect it is setting yourself up for interop problems, could be part of a list of things that are broken when IPv4 and IPv6 coexist, etc. Also, it reduces the "general and extensible" nature of what it seems like you were trying to do here. For example, this claim is made:

>    Separation of forwarding and processing -  A protocol using this
>      specification can be designed such that duplicate detection and
>      controlled scope message forwarding decisions can be made using
>      information contained in the message header, without processing
>      the message body.

However, processing of and creation of the message body itself is actually tied to the IP header. I understand that this isn't precisely the same thing as above (the "message header" is not the "IP header"), but in principle this statement and the design choice linking the IP version in the IP header to the format of the address block in the message body seem at odds.

IANA Evaluation questions/comments:

[ IESG Note: Expert Reviewer Assignment Required ]

IANA has questions:

- Do you want a registry for pkt-flags in section 5.1?
- Do you want a registry for msg-flags in section 5.2?
- Do you want a registry for addr-flags in section 5.3?
- Do you want a registry for tlv-flags in section 5.4.1?

Action 1 (Section 6.2):

Upon approval of this document, the IANA will create the following
registry "Message Types" located at http://www.iana.org/assignments/TBD

o Registration of a message type implies creation of two registries
for message type specific message TLVs and message type specific
address block TLVs. The document which requests the registration
of the message type MUST indicate how these message type specific
TLV types are to be allocated, from any options in [BCP26], and
any initial allocations. The Designated Expert SHOULD take the
allocation policies specified for these registries into
consideration in reviewing the message type allocation request.

Allocation Policy: Expert Review
Initial contents of this registry will be:

Type Description Reference
---- ----------- ---------
0-223 Unassigned [RFC-manet-packetbb-15]
224-255 Experimental Use [RFC-manet-packetbb-15]


Action 2 (Section 6.3):

Upon approval of this document, the IANA will create the following
registry "Packet TLV Types" located at http://www.iana.org/assignments/TBD

o These are Hierarchical Allocations, allocation of a type creates a
registry for the extended types corresponding to that type. The
document which requests the registration of the type MUST indicate
how these extended types are to be allocated, from any options in
[BCP26], and any initial allocations. Normally this allocation
should also be Expert Review, but with the possible allocation of
some type extensions as Reserved, Experimental and/or Private.

o TLV type values 0-7 MUST NOT be registered except when a
documented need exists that TLVs of a given type are required to
appear before all other TLVs in the TLV block as encoded for
transmission. Note that the need for a TLV to be processed before
other TLVs does not however automatically translate into a need
for the TLV to appear before all other TLVs in the TLV block (the
order in which TLVs are to be processed MUST be defined, if
applicable, in the protocols using this specification).

o The request for a TLV type MUST include the specification of the
permitted size, syntax of any internal structure of, and meaning
of, the value field (if any) of the TLV.

Allocation Policy: Expert Review
Initial contents of this registry will be:

Type Description Reference
---- ----------- ---------
0-223 Unassigned [RFC-manet-packetbb-15]
224-255 Experimental Use [RFC-manet-packetbb-15]


Action 3 (Section 6.4):

Upon approval of this document, the IANA will create the following
registry "Message TLV Types" located at http://www.iana.org/assignments/TBD

o These are Hierarchical Allocations, allocation of a type creates a
registry for the extended types corresponding to that type. The
document which requests the registration of the type MUST indicate
how these extended types are to be allocated, from any options in
[BCP26], and any initial allocations. Normally this allocation
should also be Expert Review, but with the possible allocation of
some type extensions as Reserved, Experimental and/or Private.

o TLV type values 0-7 MUST NOT be registered except when a
documented need exists that TLVs of a given type are required to
appear before all other TLVs in the TLV block as encoded for
transmission. Note that the need for a TLV to be processed before
other TLVs does not however automatically translate into a need
for the TLV to appear before all other TLVs in the TLV block (the
order in which TLVs are to be processed MUST be defined, if
applicable, in the protocols using this specification).

o The request for a TLV type MUST include the specification of the
permitted size, syntax of any internal structure of, and meaning
of, the value field (if any) of the TLV.

o TLV type values 0-127 are common for all message types. TLVs
which receive registrations from the 0-127 interval SHOULD be
modular in design to allow reuse among protocols.

o TLV type values 128-223 are message type specific TLV type values,
relevant only in the context of the containing message type.
Registration of TLV type values within the 128-223 interval
requires that a registry in the 128-223 interval exists for a
specific message type value (see Section 6.2.1), and registrations
are made in accordance with the allocation policies specified for
these message type specific registries. Message type specific TLV
types SHOULD be registered for TLVs which the Designated Expert
deems too message type specific for registration of a 0-127 value.
Multiple different TLV definitions MAY be assigned the same TLV
type value within the 128-223 interval, given that they are
associated with different message type specific TLV type
registries. Where possible, existing global TLV definitions and
modular global TLV definitions for registration in the 0-127 range
SHOULD be used.

Allocation Policy: Expert Review
Initial contents of this registry will be:

Type Description Reference
---- ----------- ---------
0-127 Unassigned [RFC-manet-packetbb-15]
128-223 Message Type Specific [RFC-manet-packetbb-15]
224-255 Experimental Use [RFC-manet-packetbb-15]


Action 4 (Section 6.5):

Upon approval of this document, the IANA will create the following
registry "Address Block TLV Types" located at http://www.iana.org/assignments/TBD

o These are Hierarchical Allocations, allocation of a type creates a
registry for the extended types corresponding to that type. The
document which requests the registration of the type MUST indicate
how these extended types are to be allocated, from any options in
[BCP26], and any initial allocations. Normally this allocation
should also be Expert Review, but with the possible allocation of
some type extensions as Reserved, Experimental and/or Private.

o TLV type values 0-7 MUST NOT be registered except when a
documented need exists that TLVs of a given type are required to
appear before all other TLVs in the TLV block as encoded for
transmission. Note that the need for a TLV to be processed before
other TLVs does not however automatically translate into a need
for the TLV to appear before all other TLVs in the TLV block (the
order in which TLVs are to be processed MUST be defined, if
applicable, in the protocols using this specification).

o The request for a TLV type MUST include the specification of the
permitted size, syntax of any internal structure of, and meaning
of, the value field (if any) of the TLV.

o TLV type values 0-127 are common for all message types. TLVs
which receive registrations from the 0-127 interval SHOULD be
modular in design to allow reuse among protocols.

o TLV type values 128-223 are message type specific TLV type values,
relevant only in the context of the containing message type.
Registration of TLV type values within the 128-223 interval
requires that a registry in the 128-223 interval exists for a
specific message type value (see Section 6.2.1), and registrations
are made in accordance with the allocation policies specified for
these message type specific registries. Message type specific TLV
types SHOULD be registered for TLVs which the Designated Expert
deems too message type specific for registration of a 0-127 value.
Multiple different TLV definitions MAY be assigned the same TLV
type value within the 128-223 interval, given that they are
associated with different message type specific TLV type
registries. Where possible, existing global TLV definitions and
modular global TLV definitions for registration in the 0-127 range
SHOULD be used.

Allocation Policy: Expert Review
Initial contents of this registry will be:

Type Description Reference
---- ----------- ---------
0-127 Unassigned [RFC-manet-packetbb-15]
128-223 Message Type Specific [RFC-manet-packetbb-15]
224-255 Experimental Use [RFC-manet-packetbb-15]


We understand the above to be the only IANA Actions for this document.

[Ballot comment]
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.

[Ballot comment]
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 protocol difficult to implement, but I don't think that it does any real harm to the Internet.

[Ballot comment]
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.

[Ballot comment]
>    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. ( 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.

[Ballot discuss]
Revision -12 resolved my byte order interoperability concern, but does
not resolve my concern about the security considerations section:

>  This specification does not describe a protocol; it describes a
>  packet format.  As such it does not specify any security
>  considerations, these are matters for a protocol using this
>  specification.

I disagree with this statement.  Security is systemic and a data format
is just as likely to introduce security concerns as a protocol.  This
format, for example, provides different ways to encode semantically
identical meanings.  Any mechanism to sign or checksum the format may
have to accommodate that.  That is a security consideration introduced
by the data format.

[Ballot discuss]
Revision -12 resolved my byte order interoperability concern, but does
not resolve my concern about the security considerations section:

>  This specification does not describe a protocol; it describes a
>  packet format.  As such it does not specify any security
>  considerations, these are matters for a protocol using this
>  specification.

I disagree with this statement.  Security is systemic and a data format
is just as likely to introduce security concerns as a protocol.  This
format, for example, provides different ways to encode semantically
identical meanings.  Any mechanism to sign or checksum the format may
have to accommodate that.  That is a security consideration introduced
by the data format.

[Ballot discuss]
The Security Considerations section needs to be expanded a bit.  While this specification
describes a packet format, rather than a protocol, decisions made in this specification
have a strong impact the design of the protocol especially with respect to security services.

As I understand it, this packet format does not include any intrinsic security features.  The
format can be extended to support authentication and integrity by including a TLV with a
digital signature or a message authentication code (MAC).  [I was really pleased to see the
concise description of signature calculation, BTW.  That is very helpful information to future
protcol designers!]  The format can't really be extended to provide confidentiality for the
packet, so if this service is required it must be provided at another layer.  I haven't thought
this one through, but I guess it is possible to specify a TLV with an encrypted value if the
entire packet doesn't need to be protected? 

Anyway, some text that explains what has been left up to the protocol designer, and some
thoughts about their choices, would be appropriate.

[Ballot discuss]
The Security Considerations section needs to be expanded a bit.  While this specification
describes a packet format, rather than a protocol, decisions made in this specification
have a strong impact the design of the protocol especially with respect to security services.

As I understand it, this packet format does not include any intrinsic security features.  The
format can be extended to support authentication and integrity by including a TLV with a
digital signature or a message authentication code (MAC).  [I was really pleased to see the
concise description of signature calculation, BTW.  That is very helpful information to future
protcol designers!]  The format can't really be extended to provide confidentiality for the
packet, so if this service is required it must be provided at another layer.  I haven't thought
this one through, but I guess it is possible to specify a TLV with an encrypted value if the
entire packet doesn't need to be protected? 

Anyway, some text that explains what has been left up to the protocol designer, and some
thoughts about their choices, would be appropriate.

[Ballot comment]
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.

IESG internal process comment:

I have to agree with Dan here. It is the work of the responsible A to not place documents on the IESG agenda that are not ready in the AD's view. That means following up on reviews in WG last call. Yes, in this case the Gen-art review was two days late.

[Ballot comment]
IESG internal process comment:

I have to agree with Dan here. It is the work of the responsible A to not place documents on the IESG agenda that are not ready in the AD's view. That means following up on reviews in WG last call. Yes, in this case the Gen-art review was two days late.

[Ballot discuss]
I don't think this document is using a syntax describing format that is well enough defined. I would like to point at the following IESG statement:

http://www.ietf.org/IESG/STATEMENTS/syntax-format-def.txt

[Ballot comment]
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.

[Ballot discuss]
The Gen-ART review and the DISCUSS from Lars showed many problems with the format and content of this document that prevent me to support its aprroval. In any case together with addressing the issues in these DISCUSSes I would like to see text presenting a clear analysis and justification of why defining the multi-messages format is needed and what are the advantages of using it. I would also suggest that the Abstract section is re-edited, its current format seems to indicate a scope that is even beyond MANET, and I do not believe that this was or should be the intent.

[Ballot comment]
> 2.  Terminology

I suggest calling this section:

"Terminology and Notation"

or

"Terminology and Regular Expression Notation"

To make it clearer the regular expression syntax is defined here.


The document never defines the '{' '}' notation used in the "regular
expressions".  For clarity I recommend adding them to section 2 or
normatively referencing a regular expression specification from which
the symbols are imported.

>      bits 5-7:  are RESERVED, and MUST each be cleared ('0') to be in
>        conformance with this version of the specification.

Do you really want an implementation which uses an extension that
defines meaning for these bits to be non-compliant with this
specification?  Perhaps say: these bits MUST be cleared ('0') by all
implementations until a subsequent IESG approved RFC gives them meaning.

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

>  The padding after a message may be freely changed when a message is
>  forwarded without affecting the message.

"The padding" -> "The amount of padding"

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

[Ballot discuss]
>    is omitted if the phassize bit is cleared ('0'),
>    otherwise is a 16 bit field, specifying the size of the
>    counted in octets.

The document has failed to specify a byte ordering for this (or other
non-octet) fields.  As a result, the format will not interoperate
between implementations that choose different endians.  Suggested
resolution: state that the format uses network byte order for all
fields.

>  This specification does not describe a protocol; it describes a
>  packet format.  As such it does not specify any security
>  considerations, these are matters for a protocol using this
>  specification.

I disagree with this statement.  Security is systemic and a data format
is just as likely to introduce security concerns as a protocol.  This
format, for example, provides different ways to encode semantically
identical meanings.  Any mechanism to sign or checksum the format may
have to accommodate that.

[Ballot discuss]
I think the packet format defined in this document is MUCH too complex for the given domain. Where is the gain from using the same packet format for different MANET routing protocols, given that the processing is all different? Defining a common packet format introduces complexity and space overhead that wouldn't be there if each protocol defined its own, minimal messages. The packet format then adds even more parsing/processing complexity, in order to reduce the space requirements that to a large part stem from defining a general packet format. (Since this isn't really actionable, I expect to move to an ABSTAIN after my DISCUSS is resolved.)

> This document enumerates several common IANA allocations for use by
> one or more protocols that conform to [I-D.ietf-manet-packetbb].
> The following well-known numbers are required: a UDP port number, an
> IP protocol number, and a link-local multicast group address.  All
> interoperable protocols running on these well-known IANA allocations
> MUST conform to [I-D.ietf-manet-packetbb].
> [I-D.ietf-manet-packetbb] provides a common format that enables one
> or more protocols to share the IANA allocations defined in this
> document unambiguously.

DISCUSS: The above text is from draft-ietf-manet-iana. It remains
unclear to me exactly how the specification in
draft-ietf-manet-packetbb achieves the stated goal. For example, how
does the common packet format allow two MANET routing
implementations to share the same UDP port?



Section 1., paragraph 1:
> All syntactical entities, including packets and messages,
> are specified using regular expressions.

  DISCUSS: Must reference a particular regular expression scheme, or
  define one in this document (but please rather reuse and cite an
  existing one.) Section 2 includes the beginnings of such a definition,
  but isn't complete; for example, it doesn't define the grouping
  through {} used in Section 3. (Also, ABNF is much more common for IETF
  documents and has automated validation tools.)


Section 5.3., paragraph 2:
> 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.

  DISCUSS: This is impossible, because pkt-version and msg-version are
  defined as optional to include. To make this work, they need to be
  required in all packets and messages.


Section 5.4., paragraph 0:
> 5.4.  Address Blocks

  DISCUSS: Given that the examples in appendix A.1 illustrate that the
  size reduction achived by the proposed encoding is small (or even
  non-existent), I question the need for such a complex scheme.

[Ballot discuss]
I think the packet format defined in this document is MUCH too complex for the given domain. Where is the gain from using the same packet format for different MANET routing protocols, given that the processing is all different? Defining a common packet format introduces complexity and space overhead that wouldn't be there if each protocol defined its own, minimal messages. The packet format then adds even more parsing/processing complexity, in order to reduce the space requirements that to a large part stem from defining a general packet format. (Since this isn't really actionable, I expect to move to an ABSTAIN after my DISCUSS is resolved.)

> This document enumerates several common IANA allocations for use by
> one or more protocols that conform to [I-D.ietf-manet-packetbb].
> The following well-known numbers are required: a UDP port number, an
> IP protocol number, and a link-local multicast group address.  All
> interoperable protocols running on these well-known IANA allocations
> MUST conform to [I-D.ietf-manet-packetbb].
> [I-D.ietf-manet-packetbb] provides a common format that enables one
> or more protocols to share the IANA allocations defined in this
> document unambiguously.

DISCUSS: The above text is from draft-ietf-manet-iana. I remains
unclear to me exactly how the specification in
draft-ietf-manet-packetbb achieves the stated goal. For example, how
does the common packet format allow two MANET routing
implementations to share the same UDP port?



Section 1., paragraph 1:
> All syntactical entities, including packets and messages,
> are specified using regular expressions.

  DISCUSS: Must reference a particular regular expression scheme, or
  define one in this document (but please rather reuse and cite an
  existing one.) Section 2 includes the beginnings of such a definition,
  but isn't complete; for example, it doesn't define the grouping
  through {} used in Section 3. (Also, ABNF is much more common for IETF
  documents and has automated validation tools.)


Section 5.3., paragraph 2:
> 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.

  DISCUSS: This is impossible, because pkt-version and msg-version are
  defined as optional to include. To make this work, they need to be
  required in all packets and messages.


Section 5.4., paragraph 0:
> 5.4.  Address Blocks

  DISCUSS: Given that the examples in appendix A.1 illustrate that the
  size reduction achived by the proposed encoding is small (or even
  non-existent), I question the need for such a complex scheme.

[Ballot comment]
Section 2., paragraph 0:
> 2.  Terminology

  The definition of some terms (packet, message, etc.) defines how
  packets are or aren't processed, for which a packet format
  specification is the wrong place - this should be defined in the
  protocol documents that use the packet format.


Section 5., paragraph 1:
> This section provides syntactical specification of a packet,

  "Signaling Framework" is hence an odd name for this section.


Section 5.1., paragraph 3:
> A packet MUST
> contain either a  or at least one .

  If that's the case, the regular expression should express this.


Section 5.2., paragraph 22:
>      If bit 1 (mnoorig) and bit 4 (mnoseqnum) are both cleared, then
>      the message header provides for duplicate suppression.

  I don't understand how this is supposed to work - please elaborate.


Section 5.2., paragraph 23:
>      If bit 2 (mnohoplimit) is cleared, then the message header
>      provides for scope-delimited forwarding.

  I don't understand how this is supposed to work - please elaborate.


Section 5.2., paragraph 27:
>      ( SHOULD be decremented if the message is
>      forwarded.)

  Defines processing, not format.


Section 5.2., paragraph 28:
>      ( SHOULD be
>      incremented if the message is forwarded.)

  Defines processing, not format.


Section 5.2., paragraph 29:
>  is omitted if the mnoseqnum bit is set ('1'),
>    otherwise is a 16 bit field, which contains a unique number,
>    generated by the message's originator node.  The ,
>    , and, if the mistypedep bit in the
>    field is set, the  of a message serves to uniquely
>    identify the message in the network (within the time period until
>    wraps around to a matching value).

  If msg-seq-num is a unique number, it alone is sufficient to identify
  a message and the other fields aren't needed. Also, a 16-bit field can
  wrap around *very* quickly.


Section 5.5.1., paragraph 5:
>    *  all addresses in the address block; OR
>    *  any continuous sequence of addresses in the address block; OR
>    *  a single address in the address block.

  More complexity. Instead of sticking a TLV into an address block and
  then needing to indicate which addresses it applies to, why not stick
  an address block into the value of the TLV that explicitly states
  which addresses the TLV applies to?


Section 5.5.1., paragraph 12:
>    bit 1 (thasextlen) and bit 2 (tnovalue):  MUST NOT both be set
>      ('1').  Otherwise, they are interpreted according to Table 3.

  Are bits really so expensive that we need this complexity to save 7 of
  them for short TLVs?


Section 5.5.2., paragraph 7:
>    Note that the above constrains only the encoding of TLVs in a TLV
>    block for transmission, and do specifically NOT mandate any given
>    order of processing or interpretation by a protocol of the TLVs and
>    the entities to which these are associated.

  If the processing order can be different from the encoding order (and
  remains undefined), why is it important to define the encoding order
  and especially options that permit different encoding orders?


Section 5.7., paragraph 0:
> 5.7.  Padding

  This definition mixes regular expression semantics (refers to the size
  of the preceding element) with packet format semantics (all bits
  zero), which is confusing. (This may be an indication that regular
  expressions are the wrong language for the job.)


Section 6.1., paragraph 1:
>  Additionally,
>  values in the range 128-255 are reserved for private/local use.

  Private/local use not indicated in Table 6.


Section 6.1., paragraph 4:
>    Message types 1
>    to 4 are reserved because they are used by OLSR [4], which uses a
>    compatible packet/message header format.

  Since [4] apparently doesn't define a registry and this document does,
  it needs to populate the registry with each value from [4].


Section 6.2., paragraph 3:
>    values 0-7  - MUST NOT be assigned except when a documented need
>      exists that TLVs of a given type are required to appear before all
>      other TLVs in the TLV block as encoded for transmission.  Note
>      that the need for a TLV to be processed before other TLVs does not
>      however automatically translate into a need for the TLV to appear
>      before all other TLVs in the TLV block - the order in which TLVs
>      are to be processed MUST be defined, if applicable, in the
>      protocols using this specification.

  This still leaves me confused with reagrds to processing and encoding
  orders. (I have the same issue below with similar text for other
  TLV types.)


Section 7.1., paragraph 0:
> 7.1.  Security Suggestions

  The text below uses "security" where it probably should use
  "authentication", since the text doesn't discuss encryption at all.


Appendix B., paragraph 0:
> Appendix B.  Illustrations

  I don't think these illustrations add much to the document - suggest
  to cut.

[Ballot discuss]
I think the packet format defined in this document is MUCH too complex for the given domain. Where is the gain from using the same packet format for different MANET routing protocols, given that the processing is all different? Defining a common packet format introduces complexity and space overhead that wouldn't be there if each protocol defined its own, minimal messages. The packet format then adds even more parsing/processing complexity, in order to reduce the space requirements that to a large part stem from defining a general packet format. (Since this isn't really actionable, I expect to move to an ABSTAIN after my DISCUSS is resolved.)

Section 1., paragraph 1:
> All syntactical entities, including packets and messages,
> are specified using regular expressions.

  DISCUSS: Must reference a particular regular expression scheme, or
  define one in this document (but please rather reuse and cite an
  existing one.) Section 2 includes the beginnings of such a definition,
  but isn't complete; for example, it doesn't define the grouping
  through {} used in Section 3. (Also, ABNF is much more common for IETF
  documents and has automated validation tools.)


Section 5.3., paragraph 2:
> 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.

  DISCUSS: This is impossible, because pkt-version and msg-version are
  defined as optional to include. To make this work, they need to be
  required in all packets and messages.


Section 5.4., paragraph 0:
> 5.4.  Address Blocks

  DISCUSS: Given that the examples in appendix A.1 illustrate that the
  size reduction achived by the proposed encoding is small (or even
  non-existent), I question the need for such a complex scheme.

[Ballot discuss]
Elwyn Davies wrote a very critical Gen-ART Review, but there has not
  been a response to it.  The review can be found at:

    http://www.alvestrand.no/ietf/gen/reviews/
    draft-ietf-manet-packetbb-11-davies.txt

  While I do not expect the authors to agree with all of the concerns
  that are raised by Elwyn, I do expect to see a response, which may
  lead to a discussion.

IANA Last Call comments:


[ Note: Nowhere in the document is MANET defined or expanded as
an acronym. ]

[ Should the bits in  in section 5.1 have a registry?]

[ Should the bits in  and  in section
5.2 have registries? ]

[ Should the bits in  in section 5.4 have a registry? ]

[ Should the bits in  in section 5.5.1 have a registry? ]



Action 1 (Section 6.1):

Upon approval of this document, the IANA will create the following
registry "Message Types" located at http://www.iana.org/assignments/TBD
Allocation Policy: standards action
Initial contents of this registry will be:

Type Description Reference
---- ----------- ---------
0 MUST NOT be allocated [RFC-manet-packetbb-11]
1-4 RESERVED [RFC-manet-packetbb-11]
5-127 Available for allocation [RFC-manet-packetbb-11]
128-255 Reserved for Private/Local Use [RFC-manet-packetbb-11]


Action 2 (Section 6.2):

Upon approval of this document, the IANA will create the following
registry "Packet TLV Types" located at http://www.iana.org/assignments/TBD
Allocation Policy: standards action
Initial contents of this registry will be:

values 0-7 - MUST NOT be assigned except when a documented
need exists that TLVs of a given type are required to appear before
all other TLVs in the TLV block as encoded for transmission. Note
that the need for a TLV to be processed before other TLVs does not
however automatically translate into a need for the TLV to appear
before all other TLVs in the TLV block - the order in which TLVs
are to be processed MUST be defined, if applicable, in the
protocols using this specification.

Type Description Reference
---- ----------- ---------
0-7 Available with constraints [RFC-manet-packetbb-11]
8-127 Available for assignment [RFC-manet-packetbb-11]
128-255 Reserved for Private/Local Use [RFC-manet-packetbb-11]


Action 3 (Section 6.3):

Upon approval of this document, the IANA will create the following
registry "Message TLV Types" located at http://www.iana.org/assignments/TBD
Allocation Policy: standards action
Initial contents of this registry will be:

values 0-7 - MUST NOT be assigned except when a documented
need exists that TLVs of a given type are required to appear before
all other TLVs in the TLV block as encoded for transmission. Note
that the need for a TLV to be processed before other TLVs does not
however automatically translate into a need for the TLV to appear
before all other TLVs in the TLV block - the order in which TLVs
are to be processed MUST be defined, if applicable, in the
protocols using this specification.

Type Description Reference
---- ----------- ---------
0-7 Available with constraints [RFC-manet-packetbb-11]
8-127 Available for assignment [RFC-manet-packetbb-11]
128-255 Reserved for Private/Local Use [RFC-manet-packetbb-11]


Action 4 (Section 6.4):

Upon approval of this document, the IANA will create the following
registry "Address Block TLV Types" located at http://www.iana.org/assignments/TBD
Allocation Policy: standards action
Initial contents of this registry will be:

values 0-7 - MUST NOT be assigned except when a documented
need exists that TLVs of a given type are required to appear before
all other TLVs in the TLV block as encoded for transmission. Note
that the need for a TLV to be processed before other TLVs does not
however automatically translate into a need for the TLV appearing
before all other TLVs in the TLV block - the order in which TLVs
are to be processed MUST be defined, if applicable, in the
protocols using this specification.

Type Description Reference
---- ----------- ---------
0-7 Available with constraints [RFC-manet-packetbb-11]
8-127 Available for assignment [RFC-manet-packetbb-11]
128-255 Reserved for Private/Local Use [RFC-manet-packetbb-11]


We understand the above to be the only IANA Actions for this document.

PROTO writeup by Ian Chakeres:


    1. Have the chairs personally reviewed this version of the  Internet Draft (I-D), and in particular, do they believe this I-D is  ready to forward to the IESG for publication?

YES.

    2. Has the document had adequate review from both key WG members  and key non-WG members? Do you have any concerns about the depth or  breadth of the reviews that have been performed?

YES the ID has been adequately reviewed.

    3. Do you have concerns that the document needs more review from a  particular (broader) perspective (e.g., security, operational  complexity, someone familiar with AAA, etc.)?

The document has been reviewed by the security directorate, and the  suggestions were included in the recent revisions.

    4. Do you have any specific concerns/issues with this document  that you believe the ADs and/or IESG should be aware of? For example,  perhaps you are uncomfortable with certain parts of the document, or  have concerns whether there really is a need for it. In any event, if  your issues have been discussed in the WG and the WG has indicated it  that it still wishes to advance the document, detail those concerns  in the write-up.

During the WGLC period a few issues were brought up.

Efficiency - The I-D represents a trade-off between  expressiveness/flexibility on one side and encoding-efficiency on the  other side. Certain members of the WG feel that a trade-off favoring  more encoding-efficiency against less expressiveness or flexibility  would be desirable. The I-D has developed since its inception to be  accommodating in this area and, despite some remaining criticism,  there is consensus to progress with the current specification.

Ordering and uniqueness of TLVs - Previous versions of this I-D  mandated strict ordering and uniqueness constraints on TLVs,  recognizing that (i) such allows for efficiency in parsing and (ii)  that such does not limit expressiveness and processing by a protocol  using this specification. Certain members of the WG felt that this  was unacceptable for potential future uses. This was accommodated by  the latest I-D, which allows relaxing these constraints if explicitly  signaled. The WGLC was extended to allow for comments on this  compromise and no negative comments were received.  There is  therefore consensus to progress with the current specification.

    5. How solid is the WG consensus behind this document? Does it  represent the strong concurrence of a few individuals, with others  being silent, or does the WG as a whole understand and agree with it?

All the other significant WG documents contain a reference to this  ID. Though there has been recent disagreement on a few small details  (described above), the document overall has significant support.

    6. Has anyone threatened an appeal or otherwise indicated extreme  discontent? If so, please summarize the areas of conflict in separate  email to the Responsible Area Director.

The current version of this I-D has addressed the issues causing  discontent, and during the extended WGLC no objections were raised.

    7. Have the chairs verified that the document adheres to all of  the ID Checklist items ?

YES.

    8. Is the document split into normative and informative  references? Are there normative references to IDs, where the IDs are  not also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with normative  references to IDs, it will delay publication until all such IDs are  also ready for publication as RFCs.)

YES the references are split into normative and informative  references.

    9. What is the intended status of the document? (e.g., Proposed  Standard, Informational?)

Proposed Standard.

  10. For Standards Track and BCP documents, the IESG approval  announcement includes a write-up section with the following sections:

          * Technical Summary

This document specifies the syntax of a general purpose multi-  message packet format for information exchange between MANET  routers. The format has been designed with extensibility, efficiency,  and a clear separation of forwarding and processing.

          * Working Group Summary

This document contains information that was originally in OLSRv2.  It  was pulled out and generalized, since it is applicable to many MANET  WG protocols - specifically NHDP, OLSRv2, and DYMO.

Though there was some recent disagreement about some details (see  above), the overall support for this document is large. It is an  integral component of other WG specifications, namely NHDP, OLSRv2,  and DYMO.

          * Protocol Quality

From an efficiency standpoint this specification is a large  improvement from previous protocol instances. For example, in OLSRv1  with IPv6 - OLSRv2 (using the document being put forward for
publication) can reduce the number of packets transmitted by half (by  aggregating multiple messages) and it can reduce the overhead by half  (by compressing addresses).

There are many implementations. Interoperability (of this
specification) in conjunction with others that cite (namely OLSRv2)  have been performed.