Subject: Re: [manet] DYMO review comments

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 22 Oct 2012 12:46:53 -0700

Hello Thomas,

Thanks for the detailed review, and please excuse the long delay.
I'm on it now.  Many of these points are already fixed in the
new draft, but some of the important points require more time
than I can spend on it today.

On 7/28/2010 11:07 AM, Thomas Heide Clausen wrote:

> General comments:
>
> oI 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).

Agreed.  I have started to do this.

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

This will require another rigorous proofreading after
today's submission of the reorganized draft, but I do fully
agree with your point.

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

The difference is that AODVv2 routers are allowed to route on
behalf of other nodes that are not AODVv2 routers.  This point
of confusion has been observed by others, and I intend to make
it perfectly clear ASAP.

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

It certainly is not intended to preclude other RFC5444 protocols
from running.  I have already cleared up this language in a
number of places in the draft.  Typically, language has to be
changed from "discarding a packet" to "ignoring a message".

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

Generally, the IP address would mean that of the sending interface.
If an interface has several addresses, then I expect that the
choice may not matter very much.  If there are cases where the
choice does matter, then I need to figure out how to insure that
the choice is done interoperably.

> oFinally, 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:
> oDo FOO;
> otherwise:
> oDo 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.

I also prefer bullet point oriented explanations in most
cases where there are more than three points, and even quite
often when there are only two.  I have made several changes
along that direction in the draft.

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

Well, presumably, over other routing protocols that may suffer
from performance issues in the realm of applicability ascribed
to reactive protocols.  Should that be added to the abstract?

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

Hmmm...  I will add a definition for "reactive" so that it is
specified to mean the same thing as "on-demand".  I think the latter
has a more intuitive meaning, but the former works better grammatically
in most places.

>>     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?")

This is a good point.  I will replace "dissemination" by flooding.
Perhaps "disseminate" sounds less "brute force" than "flood".
And anyway it needs to be emphasized that AODVv2 can use better
techniques than brute force for the flooding operation.  This was
also true for AODV, but most people seemed to assume that brute
force flooding was required when it was not.

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

In most cases, "target" is the same as "destination", but there may
be a few cases where it is different.  I need to carefully check
all occurrences.

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

That is a good point.  My belief is that multi-homing would work
just fine, but that needs to be checked.  In the meantime, I have
placed the following sentence in the Applicability section:
       Any such node which is not itself an AODVv2 router SHOULD NOT
       be served by more than one AODVv2 router.

This should also be inserted as an issue in the Issue Tracker.

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

Well, all flooding is hop-by-hop.  There are of course
cases where an AODVv2 router may determine not to retransmit.

>> 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.
> ois this relative to the "originator address" from RFC5444?
> ois this the "originator" of the RREP  or the RREQ?

The originator is the IP address of the node that triggered
the creation of the RteMsg.

RREPs are sent hop by hop but (typically) not flooded.
I think the intention is to mention that RREPs are processed
at every intermediate AODVv2 router.

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

Yes, it's the same.  I changed "sent" to "unicast".

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

AODVv2 is not constrained to create symmetric routes, but
in practice given the operation of RREQ and RREP, the routes
will be symmetric.

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

Here, destination seems proper.

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

Yes, that is the same.  But a route table entry can be marked as Broken.

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

This is a good point.  Perhaps the prudent thing for now is
simply to make all UnreachableNode addresses to be host addresses
and not allow the Prefix to be added.

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

Right now nothing comes to mind.

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

I have added a statement about multihoming.  For security, I think it
is appropriate to make a cross reference to the Security Considerations.
In that section, additional restrictions due to security requirements
would properly be included.

The mandate for persistent storage is "SHOULD".  For devices that
do not have persistent storage, some performance degradation might
be experienced when the procedures for recovering from lost
SeqNum have to be followed.

I think that is a reasonable formulation of the requirement.

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

I can be a little more specific but I do not have the numbers.

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

No, as above they should be treated as having the same meaning.

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

I will add more clarification.

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

Yes, that is correct.  I have added that clarification.

>
>>     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"?

I have used your proposed text.

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

Well, for various technologies, that is done at layer 2.
Generally, AODVv2 attempts to avoid unidirectional links
by using the blacklist mechanism.

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

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

Check.  I would be O.K. to delete it, but I don't think it's
normative, and I don't think it's hurting anything.

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

Good catch!

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

That should not happen.  I will fix it, even if I cannot
get it done today.

>>     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:
>
> oAdjacency 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?

Would it be better to make a normative reference to OSPF in order
to have a specification for this definition?  To my understanding,
without going back and reviewing OSPF just now, the meaning is
the same.

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

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

Routing message is RteMsg, but I need to check if there are instances
whether RERR is also included.

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

I think the original intention was "process", but I have reworded
the places in the draft to avoid using "attend".

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

I think the draft is fine without this definition anyway.
I hope that is O.K.

>>     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" ?

Yes, and I have reworded this passage.

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

The originating node address is used as part of the payload in
some packets where it is not the IP source address of packet.
Trying to find the clearest language to express this has been
tricky.  I'll try to make some alternate suggestion.

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

