Summary: Needs a YES. Has 3 DISCUSSes. Needs 5 more YES or NO OBJECTION positions to pass.
Comment (2014-06-21 for -06)
I have a couple of questions about the use of 2119 "MAY" below; I think it's
important to resolve them, so please consider these comments.
-- Section 8 --
messages MAY be sent as above, or MAY be sent to a site-local all-
MLE-nodes multicast address (to be assigned by IANA).
Or they may be sent in any other way, as those "MAY"s specify optional
behaviour -- so you MAY also do neither. Is that the intent? Or is the intent
that one can choose, at one's option, between those two choices, but no other?
If that's what's meant, let me suggest this instead:
messages MUST either be sent as above, or be sent to a site-local
all-MLE-nodes multicast address (to be assigned by IANA).
What is the line that says "MAX_RESPONSE_DELAY_TIME 1 second" meant for?
Should there be some other text around it?
Similarly for the table: should the previous paragraph have an additional
sentence that says, "The following are recommended default values for relevant
timeout and retransmission parameters."? I think this would read better with
an explanation such as that.
-- Section 10 --
If large numbers of Link Request messages arrive
a device MAY reduce or completely suspend sending Link Accept
messages, and MAY send Link Reject messages instead.
This is a similar double-MAY to the previous one, and it brings up a similar
question: as written, it says: 1. If large numbers of Link Request messages
arrive, a device has the option of reducing or completely suspending sending
Link Accept messages. 2. If it does that, it has the option of sending Link
Reject messages instead. It also has the option of not sending Link Reject
messages instead. It could, for example, not respond at all, or respond in
some other way.
Is that what's intended? Or is it intended that if it stops sending Link
Accepts, it will always send Link Rejects? If so, then just removing the
second "MAY" will fix it.
Discuss (2014-06-25 for -06)
I have no objection to the publication of this document, but there are some
points that need work...
1. In section 6, it is unclear as to how Command Type 2 differs from a
combination of Command Types 0 and 1. In what instances would a sender use
Command Type 2? It seems to me that this *could* be an exchange like: 1) A
sends CT==0 to B, 2) B sends CT==2 to A, and 3) A sends CT==1 to B. Is that
the expected usage? If so, it should be explained. I was expecting to see
Section 10 do that, but that didn't materialize.
2. Some of the specified Command Types and TLVs are obviously link-local in
nature. Are there Command Types and TLVs that are only network-wide? I would
like to see some description of how far each of the Types and TLVs should be
3. This is related to Barry's comment about destination address selection.
Section 8 should tighten up the guidance on address selection. This should be
tied to the point raised in #2 above, in that the destination address needs to
take the scope of the information contained in the message into account.
4. It is unclear to me what Section 9 is saying about "reserved Command Types"
and "reserved TLV Types". Are those just values that are not recognized?
Discuss (2014-06-26 for -06)
The draft seems okay, although I'd like to understand why there isn't a
stronger requirement around replay protection or see that fixed with stronger
language. The Security Considerations section says:
Because of this, implementers must
be careful in how they use information obtained from these possibly-
replayed messages. For example, information from unsecured messages
should not be used to modify any stored information obtained from
and section 7.4 provides a way to do this with a challenge:
The recommendations in [RFC4086] apply with
regard to generation of the challenge value. The byte string MUST be
at least 4 bytes in length and a new value MUST be chosen for each
Challenge TLV transmitted. An important part of replay protection is
determining if a newly-heard neighbor is actually present or is a set
of recorded messages. This is done by sending a random challenge
value to the neighbor and then receiving that same value in a
Response TLV sent by the neighbor.
Discuss (2014-06-26 for -06)
I'm not familiar with 802.15.4 security sorry, so you
may need to educate me a bit, and I had to review this
in a hurry so might be wrong below (and sorry again:-)
but I had the following questions to discuss:
(1) I don't get why its ok that there is no key
management defined, either here or somewhere else via
reference. That could be fixed via some more text in
section 3 perhaps, if there are other specs that do
define how to do key management, e.g. to reference one
(or more) that do define that and to say that other
uses of this need to do similarly. Absent that, maybe
we're back to looking at BCP107, but I'm not sure we
want to (or hopefully, need to:-) go there.
(2) The overall security model is a bit complicated, I
wasn't clear whether the combinations of security
being on and off (i.e. initial byte = 0 or 255) adds
up to a good outcome. There are also cases (e.g.
joining) where where MLE security MUST NOT be used but
link layer MUST be used. Has someone done an analysis
of how that all stacks up together? Can you point me
at that? (Sorry for the fairly vague question.)
(3) As a particular case of (2), I don't get how the
device joining without any keys thing is meant to
work, nor under exactly what conditions. Don't you
need to specify this or at least state the
requirements for it to work if specified elsewhere?
(4) I'm not clear that the frame counter + key cannot
repeat, esp. since we don't have the key management
detail here and that there seems to be a way for one
node to tell another which frame counter value to
start from (is that right or is that just telling a
new peer what my current frame counter is at? If the
latter, why not just get that by observation?). I do
see you say that they MUST NOT be repeated, but if
there are shared keys over >1 device, or, if its
allowed to not use the same frame counter for link and
MLE but is allowed to use the same key, then that may
not be implementable.
Comment (2014-06-26 for -06)
- section 9, 2nd para: I don't get the last sentence
there - what does it mean?
Discuss (2014-06-26 for -06)
I am sorry that I have only had time for a very brief review of this document.
I should be happy if you are able to say that any of my Discuss points is
rubbish based on my reading too fast.
The purpose of the third, detecting neighboring
devices, is to make link management more efficient by detecting
unreliable links before any effort is spent configuring them.
Do you not think "detecting neighbor devices" is an odd name for a
feature which is intended to detect unreliable links before any effort
is spent configuring them?
Similarly the title of section 4.3.
Isn't this link discovery? (A link not being an interface :-) For
example, suppose there are two links that reach the same neighbor?
But in section 8...
and advertisement messages MUST be sent with an IP Hop Limit of 255,
either to a link-local unicast address or to the link-local all-nodes
(FF02::1) or all-routers (FF02::2) multicast addresses.
...I believe that what you are defining is effectively a link state
protocol by full flooding. This is not a discovery protocol. I am very
wary of such a protocol being defined (we have been there before and it
At the very least, this document needs to be clear whether it is a
discovery protocol, a link parameter negotiation/discovery protocol, or
a link parameter flooding protocol. In the latter case, I would like the
document to explain the scope and purpose of this wholesale flooding.
On the other hand, part of the problem may be that you intend that MLE
should be able to send (from a central location) configuration
information that is to be used at each node (or some set of nodes) in
the network. Section 11 gives this hint. Yet that is a very different
use of the protocol and many features of that operation (such as how
thrashing between two senders is handled) are left for the reader to
Section 5 needs to indicate how a parser knows the length of an MLE
message. How do I know when to stop parsing TLVs and start parsing the
MIC (in the 0 case) or stop parsing the message (in the 255 case).
With the exceptions of the Source Address TLV and Parameter TLV, an
MLE message MUST NOT contain two or more TLVs of the same type.
You need to say how such errors are handled.
However, I think you have hamstrung yourself for the future. Why not add
a column to the registry that says "Multi-occurrence allowed" and then
state that RFCs defining new TLVs must state whether multiple occurrences
The Source Address TLV (TLV Type 0) has a Value containing a byte
string representing a link-layer address assigned to the source of
Does "a byte string representation" have a specific meaning in the
context of IEEE 802.15.4? To me it is not specific enough to write code.
"encoded as an N-bit unsigned integer."
This is curious as the TLV length can only indicate full octet lengths.
Is N allowed to be other than an integer multip of 8?
Size The size in bytes of the included neighbor link-
layer addresses, minus 1. This supports
addresses of lengths 1 to 16 bytes.
This is ambiguous. Do you mean the total size of all addresses, or the
size of a single address with the requirement that all addresses must be
the same size?
Yet later in the same description of the data format...
Address A link-layer address of a neighbor.
... which says that only one address is present (and misnames the field
compared to the figure).
Value A byte string containing the new value of the
parameter. The format of this value is
determined by the particular parameter
And yet the formats don't appear to be described when the parameters
are listed later in the section.
7.9. MLE Frame Counter
The MLE Frame Counter TLV (TLV Type 8) has a Value containing the
sender's current outgoing MLE Frame Counter, encoded as an 32-bit
What is an MLE frame? Is this a count of messages or L2 frames or...?
How does this wrap?
When is it reset?
Is the 32 bit integer in line format?
Section 5 gives some information about this with cross-pointers to [CCM]
Section 9 tells us how to handle received frame counters.
But 7.9 needs to point to these other sections, and Section 8 should
explicitly state about setting the counter.
Comment (2014-06-26 for -06)
I wish this document had been scrubbed for acronym expansion so that I
could have reviewed it more easily.
MLE can also be used to distribute configuration values that are
shared across a network, such as the channel and PAN ID. Network-
wide configuration uses multicasts and requires some form of multi-
hop multicast forwarding. These messages are sent infrequently, so
forwarding with simple flooding is sufficient.
This is a confusing paragraph:
- "MLE can also be used..."
There has been no previous mention of MLE. What does "also" mean?
- "Network-wide configuration uses..."
Do you mean "MLE uses..."
- "These messages...."
I find the definition of ETX confusing. You have...
ETX Expected Transmission Count [RFC6551]; the number
of transmission attempts required to send a
packet over a particular link. Defined to be the
product of the IDR values for both directions. A
perfect link has an ETX of 1, less than perfect
links have higher ETX values.
If ETX is the product of IDR in both directions then ETX is a complex
characteristic of both directions of the link. Yet the definition says
the number of transmission attempts required to send *a* packet. A
single packet is, of course, sent in a single direction and the quality
of the link in the other direction doesn't matter. But, presumably,
since you want ETX to be a characteristic of both diretions you need to
rephrase this definition.
MLE adds three capabilities to IEEE 802.15.4:
o Dynamically configuring and securing radio links.
I don't believe MLE secures links. I believe MLE exchanges parameters
for the SA between link ends that allows security to be used on the
Network-wide changes to radio parameters, such as moving the network
to a new channel, is done by multicasting the new value(s) to all
devices in the network.
Really? All devices in the network?
Surely a device 27 hops away is less than interested in the channel
being used on this link.
I find Section 5 confused/confusing.
The section seems to have two purposes:
- defining the MLE message formats
- describing how the MLE messages may themselves be secured.
It may be as simple as fixing the section title and tweaking the text.
[CCM] requires that each key and nonce pair be
used exactly once
You mean for just one packet? No, you don't! Please clarify the text.
It would be nice if Section 6 pointed to Section 14.2
The recommendations in [RFC4086] apply with
regard to generation of the challenge value.
This is done by sending a random challenge value
These to statements may be interpretted as conflicting. At best you
are saying the same thing twice.
While the Link-layer Frame Counter in section 7.6 probably has well-
known meaning to those in the know, I think you need more description
to let coders understand what they are supposed to put in one of these
Res Reserved; MUST be set to 000 and SHOULD be
ignored on receipt.
Normally the MUST and SHOULD are the other way around.
In this spec, why would you not ignore the received reserved field that
has been set to zero?
MLE messages SHOULD be sent using the assigned UDP port number
(19788) as both the source and destination port.
Are you sure you want to confine the source port in this way? In general
this turns out to be a mistake.
Incoming messages whose Command Type is a reserved value MUST be
ignored. Any TLVs in an incoming message whose TLV Type has a
reserved value MUST be ignored.
I think "reserved" means "unknown" or "unsupported" in both cases.