Please see attached review.
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-ietf-6lowpan-btle-08.txt Reviewer: Brian Carpenter Review Date: 2012-07-03 IETF LC End Date: 2012-07-11 IESG Telechat date: Summary: Almost ready -------- Comment: -------- The document is very clear and easy to understand. My issues are definitely not fundamental. Major issues: ------------- Section 3: "BT-LE technology sets strict requirements for low power consumption and thus limits the allowed protocol overhead. 6LoWPAN standards [RFC4944], [I-D.ietf-6lowpan-nd] and [RFC6282] provide useful generic functionality like header compression, link-local IPv6 addresses, Neighbor Discovery and stateless IP-address autoconfiguration for reducing the overhead in 802.15.4 networks. This functionality can be partly applied to BT-LE." This is unclear. The three references are normative but only "partly applied". An implementer needs to know *exactly* which parts of the references are normative. For example you could add something here like "Precise details of the functionality applied to BT-LE are given in this document, and other parts of these references are not applicable to BT-LE." Sections 3.2.2 and 3.2.3 are reasonably detailed for [I-D.ietf-6lowpan-nd] and [RFC6282], although it would be good to give references to section numbers. However, very little is explained for [RFC4944]. Section 3.1: "In order to enable transmission of IPv6 packets over BT-LE, a new fixed L2CAP channel ID MUST be reserved for IPv6 traffic by the BT- SIG. A request for allocation of a new fixed channel ID for IPv6 traffic by the BT-SIG should be submitted through the liaison process or formal communique from the 6lowpan chairs and respective area directors. Until a channel ID is allocated by BT-SIG, the channel ID 0x0007 is recommended for experimentation. Once the channel ID is allocated, the allocated value MUST be used." This is a very clumsy situation to leave in a standards track RFC. It does not state who must submit the allocation request; this should be made definite. But it would be much better to get the allocation *before* the RFC is published, as we would for an IANA allocation. Otherwise the risk that products ship with 0x0007 built in is very high. Minor issues: ------------- Section 2.3: "This specification mandates that the Bluetooth Device Address MUST be a public address." Why? As long as the U bit is set correctly, a non-universal MAC address is acceptable in IPv6. (Also affects section 3.2.1.) Section 2.4: "An inherent function of the BT-LE L2CAP layer, called Fragmentation and Recombination (FAR), can assist in transferring IPv6 packets that do not fit in a single BT-LE data channel PDU." That implies that some IPv6 packets do fit in a single channel PDU, which is impossible without compression. You discuss compression later but it should be mentioned here for clarity. s/IPv6 packets/compressed IPv6 packets/ Section 3: "In addition, a BT-LE device MUST NOT play the role of a 6LoWPAN Router (6LR)." Just for clarity: remind that the BT-LE Master may be a 6BLR, which is a sort of exception to this rule. "Appendix A. Bluetooth Low Energy fragmentation and L2CAP Modes" This is so short that it could perhaps be included in the main text.
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
