Subject: [manet] Review of draft-kelsey-intarea-mesh-link-establishment-04

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 22 Oct 2012 20:15:53 +0200

Dear all,

Kindly find my review of the I-D in <subj> below. Note that I have reviewed an earlier version of this document (I believe it was -02) as well, and the authors were quite reactive to my comments (thanks, Richard!).

Ralph, this review is identical to the one you received in unicast a few days ago. As you ask on the [manet] mailing list, I re-send my review to that list to be "publicly on the record".

My main worry is, that MLE seems to overlap substantially with the scope of RFC6130, and that is something which I would want to see clarified before moving forward.

As usual, textual comments below, an annotated PDF attached.

Respectfully yours,

Thomas

See file attached to this message

File: 121018 - THC Review - draft-kelsey-intarea-mesh-link-establishment-04-1 - flattened.pdf

Annotation summary:

--- Page 1 ---

Highlight (yellow), 18 oct. 2012 13:30, TClausen:
ad hoc mesh network

Note (yellow), 18 oct. 2012 13:30, TClausen:
I'm being a nitpicker here, but: ad hoc mesh network? Is that the same as a mobile ad hoc network? Or is it something else? Or, is it - like LLNs - a subset of a mobile ad hoc network?

I guess that this ties in with trying to understand where this fits into the IETF picture. I am repeating myself here from my last review, but so far this sounds like something that belongs in [MANET]. This comment, probably, is to the sponsoring AD more than to anything else, but this document does seem like something that would belong in a working group, and it does seem like there should be at least one working group, in which this would be "in scope".

I understand that the [MANET] and [ROLL] wg chairs have refused to accept this document, even discuss it in meetings. I would assume that they have good reasons? If not, then I would recommend that they be "encouraged". 

Highlight (yellow), 18 oct. 2012 13:30, TClausen:
Internet Area WG

Note (yellow), 18 oct. 2012 13:30, TClausen:
1) Is that true?
2) Isn't tradition that all I-Ds are published in the "Networking Working Group"?

Note (yellow), 18 oct. 2012 13:30, TClausen:
I am making the same comment as I did in my previous review: from reading the abstract, this looks very very much like RFC6130 except for the configuration parameters -- which, as I think I have indicated, is something that could simply be additional TLVs for RFC6130.

I think that, at the very very least, why a different (from RFC6130) approach is taken should be clear even from the abstract.

Note (yellow), 18 oct. 2012 14:37, TClausen:
I have a couple of overall comments:

o    This document sorely needs an
applicability statement. There are bits and
pieces scattered through the document, 
that can constitute parts of an applicability
statement, but even that is not 
sufficient

o    The document seems to claim to be
supporting multiple L2s, but in many places
looks as if designed for one specific L2
(PAN ID, Security, ...). This is not at all
appropriate.

o    I am also missing some sort of overview-
and-functioning section. There seems to
be a number of different signaling 
components (request network parameters/ 
reply ; periodic beaconing of ETX 
parameters, security negotiation....) each 
of which having different signaling 
semantics.

--- Page 3 ---

Highlight (yellow), 18 oct. 2012 13:30, TClausen:
recommend (NHDP) that their messages be sent over secured links

Note (yellow), 18 oct. 2012 13:30, TClausen:
As one of the authors of RFC6130, this is quite simply not true.

If you have secured links, then sure, RFC6130 can use that. 

Absent secured links, RFC6130 suggests adding TLVs containing authentication (using RFC6622 - the actual spec for using RFC6622+RFC6130 is being developed by [manet] currently]).

So, this is not a distinguishing feature for MLE-vs-6130, and thus not a valid motivation for MLE.

Highlight (yellow), 18 oct. 2012 13:30, TClausen:
already-configured links

Note (yellow), 18 oct. 2012 13:30, TClausen:
I am actually not sure what this means.

NHDP makes few assumptions as to what the underlying link layer does, other than support broadcast transmissions.  The L2 may do "stuff" (negotiate interface speeds, or some such thing).

Allow me also to ask: when you say "link", what exactly is meant? In NHDP, it  is simply "any two interfaces, able to communicate with each other". ND has a very different understanding of link.

Highlight (yellow), 18 oct. 2012 13:30, TClausen:
IP properties

Note (yellow), 18 oct. 2012 13:30, TClausen:
ND, yes - NHDP, not so much. 

Note (yellow), 22 oct. 2012 20:06, TClausen:
So this sounds like a channel-estimation protocol of sorts. Is that related to the ETx estimations? 

I remember on manet@ietf that there has been some contention as to what the proper information exchange is for evaluating such, has this been reflected?

Highlight (yellow), 18 oct. 2012 13:30, TClausen:
multicast

Note (yellow), 18 oct. 2012 13:30, TClausen:
Observing also, that different L2's

Note (yellow), 18 oct. 2012 13:30, TClausen:
Observing also, that different L2's treat unicast and broadcast differently: transmission rates, retransmissions, ....

--- Page 5 ---

