Hi Elwyn, Sorry for the lack of feedback from our side during these days.
We are finalizing a draft update which (hopefully) incorporates all your suggestions, as well as other comments that we have received. By the way, thank you very much for your thorough review. We believe it has helped a lot to improve the document. We will let you know once we submit -14. Best regards, Carles > Hi, Draft Authors. > > I was just checking that you had seen the review below (sent on > 2015-06-02) as I haven't had any feedback and there hasn't been an > update to the draft as yet. > > Regards, > Elwyn > > 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-6lo-btle-13.txt > Reviewer: Elwyn Davies > Review Date: 2015/06/02 > IETF LC End Date: 2015/06/09 > IESG Telechat date: (if known) - > > Summary: Almost ready. A couple of minor issues - I think it is > important to bring out the multi-link subnet model as a separate section > and there are some details about peripheral to peripheral communication > that seem to have conflicting statements. Otherwise, there are a > largish number of missing definite and indefinite articles and a few > clarifications that I have suggested. > > Major issues: > None. > > Minor issues: > s2.2: As I read this section, it seems to imply (but doesn't make it > totally clear) that a peripheral would only connect to a single central > over IPv6 at a time. Is this true? Mesh networking being out of scope > would appear to be another issue that would not necessarily preclude a > peripheral from having multiple interfaces to different centrals - > provided it was capable of handling the multiple interfaces - but would > not need to act as a router. OK, this might not be something that would > be an everyday event in the IoT but it would be good to make it clear > what the specification implies in this area. > > s3.2, para 5: [This is just fractionally more than editorial] The > selection of the multilink subnet model is important and deserves a > (sub-sub-)section to itself. I suggest moving the second and subsequent > sentences of para 5 of s3.2 to a new s3.2.1 and renumbering the > remaining sub-sub-sections, thus: > OLD: > Bluetooth LE connections used to build a star topology are point-to- > point in nature, as Bluetooth broadcast features are not used for > IPv6 over Bluetooth LE (except for discovery of nodes supporting > IPSS). As the IPv6 over Bluetooth LE is intended for constrained > nodes, and for Internet of Things use cases and environments, > multilink model's benefits are considered to overweight multilink > model's drawbacks described in RFC 4903 [RFC4903]. Hence a multilink > model has been chosen, as further illustrated in Section 3.3. > Because of this, link-local multicast communications can happen only > within a single Bluetooth LE connection, and thus 6LN-to-6LN > communications using link-local addresses are not possible. 6LNs > connected to the same 6LBR has to communicate with each other by > using the shared prefix used on the subnet. The 6LBR ensures address > collisions do not occur (see Section 3.2.2) and forwards packets sent > by one 6LN to another. > > After the peripheral and central have connected at the Bluetooth LE > level, the link can be considered up and IPv6 address configuration > and transmission can begin. > > 3.2.1. Stateless address autoconfiguration > ... > NEW: > Bluetooth LE connections used to build a star topology are point-to- > point in nature, as Bluetooth broadcast features are not used for > IPv6 over Bluetooth LE (except for discovery of nodes supporting > IPSS). > After the peripheral and central have connected at the Bluetooth LE > level, the link can be considered up and IPv6 address configuration > and transmission can begin. > > 3.2.1. IPv6 Subnet Model > > In the Bluetooth LE piconet model (see Section 2.2) peripherals each > have a separate link to the central and the central acts as an IPv6 > router rather than a link layer switch. As discussed in [RFC4903], > conventional usage of IPv6 anticipates IPv6 subnets spanning a single > link at the link layer. As IPv6 over Bluetooth LE is intended for > constrained nodes, and for Internet of Things use cases and > environments, the complexity of implementing a separate subnet on > each peripheral-central link and routing between the subnets appears > to be excessive. In the Bluetooth LE case, the benefits of treating > the collection of point-to-point links between a central and its > connected peripherals as a single multilink subnet rather than a > multiplicity of separate subnets are considered to outweigh the > multilink model's drawbacks as described in RFC 4903 [RFC4903]. > > Hence a multilink model has been chosen, as further illustrated in > Section 3.3 Because of this, link-local multicast communications > can happen only within a single Bluetooth LE connection, and thus > 6LN-to-6LN communications using link-local addresses are not > possible. 6LNs connected to the same 6LBR have to communicate with > each other by using the shared prefix used on the subnet. The 6LBR > ensures address collisions do not occur (see Section 3.2.3) and > forwards packets sent by one 6LN to another. > > 3.2.2. Stateless address autoconfiguration > .... > END > > s3.2, para 5: Additional query: As written and in the nEW version just > above, the text seems to imply that you can't do peripheral to > peripheral comms between peripherals connected to the same central using > link local addresses ("thus 6LN-to-6LN communications using link-local > addresses are not possible"). This appears to conflict with various > statements later in the draft in s3.2.3, paras 4 and 5 which seem to > imply that comms using link local addresses is entirely possible. I may > have misunderstood this but would be grateful for explanation. > > > Nits/editorial comments: > ======================== > General: Prefer 'octet' to 'byte'. > > General: Consistent use of 'link layer' or 'link-layer' - both are used > in a somewhat aribitrary fashion. > > Abstract: s/is standardized since the revision/has been standardized > since revision/ > > Abstract: The 6LoWPAN acronym needs to be expanded. > > s1: To be consistent with the abstract it would be best if the > connection (equivalence) between Bluetooth Smart and Bluetooth LE was > reiterated in the first sentence and noted that Bluetooth LE is used in > the rest of the document. > > s1, para 1: To avoid jargon s/coin cell/very low capacity (e.g., "coin > cell")/ > > s1, para 2: Suggest s/ideal protocol/ideal protocol for communication > with such devices/ to make it clear what it is ideal for. > > s1, para 3: 802.15.4 needs a reference. Should this be to the updated > 2011 version ( RFC 4944 refers to the 2003 standard)? > IEEE Computer Society, "IEEE Std. 802.15.4-2011 IEEE Standard for Local > and metropolitan area networks-- > Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", June > 2011. > > s1, para 3: The general connection to 6LoWPAN mentioned in the last > sentence of the Abstract ought to be repeated at the start of para 3; > OLD: > RFCs 4944, 6282, and 6775 [RFC4944][RFC6282][RFC6775] specify the > transmission of IPv6 over IEEE 802.15.4. > NEW: > This document describes how IPv6 is transported over Bluetooth Smart > (also known as > Bluetooth LE) low power connections using IPv6 over Low power > Wireless Personal Area > Networks (6LoWPAN) techniques. RFCs 4944, 6282, and 6775 > [RFC4944][RFC6282][RFC6775] > developed for 6LoWPAN specify the transmission of IPv6 over IEEE > 802.15.4. > END > > s1.1, para 2: Please include the expansions of the acronyms 6LN, 6LR and > 6LBR here. > > s2, para 1: >> Bluetooth LE is designed for transferring small amounts of data >> infrequently at modest data rates at a very low cost per bit. > Presumably this is energy cost? Maybe better: > s/at a very low cost/with a very small energy expenditure/ > > s2, para 2: s/published/published the/, > s/includes/includes the/, > s/link-layer/a link-layer/ > > s2, para 2: To be clear 'newer' (presumably) applies to both BT 4.1 and > IPSP 1.0: > s/newer/more recent versions of either specification to provide > necessary capabilities/ > > s2, para 3: > OLD: > which will include Bluetooth 4.1 chipsets > NEW: > that incorporate chipsets implementing Bluetooth 4.1 or later > END > > s2, para 3: The standard cannot guarantee presences of Bluetooth LE: > s/will also be included/is also expected to be included/ > > s2.1, para 1: >> The device internal Host Controller Interface (HCI) > I don't think the qualifier 'device internal' really helps here and > could be usefully omitted. > The nature of the interface is explained in the following text. > > s2.2, para 1: 'but since Bluetooth 4.1' is a bit ambiguous. After some > thought, I assume it is supposed to mean that the capability to connect > to multiple centrals at once started only with BT 4.1. How about: > OLD: > but since Bluetooth 4.1 can also connect to multiple centrals. > NEW: > but with versions of Bluetooth from 4.1 onwards it can also connect to > multiple centrals at the same time. > END > > s2.2, para 1: s/i.e. a Bluetooth/i.e., a Bluetooth/ > > s2.3, para 1: Hope the device isn't running on AC!! > OLD: > This typically happens at every power cycle of a device. > NEW: > New addresses are typically generated each time a device is powered on. > END > > s2.4, title: s/packets sizes/packet sizes/ > > s2.4: s/Optimal/The optimal/, > s/Default MTU/The default MTU/, > s/exclusing L2CAP/excluding the L2CAP/, > s/protocol data/a protocol data/, > s/link layer fragmentation/a link layer fragmentation/, > s/provides MTU/provides an MTU/ > s/single link-layer MTU value/an equal link layer MTU for the > two directions/ > > s3, para 1: s/due Bluetooth LE's/due to Bluetooth LE's/ > > s3, para 2: s/both star and mesh topology/both star and mesh topologies/, > s/inter- peripheral/inter-peripheral/ [Space removed] > > s3, para 4: s/Bluetooth SIG/the Bluetooth SIG/ > > s3, last sentence: This duplicates the statement made in s2 (subject to > the mod proposed above). It could be omitted. However, if repeating it > is thought worthwhile, it might be better right at the start of s3. > > s3.1: s/IPv6 stack/the IPv6 stack/, > s/GATT stack/the GATT stack/, > s/Bluetooth LE/the Bluetooth LE/, > s/GATT/The GATT/ > s/Internet/The Internet/ > > s3.2, para 1: s/The concept of/The distinct concepts of the/, > s/needs/need/, s/the relationship/their relationship/ > > s3.2, para 2: s/6LoWPAN/the 6LoWPAN/, > s/use of 1280 byte/use of a 1280 byte [octet] MTU/ > > s3.2.1, para 1: s/underlying/the underlying/, > s/guidance/the guidance/, > s/formed from 48-bit/from the 48-bit/, > s/a bit from Bluetooth/a bit from the Bluetooth/, > s/no bit in IID/no bit in the IID/ > > s3.2.1, para 2: s/appended with/prepended with the/, > s/After Bluetooth/After a Bluetooth/ > s/existing L2CAP channel/existing L2CAP channels/ [or > "an L2CAP channel"] > > s3.2.1, para 3: s/responsible of/responsible for/, > s/and of/and for/, > s/complexity/the complexity/, > s/at link establishment/in the link establishment/, > s/number/the number/ > > s3.2.1, para 4: s/6LN sends/the 6LN sends/ > > s3.2.1, para 5: s/alternatice/alternative/, > s/6LN generates/that a 6LN generates/, > s/with 6LBR/with the 6LBR/ > > s3.2.1, para 6: Referring to the new section on the subnet model > proposed in the 'Minor Issues' section above would be helpful instead of > s2.2. > > s3.2.1, para 6: s/Prefix Information Option [RFC4861]/Prefix > Information Option in Neighbor Discovery messages [RFC4861] (see Section > 3.2.2)/ > > s3.2.3, para 3: s/of EUI-64/of an EUI-64/ > > s3.2.3, para 4: Suggest a little clarification of this para: > OLD: > To enable efficient header compression, the 6LBR MUST include 6LoWPAN > Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises > in Router Advertisements for use in stateless address > autoconfiguration. > NEW: > To enable efficient header compression, when the 6LBR sends a > Router Advertisement it MUST include a 6LoWPAN Context Option (6CO) > [RFC6775] matching each address prefix advertised via a Prefix > Information Option (PIO) [RFC4861] for use in stateless address > autoconfiguration. > END > > s3.2.4, para 5: s/related to compression context/related to the > compression context/ (2 places) > > s3.2.4, para 5: > OLD: > 6LBR has sent Neighbor Advertisement with ARO having status field set to > success. > NEW: > 6LBR has sent a Neighbor Advertisement with an ARO having its status > field set to success. > END > > s3.2.4, para 5: s/address is 6LBR's/address is the 6LBR's/, > s/for the used destination prefix./for the destination > prefix used./ > > s2.2.4, para 6: s/packets to 6LN/packets to a 6LN/, > s/on 6LBR's/on the 6LBR's/, > s/based on 6LN's/based on the 6LN's/, > s/then 6LN/then the 6LN/, > s/of IID match/of the IID match/ > > s3.2.3.1, para 1: s/full or part of IID/part or all of the IID/, > s/depending which/depending on which/ > > s3.2.3.2, last para: s/secondly/most recently/ > > > > > > > > > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
