I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-kelsey-intarea-mesh-link-establishment-05
Reviewer: Ben Campbell
Review Date: 2013-09-16
IETF LC End Date: 2013-09-16
Summary: This draft is almost ready to be published as a proposed standard.
There are a few minor issues that should be considered prior to publication.
General: The draft is well written, and easier to read than many internet
drafts.
Major issues:
none
Minor issues:
-- Applicability Statement
The applicability statement seems a bit lightweight. I understand it is
needed for some other IETF work; it might be nice to mention the specifics here
(or in the introduction.) The assertion that this "extends 802.15.4" makes me
wonder why this is an IETF effort rather than IEEE 802 effort--some IETF
context would help.
-- section 5, 1st paragraph: "To avoid the cost and complexity of adding a
second security suite, MLE reuses that of 802.15.4. This document describes
two security suites..."
The two sentences seem to contradict. Is this document describing security
suites that are already in 802.15.4, or is it adding new ones?
-- section 7.8: Delay
Can you offer guidance on how to choose a delay value?
-- section 7.9, paragraph starting with "Update messages SHOULD..."
What is the rational for SHOULDs instead of MUSTs? Can you offer guidance on
when it might make sense to violate these? What might happen if one does?
-- section 8: "Outgoing link configuration and advertisement messages SHOULD be
secured..."
Can you be more precise than "secured"? Does this mean "signed", "encrypted",
or both? Also, what would be the consequences of violating the SHOULD?
-- section 8, paragraph 6: "... MUST be delayed by a random time between 0 and
MAX_RESPONSE_DELAY_TIME seconds."
What's a reasonable resolution for that random time? I note that
MAX_RESPONSE_DELAY_TIME is set to 1 second. I assume a random number between
zero and one is not what you have in mind. :-)
-- section 8, paragraph 9: "Because MLE messages do not require complex
processing and are not relayed, a simple timeout scheme is used for
retransmitting."
You mention forwarding multiple hops two paragraphs back; do you mean something
different here? There are other mentions of forwarding in the draft that makes
me wonder about the assertion that messages "are not relayed".
-- section 8, last paragraph:
Can you offer guidance on an appropriate resolution for the random multiplier?
-- section 9, paragraph 3: "Unsecured incoming messages SHOULD be ignored."
Why not MUST? Also does this imply the requirement to secure messages in the
first place should have been MUST?
-- section 9, paragraph 4: " A device SHOULD maintain a separate incoming MLE
frame counter for each neighbor."
What happens if it doesn't?
-- Security Considerations:
I'd like to see a bit more on the consequences of accepting unsecured messages.
The normative requirement says SHOULD NOT accept unprotected messages, instead
of MUST NOT, so I assume that you contemplate that implementations may have
reasons to accept unsecured messages.
It's also worth some discussion of securing at the 802.15.4 layer vs at the MLE
layer, since that's mentioned a few times in the draft
Nits/editorial comments:
-- section 4.1, 1st paragraph: " ... (addresses, node capabilities, frame
counters)..."
Is that list exhaustive or exemplary? A "that is" or "for example" would help.
Also, missing a conjunction before last element.
-- section 7.8, last line: "Values to be confirmed..."
Do you expect that to be removed prior to publication? If you think that IANA
might not confirm the values, it might be better to use placeholders that refer
back to the IANA Considerations section. (Note that this occurs several times
throughout the draft.)