Note (yellow), 18 oct. 2012 13:30, TClausen:
So, at this point, you are with MLE at the same point as NHDP: if a device has an IP address, it can participate in NHDP. For MLE to use UDP, this would be the same.

The message exchange in NHDP serves to establish, for a router and over each interface, the "links" to neighbors. The minimum property that is established by NHDP is bidirectional connectivity, but this is by design - and for further properties (such as ETX, if needed) can be done by TLVs.

Again, my point is not saying "thou shalt use" another protocol, but I would very much like for it to be clearly spelled out in which way this is not "old wine in smaller bottles".

This very much links in with the lack of an applicability statement in this document, which is an absolute must given what appears to be a strong overlap with what other protocols do.

--- Page 6 ---

Note (yellow), 18 oct. 2012 13:30, TClausen:
Is this not something that should be parametrized and set up IANA registries? I see that you agree, there is a registry. In that case, I would recommend to not specify these security suites in the main part of the document, but simply hive those specifics off to the IANA registry, and define the interface between MLE and these suites?

In other words, I would avoid "this document describes two security suites"

Note (yellow), 18 oct. 2012 13:30, TClausen:
So is this specific to 802.15.4, or is it general?

Again, this is one bit that would benefit from having a proper applicability statement. So far in this I-D, one could get away with the impression that it was for "general L2s", but this seems to indicate otherwise?

Note (yellow), 18 oct. 2012 13:30, TClausen:
Is the length of that constant? For all security suites? When not running over 802.15.4?

Highlight (yellow), 18 oct. 2012 13:30, TClausen:
MUST NOT

Note (yellow), 18 oct. 2012 13:30, TClausen:
Why is that? A bit of education here, please...

--- Page 7 ---

Note (yellow), 18 oct. 2012 14:37, TClausen:
This reads like a "mini-IANA section", embedded into the middle of the document.

I vividly recommend, in the IANA section, to define values, mnemonics, and descriptions, and use the mnemonics in the document. 

That way, when IANA assign numbers, there is less space for confusion in editing.

--- Page 8 ---

Note (yellow), 22 oct. 2012 20:06, TClausen:
This is incoherent. The section is entitled "values", yet the content is the TLV format. Suggest changing to "TLV Format"

Note (yellow), 18 oct. 2012 14:37, TClausen:
Reference to IANA registry, wherein these TLVs are defined.

Note (yellow), 18 oct. 2012 14:37, TClausen:
A question: is multiple TLVs with the same type permitted or not? Or, must that be specified for each TLV type?

I would suggest that the general rule be given here, if it is "must be specified for each TLV type", then this should be called out -- and, the document MUST in that case say that "each TLV type defined MUSt specify if it is permitted to have more TLVs of that type in a given message" - or something.

For all of the below, references to IANA section, by way of mnemonics, not number-values, are required.

Note (yellow), 18 oct. 2012 14:37, TClausen:
Is this represented in the same TLV (and how), or by way of including multiple TLVs of that type?

Note (yellow), 18 oct. 2012 14:37, TClausen:
1) presumably, only one TLV of that type may exist in a message?
2) how are all those different kinds of information encoded in this TLV?

Highlight (yellow), 18 oct. 2012 14:37, TClausen:
specific to the link layer in use

Note (yellow), 18 oct. 2012 14:37, TClausen:
This is a no-go.

While it may be specific to the link-layer, you need this specified somewhere; as it is, I couldn't implement it.

Also, you previously - with respect to security - seemed to link the protocol very tightly to 802.15.4, so this seems to be an internal contradiction?

Finally, you presumably will only want one of these per message?

Note (yellow), 18 oct. 2012 14:37, TClausen:
You presumably will only want one of these per message?

--- Page 9 ---

Note (yellow), 18 oct. 2012 14:37, TClausen:
I cannot figure out if you want only one, or more, of these TLVs in a given message....I would imagine that you would need more than one in some circumstances?

Highlight (yellow), 18 oct. 2012 14:37, TClausen:
each

Note (yellow), 18 oct. 2012 14:37, TClausen:
Each TLV in the same, or in different, messages?

Note (yellow), 18 oct. 2012 14:37, TClausen:
Presumably, you should want this in the security considerations section?

Note (yellow), 18 oct. 2012 14:37, TClausen:
In that case, same comment as above regarding how many TLVs, as well as discussion in the security considerations section apply here as well.

Note (yellow), 18 oct. 2012 14:37, TClausen:
Presumably, you want only one of these in a message?

Note (yellow), 18 oct. 2012 14:37, TClausen:
Presumably, you want only one of these in a message?

--- Page 10 ---

Note (yellow), 18 oct. 2012 14:37, TClausen:
How should this be set when transmitting, or interpreted when received?

Usually "Reserved, and MUST be set to 000 on transmission and SHOULD be ignored on receipt to be in compliance with this version of the specification" is the used phrase.

Note (yellow), 18 oct. 2012 14:37, TClausen:
1 to 16 what? Octets? Gigabytes? ;)

