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