The Optimized Link State Routing Protocol Version 2
draft-ietf-manet-olsrv2-19

No objection to the publication of this document.
However, I would appreciate an answer/discussion on the following two points.

1. 
When reading about MPRs, the first question I asked myself was: why two distinct devices for the two MPR types (flooding and routing). I found some information in the draft:

   When possible (in particular if using a
   hop count metric) the same routers may be picked as both flooding
   MPRs and routing MPRs.

And in section 18.1:

   Each router MAY select its flooding and routing MPRs independently
   from each other, or coordinate its selections. 

However, the draft doesn't really explain the pros/cons of one versus two devices.
At first glance, I was thinking: "why do I want to have two different devices in dynamic topology: it simply going to add a level of complexity?". Maybe there are some other cases where link speed is involved.
A few words about this would be appreciated.

2.
More of clarifying question to start with. Not sure if there is a problem.
Since "OLSRv2 retains the same basic mechanisms and algorithms, enhanced by the ability to use a link metric other than hop count in the selection of shortest routes", I was wondering about the metric semantic.
Looking at this sentence:
   "This specification does not define the nature of the link metric.
   However, this specification allows, through use of the type extension
   of a defined Address Block TLV, for link metrics with specific
   meanings to be defined and either allocated by IANA or privately
   used."
I was expecting an IANA registry with the different metric types. What do I miss?
Or "Table 3: LINK_METRIC TLV definition" is really a placeholder for a metric, and we have no idea about the semantic? If this is the case, don't we run the risk that parts of the network have different configured metric types (hop count versus OSPF-like cost).

Disclaimer 1: I'm not a MANET expert
Disclaimer 2: I glanced through some parts of the draft.

Thank you for addressing my DISCUSS.

Throughout the document, there are references to assorted "time" values, but nowhere that I can find is there an explicit granularity requirement. Is the granularity documented elsewhere and therefore so obviously understood to be seconds by the MANET community that it is not worth mentioning in this document? If not, it might be worth mentioning.

I find all of the MUSTs and MAYs in the definitions of section 2 weird. For example:

      A router MUST be able to distinguish a routable address
      from a non-routable address by direct inspection of the network
      address, based on global scope address allocations by IANA and/or
      administrative configuration.  Broadcast and multicast addresses,
      and addresses which are limited in scope to less than the entire
      MANET, MUST NOT be considered as routable addresses.  Anycast
      addresses may be considered as routable addresses.

I'm trying to figure out what it would mean for a router to be unable to distinguish routable from non-routable addresses. What are the interoperability considerations here? "Considering broadcast and multicast addresses as routable" seems problematic in general, not just for this protocol. Aren't you simply saying that routers that implement this protocol will need to distinguish routable and non-routable addresses? Either way, why is this protocol instruction in the definitions section? Sounds like it should be in a "Basic Requirements" section if it needs to be a protocol requirement.

5.1

   TC messages and HELLO messages [RFC6130] MUST, in a given MANET, both
   be using the same of either of IP or UDP, in order that it is...

Don't you mean, "TC messages and HELLO messages [RFC6130] will all use either IP or UDP in a given MANET in order that it be..."? I don't see what the MUST is doing in this sentence. The sentence is a statement of fact, not a protocol directive.

16.3.3.1 - 16.3.3.4: "The router MUST update its...". I always find MUSTs of this sort weird. It's not really a protocol requirement to update the internal state of the router. It's the behavior of the router that's the protocol requirement. These probably simply don't need MUSTs, though perhaps rewording is in order. But these sorts of MUSTs seem to appear throughout sections 7 through 12 anyway (requirements for local implementation of information bases), so perhaps this ship has sailed long ago in the MANET work.

Thanks for addressing my discuss points and later comments.