Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[802SEC] Report of P802.15.3D17 under Procedure 10




In our meeting of 14 March, the SEC granted conditional approval, according to Procedure 10, to forward P802.15.3/D17 to RevCom. Accordingly, I am making this mandatory report.  Sorry for the slight delay in getting this out. As you will see in the report below, I wanted to get an up to date email reaffirmation from 6 of the no voters who had accepted the comment resolution on the previous recirculation but neglected to change their vote during the 2nd recirculation.

On April 22 we concluded a 15 day recirculation of Draft 17.

Ballot Summary
P802.15.3/D17 2nd Recirculation
Closing date: 2003-04 -22
This is a recirculation ballot. The report collates the results from the following groups: 0000290 0000476 0000503.
1. This ballot has met the 75% returned ballot requirement.
101 eligible people in this ballot group.
70 affirmative votes
8 negative votes with comments
0 negative votes without comments
6 abstention votes
=====
84 votes received = 83% returned
7% abstention
2. The 75% affirmation requirement is being met.
70 affirmative votes
8 negative votes with comments
=====
78 votes = 89% affirmative

We received 2 new yes votes, 1 change from no to yes and  no new no votes.  Of the 8 no votes, all were from the original ballot or the first recirculation of D16.  6 of the no voters had accepted the resolution to their comments following the recirculation of D16 and confirmed via email prior to the start of the second recirculation on D17.  They apparently assumed their email confirmation was sufficient and did not change their vote in the recirculation of D17. I have requested and have received reaffirmation of their acceptance on the current draft. One of the remaining no voters accepted the resolution on one of his comments prior to the start of the second recirculation. This leaves 2 no voters and a total of 6 comments which have been rejected, rebutted, and recirculated. Copies of these comments are at the end of this email.  The email confirmations will be forwarded along with Draft 17 to RevCom.  The final tally, accounting for the those who have accepted the comment resolution, is:

76 affirmative votes or  97% affirmative
2 negative votes with comments
0 negative votes without comments
6 abstention

As there were no new no votes or comments and no change is being made to D17, this ballot is concluded and Draft 17 and supporting documentation will be forwarded to RevCom for action at the upcoming meeting in June.

Rejected and Recirculated Comments:

CID 167:
CommenterName:  Struik, Rene
Comment Type: TR

COMMENT START:
The 802.15.3 Chair directed the removal of all public-key key establishment mechanisms from the D15 Draft (see 03/054r1). It is however not clear at all on which rationale this decision was made. In fact, one can easily provide technical arguments that the decision lacks any justification and is not based on sound professional or engineering arguments The 802.15.3 standard without proper entity authentication and key establishment mechanisms is a standard that cannot be implemented by industry, since it is incomplete. Moreover, no concrete suggestions are done how to provide adequate specifications for this functionality. Without this, this standard cannot be implemented by industry and will not be used or used with considerable delay. Last, but not least, the decision on what is supposed to be inside scope and what isn’t seems to be based on arbitrary arguments. For a detailed rationale considering this comment, see the document I will post during the March 2003 Dallas meeting and the presentation I intend to give there.
COMMENT END:

SUGGESTED REMEDY:
Revert the decision to drastically modify the security properties of the standard. Re-incorporate all authentication and key establishment-related security mechanisms that were removed from the draft in the transition process from Draft D15 towards Draft D16. Re-consider all sponsor ballot comments related to Draft D15.
SUGGESTED REMEDY END:

RESPONSE:
REJECT. The PAR of 802.15.3 limits the scope of our standard. There are many issues of an implementation that are outside of the scope of a MAC and PHY. For example, service discovery, network address resolution, routing and bridging are all outside of the scope of a MAC/PHY standard. The committee has used the experience with the public-key cryptography suites to ensure that the 802.15.3 MAC supports the use of these higher layer protocols to perform entity authentication and key establishment. There are higher layer protocols, e.g. 802.1x, that allow MAC/PHY standards to implement entity authentication and key establishment. The 802 leadership and the 802.15 working group chair both indicated that the inclusion of these security suites was outside of the scope of a MAC/PHY standard.
RESPONSE END:

