IEEE P802.15.1/D0.9.2 Unresolved Technical Comment Report DATE: 24Sep01 SB1 Summary: There were 33 Voting members. 30 submitted their vote. The return ratio is 30/33 = 90% (75% is required) and the abstention rate was less than 30% of those voting. The ballot was valid. Motion passed with 26/3/1 or 89%. 3 failed to vote. 802.15.1/D0.9.2; Date Closed: 25Aug01 -3 Disapproving Voters w/ 95 Comments (was 96 but #7 & #8 are same) -19 unresolved "T"echnical comments, out of 30 received -3 (#66, 80, and 83) rejected "E"ditorial comments, out of 65 received The 19 unresolved "T"echnical comments follow: ==================== COMMENT #: 1 IEEE #: 8944704 NAME: O'Hara, Bob E-MAIL: bob@informed-technology.com PHONE: +1 408 986 9596 FAX: +1 408 727 2654 CO/ORG: Informed Technology, Inc. PAGE: 0 LINE: 0 CLAUSE: 0 TYPE OF COMMENT: T COMMENT: "This proposed standard operates in the same band as an existing IEEE approved standard, 802.11 and its approved supplement 802.11b. It has been demonstrated that the operation of this proposed standard interferes with devices complying with the 802.11 standard operating in the same band." SUGGESTED REMEDY: "A means of mitigating or, preferably, eliminating the interference with the 802.11 standard is required and must be incorporated into this proposed standard in order for it to be acceptable. It is not acceptable to approve this proposed standard based on potential work being done in other task groups that, obviously, will not be incorporated in devices built to comply with this proposed standard." RESPONSE: "REJECT. In terms of the suggested remedy: ""A means of mitigating or, preferably, eliminating the interference with the 802.11 standard is required and must be incorporated into this proposed standard in order for it to be acceptable."" we reject this requirement because we believe the IEEE should, wherever possible, rely on market forces to ensure economically efficient use of spectrum. Also, we consider a standard that uses a designated spectrum shall not constitute ownership of that spectrum. The Ballot Review Committee (BRC) suggests that the IEEE and the P802 Sponsor Executive Committee carefully review the resolution of this issue as it may arise again; that one working group member is attempting to block another working group from having their Project's deliverable approval based on a similar fallacy of logic - argumentum ad baculum (Appeal to Force). For example given that the 802.11 Working Group has received approval for standards in the 2.4 and 5 GHz bands will this type of 802.11 requirement reoccur at Sponsor Ballot for 802.15.3 at 2.4GHz, 802.15.3 at 5 GHz, 802.15.4 at 2.4 GHz, and/or 802.16b at 5 GHz? The IEEE should not be put into the position of deciding which technology and/or standard is the best to promote. The IEEE approval policies, therefore, should both permit and promote the operation of competitive market forces. In large part, the IEEE can serve these principles simply by not interfering where it concludes that the judgment of the marketplace is sufficiently reliable. Also, and more importantly an approved standard that uses a designated spectrum shall not constitute ownership of that spectrum. Specifically, the BRC believes based on an approved IEEE Std. 802.15.1-2001 that the marketplace will continue to demand Wi-Fi(tm) (802.11b) and Bluetooth(tm) (802.15.1) products. The IEEE should approve the IEEE Std. 802.15.1-2001." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 2 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp. PAGE: 1 LINE: 29-30 CLAUSE: 1.1 TYPE OF COMMENT: T COMMENT: "In clause 1.1 it states: ""The proposed WPAN standard will be developed to ensure coexistence with all 802.11 networks."" however this subject is not addressed in any normative clause of this draft. In fact, the word ""coexistence"" does not even appear anywhere else within the 1159 pages of D0.0.2. The characteristics of the 2.4GHz radio and physical layer protocol specified in subsequent clauses shows no clear manner by which such coexistence is even possible in overlapping space with any of the 802.11 PHYs that operate in the 2.4GHz band (FH, DS, 802.11B, and the pending P802.11G). 802.15.1 is the first instance in the past 10 years, and probably the first instance ever in the history of 802 that an 802 draft has gone to sponsor ballot with a proposal to transmit conflicting and mutually incompatible signals onto the SAME INSTANCE of the physical medium as is already in use by another 802 MAC/PHY. There is not even a plausible argument that 802.11 and 802.15 networks will rarely be operated in overlapping space, since there are devices, such as notebook and subnotebook computers, which are explicitly stated as needing to attach to both WLANs and WPANs, concurrently if not simulatneously." SUGGESTED REMEDY: "The proper technical solution is to modify the Bluetooth protocol to support an ""etiquette"" for sharing access to the 2.4GHz ISM band -- preferably listen-before-talk, although an approach based on a maximum duration for any transmission and a maximum transmit duty cycle are likely to be easier to implement than LTB." RESPONSE: "REJECT. In terms of the suggested remedy: "The proper technical solution is to modify the Bluetooth protocol to support an "etiquette" for sharing access to the 2.4GHz ISM band..." we reject this solution because we believe the IEEE should, wherever possible, rely on market forces to ensure economically efficient use of spectrum. Also, we consider a standard that uses a designated spectrum shall not constitute ownership of that spectrum. Specifically, the Ballot Review Committee believes based on an approved IEEE Std. 802.15.1-2001 that the marketplace will continue to demand Wi-Fi(tm) (802.11b) and Bluetooth(tm) (802.15.1) products. The IEEE should approve the IEEE Std. 802.15.1-2001. Additionally, that the market will continue to review the myriad of emerging coexistence approaches for collocated Wi-Fi & Bluetooth e.g.: * 802.15.2 collaborative and non-collaborative coexistence mechanisms * Simple device collocation with no coexistence mechanisms * Restricted or adaptive band hopping for Bluetooth devices * Switching between the two protocols * System-level approaches covering the entire wireless sub-system and many of the above techniques Note: Some of these mechanisms will provide "...sharing access to the 2.4GHz ISM band..." but note that they are outside of the scope and charter of 802. (see SB1 #1 response for more information) Finally, the word coexistence, does appear again in the GAP, so if the commentor has not closely reviewed the text, how can we trust his comment. Based on the definition of coexist as defined in the PAR and Five criteria, coexistence does not imply cooperation (exchange of information to reduce or avoid the other) between or among WPANs and WLANs. Therefore there is no requirement to add or change the current procedures to include a cooperating mechanism to detect other WPANs or WLANs before creating a WPAN (i.e. piconet). It is not clear what criteria would be used to determine whether a channel, frequency, or both would be busy/free. When such criteria are defined for the IEEE 802.11, all parts), then one might be able to consider such a requirement from another standard. The IEEE 802.5 is not a listen before talk mechanism, in fact in some ways the token ring is much like the master/slave relationship defined in IEEE 802.15.1. The bottom line is the Ballot Review Committee is aware of the mutual interference between IEEE 802.11 and IEEE 802.15.1 and as was correctly pointed out by the commenter the 802.15 Working Group has formed a Task Group, IEEE 802.15.2, to address the issue of coexistence of IEEE WLAN and WPAN systems. The work of that task group will publish recommended practices to allow systems to reduce levels of mutual interference between the IEEE WLAN and WPAN systems. Based on the preceding response we REJECT the comment but we look forward to reviewing the 802.15.2 draft. More info: http://ieee802.org/15/pub/TG2.html COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 7 IEEE #: 8518995 NAME: Freedman, Avraham E-MAIL: avif@hexagonltd.com PHONE: +972-3-5101128 FAX: +972-3-5103331 CO/ORG: Hexagon System Engineering PAGE: 28 LINE: 17 CLAUSE: 7.2 TYPE OF COMMENT: T COMMENT: "The declaration that one Bluetooth product ""will not work"" with another is unacceptable for a product like Bluetooth and the global market it targets. This is the reason I am not approving the standard." SUGGESTED REMEDY: "1. Make arrangements to handle the band switch 2. Work in Spain, France, Japan etc. to change the regulation to allow 79 frequencies sequence in its hopping. I will change my vote to ""approve"" if I am assured that future versions of the standard will take care of this problem." RESPONSE: "REJECT. The disputed statement: ""...products implementing the reduced frequency band will not work with the products that implement the full band..."" refers to product implementations rather to a feature of the standard. These implementations are subject to government regulations beyond the control of the standard (if I recall well, the 802.11a (5 GHz) is illegal in Europe!)" COMMENT STATUS: R RESPONSE STATUS: W EDITOR NOTE: ICG Comment #7 and #8 are duplicates we CHOSE Comment #7 - they were basically the same. -------------------- COMMENT #: 9 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp. PAGE: 29 LINE: 34-48 CLAUSE: 7.3 TYPE OF COMMENT: T COMMENT: "Power class 1 specifies a maximum transmit power of 100mW, which is far in excess of what is reasonably required to provide RF coverage for a 10-meter personal operating space (see 6.1.2.1). Indeed, according to 6.1.2.1 the principal difference in radio characteristics which justifies the distinction between WLAN and WPAN is that WLAN radios are optimized to provide coverage on the order of 100 meters at the expense of power consumption, and therefore typically use 100mW of transmit power!" SUGGESTED REMEDY: "Power class 1 should be eliminated, or reduced to a maximum level which is sensible for coverage of a 10-meter personal operating space (such as 4mW or 10mW). This has the ancillary benefit of simplifying the 802.11 coexistence scenarios by reducing the range at which a Bluetooth piconet can interfere with an 802.11 BSS." RESPONSE: "REJECT. In terms of the suggested remedy: "Power class 1 should be eliminated, or reduced to a maximum level..." we reject this solution because we believe the IEEE should, wherever possible, rely on market forces to ensure economically efficient use of spectrum. Also, we consider a standard that uses a designated spectrum shall not constitute ownership of that spectrum. Specifically, the Ballot Review Committee believes based on an approved IEEE Std. 802.15.1-2001 that the marketplace will continue to demand Wi-Fi(tm) (802.11b) and Bluetooth(tm) (802.15.1) products. The IEEE should approve the IEEE Std. 802.15.1-2001. Additionally, that the market will continue to review the myriad of emerging coexistence approaches for collocated Wi-Fi & Bluetooth e.g.: * 802.15.2 collaborative and non-collaborative coexistence mechanisms * Simple device collocation with no coexistence mechanisms * Restricted or adaptive band hopping for Bluetooth devices * Switching between the two protocols * System-level approaches covering the entire wireless sub-system and many of the above techniques Note: Some of these mechanisms are "...simplifying the 802.11 coexistence scenarios..." but note that they are outside of the scope and charter of 802. (see SB1 comment #1 response for more information) COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 10 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp. PAGE: 30 LINE: 13 CLAUSE: 7.3 TYPE OF COMMENT: T COMMENT: "This ought to be a requirement, not a recommendation." SUGGESTED REMEDY: "Change ""should"" to ""shall"" since as a non-mandatory recommendation the 802.11 coexistence scenarios become even more intractable." RESPONSE: "REJECT. Inquiries and pages comprise of occasional, short-energy bursts (ID packets). As such even if they are used by Class 1 radios any interference that may cause (if they do) will be occasional and short lasted. Furthermore, due to power constraints, class 1 radios are primarily targeting ""stationary"" kiosk/type installations permanently attached to a power supply. For such systems, inquiries will typically occur from the lower-powered radios (class 2 or 3) in personal devices in search of the kiosk-based applications. Therefore, the recommended practice of using low power for inquiries is sufficient. There is no need to make it a requirement." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 11 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp. PAGE: 55LINE: 52 CLAUSE: 8.4.5.2 TYPE OF COMMENT: T COMMENT: "Given the stated reason for not using payload flow bit ""stop"" in AUX1 packets (lack of payload CRC in that packet format), a stronger enforcement of this non-use is appropriate." SUGGESTED REMEDY: "It would be far safer to specify that the flow bit=""stop"" is ignored in received AUX1 packets instead of suggesting that this bit ""should not be used.""" RESPONSE: "REJECT. The 802.15.1 (draft) standard says that ""...AUX1 packets should not be used with payload flow bit of ""stop""..."" On the other hand the comment suggest that the payload flow control bit shall be ignored when received in AUX1 packets. What the standard says and what the comments suggest are totally different. The standard recommends not using AUX1 when payload flow control equals 0, the comment proposes ignoring payload flow control when AUX1 packets are sent." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 12 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp. PAGE: 61 LINE: 22-23 CLAUSE: 8.5.3.2 TYPE OF COMMENT: T COMMENT: "The final sentence above figure 28 states that ""The described flushing procedure is considered optional, although strongly recommended."" It is unclear how much of the specified behavior is part of this optional procedure. Also, how can one determine if a given Bluetooth device has implemented this option? -- there are no PICS entries which refer to clause 8.5.3.2 nor to ""flushing procedure.""" SUGGESTED REMEDY: "Provide a clear definition of which functions are part of the optional procedure. If there is a way to determine that this option has been implemented, add mention of such at least here and probably in the PICS as well. If there is no operational need for the communication partner ever to need to know whether this option is implemented, please add an explanation of why this is so." RESPONSE: "REJECT. The recommended flushing procedure refers to the whole paragraph to which the disputed statement resides (page 61, lines 17-23). Furthermore, this is an internal implementation feature not a standards requirement. A communicating partner does not need to know (it does not effect interoperability, it simply is a suggestive practice to baseband implementors). As such, there is no need to specify, say in PICS, on whether this feature has been implemented or not." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 13 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp. PAGE: 63 LINE: 26-29 CLAUSE: 8.5.4 TYPE OF COMMENT: T COMMENT: "Because the HEC and CRC are used to perform both error detection and part of the address matching, it is possible that a data error during packet transfer could cause a packet with UAP mismatch to appear as an error-free packet addressed to this device." SUGGESTED REMEDY: "Please add to the specification the necessary analysis, including equation(s), to quantify, for a given bit error rate on the wireless medium, the probability that a device with an LAP equal to the LAP of the intended recipient will accept an erroneous transmission intended for a different UAP as an error-free packet to itself. For this analysis it is acceptable to assume a uniform likelihood of bit errors occuring at any bit position within the packet (although this will probably not be true in practice)." RESPONSE: "REJECT. The actual calculation is not required as part of a standard. That is left for the user, but the user must understand that this calculation is not solely base on the LAP, HEC and CRC. Therefore this is not an issue. In order to get a packet to this level (i.e. baseband), a packet must have passed at least two other error checking mechanism and a frequency hopping sequence, plus the Master/Slave procedures. One is the access code that uses the LAP ((24-bit Bluetooth) (MAC)) and the second is the 1/3 FEC. In the data transfer phase a frequency hopping sequence is used, thus if the intended (or unintended) device is not using the same hopping sequence, then the likely hood of a packet being received by an unintended device is based on the chance that the device happened to have used the same hopping frequency for this time slot. This is the case of two piconets. However, since the piconets are not synchronized, even if the frequency hop matches for both piconets the time slots would not be aligned, so the packet would not be received by the unintended device. Also the procedures defining the Master/Slave relationship for transmission also provides error checking of received packets, since a slave is not to transmit a packet unless it receives a indication from the master that the slave is allowed to transmit. The Master can then match the received address to the indicated address." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 14 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp. PAGE: 63 LINE: 26-29 CLAUSE: 8.5.4 TYPE OF COMMENT: T COMMENT: Using the HEC and CRC to perform part of the address matching function means that some of the HEC and/or CRC errors detected in received packets will be due to UAP mismatch instead of errors occurring during transfer over the wireless medium. SUGGESTED REMEDY: "Please add a statement that makes it clear that in 802.15.1, unlike other 802 MAC/PHY protocols, HEC and/or CRC errors can and will occur on packets that are received without errors, and therefore HEC and/or CRC error counts in 802.15.1 must not be used in assessment of communication link reliability." RESPONSE: "REJECT. If this statement is needed based on the previous comment [SB1 #13], then this statement is not relevant, since the previous comment was not deemed to be correct and therefore does not support this inclusion." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 15 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp. PAGE: 117 LINE: 46-54 CLAUSE: 8.13.1 TYPE OF COMMENT: T COMMENT: "How is the possibility of an address collision detected? (What I am calling an address collision is the case where two or more stations have MAC addresses with the same LAP and UAP, so these addresses differ only within the NAP portion.) The LAP is assigned by the manufacturer of the Bluetooth device, and equal LAP values can be expected to exist within each OUI. The UAP includes only 8 of the 22 significant bits of the OUI, so each (LAP,UAP) pair can represent any of up to 16384 devices, each of which has a unique IEEE 48-bit MAC addresses. At a time when other communication standards (at ISO, IETF, etc.) are moving toward addresses with 64 to 80 bits, I have serious concerns about the advisability of standardizing a nominally universal, self-configuring protocol that uses a 32-bit subset of the 48-bit MAC address. It is also arguable that a 32-bit address space is insufficient for WPAN, since some market surveys have predicted sales volumes for Bluetooth-class wireless devices that would consume over 25% of this address space by the middle of this decade. On the other hand, due to the small number of devices in any given piconet or scatternet, this 32-bit operational address space should be adequate, provided it is accompanied by a normative mechanism for detecting and resolving address collisions. Note that the lack of required MAC layer management facilities in 802.15.1 (stated in 6.1.2.2) in conjunction with the requirement that piconets be established without pre-deployment (stated in 6.1.2.3) will make it essentially impossible for a WPAN user who is experiencing operational problems to determine whether an address collision is the cause." SUGGESTED REMEDY: "Add a mechanism for detecting and resolving address collisions, or include a reference to the existing mechanism which provides this detection and resolution." RESPONSE: "REJECT. The remedy suggested is what the baseband procedures describe. This is a complicated mechanism, and cannot be summarized into a single statement. The reference is the entire baseband clause." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 21 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp. PAGE: 445 LINE: 30 CLAUSE: 12.3.2 TYPE OF COMMENT: T COMMENT: "The relationship of HCI primitives to L2CAP primitives is unclear in the context of this clause. Both the L2CAP and HCI SAPs are shown at the top of the MAC, but clearly they are not two paths that provide equivalent functionality. Based on information in some of the cited external (Bluetooth SIG) documents it appears that the HCI SAP should be considered from an 802 point of view to be a MAC Management SAP rather than a MAC Data SAP." SUGGESTED REMEDY: "I recommend changing the HCI SAP so it is described as an MLME SAP for the 802.15 MAC that provides primitives which map to{an identified subset of?} the Bluetooth HCI functions. This approach also has the advantage of fitting well with the stated reasons for removing implementation-specific specification subclauses from clause 11 -- in effect replacing a set of implementation-oriented specifications with an abstract management interface that provides equivalent, but implementation-neutral functionality." RESPONSE: "REJECT. The HCI is not only management but data as well. Since Bluetooth does not provide a single system/architecture view, no solution will be correct." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 22 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp. PAGE: 482 LINE: 23-30 CLAUSE: B.1.2.2.1 TYPE OF COMMENT: T COMMENT: "I disagree strongly with the statement ""These {Bluetooth clock, buffers, flow control, ARQ, SEQN} are important, but not so from a behavior point of view in the overall understanding of things. ... Our plan is to implement these last, if then. {emphasis mine} As a minimum, if this statement is true there needs to be a much clearer explanation of what behavior this SDL model is attempting to define and to promote the understanding of. After all, the primary place within the scope of 802.15.1 where there is an exposed interface BETWEEN devices (which is where the interoperability created by this standard must exist) is the wireless medium -- and a substantial part of the behavior that can be observed on the wireless medium involves packet exchanges that use one or more of flow control, ARQ (retry), and SEQN (duplicate filtering), and all such exchanges occur under control of the Bluetooth clock. It appears to me that the behavior of these items is of critical importance in ""the overall understanding of things.""" SUGGESTED REMEDY: "I recommend that the mention of of unimportance, and the ""... if then"" be deleted, and that the listed items be included in the complete version SDL model. I agree that it is appropriate to add these items to the model near the end of its development, as doing so will reduce the effort required for testing of higher-level functions within the SDL model." RESPONSE: "REJECT. These three items are not standardizable things, especially the buffers. The SDL language has a built in channel and buffering system (First in First Out). Since real buffers require manipulation (i.e. not FIFO), the built-in features of SDL cannot be used. Therefore a buffering and channel scheme must be created using other features of the SDLs. However, since the standard can not require an implementation scheme on buffer management, then neither can the SDLs. The Bluetooth Clock is not standardized either. The SDL language does not provide a clock. So again a clock behavior would need to be contructed using other features of the SDL. Finally the ARQ is use to confirm delivery or to retransmitt a lost packet, that is needed to be stored in a buffer/channel not a built-in SDL feature. See 8.8 on Transmit and Receive procedures. Significant amounts of work would be needed to implement these ""real"" features in SDL, while the behavior gain would be minimal. An SDL model does not necessarily implement every aspect of a system. Therefore it is important to note what is not modeled." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 23 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp. PAGE: 482 LINE: 37-38 CLAUSE: B.1.2.2.2 TYPE OF COMMENT: T COMMENT: """Similar to but not exactly the IEEE's protocol stack model"" is a curious statement to find in an IEEE 802 draft. Given that Annex B is identified in clause 5.2 as ""a value add by IEEE"" rather than as an item closely derived from a preexisting Bluetooth document, there is no obvious reason why this annex should not use the IEEE's protocol stack model. Of even greater importance is the fact that a description of the MAC SAP is absent in both the current SDL model and list of changes known to be needed to complete this model." SUGGESTED REMEDY: "This omission should be rectified, by including a specification of the mechanism for interoperable transfer of LAN traffic (802-style MSDUs) over Bluetooth piconets as a new section in the completed SDL description. This is a topic that the Bluetooth specifications do not address in sufficient detail, and is clearly a topic about which an IEEE P802.15.1 standard derived from Bluetooth v1.1 can actually add significant value to those specifications already published by the Bluetooth SIG. Indeed, the existence of a normative mechanism for MSDU transfer between peer MAC entities using the 802.15 MAC/PHY is implicit in the position that the 802.15 MAC/PHY box appears in the overview diagram on page ii." RESPONSE: "REJECT. Since the SDLs are informative, a normative mechanism for MSDU can not be accomplished unless the Annex is normative " COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 24 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp PAGE: 482 LINE: 46-47 TYPE OF COMMENT: T COMMENT: "The intent implied in the statement ""The SDL model is a work in progress and Project 802.15.1 anticipates the day when we can provide this as a normative annex -- until such time this SDL model is for informative use only"" is absurd. Attempting to change a 580-page portion of this document (e.g. 50%, which will probably have grown to well over 60% by the time the SDL model is complete) from informative to normative AFTER approval of a version in which the prose is the sole normative content is tantamount to redefining the whole protocol. The complexity of both the formal model and the Bluetooth protocols themselves is far too great for the voters in that subsequent sponsor ballot to determine equivalence between the prose and the SDL within a 30 day ballot period." SUGGESTED REMEDY: "The P802.15.1 task group needs to decide whether the SDL model is to be normative or informative, then to stick with that decision. EITHER change Annex B to a normative annex in the next revision of this draft which is sent out for ballot (my preference), OR decide to leave Annex B as an informative annex and state this in the next revision of Annex B. Note that changing Annex B to a normative annex does not mean that 100% of the Bluetooth protocol functionality needs to be described therein. Instead of the present ""... until such time ..."" statement, I recommend that the group select an appropriate subset of Bluetooth for which the SDL model is useful, include a (reasonably) complete description of that subset into Annex B of the next draft sent for ballot, and replace the ""work in progress ..."" disclaimer with a statement of what is and is not described in the SDL model.Another suggestion: Given the size and complexity of the SDL model, on future ballots please make a set of the Tau files available to those voters who want to explore the model in Tau or to [sic]" RESPONSE: "REJECT. It is not the intent to change the status of annex B from Informative to Normative during the balloting this version of the draft standard. The Annex B (SDLs) is marked as informative and will stay that way for this version of the draft standard. It is hoped that future revisions of this standard will change Annex B to normative." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 25 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp PAGE: 437 and 440 LINE: "15-29 on p.437, 34-35 on p.440" CLAUSE: 12.1 and 12.2.1 TYPE OF COMMENT: T COMMENT: "Since L2CAP supports connections, it is unclear why LLC type 2 connection oriented service service is not supported along with LLC type 1 connectionless service." SUGGESTED REMEDY: "Either allow LLC type 2 or provide an explanation. It may be acceptable, even appropriate, to omit support for LLC type 2, but as a minimum there should be mention of why connection oriented service is omitted when the L2CAP protocol is clearly capable of providing such a service. Also, if LLC type 2 is not going to be supported, remove the inconsistency between 12.1, which states that only LLC type 1 is supported, and 12.2.1, which mentions LSDUs generated internally by LLC as part of type 2 service." RESPONSE: "REJECT. There is nothing prohibiting LLC type 2 from L2CAP." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 26 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp PAGE: 440-441 LINE: 49-54 and 1-47 CLAUSE: 12.2.2 TYPE OF COMMENT: T COMMENT: "This clause appears to have been copied from 8802-2, clause 2.3.2.2, which defines MA-UNITDATA.indication from the LLC side of the MAC SAP. Much of this text is inappropriate when defining the MAC side of the MAC SAP (for example, line 22 on page 441)." SUGGESTED REMEDY: Please modify this clause to be a definition of the MA-UNITDATA.indication primitive and associated parameter values that will actually be generated by 802.15.1 MAC entities. RESPONSE: "REJECT. The BRC understands the comment but based on our understanding of the Bluetooth Specification we decline the suggested remedy. We are open to further discussion but based on the signed agreement (see note below) we refer the commenter to the two (2) Bluetooth document references to Clause 2: * 2.4.5. Bluetooth Personal Area Networking Profile Bluetooth Special Interest Group, "Bluetooth Personal Area Networking Profile Revision 0.95a", June 26, 2001. [PAN-Profile.pdf] * 2.4.6 Bluetooth Network Encapsulation Protocol (BNEP) Specification Bluetooth Special Interest Group, "Bluetooth Network Encapsulation Protocol (BNEP) Specification Revision 0.95a", June 12, 2001. [BNEP.pdf] Note: Bluetooth documents are available from the IEEE website: http://ieee802.org/15/Bluetooth/ Note: License Agreement - The signed Bluetooth SIG - IEEE Copyright License Agreement to publish the Derivative Work states: ""Make such limited changes to the licensed portion of the Bluetooth Specification as the Licensee determines are required for the Derivative Work."" The Ballot Review Committee (BRC) considers the suggested remedy a misapplication of the license agreement and would therefore constitute an infringement and nullify the contract." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 27 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp PAGE: 441-442 LINE: 49-54 and 1-38 CLAUSE: 12.2.3 TYPE OF COMMENT: T COMMENT: "This clause appears to have been copied from 8802-2, clause 2.3.2.3, which defines MA-UNITDATA-STATUS.indication from the LLC side of the MAC SAP. Much of this text is inappropriate when defining the MAC side of the MAC SAP (a glaring example is the discussion of an ""excessive collisions"" status value on line 19 of page 442)." SUGGESTED REMEDY: Please modify this clause to be a definition of the MA-UNITDATA-STATUS.indication primitive and associated parameter values that will actually be generated by 802.15.1 MAC entities. RESPONSE: "REJECT. See comment resolution SB1 #26." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 28 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp PAGE: 443-447 LINE: 1-54 CLAUSE: 12.3.2 TYPE OF COMMENT: T COMMENT: "This is a critically important section that appears to be seriously incomplete. A useful nomenclature is defined, along with references to appropriate items in the foregoing clauses. There is also useful information in the attempt to identify what portions of the Bluetooth functional decomposition correspond to the 802 PHY layer and 802 MAC sublayer. However, there is no information about what L2CA primitives are generated, in what order, to perform the MA-UNITDATA.request function; what L2CA_Indications cause an MA-UNITDATA.indication; nor what transmission status information is conveyed in the MA-UNITDATA-STATUS.indication and which (if any) L2CA_Confirm messages supply this status information. Without a definition of the mapping between the MAC SAP primitives and L2CA primitives, there is insufficient information to understand the ""relationship of Bluetooth entities to IEEE 802 constructs.""" SUGGESTED REMEDY: "Please define which L2CA primitives are generated, in what order, to perform the MA-UNITDATA.request function; which L2CA_Indications cause an MA-UNITDATA.indication; and which transmission status information is conveyed in the MA-UNITDATA-STATUS.indication and which (if any) L2CA_Confirm messages supply this status information. State whether these definitions are strict (normative) or exemplary (informative), with consideration for whether interoperation of peer MAC entities will be reliable if these definitions are exemplary."RESPONSE: "REJECT. See comment resolution SB1 #26." COMMENT STATUS: R RESPONSE STATUS: W -------------------- COMMENT #: 29 IEEE #: 06810238 NAME: Fischer, Michael E-MAIL: mfischer@choicemicro.com PHONE: +1-210-614-4096 FAX: +1-210-614-8192 CO/ORG: Intersil Corp PAGE: 61-62 LINE: 27-47 and 14-15 CLAUSE: 8.5.3.3 TYPE OF COMMENT: T COMMENT: "This sentence states that ""Flushing will not necessarily result in a change in the SEQN bit value ..."" but based on figure 28 it appears that flushing NEVER results in a change to the SEQN bit value, since there is only one ""invert SEQN"" symbol and all possible flush paths go around that symbol." SUGGESTED REMEDY: "Either clarify this mention of ""not necessarily"" by identifying when SEQN does change in conjunction with flush, or correct figure 28 and the associated text in the previous section. The wording in the previous section can be interpreted to indicate there are really multiple places where a ""flush"" decision can occur, but only one such place appears in figure 28." RESPONSE: "REJECT. Figure 28 does NOT show an algorithm for deciding when a flush occurs as comment 29 and the suggested remedy imply. Figure 28 shows when the SEQN is or is not inverted. For example, if a transmission is ACKed once, then the SEQN number is always inverted (independently if FLUSH has occurred in the mean time or not). If a transmission has not been ACKed once then the SEQN is not inverted (independently if flush has occurred or not). Thus, there are cases that SEQN may be inverted even if flush has occurred, or SEQN may not be inverted even if flush has occurred. FLUSHing here means the emptying of the transmit buffer for a reason other than a successful transmission (for example, because a packet has stayed in the transmit buffer for too long). Clause 8.5.3.3 states this in the last sentence of the first paragraph ""...Aborting the retransmit scheme is accomplished by flushing the old data...""" COMMENT STATUS: R RESPONSE STATUS: W -------------------- ==================== Legend: Comment Type: T/technical E/editorial Comment Status: D/dispatched A/accepted R/rejected Response Status: O/open W/written C/closed U/unsatisfied Z/withdrawn More info: http://ieee802.org/15/pub/SB1/SB1.html -- Ian Gifford giffordi@ieee.org -EOF-