Mesh Link Establishment
draft-kelsey-intarea-mesh-link-establishment-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
06 | (System) | Notify list changed from richard.kelsey@silabs.com, draft-kelsey-intarea-mesh-link-establishment@ietf.org, robert.cragie@gridmerge.com to (None) |
2015-03-26
|
06 | Martin Stiemerling | Request for Last Call review by TSVDIR Completed: Ready. Reviewer: Wesley Eddy. |
2015-01-24
|
06 | (System) | Document has expired |
2015-01-23
|
06 | Ted Lemon | From the author: Please mark it dead. It was part of the ZigBee IP effort, which is fading into oblivion. It can be revived if … From the author: Please mark it dead. It was part of the ZigBee IP effort, which is fading into oblivion. It can be revived if and when it has an active constituency within an IETF working group. I greatly appreciate your efforts, and the efforts of the reviewers. |
2015-01-23
|
06 | Ted Lemon | IESG state changed to Dead from IESG Evaluation::Revised I-D Needed |
2014-08-08
|
06 | Ben Campbell | Request for Telechat review by GENART Completed: Ready. Reviewer: Ben Campbell. |
2014-06-26
|
06 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2014-06-26
|
06 | Stephen Farrell | [Ballot discuss] 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 … [Ballot discuss] 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. |
2014-06-26
|
06 | Stephen Farrell | [Ballot comment] - section 9, 2nd para: I don't get the last sentence there - what does it mean? |
2014-06-26
|
06 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2014-06-26
|
06 | Adrian Farrel | [Ballot discuss] I am sorry that I have only had time for a very brief review of this document. I should be happy if you … [Ballot discuss] 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. ------- Section 4 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... Link configuration 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 sucks!) 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 ponder. --- 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). --- Section 7 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 are allowed. --- Section 7.1 The Source Address TLV (TLV Type 0) has a Value containing a byte string representing a link-layer address assigned to the source of the message. 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. --- Section 7.6 "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? --- Section 7.7 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). --- Section 7.8 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 unsigned integer. 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. |
2014-06-26
|
06 | Adrian Farrel | [Ballot comment] I wish this document had been scrubbed for acronym expansion so that I could have reviewed it more easily. --- Section 1 … [Ballot comment] I wish this document had been scrubbed for acronym expansion so that I could have reviewed it more easily. --- Section 1 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...." Which 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. --- Section 4 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 link. --- Section 4.2 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. --- Section 5 [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 --- Section 7.4 The recommendations in [RFC4086] apply with regard to generation of the challenge value. and 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 TLVs. --- Section 7.7 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? --- Section 8 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. --- Section 9 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. |
2014-06-26
|
06 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
2014-06-26
|
06 | Kathleen Moriarty | [Ballot discuss] 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 … [Ballot discuss] 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 secured messages. 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. |
2014-06-26
|
06 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to Discuss from No Objection |
2014-06-26
|
06 | Kathleen Moriarty | [Ballot comment] The draft seems okay, although I'd like to know why there isn't a stronger requirement around replay protection. The Security Considerations section says: … [Ballot comment] The draft seems okay, although I'd like to know why there isn't a stronger requirement around replay protection. 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 secured messages. 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. |
2014-06-26
|
06 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2014-06-26
|
06 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-06-25
|
06 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-06-25
|
06 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2014-06-25
|
06 | Brian Haberman | [Ballot discuss] I have no objection to the publication of this document, but there are some points that need work... 1. In section 6, it … [Ballot discuss] 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 propagated. 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? |
2014-06-25
|
06 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2014-06-24
|
06 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-06-24
|
06 | Gunter Van de Velde | Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: Fred Baker. |
2014-06-23
|
06 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2014-06-22
|
06 | Ted Lemon | Notification list changed to : richard.kelsey@silabs.com, draft-kelsey-intarea-mesh-link-establishment@tools.ietf.org, robert.cragie@gridmerge.com |
2014-06-21
|
06 | Barry Leiba | [Ballot comment] I have a couple of questions about the use of 2119 "MAY" below; I think it's important to resolve them, so please consider … [Ballot comment] 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 -- Update 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: NEW Update messages MUST either be sent as above, or be sent to a site-local all-MLE-nodes multicast address (to be assigned by IANA). END 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. |
2014-06-21
|
06 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-06-19
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Ben Campbell |
2014-06-19
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Ben Campbell |
2014-06-13
|
06 | Ted Lemon | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::External Party |
2014-06-11
|
06 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Fred Baker |
2014-06-11
|
06 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Fred Baker |
2014-06-09
|
06 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2014-06-08
|
06 | Ted Lemon | Ballot has been issued |
2014-06-08
|
06 | Ted Lemon | [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon |
2014-06-08
|
06 | Ted Lemon | Created "Approve" ballot |
2014-06-08
|
06 | Ted Lemon | Ballot writeup was changed |
2014-06-08
|
06 | Ted Lemon | Changed consensus to Yes from Unknown |
2014-06-08
|
06 | Ted Lemon | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? i) Type of RFC Requested: Proposed Standard ii) It is the proper type of RFC because the document describes a communications protocol iii) The type of RFC is indicated in the title page header (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. MLE is a protocol for link-layer configuration, including link layer addressing, transmit and receive modes, wake/sleep cycles and security. Its use in ad hoc mesh networks is complementary to existing IETF neighbor discovery protocols, such as IPv6 ND [RFC4861] and NHDP [RFC6130]. MLE can be used to configure individual links and to distribute configuration values that are shared across a network. Per-link configuration uses one-hop messages with link-local addresses. Network-wide configuration uses multicasts and requires some form of multi-hop multicast forwarding. MLE resolves the issue of determining two-way link quality between nodes in a lossy network (e.g. wireless) by allowing a node to periodically multicast an estimate of the quality of its links. This allows a node to determine if it has a usable link to a neighbor without first configuring that link. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Due to the general nature of the protocol and its application to link layer technology, there was no particular WG which suited the draft. It has been discussed in the 6lowpan and roll WG mailing lists. The only controversy notable was the use of UDP as the base protocol for MLE. Some suggested ICMPv6 would be more appropriate tied to RPL messages, however this had the criticism of narrowing the scope of MLE, which has been written without any specific IETF protocol in mind. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are numerous existing implementations of the protocol as it is currently being adopted and tested by ZigBee Alliance members involved in the development of the ZigBee IP stack. There are currently 7 independent vendors implemeting the protocol. Thomas Clausen has performed a thorough review of draft version 02 and his comments have been incorporated in version 03 onwards. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? The Document Shepherd is Robert Cragie. The Responsible Area Director is Ted Lemon. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd and Responsible Area Director have reviewed the draft document and have been party to the interoperability testing events undertaken by the vendors to confirm interoperable implementation of the protocol and its fitness for purpose. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been submitted for review on all relevant WG mailing lists and has had discussion. It has also been through practical implementations subject to continuous review by the implementors, who have fed back comments to the author, who has subsequently incorporated the comments into the latest draft. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. As the protocol describes message security, the Document Shepherd recommends the document is reviewed by the Security area. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd/Responsible Area Director has not indicated any specific concerns or issues with the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The authors have confirmed that there are no IPR disclosures required for full conformance with BCP 78 and BCP 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures that reference the document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The interested community as a whole understands and agrees with the document, proven by implementation. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no error and no warnings from a verbose nits check of draft-04. There are comments related to normative references; these references (AES, CCM and IEEE802154) are correctly stated as normative. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are in a clear state. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are three documents which the nits checker picked up as possible downward references: -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' All these are complete standard specifications within their appropriate standards authority (NIST and IEEE) (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The publication of this document will not affect the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA considerations section clearly identifies the requirements for MLE: * Additional UDP service name and port assignment * Security Suites * Command Types * TLV Types * Network Parameters (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. MLE requires a Service Name and Port Number that requires Expert Review. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no parts of the document written in a formal language. |
2014-06-08
|
06 | Ted Lemon | Placed on agenda for telechat - 2014-06-26 |
2014-06-08
|
06 | Ted Lemon | IESG state changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead::AD Followup |
2014-05-28
|
06 | Ted Lemon | IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for AD Go-Ahead::External Party |
2014-05-23
|
06 | Richard Kelsey | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2014-05-23
|
06 | Richard Kelsey | New version available: draft-kelsey-intarea-mesh-link-establishment-06.txt |
2013-12-23
|
05 | Ted Lemon | State changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead |
2013-10-01
|
05 | Ted Lemon | Removed from agenda for telechat |
2013-09-19
|
05 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Scott Kelly. |
2013-09-17
|
05 | Ted Lemon | Telechat date has been changed to 2013-10-10 from 2013-09-26 |
2013-09-16
|
05 | Pearl Liang | IESG/Authors/ADs: IANA has reviewed draft-kelsey-intarea-mesh-link-establishment-05. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as … IESG/Authors/ADs: IANA has reviewed draft-kelsey-intarea-mesh-link-establishment-05. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA has questions for some of the IANA actions requested in this draft document. IANA understands that, upon approval of this document, there are six actions which must be completed. First, the following UDP has been assigned to 'mle': mle 19788 udp Mesh Link Establishment [IESG] See: http://www.iana.org/assignments/service-names-port-numbers QUESTION: Should this draft document be cited as the defining reference in the port number registry? Second, IANA will create a new top-level registry, called "MLE: Mesh Link Establishment", to contain all MLE objects, codepoints, and sub-registries. Third, in the newly created MLE: Mesh Link Establishment, a new subregistry will be created called the "Security Suites" subregistry. The registration policy for this new subregistry will be IETF Review as defined in RFC 5226. The values in the new subregistry range from 0 to 255. There are initial values in this registry as follows: Value Meaning Reference --------+--------------------------------------+-------------------- 0 802.15.4 Security [ RFC-to-be ] 1-254 Unassigned 255 No security [ RFC-to-be ] Fourth, also in the newly created MLE: Mesh Link Establishment, a new subregistry will be created called the "Command Types" subregistry. The registration policy for this new subregistry will be IETF Review as defined in RFC 5226. The values in the new subregistry range from 0 to 255. There are initial values in this registry as follows: Value Meaning Reference --------+---------------------------------------+------------------ 0 Link Request [ RFC-to-be ] 1 Link Accept [ RFC-to-be ] 2 Link Accept and Request [ RFC-to-be ] 3 Link Reject [ RFC-to-be ] 4 Advertisement [ RFC-to-be ] 5 Update [ RFC-to-be ] 6 Update Request [ RFC-to-be ] 7-255 Unassigned QUESTION: Is the value 6 in the following text a typo? "Values 6-255 are currently unassigned." Fifth, also in the newly created MLE: Mesh Link Establishment, a new subregistry will be created called the "TLV Types" subregistry. The registration policy for this new subregistry will be IETF Review as defined in RFC 5226. The values in the new subregistry range from 0 to 255. There are initial values in this registry as follows: Value Meaning Reference --------+---------------------------------------+------------------ 0 Source Address [ RFC-to-be ] 1 Mode [ RFC-to-be ] 2 Timeout [ RFC-to-be ] 3 Challenge [ RFC-to-be ] 4 Response [ RFC-to-be ] 5 Link-layer Frame Counter [ RFC-to-be ] 6 Link Quality [ RFC-to-be ] 7 Network Parameter [ RFC-to-be ] 8 MLE Frame Counter [ RFC-to-be ] 9-255 Unassigned QUESTION: Is the value 8 in the following text a typo? Values 8-255 are currently unassigned. Sixth, also in the newly created MLE: Mesh Link Establishment, a new subregistry will be created called the "Network Parameters" subregistry. The registration policy for this new subregistry will be IETF Review as defined in RFC 5226. The values in the new subregistry range from 0 to 255. There are initial values in this registry as follows: Value Meaning Reference --------+---------------------------------------+------------------ 0 Channel [ RFC-to-be ] 1 PAN ID [ RFC-to-be ] 2 Permit Joining [ RFC-to-be ] 3 Beacon Payload [ RFC-to-be ] 4-255 Unassigned IANA understands that these six actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2013-09-16
|
05 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2013-09-16
|
05 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2013-09-16
|
05 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call (ends 2013-09-16) |
2013-09-13
|
05 | Ted Lemon | Placed on agenda for telechat - 2013-09-26 |
2013-09-10
|
05 | Martin Stiemerling | Request for Last Call review by TSVDIR is assigned to Wesley Eddy |
2013-09-10
|
05 | Martin Stiemerling | Request for Last Call review by TSVDIR is assigned to Wesley Eddy |
2013-08-22
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2013-08-22
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2013-08-22
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Scott Kelly |
2013-08-22
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Scott Kelly |
2013-08-19
|
05 | Maddy Conner | IANA Review state changed to IANA - Review Needed |
2013-08-19
|
05 | Maddy Conner | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Mesh Link Establishment) to Proposed Standard … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Mesh Link Establishment) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Mesh Link Establishment' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the mesh link establishment (MLE) protocol for establishing and configuring secure radio links in IEEE 802.15.4 radio mesh networks. MLE extends IEEE 802.15.4 for use in multihop mesh networks by adding three capabilities: 1) dynamically configuring and securing radio links, 2) enabling network-wide changes to radio parameters, and 3) detecting neighboring devices. MLE operates below the routing layer, insulating it from the details of configuring, securing, and maintaining individual radio links within a larger mesh network. The file can be obtained via http://datatracker.ietf.org/doc/draft-kelsey-intarea-mesh-link-establishment/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kelsey-intarea-mesh-link-establishment/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-08-19
|
05 | Maddy Conner | State changed to In Last Call from Last Call Requested |
2013-08-19
|
05 | Ted Lemon | Last call was requested |
2013-08-19
|
05 | Ted Lemon | Ballot approval text was generated |
2013-08-19
|
05 | Ted Lemon | State changed to Last Call Requested from AD Evaluation::External Party |
2013-08-19
|
05 | Ted Lemon | Last call announcement was generated |
2013-08-19
|
05 | Ted Lemon | Document shepherd changed to Robert Cragie |
2013-08-19
|
05 | Ted Lemon | Changed document writeup |
2013-05-05
|
05 | Ted Lemon | Waiting feedback from authors. |
2013-05-05
|
05 | Ted Lemon | State changed to AD Evaluation::External Party from AD Evaluation |
2013-04-25
|
05 | Ted Lemon | Shepherding AD changed to Ted Lemon |
2013-02-21
|
05 | Richard Kelsey | New version available: draft-kelsey-intarea-mesh-link-establishment-05.txt |
2012-10-19
|
04 | Ralph Droms | Ballot writeup was changed |
2012-10-19
|
04 | Ralph Droms | Ballot writeup was generated |
2012-10-19
|
04 | Ralph Droms | State changed to AD Evaluation from Publication Requested |
2012-10-11
|
04 | Cindy Morgan | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? i) Type of RFC Requested: Proposed Standard ii) It is the proper type of RFC because the document describes a communications protocol iii) The type of RFC is indicated in the title page header (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. MLE is a protocol for link-layer configuration, including link layer addressing, transmit and receive modes, wake/sleep cycles and security. Its use in ad hoc mesh networks is complementary to existing IETF neighbor discovery protocols, such as IPv6 ND [RFC4861] and NHDP [RFC6130]. MLE can be used to configure individual links and to distribute configuration values that are shared across a network. Per-link configuration uses one-hop messages with link-local addresses. Network-wide configuration uses multicasts and requires some form of multi-hop multicast forwarding. MLE resolves the issue of determining two-way link quality between nodes in a lossy network (e.g. wireless) by allowing a node to periodically multicast an estimate of the quality of its links. This allows a node to determine if it has a usable link to a neighbor without first configuring that link. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Due to the general nature of the protocol and its application to link layer technology, there was no particular WG which suited the draft. It has been discussed in the 6lowpan and roll WG mailing lists. The only controversy notable was the use of UDP as the base protocol for MLE. Some suggested ICMPv6 would be more appropriate tied to RPL messages, however this had the criticism of narrowing the scope of MLE, which has been written without any specific IETF protocol in mind. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are numerous existing implementations of the protocol as it is currently being adopted and tested by ZigBee Alliance members involved in the development of the ZigBee IP stack. There are currently 7 independent vendors implemeting the protocol. Thomas Clausen has performed a thorough review of draft version 02 and his comments have been incorporated in version 03 onwards. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? The Document Shepherd is Robert Cragie. The Responsible Area Director is Ralph Droms. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd and Responsible Area Director have reviewed the draft document and have been party to the interoperability testing events undertaken by the vendors to confirm interoperable implementation of the protocol and its fitness for purpose. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been submitted for review on all relevant WG mailing lists and has had discussion. It has also been through practical implementations subject to continuous review by the implementors, who have fed back comments to the author, who has subsequently incorporated the comments into the latest draft. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. As the protocol describes message security, the Document Shepherd recommends the document is reviewed by the Security area. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd/Responsible Area Director has not indiciated any specific concerns or issues with the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The authors have confirmed that there are no IPR disclosures required for full conformance with BCP 78 and BCP 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures that reference the document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The interested community as a whole understands and agrees with the document, proven by implementation. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no error and no warnings from a verbose nits check of draft-04. There are comments related to normative references; these references (AES, CCM and IEEE802154) are correctly stated as normative. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are in a clear state. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are three documents which the nits checker picked up as possible downward references: -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' All these are complete standard specifications within their appropriate standards authority (NIST and IEEE) (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The publication of this document will not affect the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA considerations section clearly identifies the requirements for MLE: * Additional UDP service name and port assignment * Security Suites * Command Types * TLV Types * Network Parameters (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. MLE requires a Service Name and Port Number that requires Expert Review. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no parts of the document written in a formal language. |
2012-10-11
|
04 | Cindy Morgan | Assigned to Internet Area |
2012-10-11
|
04 | Cindy Morgan | Note added 'Robert Cragie (robert.cragie@gridmerge.com) is the document shepherd.' |
2012-10-11
|
04 | Cindy Morgan | State Change Notice email list changed to richard.kelsey@ember.com, draft-kelsey-intarea-mesh-link-establishment@tools.ietf.org, robert.cragie@gridmerge.com |
2012-10-11
|
04 | Cindy Morgan | Intended Status changed to Proposed Standard |
2012-10-11
|
04 | Cindy Morgan | IESG process started in state Publication Requested |
2012-10-11
|
04 | Cindy Morgan | Stream changed to IETF from None |
2012-06-28
|
04 | Richard Kelsey | New version available: draft-kelsey-intarea-mesh-link-establishment-04.txt |
2012-05-17
|
03 | Richard Kelsey | New version available: draft-kelsey-intarea-mesh-link-establishment-03.txt |
2012-03-07
|
02 | Richard Kelsey | New version available: draft-kelsey-intarea-mesh-link-establishment-02.txt |
2012-03-01
|
01 | Richard Kelsey | New version available: draft-kelsey-intarea-mesh-link-establishment-01.txt |
2011-09-29
|
00 | (System) | New version available: draft-kelsey-intarea-mesh-link-establishment-00.txt |