Note (yellow), 18 oct. 2012 14:37, TClausen:
OK, so here you give guidance as to what is the expected behavior, and that is good.

On the other hand, why "SHOULD NOT" and not "MUST NOT"? 

I am of the mind that unless there are really compelling reasons (in which case, these reasons should be spelled out, as well as their consequences), it should be MUST/MUST NOT. As it is, I have not managed to come up with a compelling reason as to why one would want to not write MUST NOT here.

UNLESS, that is, that these are broad/multicast, in which case I would imagine that one would need one such TLV per neighbor (and it should be specified to be exactly one per neighbor)?

--- Page 11 ---

Note (yellow), 18 oct. 2012 14:37, TClausen:
This bit appears underspecified, to say the least. Either you describe how to do that precisely later, or it has to be described here.

Also, I infer that there can be multiple of this TLV type in a given message?

Note (yellow), 18 oct. 2012 14:37, TClausen:
Again, why not must?

Highlight (yellow), 18 oct. 2012 14:37, TClausen:
SHOULD be multicast to the  entire MLE domain.  They MAY also be 

Note (yellow), 18 oct. 2012 14:37, TClausen:
Suggest:

"SHOULD be multicast to the entire MLE domain, except for when a node that has just joined the network, in which case a Network Parameter TLV MAY be unicast to that node".

--- Page 12 ---

Note (yellow), 18 oct. 2012 14:37, TClausen:
Another IANA registry to set up, as well as mnemonics, reference, ...

Highlight (yellow), 18 oct. 2012 14:37, TClausen:
PAN

Note (yellow), 18 oct. 2012 14:37, TClausen:
This reads as if linked to a specific L2?

Note (yellow), 18 oct. 2012 14:37, TClausen:
Again, presumably just one permitted per message?

--- Page 13 ---

Note (yellow), 18 oct. 2012 14:37, TClausen:
Under which conditions is is acceptable to not do thus?

Note (yellow), 18 oct. 2012 14:37, TClausen:
No, this is a MUST - otherwise, interoperability can't be ensured.

Note (yellow), 18 oct. 2012 14:37, TClausen:
Suggest "sent using the MLE-port, and then define MLE port in IANA and request the assignment there?

Note (yellow), 18 oct. 2012 14:37, TClausen:
Suggest sticking a reference into the document, to the RFC defining those.

Highlight (yellow), 18 oct. 2012 14:37, TClausen:
MAY

Note (yellow), 18 oct. 2012 14:37, TClausen:
How many times? Minimum and maximum intervals? This MUST be defined. I do not think that the reference stuck in suffices.

--- Page 15 ---

Note (yellow), 18 oct. 2012 14:37, TClausen:
So, a couple of different things...

What is the appropriate behavior if one receives two identical TLVs? With conflicting values? Can such be discarded?

This section does not specify what one does with an incoming message other than security (and, even that is very weakly defined). I would, at the very least, expect a protocol set / information set defined, that represents the values received, and which is updated according to the message exchange.

I understand that this may be something that a "smart implementer can think out herself", alas, while that may well be true, I do not find it sufficient. In part, an information set defined would give the interface to the rest of the system (in which I believe that this integrates?). As it is, it's insufficient.

--- Page 16 ---

Highlight (yellow), 18 oct. 2012 14:37, TClausen:
This section is not normative

Note (yellow), 18 oct. 2012 14:37, TClausen:
In that case, I would suggest that it be stuck into an appendix.....

--- Page 19 ---

Note (yellow), 18 oct. 2012 13:30, TClausen:
Recommended reading: RFC58

Note (yellow), 18 oct. 2012 13:30, TClausen:
Recommended reading: RFC5226.

Also, ther

Note (yellow), 18 oct. 2012 13:30, TClausen:
Recommended reading: RFC5226.

Also, Are you sure that IETF review is what you want, it seems fairly restrictive to me -- would allocating a few code-points as "experimental" and a good lot for "expert review" (with proper guidelines) not be a good idea?

Generally, a couple of code-points for experimental use is a good thing. 

I am not a security wonk, so I do not know - but are all security related suites translated into RFCs (which are a necessary precondition for IETF Review)?

Note (yellow), 18 oct. 2012 14:37, TClausen:
Recommended reading: RFC5226.

Also, Are you sure that IETF review is what you want, it seems fairly restrictive to me -- would allocating a few code-points as "experimental" and a good lot for "expert review" (with proper guidelines) not be a good idea?

Generally, a couple of code-points for experimental use is a good thing. 

I am not a security wonk, so I do not know - but are all security related suites translated into RFCs (which are a necessary precondition for IETF Review)?

Finally, I have given comments through the I-D that it is greatly preferred to define mnemonics for each code-point, and use those through the document - leaving actual numbers for IANA to manage.

Note (yellow), 18 oct. 2012 14:37, TClausen:
Subregistry of what?

There are, as I see it, two distinct options:

A registry under MLE
A registry under each command code.

It is not clear to me what it is, how you define your namespace here, so this should be clarified.

(report generated by GoodReader)

Sent from my iPad