The intention is to have "ThisNode" as a way to reference the particular
AODVv2 router currently dealing with the mssage even when other router
addresses need to be discussed.  I also feel the terminology is stilted,
but I don't have a better suggestion just at the moment.

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

Thanks, I used your formulation and eliminated "semantics".

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

It is the IP address that ThisNode believes serves as the next hop.
This question has been raised by others.  I think the language is
pretty clear, but I will change "The IP address" to "An IP address"

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

I have eliminated Route.Forwarding.  Thanks for your suggestion.

> 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"?

Thanks, I have used your formulation.

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

Let's discuss this further.  I am O.K. to do this, but I need to
study it to make sure.

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

I agree that the terminology needs to be clarified in many places.

>>
>>     Information found in the table.
> I believe that the above sentence is orphaned?

I fixed that, thanks.

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

Here I am not very sure.  The first thing will be to make the
RFC5444 terminology correspond correctly to RFC 5444.  Getting
rid of "IP." and "UDP." could have some downsides in the rest of
the specification.  I'm not yet visualizing the refactored document
structure -- if you have a more concrete suggestion that would
be appreciated.

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

If not here, then the information could be instead presented at the
end of the "Overview" section.  Another alternative would be a short
section after the Applicability section.

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

Yes, Ulrich has pointed this out.  To fully enable the piggybacking
in the general case would preclude the use of GTSM.  I'd prefer to
get some more feedback from the working group about whether or not
the piggybacking is worth the loss of whatever improvement GTSM
can offer.  I am O.K. either way, but if there is experience showing
that the piggybacking offers improvement in real life I would prefer
to enable the better performance.

...

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

This was supposed to have the conventional meaning.
I've reworded it.

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

Fixed.

>>
>>     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"?

This was essentially inherited from DSR and is a way to include source
route information in an RREP.  I have moved this functionality into
a new section for "Optional Features".

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

Fixed.

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

Ooof.  I can't do that before the submission deadline of today.
I'll try to have this done before the IETF meeting and make a
report.

>
>> 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 think that specifying the arithmetic operation as signed 16-bit
was intended to make this precise.  Since 65000 - 30000 is > 0,
the router would assume the #30000 message was old, and that
it had not received messages #30000-#64999.  That doesn't mean
the messages were 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.

What do you think about signed arithmetic?

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

This was answered above.  However, I added language to the Applicability
statement to explain why persistent storage would be useful.

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

Done.

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

Fixed.

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

Here the meaning is the same, so I used "transmit" instead.

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

I inserted "last".  I didn't find the other places though.

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

I was also puzzled by this, and it was mentioned by others.  It would
be better for all fields to be populated by default values.  I will
make this change, even if I don't find every instance before today's
draft submission deadline.

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

Fixed.

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

I'll be on the lookout for better terminology, but at least it's
not misleading.

>>     The IP.DestinationAddress for RREP is set to the IP address of the
> See comments regarding "Layer Violation" above.

Here is the tradeoff between packet size and message aggregation
that needs to be considered.

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

In those cases the messages are not forwarded.  According to
previous discussion, perhaps "ignored and not forwarded" is
better than "dropped".

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

Yes, mutable fields affect security algorithms for protocol
messages.  I believe this also requires discussion in the
Security Considerations.  It could be that some approaches to
security would preclude mutability, and if that matters then
the mutable fields should be specified to be optional so that
the base protocol is not affected.

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

At the cost of additional useless network load, so I'd say not.

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

I think this was an attempt to enable broadcast/multicast RREP
which was done for various reasons in the past.  For one thing,
it allows utilization of unidirectional components in the routing
path.

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

This is a good question.  I will delete that word.  But it is an
interesting point to think about whether there are cases where small
differences should be tolerated.  This is especially true for other
route metrics.

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

Would you like to suggest some text?  There are a lot of
considerations, and anyway it only matters for intermediate
route repair operations.

>
>>     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)?

Yes.  I will make that clarification.

>> 5.5.4.  RERR Handling
...
>>     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.

I guess that the security requirement for RERR is anyway a little
less strict than, say, for RREP.

>> 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)?

I have deleted this section.  It seems to have no defenders.

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

Sometimes things happen that protocol mandates should not happen,
isn't that possible?  Or did I misunderstand your point?

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

O.K.  I have deleted that sentence and the administrative knob.

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

Presumably an AODVv2 router would have routes to the Internet.
If it gets an RREQ for an Internet address, it can "assume" that
the TargetNode is reachable and send back an RREP for that node.
The initial metric might be more than 1 for that target.

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

It can be made to work, and if some small assumptions are made then
it can work pretty well.  You have a great deal of experience with
this, I am sure, based on your position of chair of the [autoconf]
working group.  But certainly per-host explicit entries are not
needed, and not scalable.

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

Point noted.  Work to do.

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

Work to do.

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

O.K.  I need to fix 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
>>     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.

This is a highly nontrivial point, and I need to review various
things about RFC 5444 that I have not looked at lately.
Nevertheless, I didn't see how "SHOULD" would be "dangerous"
in context (i.e., "In these situations").

-- 
Regards,
Charlie P.