[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