----------------------------------

CID 168:
CommenterName:  Struik, Rene
Comment Type: TR
 
COMMENT START:
The 802.15.3 Chair directed the removal of all public-key key establishment mechanisms from the D15 Draft (see 03/054r1). It is however not clear at all on which rationale this decision was made. In fact, one could address Paul Nikolich’s comments (as worded in 03/54r1) by implementing just 1 public-key security suite (this removing choice). This would allow a standard that is functional and complete and was also the initial intention before politics entered the 802.15.3 stage.
COMMENT END:

SUGGESTED REMEDY:
Revert the decision to drastically modify the security properties of the standard. Re-incorporate 1 authentication and key establishment-related security mechanisms, viz. the ECMQV security suite that was removed from the draft in the transition process from Draft D15 towards Draft D16. Re-consider all sponsor ballot comments related to Draft D15.
SUGGESTED REMEDY END:

RESPONSE:
REJECT. The SBRC voted 11 to 1 to remove the public-key cryptography suites, per the recommendation from the 802 SEC chair and the 802.15 working group chair. The SBRC agreed that the inclusion of these suites could be seen as being outside of the scope of the PAR which limits the standard to the MAC and PHY only. The decsion to remove the security suites was affirmed by the working group in the closing plenary of the Ft. Lauderdale meeting as well. The issue of the inclusion of the public-key cryptography suites was not that there were more than one option, but rather that the authentication process took place in layers above the MAC and PHY. Removing all but one public-key suite would not resolve the issue of the public-key security suites being out of scope of the 802.15.3 PAR.
RESPONSE END:

-------------------------------------

CommentID:  150
CommenterName:  Gubbi, Rajugopal
CommentType:  TR

Comment: 
Remove Slotted aloha scheme from the draft ref: CID 537 - LB12, CID 387 - LB19, and CID 56 - LB22.  What is the point in having slotted aloha access in addition to the backoff in CAP, TDMA in CFP? I don't see any justification in having yet another access scheme with WPAN. Why is this unncessary additional complexity being forced on to the implementors of this "low cost", "low complexity" and "low power" standard? If some future PHYs need it, let this be added as and when such a PHY is added to the 802.15.3 standard.
CommentEnd: 

SuggestedRemedy: 
Make the change as requested.
RemedyEnd: 

Response: 
REJECT. The open and association MCTAs were added to handle two concerns, the first was that new PHYs may not support efficient CCA detection. In this case, slotted aloha provides a contention access method that provides for the needs of the piconet. Another reason to used slotted aloha is that under certain conditions, it can be more efficient than using the CAP. Adding a new contention method to the MAC when a PHY group has been formed is probably not the best venue. At this time, the TG has many members who have expertise in the MAC available to review draft. In the future, when a new PHY is down-selected, there may not be as many people available who have the experience and knowledge of the TG3 MAC to be able to add a new contention method. Adding slotted aloha does not add much, if any complexity, the DEV needs the random number generatora and exponential increasing backoff for any contention based method. The DEV is already required to be able to send frames and look to see if it gets an ACK. Depending on the parameters used for either the CAP or the open and association MCTAs, the power usage may actually be lower using MCTAs for the DEVs in the piconet than using the CAP. MCTAs have an advantage over the CAP in that they can be put into multiple locations in the superframe allowing the PNC to potentially use the time more efficiently.
ResponseEnd: 

-----------
CommentID:  151
CommenterName:  Gubbi, Rajugopal
CommentType:  TR

