Dear all,

I've promised to provide a review of DYMO for a while, and finally got my act together and got around to writing  up my comments into an email. I should add that I cornered Charlie over lunch today, and we went through a large part of these comments. He encouraged, none the less, that I bounce my comments to the mailing list, so here goes. Hope they are helpful and somewhat clear....

Cheers,

Thomas


General comments:

	o	I found the document rather hard to read, in part due to the terminology used.
		The Terminology section states that it uses "some terminology from [RFC5444]",
		but is not explicit as to what. RFC5444 defines terms such as packet/message,
		both of which are used in this document in (I think) manners inconsistent with
		their definitions in RFC5444. I'll point out a couple of examples of this in the
		below, but the terminology use should be cleaned up through the document
		to be consistent with RFC5444. I think that as RFC5444 and this document
		are both products of the MANET wg, and that this document uses RFC5444,
		then the terminology should be perfectly aligned with the terminology from 
		RFC5444 (I have not seen overruling reasons otherwise in the document).

	o	There is an awful lot of places where different terminology is used for the same 
		concept, e.g. "target" vs. "destination" and "source" vs. "originator" etc. Unless
		these are truly different concepts, then I would suggest consistency so as to
		make the text easier to read and less ambiguous.

		I have tried to indicate the first handful of issues I found of this kind, but I stopped
		after a few pages; still suggest that the terminology is cleaned up throughly.

	o	I find the use of "node" unfortunate. I would much prefer "router", as this is a
		protocol running between routers. This applies both in the text and in the 
		"terminology mnemonics". I note that the text sometimes uses "router" and 
		sometimes "node", and it is not clear that/if there is a difference, or if there
		should be a difference.

	o	I have a general concern about how DYMO imposes constraints on RFC5444 usage,
		which precludes co-existence with other RFC5444 protocols running on the same 
		device. I detail this below, but I think that this is an issue that needs to be resolved.

	o	In a great many places, it is stated "IP address of the node sending the message". 
		If a router has multiple interfaces, and/or if these interfaces have multiple addresses,
		which of these (any? one matching the interface over which the message is sent?)
		should be used? I'm not pointing this out explicitly in the detailed review below, it is
		a general comment which applies too often through the document.

	o	Finally, I have a very simple mind, and I like bullet-point-pseudocode over 
		"textual pseudocode". E.g something like this is more readable to me:

				Upon receiving an RREQ, a router:
					1.	Record X;
					2.	Record Y;
					3.	If z then:
							o	Do FOO;
						otherwise:
							o	Do BAR;
					4.	Retransmit the RREQ
				
		This is, of course, a personal preference / stylistic preference, but it is hardish to follow
		the flow of the algorithm as it is currently written.

> Abstract
> 
>    The Dynamic MANET On-demand (DYMO) routing protocol is intended for
>    use by mobile routers in wireless, multihop networks.  DYMO
>    determines unicast routes among DYMO routers within the network in an
>    on-demand fashion, offering improved convergence in dynamic
>    topologies.
> 
>> 
"Improved convergence in dynamic topologies" - improved over what?

> 1.  Overview
> 
>    The Dynamic MANET On-demand (DYMO) routing protocol enables reactive,
>    multihop unicast routing among participating DYMO routers.  The basic
>    operations of the DYMO protocol are route discovery and route
>    maintenance.
> 


The document uses the terms "on-demand fashion" in the abstract, and "reactive" in the Introduction; these are not described. Are they terms representing the same or different concepts? If the same, I suggest consistency, otherwise I suggest clarification.
>    During route discovery, the originator's DYMO router initiates
>    dissemination

"dissemination" merits being elaborated; I believe that "flooding" is a more commonly used term in [manet]. Is this the same, or a different, concept? If different, this needs to be elaborated (*how* is the information disseminated?")

>  of a Route Request (RREQ) throughout the network to
>    find a route to the target's DYMO router. 
Couple of questions here:

	o	"target", is that what is commonly referred to as "destination", e.g. in IP 
		headers or elsewhere?

	o	"target", I would assume that that's a "host", see issue below?

	o	"target's DYMO router" - should this be read as to indicate that a given host
		 (destination for data traffic) is connected to one and only one DYMO router,
		i.e. that hosts can not be "multi-homed" to different DYMO routers? If so, then
		this merits being called out in the "applicability statement" section.

>  During this hop-by-hop
>    dissemination process, 
It is not clear what a "hop-by-hop dissemination process" is at this point. I assume that it is some sort of "flooding, but with selective relaying other than for coverage", but it is not clear if this is the case.

> each intermediate DYMO router records a route
>    to the originator.  When the target's DYMO router receives the RREQ,
>    it responds with a Route Reply (RREP) sent hop-by-hop 
"sent hop-by-hop" - how is this different from "dissemination" and "hop-by-hop dissemination"?
> toward the
>    originator.
	o	is this relative to the "originator address" from RFC5444?
	o	is this the "originator" of the RREP  or the RREQ?

>   Each intermediate DYMO router that receives the RREP
>    creates a route to the target, and then the RREP is unicast hop-by-
>    hop toward the originator. 
Above, the RREP was "sent hop-by-hop", here it is "unicast hop-by-hop". Same or different thing?

>  When the originator's 
Of what?
> DYMO router
>    receives the RREP, routes have then been established between the
>    originating DYMO router and the target DYMO router in both
>    directions.
Just a question: does DYMO create symmetric routes? It is said later that DYMO must use bidirectional links.
>    Route maintenance consists of two operations.  In order to preserve
>    routes in use, DYMO routers extend route lifetimes upon successfully
>    forwarding a packet.  In order to react to changes in the network
>    topology, DYMO routers monitor routes over which traffic is flowing.
What does it mean for a router to "monitor routes"?
>    When a data packet is received for forwarding and a route for the
>    destination is not known or the route is broken, then the DYMO router
>    of the source of the packet is notified.  A Route Error (RERR) is
>    sent toward the packet source to indicate the route to that
>    particular destination
destination or target?
>  is invalid or missing. 
I would suggest to be more specific on the "route to that particular destination is missing"; is that not the same as "there is no entry in the routing table, matching the address of the destination". This, obviously, then raises the question of how this is done in case there're network entries (i.e. non-host routes) matching the destination address -- the pathological example is, what happens if the routing table has a default route?
>  When the source's DYMO
>    router receives the RERR, it deletes the route.  If this source's
>    DYMO router later receives a packet for forwarding to the same
>    destination, it will need to perform route discovery again for that
>    destination.

Is there any functional difference here between a packet for a new destination (i.e. for a destination for which no previous route was installed) or destination which has been "deleted" due to an RERR?
>    DYMO uses sequence numbers to ensure loop freedom [Perkins99].
>    Sequence numbers enable DYMO routers to determine the temporal order
>    of DYMO route discovery messages, thereby avoiding use of stale
>    routing information.
> 
> 
> 2.  Applicability Statement
I think that the applicability statement should call out if/that multi-homed hosts are supported, as described above. I also believe that the applicability statement should call out some of the security questions that I raise later below. Also, the requirement that DYMO routers have persistent story available (5.1.4) should be called out here, as some (smaller) platforms do not have persistent storage (outside of that which requires flashing the device....)

>    The DYMO routing protocol is designed for stub or disconnected mobile
>    ad hoc networks (MANETs).  DYMO handles a wide variety of mobility
>    patterns by dynamically determining routes on-demand.  DYMO also
>    handles a wide variety of traffic patterns. 

Can this (wide variety of mobility patterns, traffic patterns) be quantified somewhat?
>  In networks with a large
>    number of routers, DYMO is best suited for sparse traffic scenarios
>    where routers forward packets to only a small portion of the other
>    DYMO routers, due to the reactive nature of route discovery and route
>    maintenance.

Reactive vs. on-demand -- in same paragraph here, so I assume that they are different?
>    DYMO is applicable to memory constrained devices, since little
>    routing state is maintained in each DYMO router.  Only routing
>    information related to active sources and destinations is maintained,
>    in contrast to most other more proactive routing protocols that
>    require routing information to all routers within the routing region
>    be maintained.
It is not immediately clear: back-of-the-napkin math suggests that if a DYMO network would need to maintain routes between all possible communicating pairs in the network, then this would actually require more state than a pure link-state protocol. Thus, I would suggest that this be somewhat  rephrased.

>    DYMO supports routers with multiple interfaces participating in the
>    MANET.  DYMO routers can also perform routing on behalf of other
>    nodes, attached via participating or non-participating interfaces.
The first paragraph of the applicability statement states that only stub networks are supported, I would assume that "nodes" in the above should be "hosts", as otherwise it'd be a potential transit network?

>    DYMO routers perform route discovery to find a route to a particular
>    destination.  Therefore, DYMO routers MUST be configured to initiate
>    and respond to route discovery on behalf of certain nodes, identified
>    by address. 
I do not understand the "respond to route discovery on behalf of certain nodes, identified by address",  is it not rather that "Each DYMO router must be configured to respond to RREQs for a certain set of addresses"? 
>  When DYMO is the only protocol interacting with the
>    forwarding table, DYMO MAY be configured to perform route discovery
>    for all unknown unicast destinations.
>    At any time within a DYMO routing region only one DYMO router SHOULD
>    be responsible for, i.e. "own", a particular address. 

>  Coordination
>    among multiple DYMO routers to distribute routing information
>    correctly for a shared address (i.e. an address that is advertised
>    and can be reached via multiple DYMO routers) is not described in
>    this document.  The router behavior for shifting responsibility for
>    an address from one DYMO router to another are described in
>    Appendix A.
> 
I.e. multi-homing explicitly prohibited. I wonder if it is reasonable for the protocol to have this restriction. 

Is the following configuration supported: a subset of routers have two wireless interfaces, operating on distinct frequencies and being "participating interfaces". An "edge networks" (an Ethernet with hosts, say) connects to the MANET by way of two gateways, each of which having one "participating interface", and with the two gateways' "participating interface"'s being on each of the two distinct frequencies so as to allow the "edge network" to connect via either frequency?

(A banalized example, consider a vehicle with an on-board Ethernet, and two "routers", one WiMax and the other DRC, and with road-side infrastructure routers having both WiFi an WiMax interfaces on the same routers).

I do not think that the above is a particularly exotic situation, so I think it should be supported - if not, it should be spelled out very clearly. I should say that I went back and loo
>    DYMO MUST only utilizes bidirectional links. 
How're those identified?
>  In the case of possible
>    unidirectional links, either blacklists ( see Section 7.2) or other
>    means (e.g. adjacency establishment with only neighboring routers
>    that have bidirectional communication as indicated by NHDP
>    [I-D.ietf-manet-nhdp]) of ensuring and monitoring bi-directionality
>    SHOULD be used.  Otherwise, persistent packet loss may occur.
> 
>    The routing algorithm in DYMO may be operated at layers other than
>    the network layer, using layer-appropriate addresses.  For operation
>    at other layers DYMO's routing algorithm likely will
"Likely"? 

I am wondering if it is appropriate to call this sort of stuff out in an IETF specification, considering that the IETF is not in the business of standardizing L2's?

>  not need to
>    change.  Although, modification of the packet/message format may be
>    required.
> 
> 
> 3.  Terminology
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

There's an errata to 2119, "NOT RECOMMENDED" is missing in the above.

>    document are to be interpreted as described in [RFC2119].
> 
>    Additionally, this document uses some terminology from [RFC5444].

As stated in the beginning, I think it would be helpful to call out which parts of the terminology from 5444 is imported here, in particular as a large fraction of the 5444-defined terminology is used differently in this document than in 5444.
>    This document defines the following terminology:
> 
>    Adjacency
>       A relationship between selected bi-directional neighboring routers
>       for the purpose of exchanging routing information.  Not every pair
>       of neighboring routers become adjacent.  Neighboring routers may
>       form an adjacency based several different pieces of information or
>       protocols; for example, exchange of DYMO routing messages, other
>       protocols (e.g.  NDP [RFC4861] or NHDP [I-D.ietf-manet-nhdp]), or
>       manual configuration.  Similarly, loss of a routing adjacency may
>       also be based upon several pieces of information, and monitoring
>       of adjacencies where packets are being forwarded is required (see
>       Section 5.5.1).

Two issues:

	o	Adjacency is an already well-established term in OSPF, is the use of this term
		in this document identical hereto, or is this a re-definition?

	o	The definition above leaves me confused as to what an adjacency is; I am not
		sure how, for example, 4861 or NHDP forms adjacencies; NHDP discovers bi-
		directional neighbors (all of them), whereas in the above an "adjacency"
		explicitly is not formed with *all* bi-directional neighbors.
>    Distance (Dist)
>       A metric of the distance a message or piece of information has
"piece of information", can this be more specific? I assume that to be information contained in messages, and thus that this is somewhat redundant?
>       traversed.  The minimum value of distance is the number of IP hops
>       traversed.  The maximum value is 65,535.
> 
>    DYMO Identifier (DID)
>       A DID is maintained for each DYMO routing process (ThisNode.DID),
>       and the default value is zero (0).  Each routing message is tagged
>       with its associated DID (MsgTLV.DID), unless zero (0).  Upon
>       receipt of DYMO protocol message a DYMO routing protocol process
>       SHOULD only attend to messages with a matching DID value.

"Routing message" and "DYMO protocol message", what is the difference? Are they the same or different things?

Also, what does it mean to "attend to messages"? "Receive", "process", "forward", "drop" and "generate", I can understand relatively well, but "attend to" is new....while we're at this point, on occasion the document states "handle the message" -- I am not sure which subset of receive/process/forward/drop/generate that describes.

>    DYMO Sequence Number (SeqNum)
>       A DYMO Sequence Number is maintained by each DYMO router process.
>       This sequence number is used by other DYMO routers to identify the
>       temporal order of routing information generated and ensure loop-
>       free routes.
> 
>    Forwarding Route
>       A route that is used to forward data packets.  Forwarding routes
>       are generally maintained in a forwarding information base (FIB) or
>       the kernel forwarding/routing table.
> 

Suggest "forwarding/routing table of the underlying operating system"
>    Multihop-capable Unicast IP Address
>       A multihop-capable unicast IP address is a unicast IP address that
>       when put into the IP.SourceAddress or IP.DestinationAddress field
>       is scoped sufficiently to be forwarded by a router.  For example,
>       site-scoped or globally-scoped unicast IP addresses.
> 
Isn't this just a long-winded way to say "any non-link-local uni-cast address" ?
>    Originating Node (OrigNode)
>       The originating node is the source, its DYMO router creates a DYMO
>       control message on its behalf in an effort to disseminate some
>       routing information.  The originating node is also referred to as
>       a particular message's originator.
Wait, "the originating node is the source" seems wrong. If both terms are used through the document (and I think they are), then I suggest selecting one, and being consistent about the matter. 

I think, however, that there is (in places) a slight subtelty, where "originator" or "originating node" implies "the router issuing DYMO RREQs" whereas the "source" is the source IP address of an IP unicast datagram containing user data. This issue  managed to get me confused numerous times through the document, and it would be very very helpful to do a through cleanup of this matter.


>    Route Error (RERR)
>       A RERR message is used to indicate that a DYMO router does not
>       have a forwarding route to one or more particular addresses.
> 
>    Route Reply (RREP)
>       A RREP message is used to disseminate routing information about
>       the RREP OrigNode to the RREP TargetNode and the DYMO routers
>       between them.
> 
>    Route Request (RREQ)
>       A RREQ message is issued to discover a valid route to a particular
>       destination address, called the RREQ TargetNode.  When a DYMO
>       router processes a RREQ, it learns routing information on how to
>       reach the RREQ OrigNode.
> 
>    Target Node (TargetNode)
>       The TargetNode is the ultimate destination of a message.
> 
>    This Node (ThisNode)
>       ThisNode corresponds to the DYMO router process currently
>       performing a calculation or attending to a message.

So "Node corresponds to DYMO router" - just use router in place of node and be done with it.
>    Type-Length-Value structure (TLV)
>       A generic way to represent information, please see [RFC5444] for
>       additional information.
> 
>    Unreachable Node (UnreachableNode)
>       An UnreachableNode is a node for which a forwarding route does not
>       exist.
> 
> 
> 4.  Data Structures
> 
> 4.1.  Route Table Entry
> 
>    The route table entry is a conceptual data structure.
>    Implementations may use any internal representation that conforms to
>    the semantics of a route as specified in this document.

I am not sure what "semantics of a route" means. I think you mean to say that an implementation may use any internal representation, so long as it provides access to the same information as specified in the below.

>    Conceptually, a route table entry has the following fields:
> 
<SNIP>
>    Route.NextHopAddress
>       The IP address of the adjacent DYMO router on the path toward the
>       Route.Address.
> 
Is that any IP addresses of the adjacent DYMO router, or the IP address of a specific interface on the DYMO router?

>    Route.NextHopInterface
>       The interface used to send packets toward the Route.Address.
> 
>    Route.Forwarding
>       A flag indicating whether this Route can be used for forwarding
>       data packets.  This flag MAY be provided for management and
>       monitoring.
> 
>    Route.Broken
>       A flag indicating whether this Route is broken.  This flag is set
>       to true if the next-hop becomes unreachable or in response to
>       attending to a RERR (see Section 5.5.4).
> 
If I understand it right, then if Route.Forwarding  and  Route.Broken are inverse, i.e. if one is set the other is cleared. Which leaves the question, why are there both?

Route.Broken I can understand --  Route.Forwarding is somewhat odd: what would a route be used for if not forwarding data packets?

>    The following field is optional:
> 
>    Route.Dist
>       A metric indicating the distance traversed before reaching the
>       Route.Address node.
> 
>    Not including optional information may cause performance degradation,
>    but it will not cause the protocol to operate incorrectly.

I would suggest "...will not prohibit the protocol from discovering valid routes"?
>    In addition to a route table data structure, each route table entry
>    may have several timers associated with the information.  These
>    timers/timeouts are discussed in Section 5.2.3.
> 
As this section describes the conceptual data structures, I would prefer to have also the timers presented in this section, to minimize the flipping through the document.
> 4.2.  DYMO Messages
> 
>    When describing DYMO protocol messages, it is necessary to refer to
>    fields in several distinct parts of the overall packet.  These
>    locations include the IP header, the UDP header, and fields from
>    [RFC5444].  This document uses the following notation conventions.
> 

This is where I think the confusion with 5444 terminology manifests itself. If 5444 is used, then a "message" is a well-defined entity, which is part of a "packet" and possibly contained in an "IP datagram". A DYMO protocol message should, thus, be an instance of a 5444 message and described as such.
> Chakeres & Perkins      Expires January 11, 2011                [Page 8]
> 
> Internet-Draft                    DYMO                         July 2010
> 
> 
>    Information found in the table.
I believe that the above sentence is orphaned?

>              +---------------------------+-------------------+
>              |    Information Location   | Notational Prefix |
>              +---------------------------+-------------------+
>              |         IP header         |        IP.        |
>              |         UDP header        |        UDP.       |
>              |   RFC5444 message header  |      MsgHdr.      |
>              |    RFC5444 message TLV    |      MsgTLV.      |
>              |   RFC5444 address blocks  |      AddBlk.      |
>              | RFC5444 address block TLV |      AddTLV.      |
>              +---------------------------+-------------------+
> 
>                                   Table 1
> 
I am also a little worried about the IP. and, especially, UDP. notations, specifically if the subsequent processing is transport dependent. I would suggest that a brief section should allow factoring this out, and that the remainder of the spec be transport independent (i.e. you could run this over ICMP, for example, if desired?) I understand that somewhere it needs to be said that "DYMO control messages can be sent either using the ' manet' protocol number or the 'manet' UDP well-known port number, as specified in [RFC5498].", but and that we can assume to have IP somewhere, of course, for addresses - but beyond that I think it should be factorable.

> 4.2.1.  Generalized Packet and Message Structure
> 
>    DYMO messages conform to the generalized packet and message format as
>    described in [RFC5444].  Here is a brief description of the format.
>    A packet is made up of messages.  A message is made up of a message
>    header, message TLV block, and zero or more address blocks.  Each of
>    the address blocks may also have an associated address TLV block.
> 
>    For interoperability with other DYMO routers, all DYMO messages
>    specified in this document SHOULD sent using the IP protocol number
>    (138) reserved for manet protocols [RFC5498]; or the UDP destination
>    port (269) reserved for manet protocols [RFC5498] and IP protocol
>    number for UDP.
> 
>    Most DYMO messages are sent with the IP destination address set to
>    the link-local multicast address LL-MANET-Routers [RFC5498] unless
>    otherwise stated.  Therefore, all DYMO routers SHOULD subscribe to
>    LL-MANET-Routers [RFC5498] for receiving control packets.  Note that
>    multicast packets MAY be sent via unicast.  For example, this may
>    occur for certain link-types (non broadcast mediums), improved
>    robustness, or manually configured router adjacencies.
> 
Suggest that the above two paragraphs be factored out, along with the comment above, to a separate section (possibly top-level) somewhere.
>    Unicast DYMO messages (e.g.  RREP) unless otherwise specified in this
>    document are sent with the IP destination set to the
>    Route.NextHopAddress of the route to the TargetNode.
> 
>    The IPv4 TTL (IPv6 Hop Limit) field for all packets containing DYMO
>    messages is set to 255.  If a packet is received with a value other
>    than 255, it is discarded.  This mechanism helps to ensures that
>    packets have not passed through any intermediate routers, and it is
>    known as GTSM [RFC5082].
There is an issue here, regarding co-existance of different protocols using RFC5444 on the same router. "Piggybacking" multiple messages (5444 sense) from different protocols into the same packet (5444 sense) is a core feature that should be supported; e.g. for running NHDP and DYMO on the same router and take advantage of piggybagging of HELLOs and RREQs (for example) into the same transmission.

Making a requirement from DYMO that the IP header fields have specific values effectively prohibits coexistence with other protocols if these make contradictory such requirements -- and is a layer violation. DYMO should, in order to employ RFC5444 appropriately and so as to not preclude coexistence among protocols, be concerned only with messages (again, RFC5444) and their header and payload fields.

Imposing this constraint effectively precludes other protocols from co-existing on a router where DYMO is running.

I feel rather strongly about this point, as a lot of the exercise of RFC5498 and RFC5444 was to, exactly, ensure correct and efficient co-existence of multiple protocols or protocol instances on the same router, and I would want to see this addressed - it's a deal-breaker to get this right. I notice that a lot of this was brought on by RFC5498, of which one of the authors of DYMO is author.

>    The length of an address (32 bits for IPv4 and 128 bits for IPv6)
> 
> 
> 
> Chakeres & Perkins      Expires January 11, 2011                [Page 9]
> 
> Internet-Draft                    DYMO                         July 2010
> 
> 
>    inside a DYMO message depends on the msg-addr-length (MAL) in the
>    msg-header, as specified in [RFC5444].
> 
>    The aggregation of multiple messages into a packet is not specified
>    in this document, but if aggregation does occur the IP.SourceAddress
>    and IP.DestinationAddress of all contained messages MUST be the same.

Again, this is also a deal-breaker, for the same reasons as above. It imposes interdependency on the messages contained in an RFC5444 packet, which precludes co-existence again -- and, which prevents using generic multiplexer/demultiplexers, but rather require specific knowledge about what constraints on interdependency of messages that each protocol imposes.

This is contrary to the design of RFC5444: TLVs are designed to be independent of other TLVs in the same message, messages are designed to be independent from other messages in the same packet. DYMO violates this.

>    Implementations MAY choose to temporarily delay transmission of
>    messages for the purpose of aggregation (into a single packet) 
However, this is not possible unless messages are all DYMO messages; would not allow (as per the above) a DYMO message + a message from another protocol to be aggregated/piggybagged into the same packet transmission.
> or to
>    improve performance by using jitter [RFC5148].
I would surmise that this is by way of reducing collisions, and could be stated explicitly.
>    DYMO control packets SHOULD be given priority queuing and channel
>    access.

What is a DYMO control packet? A DYMO control message? A Routing Message?
>    AddBlk.TargetNode.Address
>       The IP address of the message TargetNode.  In a RREQ the
>       TargetNode is the destination address for which route discovery is
>       being performed.  In a RREP the TargetNode is the RREQ OrigNode
>       address.  The TargetNode address is the first address in a routing
>       message.
"The IP address of the message TargetNode" - TargetNode is defined to be a "node", not a message.
> 
>    AddBlk.AdditionalNode.Address
>       The IP address of an additional node that can be reached via the
>       DYMO router adding this information.  Each AdditionalNode.Address
>       MUST include its prefix.  Each AdditionalNode.Address MUST also
>       have an associated Node.SeqNum in the address TLV block.
> 
What is an "additional node that can be reached via the DYMO router adding this information"?
>    IP.DestinationAddress
>       For multicast RERR messages, The IP address is set to LL-MANET-
The -> the
>       Routers [RFC5498].  For unicast RERR messages, the IP address is
>       set to the NextHopAddress.
> 
>    IP.ProtocolNumber and UDP.DestinationPort
>       The IP Protocol Number 138 (manet) has been reserved for MANET
>       protocols [RFC5498].  In addition to using this IP protocol
>       number, DYMO may use the UDP port 269 (manet) [RFC5498] in
>       conjunction with the IP Protocol Number 17 (UDP).
Suggest factoring this to a separate section, as indicated above.


>    Example IPv4 RERR
> 
>         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
>    IP Header
>        +-+-+-+-+-+-+-+-+
>        | IP.Proto = UDP|
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                     IP.SourceAddress                          |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |         IP.DestinationAddress = LL-MANET-Routers              |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |    IP.TTL/HopLimit = 255      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    UDP Header
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   Destination Port = manet    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    Message Header
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   RERR-type   |0|1|0|0| MAL=3 |         msg-size=15           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        | msg-hoplimit  |
>        +-+-+-+-+-+-+-+-+
>    Message TLV Block
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |     msg-tlv-block-size=0      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    Message Body - Address Block
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |Number Addrs=1 |0|0|0|0|0| Rsv |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                     UnreachableNode.Address                   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    Message Body - Address Block TLV Block
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |        TLV-blk-size=0         |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                                  Figure 2
I will take this issue here, although I think it applies elsewhere. This too is an RFC5444-usage-issue, and I think it's a very very important one too.

For extensibility reasons, any address in an address block should / is recommended to be associated with an address block TLV, indicating its usage. Doing so enables internal extensibility (a protocol extension can add addresses and associated TLVs to a DYMO message, without a stock DYMO thinking that it should affix semantics to the address), not doing so leads to a design with very limited extensibility.

I would recommend thinking about it this way: just as message types allow "handing off incoming messages to the appropriate protocol implementations and indicate large-scale processing", address-block TLVs allows to specify "which specific processing action for which specific address" to undertake by a protocol. Thinking about it this way, the logical conclusion for an address without an associated TLV is "don't process at all".

Unless you are absolutely certain (and can convincingly argue so) that there never will be a need to for protocol extensions, I would recommend that the above be applied through all DYMO control messages in a systematic fashion.

> 5.1.3.  OwnSeqNum Rollover
> 
>    Incrementing an OwnSeqNum whose value is the largest largest possible
>    number representable as a 16-bit unsigned integer (i.e., 65,535),
>    SHOULD be set to one (1).  In other words, the sequence number after
>    65,535 is 1.
> 
Generally, when such wrap-around happens, I worry if there are any transient situations that can happen. A router receiving a message with seq# 65000, then a message with seq# 30000, does it assume that this message is old, or is wrapped-around (and that messages in between 65000->1->39999 have been lost?

I would like to see this specified explicitly (and if it is not a problem either way, I'd like to see why). Here seems the good place to do so.
> 5.1.4.  Actions After OwnSeqNum Loss
> 
>    A DYMO router SHOULD maintain its sequence number in persistent
>    storage.
I would suggest that this should be stated in the "Applicability Statement", that "Proper operation of DYMO requires that routers have persistent storage available", as this seems to be a notable condition for those wanting to deploy an ad hoc network on hardware which may not have persistent storage, available outside of a flashing-process (such as e.g. embedded devices).

>    If a DYMO router's OwnSeqNum is lost, it MUST take certain actions to
>    avoid creating routing loops.  To prevent this possibility after
>    OwnSeqNum loss a DYMO router MUST wait for at least
>    ROUTE_DELETE_TIMEOUT before fully participating in the DYMO routing
>    protocol.  If a DYMO control message is received during this waiting
>    period, the DYMO router SHOULD handle it normally but MUST NOT
"handle it" - previously it was called "attend to"; suggest being specific, especially.....
>    transmit or retransmit any DYMO messages.  If a data packet is
.....it is allowed to receive and process DYMO messages, but it is not allowed to forward and generate DYMO messages.
>    received for forwarding to another destination during this waiting
>    period, the DYMO router MUST generate a RERR message 
And here is the contradiction, as it is said above that it "...MUST NOT transmit .... any DYMO message" -- and here, it is "MUST generate a RERR message" [I assume that the RERR is also transmitted, otherwise generating it would be useless]. It appears that there is an internal contradiction in the specification at this point.

I note the terminology issue between "generate" and "transmit" here, which should be consistent if they are the same, appear in terminology if they are different.
> 5.2.2.  Creating or Updating a Route Table Entry with Received Superior
>         Routing Information
> 
>    The route table entry is populated with the following information:
> 
>    1.  the Route.Address is set to Node.Address,
> 
>    2.  the Route.Prefix is set to the Node.Prefix.
> 
>    3.  the Route.SeqNum is set to the Node.SeqNum,
> 
>    4.  the Route.NextHopAddress is set to the node that transmitted this
>        DYMO RM packet (i.e., the IP.SourceAddress),
> 
"The node that transmitted this DYMO RM packet" -- originally, or the last retransmitter? Applies in multiple places.

>    5.  the Route.NextHopInterface is set to the interface that this DYMO
>        packet was received on,
> 
>    6.  the Route.Broken flag is set to false,
> 
>    7.  if known, the Route.Dist is set to the Node.Dist,
> 
>    Fields without known values are not populated with any value.
> 
So in that case, what is their value? How is it identified, upon reading an entry, if it is "populated with a value" or not? Generally, when allocating a data structure, it is preferential to have known default values for all fields, so as to be able to determine this.
>    The timer for the minimum delete timeout (ROUTE_AGE_MIN) is set to
>    ROUTE_AGE_MIN_TIMEOUT.  The timer for the maximum delete timeout
>    (ROUTE_SEQNUM_AGE_MAX) is set to Node.AddTLV.VALIDITY_TIME [RFC5497]
>    if included; otherwise, ROUTE_SEQNUM_AGE_MAX is set to
>    ROUTE_SEQNUM_AGE_MAX_TIMEOUT.  The usage of these timers and others
>    are described in Section 5.2.3.
> 
>    At this point, a forwarding route has been created and the
>    Route.Forwarding flag set.  Afterward, the route can be used to send
>    any queued data packets and forward any incoming data packets for
> 
This is the only occurrence of "queued data packets" in the specification - it is called "buffered" below in 5.4.
>    Route.Address.  This route also fulfills any outstanding route
>    discovery attempts for Node.Address.
> 
> 
> 
> 5.3.2.  RREP Creation
> 
>    First, the AddBlk.TargetNode.Address is added to the RREP.  The
>    TargetNode is the ultimate destination of this RREP; the RREQ
Editorially, I think "ultimate destination" is a bit strange. We're used to an IP datagram to be delivered to the destination (after which it is no longer forwarded - or dropped), any intermediary is not the destination.
>    The IP.DestinationAddress for RREP is set to the IP address of the
See comments regarding "Layer Violation" above.
> 5.3.4.  RM Handling
> 
>    First, ThisNode examines the RM to ensure that it contains the
>    required information: MsgHdr.HopLimit, AddBlk.TargetNode.Address,
>    AddBlk.OrigNode.Address, and OrigNode.AddTLV.SeqNum.  If the required
>    information do not exist, the message is discarded and further
>    processing stopped.
> 
>    Next, ThisNode decides whether to attend to this message.  If the
>    message contains a MsgTLV.DID it SHOULD match ThisNode.DID's value.
>    If the message does not contain a MsgTLV.DID it is assumed to be zero
>    (0) and SHOULD be discarded if ThisNode.DID's value is not zero (0).
> 
> 
> 
> Chakeres & Perkins      Expires January 11, 2011               [Page 21]
> 
> Internet-Draft                    DYMO                         July 2010
> 
> 
>    Next, ThisNode MAY selectively attend to messages based upon
>    information in the message.  ThisNode SHOULD only handle messages
>    from adjacent DYMO routers.  If ThisNode chooses not to handle this
>    message, the message is discarded and further processing stopped.
> 
>    ThisNode checks if the AddBlk.OrigNode.Address is a valid multihop-
>    capable (e.g. site or global scope) unicast address.  If the address
>    is not a valid unicast address, the message is discarded and further
>    processing stopped.
> 
>    ThisNode also checks whether AddBlk.OrigNode.Address is an address
>    handled by this DYMO router.  If this node is the originating DYMO
>    router, the RM is dropped.
> 

Is "dropped" different from "discarded and further processing stopped"? Are messages forwarded in either of these cases?

>    If the routing information for an AdditionalNode.Address is not
>    considered superior, then it is removed from the RM.  Removing this
>    information ensures that the information is not propagated.
I think that this is an important point to call out: RMs are thus, presumably, mutable beyond well-known header fields while in transit - yes? If so, I would suspect that this poses problems regarding authentication and integrity verification for messages relayed with mutated contend/payload - or, alternatively, a specific set of security mechanisms are envisioned. In either case, this should be called out in the security considerations section, possibly also applicability section as it seems to preclude (some) deployments due to inability to properly secure the protocol?

>    At this point, if the routing information for the OrigNode was not
>    superior then this RM SHOULD be discarded and no further processing
>    of this message SHOULD be performed.
Can it be forwarded?
>    If the ThisNode is the DYMO router responsible for the TargetNode and
>    this RM is a RREQ, then ThisNode responds with a RREP to the RREQ
>    OrigNode (the new RREP's TargetNode).  The procedure for issuing a
>    new RREP is described in Section 5.3.2.  At this point, ThisNode need
>    not perform any more operations for the RM being processed.
> 
>    As an alternative to issuing a RREP, ThisNode MAY choose to
>    distribute routing information about ThisNode (the RREQ TargetNode)
>    more widely.  That is, ThisNode MAY optionally perform a route
>    discovery; by issuing a RREQ with ThisNode listed as the TargetNode,
>    using the procedure in Section 5.3.1.  At this point, ThisNode need
>    not perform any more operations for the RM being processed.
The above paragraph doesn't parse by me. It appears that a router is trying to discover a path to itself, which should be trivial. I think that the intent is that as RREQs also cause installation of routes, a RREQ can be sent in place of a RREP; this begs the question of when one would chose to do an RREP over an RREQ in response to an RREQ. If they can be used indiscriminately, then one should be eliminated, if not then it should be specified when each should be used.
>    Some examples of why ThisNode might choose to not re-issue a RM are:
>    if ThisNode does not want to advertise routing for the contained
>    addresses because it is already heavily loaded; if ThisNode has
>    already issued nearly identical routing information (e.g.  ThisNode
>    had recently issued a RM with nearly the same distance);

And "nearly" is determined how? 
>    Data packets awaiting a route SHOULD be buffered by the source's DYMO
>    router.  This buffer SHOULD have a fixed limited size
>    (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES) and older data packets
>    SHOULD be discarded first.
> 
>    Buffering of data packets can have both positive and negative
>    effects, and therefore buffer settings (BUFFER_DURING_DISCOVERY)
>    SHOULD be administratively configurable or intelligently controlled.
> 
Maybe it is a decent idea to stipulate if intermediate routers are allowed or discouraged from buffering traffic?

>    If a route discovery attempt has failed (i.e. an attempt or multiple
>    attempts have been made without receiving a RREP) to find a route to
>    the TargetNode, any data packets buffered for the corresponding
>    TargetNode are dropped and a Destination Unreachable ICMP message
>    SHOULD be delivered to the source.
> 
Presumably, the source of the data packet(s)?
> 5.5.4.  RERR Handling
> 
>    First, ThisNode examines the RM to ensure that it contains the
>    required information: MsgHdr.HopLimit and
>    AddBlk.UnreachableNode.Address.  If the required information do not
>    exist, the message is discarded and further processing stopped.
> 
>    Next, ThisNode decides whether to handle this message.  If the
>    message contains a MsgTLV.DID it SHOULD match ThisNode.DID's value.
>    If the message does not contain a MsgTLV.DID it is assumed to be zero
>    (0) and SHOULD be discarded if ThisNode.DID's value is not zero (0).
> 
>    Next, ThisNode MAY selectively handle messages based upon information
>    in the message.  ThisNode MAY choose to only handle messages from
>    adjacent DYMO routers.  If ThisNode chooses not to handle this
>    message, the message is discarded and further processing stopped.
> 
>    When a DYMO router handles a RERR, it examines each UnreachableNode's
> 
> 
> 
> Chakeres & Perkins      Expires January 11, 2011               [Page 28]
> 
> Internet-Draft                    DYMO                         July 2010
> 
> 
>    information.  The attending DYMO router removes the forwarding route,
>    unsets the Route.Forwarding flag, sets the Route.Broken flag, and the
>    timer for ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT for each
>    UnreachableNode.Address found using longest prefix matching that meet
>    all of the following conditions:
> 
>    1.  The UnreachableNode.Address is a multihop-capable unicast
>        address.
> 
>    2.  The Route.NextHopAddress is the same as the RERR
>        IP.SourceAddress.
> 
>    3.  The Route.NextHopInterface is the same as the interface on which
>        the RERR was received.
> 
>    4.  The Route.SeqNum is zero (0), unknown, OR the
>        UnreachableNode.SeqNum is zero (0), unknown, OR Route.SeqNum -
>        UnreachableNode.SeqNum <= 0 (using signed 16-bit arithmetic).
> 
>    During handling if Route.SeqNum is zero (0) or unknown and
>    UnreachableNode.SeqNum exists in the RERR and is not zero (0), then
>    Route.SeqNum MAY be set to UnreachableNode.SeqNum.  Setting
>    Route.SeqNum can reduce future RERR handling and forwarding.
> 
>    Each UnreachableNode that did not result in a broken route is removed
>    from the RERR, since propagation of this information will not result
>    in any benefit.
> 
>    Each UnreachableNode that did result in a broken route SHOULD remain
>    in the RERR.
> 
>    If any UnreachableNode was removed, all other information (AddTLVs)
>    associated with the removed address(es) MUST also be removed.
> 
Same issue as above; RERR are mutable in-transit (beyond their header fields), which severely constrains the ability to secure the protocol, and this should be called out explicitly in the security considerations section.
>    After handling if Route.SeqNum is known and an UnreachableNode.SeqNum
>    is not included in the RERR, then Route.SeqNum (i.e.
>    UnreachableNode.SeqNum) MAY be added to the RERR.  Including
>    UnreachableNode.SeqNum can reduce future RERR handling and
>    forwarding.
> 
>    If no UnreachableNode addresses remain in the RERR, no other handling
>    is required and the RERR is discarded.
> 
>    If handling continues, the MsgHdr.HopLimit is decremented by one (1).
>    Further, if this RERR's new MsgHdr.HopLimit is greater than one (1)
>    and at least one unreachable node address remains in the RERR, then
>    the updated RERR SHOULD be sent.
> 
> 
> 
> 
> Chakeres & Perkins      Expires January 11, 2011               [Page 29]
> 
> Internet-Draft                    DYMO                         July 2010
> 
> 
>    A multicast RERR is sent to the IP.DestinationAddress LL-MANET-
>    Routers [RFC5498].  If the RERR is unicast, the IP.DestinationAddress
>    is set to the NextHopAddress.
> 
> 5.6.  DYMO Identifier (DID)
> 
>    Each DYMO routing protocol process MUST have an associated DYMO
>    Identifier (DID).  The DID allows multiple DYMO routing protocol
>    processes to operate over the same links and on the same device
>    independently.  This function may also be used to administratively
>    separate DYMO processes with incompatible options, timers, or
>    extensions.
> 
>    The DID is similar in function to OSPF Instance ID [RFC5340]
>    [I-D.ietf-ospf-multi-instance], OSPF Area ID [RFC2328] [RFC5340],
>    and/or the MANET_ID TLV [I-D.chakeres-manet-manetid].
Do you intend to cite I-D.chakeres-manet-manetid? IIRC, it is expired and hasn't been renewed in a while (in the References section, since 2008)? 
> 5.7.  Unknown Message & TLV Types
> 
>    If a message with an unknown type is received, the message is
>    discarded.
This will, by definition, never happen. By definition because it is explicitly specified in RFC5444 that a protocol only gets message types which it "owns" and, hence, "knows". This relates closely to the general relationship between this specification and RFC5444, which appears to be not cleanly used.
>    For handling of messages that contain unknown TLV types, the default
>    behavior is to leave the information in control messages unmodified.
>    Although, this behavior (UNKNOWN_TYPES) MAY be administratively
>    controlled.
And, this behavior would be universally applied for all unknown TLVs arriving on a given router in a DYMO message. Notice that here the document is potentially (if the default behavior for unknown types becomes anything other than "ignore for processing, preserve for forwarding") severely restricting ability for protocol extensions. 

Would STRONGLY recommend to not specify that this behavior can be administratively controlled.
> 5.9.  Simple Internet Attachment
> 
>    Simple Internet attachment consists of a stub network of DYMO routers
>    connected to the Internet via a single Internet DYMO router (IDR).
> 
>    DYMO routers, and hosts behind these routers, wishing to be reachable
>    from hosts on the Internet MUST have IP addresses within the IDR's
>    routable and topologically correct prefix (e.g. 192.0.2.0/24).
> 
>    The IDR is responsible for generating RREQ to find nodes within the
>    DYMO Region on behalf of nodes on the Internet, as well as responding
>    to route requests from the DYMO region on behalf of the nodes on the
>    Internet.
> 
But how does this work in the opposite direction? Will a DYMO router have to maintain explicit entries for all hosts on the Internet, with which it wishes to connect? 

It would appear (from the explanation below) to me that a "default gateway" entry would not work, and is not used, because if one is present in the routing table then -- by definition -- the routing table would contain a prefix matching any IP Address, and so that indeed explicit entries for all host on the Internet are required.

This doesn't appear scalable, but as this section is very brief, I may be missing some subtleties. It would, in any event, merit being called out if a "default gateway" entry in the routing table is possible, or if explicit routes (and so, explicit state) for all destinations on the Internet are required.
>          /--------------------------\
>         /          Internet          \
>         \                            /
>          \------------+-------------/
>                       |
>        Routable &     |
>        Topologically  |
>        Correct        |
>        Prefix         |
>                 +-----+------+
>                 |  Internet  |
>          /------|  DYMO      |-------\
>         /       |  Router    |        \
>        /        |192.0.2.1/32|         \
>        |        |Responsible |         |
>        |        |  for       |         |
>        |        |DYMO Region |         |
>        |        |192.0.2.0/24|         |
>        |        +------------+         |
>        | +--------------+              |
>        | | DYMO Router  |              |
>        | | 192.0.2.2/32 |              |
>        | +--------------+              |
>        |              +--------------+ |
>        |              | DYMO Router  | |
>        |              | 192.0.2.3/32 | |
>        \              +--------------+ /
>         \                             /
>          \---------------------------/
> 
>                Figure 3: Simple Internet Attachment Example
> 
>    When a DYMO router within the DYMO Region wants to discover a route
>    to a node on the Internet, it uses the normal DYMO route discovery
>    for that IP Destination Address.  The IDR is responsible for properly
>    responding to RREQ on behalf of the Internet destination.
> 
>    When a packet from a node on the Internet destine for a node in the
>    DYMO region reaches the IDR, if the IDR does not have a route to that
>    destination it will perform normal DYMO route discovery for that
>    destination.
> 
> 
> 7.  IANA Considerations
> 
>    In its default mode of operation, DYMO uses the UDP port MANET
>    [RFC5498] to carry protocol packets.  DYMO also uses the link-local
>    multicast address LL-MANET-Routers [RFC5498].
> 
>    This section specifies several message types, message tlv-types, and
>    address tlv-types.
> 
General comment: I believe that it should be called out, such that IANA is instructed what to do, explicitly from which registries and intervals the various TLV types should be allocated.

> Chakeres & Perkins      Expires January 11, 2011               [Page 35]
> 
> Internet-Draft                    DYMO                         July 2010
> 
> 
> 7.1.  DYMO Message Types Specification
> 
>                             DYMO Message Types
> 
>                    +------------------------+----------+
>                    |          Name          |   Type   |
>                    +------------------------+----------+
>                    |  Route Request (RREQ)  | 10 - TBD |
>                    |   Route Reply (RREP)   | 11 - TBD |
>                    |   Route Error (RERR)   | 12 - TBD |
>                    +------------------------+----------+
> 
>                                   Table 6
> 

I direct the authors attention on RFC5444, section 6.4.1, wherein it says:

6.4.1.  Message TLV Type Extension Registry Creation

   If a Message TLV Type is registered, then a new registry for type
   extensions of that type must be created.  A document that defines a
   Message TLV Type MUST also specify the mechanism by which its type
   extensions are allocated, from among those in [BCP26].
I therefore believe this section to be incomplete.

> 7.2.  Message and Address Block TLV Type Specification
> 
>                              Message TLV Types
> 
>    +-------------------+------+--------+-------------------------------+
>    |        Name       | Type | Length | Value                         |
>    +-------------------+------+--------+-------------------------------+
>    |  Unicast Response | 10 - |    0   | Indicates to the processing   |
>    |      Request      |  TBD | octets | node that the previous hop    |
>    |                   |      |        | (IP.SourceAddress) expects a  |
>    |                   |      |        | unicast message within        |
>    |                   |      |        | UNICAST_MESSAGE_SENT_TIMEOUT. |
>    |                   |      |        | Any unicast packet will serve |
>    |                   |      |        | this purpose, and it MAY be   |
>    |                   |      |        | an ICMP REPLY message.  If a  |
>    |                   |      |        | message is not sent, then the |
>    |                   |      |        | previous hop can assume that  |
>    |                   |      |        | the link is unidirectional    |
>    |                   |      |        | and MAY blacklist the link to |
>    |                   |      |        | this node.                    |
>    +-------------------+------+--------+-------------------------------+
> 
>                                   Table 7
> 
> 
> 
> 
I direct the authors attention on RFC5444, section 6.5, wherein it says:

   Allocation policies for Message-Type-specific Address Block TLV Types
   MUST be specified when creating the registry associated with the
   containing Message Type, see Section 6.2.1.

6.5.1.  Address Block TLV Type Extension Registry Creation

   When an Address Block TLV Type is registered, then a new registry for
   type extensions of that type must be created.  A document that
   defines a Message TLV Type MUST also specify the mechanism by which
   its type extensions are allocated, from among those in [BCP26].

I therefore believe this section to be incomplete.

> Chakeres & Perkins      Expires January 11, 2011               [Page 36]
> 
> Internet-Draft                    DYMO                         July 2010
> 
> 
> 7.3.  Address Block TLV Specification
> 
>                           Address Block TLV Types
> 
>    +---------------+-----------+-----------+---------------------------+
>    |      Name     |    Type   |   Length  | Value                     |
>    +---------------+-----------+-----------+---------------------------+
>    |      DYMO     |  9 - TBD  |    DID    | ThisNode.DID's value.     |
>    |   Identifier  |           |   length  | More information can be   |
>    |     (DID)     |           |           | found in Section 5.6      |
Is DID an Address Block TLV? Section 3 and elsewhere says otherwise.

>    | DYMO Sequence |  10 - TBD |  up to 2  | The DYMO sequence num     |
>    |     Number    |           |   octets  | associated with this      |
>    |  (DYMOSeqNum) |           |           | address.  The sequence    |
>    |               |           |           | number may be the last    |
>    |               |           |           | known sequence number.    |
>    |    Distance   |  11 - TBD |  up to 2  | A metric of the distance  |
>    |               |           |   octets  | traversed by the          |
>    |               |           |           | information associated    |
>    |               |           |           | with this address.        |
>    | VALIDITY_TIME |    TBD    |           | The maximum amount of     |
>    |               | [RFC5497] |           | time that information can |
>    |               |           |           | be maintained before      |
>    |               |           |           | being deleted.  The       |
>    |               |           |           | VALIDITY_TIME TLV is      |
>    |               |           |           | defined in [RFC5497].     |

I would insist that VALIDITY_TIME is *not* "TBD" As RFC5497 defines this already. Consequently, I think it should not be listed in the IANA considerations section?

Do you use the Address-Block or Message version of this?

>    +---------------+-----------+-----------+---------------------------+
> 
>                                   Table 8
> 
> 
> 8.  Security Considerations
> 
>    The objective of the DYMO protocol is for each router to communicate
>    reachability information to addresses for which it is responsible.
>    Positive routing information (i.e. a route exists) is distributed via
>    RMs and negative routing information (i.e. a route does not exist)
>    via RERRs.  DYMO routers that handle these messages store the
>    contained information to properly forward data packets, and they
>    generally provide this information to other DYMO routers.
> 
>    This section does not mandate any specific security measures.
>    Instead, this section describes various security considerations and
>    potential avenues to secure DYMO routing.
> 
>    The most important security mechanisms for DYMO routing are
>    integrity/authentication and confidentiality.
> 
>    In situations where routing information or router identity are
> 
> 
> 
> Chakeres & Perkins      Expires January 11, 2011               [Page 37]
> 
> Internet-Draft                    DYMO                         July 2010
> 
> 
>    suspect, integrity and authentication techniques SHOULD be applied to
>    DYMO messages.  In these situations, routing information that is
>    distributed over multiple hops SHOULD also verify the integrity and
>    identity of information based on originator of the routing
>    information.
This is really difficult to do, in case messages are mutable in-transit, which appears to be the case for RERR and RM's; i.e. for all DYMO messages. For that reason, using SHOULD is - imo - dangerous here. Also, for that reason, I think that this issue of mutable messages deserves being called out explicitly in this section, especially if there are known or recommended ways of handling this (as is the case, for example, in the security considerations section of RFC5444 regarding the mutable header fields for hop-count/hop-limit of messages.
>    A digital signature could be used to identify the source of DYMO
>    messages and information, along with its authenticity.  A nonce or
>    timestamp SHOULD also be used to protect against replay attacks.
>    S/MIME and OpenPGP are two authentication/integrity protocols that
>    could be adapted for this purpose.
> 
>    In situations where confidentiality of DYMO messages is important,
>    cryptographic techniques can be applied.
> 
>    In certain situations, like sending a RREP or RERR, a DYMO router
>    could include proof that it has previously received valid routing
>    information to reach the destination, at one point of time in the
>    past.  In situations where routers are suspected of transmitting
>    maliciously erroneous information, the original routing information
>    along with its security credentials SHOULD be included.
> 
>    Note that if multicast is used, any confidentiality and integrity
>    algorithms used must permit multiple receivers to handle the message.