Comment: 
Remove MCTA scheme from the standard ref: CID 536 - LB12, CID 513 - LB19, and CID 63 - LB22.  Why can't the open and association be performed in CAP instead of devicing a new mechanism altogether for such a relatively low probability events? what is the point in having another collision based access mechanism inside a declared "collision free period (CFP)". If the concern is about a new PHY that may be added in the future, this mechanism can be added at the time of including the new PHY as allocations to a currently reserved stream ID (or DEVID) so that the legacy DEVs keep off of those slots and the new DEVs use them as per the new rules.
CommentEnd: 

SuggestedRemedy: 
Make the change as requested.
RemedyEnd: 

Response: 
REJECT. The open and association MCTAs were added to handle two concerns, the first was that new PHYs may not support efficient CCA detection. In this case, slotted aloha provides a contention access method that provides for the needs of the piconet. Another reason to used slotted aloha is that under certain conditions, it can be more efficient than using the CAP. Adding a new contention method to the MAC when a PHY group has been formed is probably not the best venue. At this time, the TG has many members who have expertise in the MAC available to review draft. In the future, when a new PHY is down-selected, there may not be as many people available who have the experience and knowledge of the TG3 MAC to be able to add a new contention method. Adding slotted aloha does not add much, if any complexity, the DEV needs the random number generatora and exponential increasing backoff for any contention based method. The DEV is already required to be able to send frames and look to see if it gets an ACK. Depending on the parameters used for either the CAP or the open and association MCTAs, the power usage may actually be lower using MCTAs for the DEVs in the piconet than using the CAP. MCTAs have an advantage over the CAP in that they can be put into multiple locations in the superframe allowing the PNC to potentially use the time more efficiently.
ResponseEnd: 

-----------
CommentID:  152
CommenterName:  Gubbi, Rajugopal
CommentType:  TR

Comment: 
Replace MIFS with SIFS ref: CID 68 - LB22
- MIFS is less than SIFS
- it does not result in any significant time eficiency given the low probability of its use
- But introduces yet another IFS at the lowest level of MAC
- Mandates that the receive frames be processed within MIFS instead of SIFS since the worst case IFS is MIFS and hence drastically increases the complexity at the MAC and PHY Remove MIFS and use SIFS in its place.
CommentEnd: 

SuggestedRemedy: 
Make the change as requested.
RemedyEnd: 

Response: 
REJECT. Using the MIFS instead of the SIFS with no-ACK frames can provide an improvement in the throughput of 8%. One of the key applications of 802.15.3 is streaming applications such as music and video which typically would be sent with either a no-ACK or Dly-ACK policy. At 55 Mb/s this is equivalent to 4.4 Mb/s, almost enough for an additional SDTV stream. This does require that the receiver process unload its input queue somewhat faster, but this can be handled in hardware.
ResponseEnd: 


-----------
CommentID:  154
CommenterName:  Gubbi, Rajugopal
CommentType:  TR

Comment: 
Remove app-specific IE ref: CID 446, 477, 478 and 479 - LB19, CID 71 - LB22.  Use of Vendor specific command is the answer to the issue that is intended to be solved through this app-specific IE. This is expecially since neither the standard nor an implementation of PNC can force the interpretation of bits in the currently undefined payload of this IE at each DEV which may be implemented by variety of vendors with their own "application" specific interpretations of those bits.
CommentEnd: 

SuggestedRemedy: 
Make the change as requested.
RemedyEnd: 

Response: 
REJECT. The ASIE is intended to be included in the beacon as an announcement. A command cannot be sent in the beacon so the vendor specific command would not be applicable to solve this need. The ASIE was put in to enable new functionality for some DEVs without breaking compatibility for all DEVs. Since the TG cannot possibly forsee all uses that might be required, this is left to be defined by the vendors.
ResponseEnd: 











Bob Heile, Ph.D
Chair, IEEE 802.15 Working Group on Wireless Personal Area Networks
Chair, ZigBee Alliance
11 Louis Road
Attleboro, MA  02703   USA
Phone: 508-222-1393
Mobile: 781-929-4832
Fax:        508-222-0515
email:   bheile@ieee.org