1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN:
Title: P to RevCom
Date Submitted: August, 2008
Authors or Source(s):
  Vivek Gupta
Abstract:
Summary of Sponsor Ballot Results and Approval to submit to RevCom

2. IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual < and in Understanding Patent Issues During IEEE Standards Development

3. P To RevCom August, 2008

4. 802.21 Sponsor Ballots Stage Open Close Sponsor Ballot Aug 17, 2007
Sep 17, 2007
Sponsor Ballot Recirc #1
Dec 20, 2007
Jan 09, 2007
Sponsor Ballot Recirc #2
Feb 08, 2008
Feb 25, 2008
Sponsor Ballot Recirc #3
April 24, 2008
April 27, 2008
Sponsor Ballot Recirc #4
June 03, 2008
June 18, 2008
Sponsor ballot Recirc #5
July 01, 2008
July 16, 2008
Sponsor Ballot Recirc #6
(Confirmation Ballot)
July 30, 2008
Aug 14, 2008

5. Vote Tally In last re-circ SB-Recirc-6: No New Disapprove votes
Draft Ver
Approve
Disapprove
Total
Approval Ratio
Abstain
Ballots
Members
Return Ratio
D13.0
126 5
131
126/131 = 96.18% 11
142
165
142/165 = 86%
In last re-circ SB-Recirc-6:
No New Disapprove votes
Total 5 Disapprove Voters with Comments
Total of 12 comments were submitted. 7 of these are from Disapprove voters.
No Technical changes are required as a result of these comments
No new valid Disapprove comments on new issues

6. Voting Results
SB #1
Recirc-1
Recirc-2
Recirc-3
Recirc-4
Recirc Recirc-6
Draft
7.0
8.0
9.0
10.0
11.0
12.0
13.0
Ballot Group
165
Approve 71
103
112
115
121
124
126
Disapprove with
Comments 43 21 15 12 7 5
Disapprove without 2
Abstain 13 11
Total Ballots
129
137
140
142
Approval %
62%
83%
88%
90%
94%
96%
Return %
78%
84%
86%

7. Comments associated with Remaining Disapprove votes and Working Group Responses

8. Tony Jeffree 1/2 Must be satisfied: Yes Category: General Comment # 1
Comment: I consider your response to my comment#1 on recirc #4 to be non-responsive. Your response was: "Niether IEEE nor IEEE 802 require a PICS Proforma. Niether IEEE or IEEE 802 provide any guidance for its creation. Therefore the only authoritative reference for the creation of a PICS Proforma is ITU-T X.296 (ISO/IEC 9646:7). Following its guidance only X.290 and X.296 are required as per " If, as you claim, you are following the guidance of X.296, then one of the requirements of X.296 is that you include a conformance clause in your standard. I would refer you to of X.296 which states very clearly in its opening sentence: "Each ICS proforma specification shall include a conformance clause,...etc. etc.".
Proposed Change: Follow the guidance of X.296, and in particular, include a conformance clause in your standard as REQUIRED by X.296.
Resolution Status: Reject
Resolution Detail: The guidance of of X.296 was followed. The suggested text from of X.296 appears in Annex M, specifically M.3.

9. Tony Jeffree 2/2
Must be satisfied: Yes Category: Technical Comment # 2
Page: 33 Sub-clause: Line #: 24
Comment: In the table you have quoted the Ethertype value as "0x89 0x17". By quoting the value as two separate octet values, you create opportunities for ambiguity in interpretation - for example, is this two separate 16-bit values? if they are separate octets of the same value what is the octet ordering?
Proposed Change: Represent the Ethertype value either as a single 16-bit hex value: 0x8917 Or use the hexadecimal representation defined in IEEE Std 802 (see 3.1.8). In the latter case, the value would be represented as: 89-17
Resolution Status: Principle
Resolution Detail: Clause 5.7.2, page 33, line 23, Table 2, value column; 1) Change "0x89 0x17" to "89-17“ 2) Insert table footnote for this value: “This Ethertype value is expressed using the hexadecimal representation defined in IEEE Std. 802.”

10. Clint Chaplin 1/1
Must be satisfied: No Category: Editorial Comment # 3
Page: 152 Sub-clause: Line #: 39
Comment: "For example, by listening to a media-specific broadcast message such as a Beacon frame in IEEE or a DCD in IEEE , link layers on an MN forward the detected MIH capabilities to its MIHF.”
Proposed Change: "For example, by listening to a media-specific broadcast message such as a Beacon frame in IEEE or a DCD in IEEE , link layers on an MN can then forward the detected MIH capabilities to its MIHF.”
Resolution Status: Accept
Resolution Detail:
Comment will be forwarded to the IEEE project editor for application.

11. Andrew Myles 1/5
Must be satisfied: Yes Category: Technical Comment # 4
Page: 259 Line #:10
Comment: Annex F.3.8: In the last ballot I commented on P245L45-65: Annex F: There is an entry for LCI in the table, but this does not address new capabilities coming in v WG stated in the last comment resolution spreadsheet, "The IETF draft is an individual submission in the IETF and is not a standard documents yet." Yet this comment failed to address the comments pertaining to non-IETF standards and so was an incomplete resolution.
Proposed Change: Change "IEEE LCI" to "IEEE "; add a new type as "LbyR with IEEE ". Note that v supports both methods.
Resolution Status: Reject
Resolution Detail: This comment (related to v) was rejected previously, no need to address it again.

12. Andrew Myles 2/5
Must be satisfied: Yes Category: Technical Comment # 5
Page: 260 Line #:34
Comment: Annex F.3.8:Bit 4 refers to at 316 THz. As far as I'm aware, there is no system, norm amendment specifying operation in this band.
Proposed Change: Change bit 4 to a reserved bit.
Resolution Status: Reject
Resolution Detail:
This is the IR clause 16 in IEEE
There has been no change to this text in last re-circulation.

13. Andrew Myles 3/5
Must be satisfied: Yes Category: Technical Comment # 6
Page: 260 Line #: 34
Comment: Annex F.3.8: Bits 0 thru 3 inclusive indicate frequency bands that the network is operating in. However, this is duplicate information, since the band is provided in FREQ_BANDS.
Proposed Change: Change bits inclusive to reserved.
Resolution Status: Reject
Resolution Detail:
The information here is not exactly the same as that in the FREQ_BANDS.
There has been no change to this text in last re-circulation.

14. Andrew Myles 4/5
Must be satisfied: Yes Category: Technical Comment # 7
Page: 230 Line #: 18
Comment: Annex F.3.2: UTF-8 is cited as the character encoding, however there is no normative reference in clause 2 to the proper RFC (RFC-3629)
Proposed Change: Add a normative citation to clause 2.
Resolution Status: Reject
Resolution Detail:
This comment is out of scope. However, insert UTF-8 RFC-3629 reference to bibliography.

15. Andrew Myles 5/5
Must be satisfied: Yes Category: Editorial Comment # 8
Page: 155 Line #: 21
Comment: : The text states, "... media-specific manner (i.e., using IEEE beacon frames, ...". However, "i.e." should be "e.g." since the parenthetical list is not comprehensive (e.g., it could be done using probe request/response).
Proposed Change: Change "i.e." to "e.g.".
Resolution Status: Accept
Resolution Detail:
Comment will be forwarded to the IEEE project editor for application.

16. Michelle Turner 1/1
Must be satisfied: Yes Category: Technical Comment # 9
Page: 5 Sub-clause: 2 Line #:29
Comment: Reference P802.1aj is not cited in text. If it is not needed to implement the standard, it should be moved to the bibliography.
Resolution Status: Reject
Resolution Detail:
The reference is already present in the draft. See page 253 line 42 (Table F.19)

17. Yoshi Ohba 1/3 Must be satisfied: No Category: General Comment # 10
Page: 60 Sub-clause: Line #:44
Comment: The current set of MIH_LINK_SAP primitives cover all primitives specified in RFC 5184 (Unified L2 Abstractions for L3-Driven Fast Handover) except for L2-LinkConnect which allows MN to connect to a specific PoA. In other words, D13 misses to support the functionality to connect to a specific PoA. It would be best if MIH_Link_Action is modified to support L2-LinkConnect so that the specification can claim that it fully supports RFC 5184.
Proposed Change: [1] Add the following sentence to Clause "The MIH_LINK_SAP primitives cover L2 abstractions specified in RFC 5184 [B35]. [2] Change the Definition of LINK_ACTION_REQ in page 232 as follows: "A set of handover action request parameters. The choice of LINK_ADDR is to provide PoA address information when the LINK_ACTION contains the attribute for DATA_FWD_REQ or CONNECT_POA." [3] Add the following bit to LINK_AC_ATTR data type: "Bit 3: CONNECT_POA". [4] Add the following entry to Table F.6: "CONNECT_POA | This indication requires MN to connect to a specific PoA." [5] Add an informative reference B35 to RFC 5184 in Annex A: "[B35] IETF RFC 5184 ( ), Unified L2 Abstractions for L3-Driven Fast Handover".
Resolution Status: Reject
Resolution Detail:
This comment is withdrawn (See comment 12).
The text "The choice of LINK_ADDR is to provide PoA address information when the LINK_ACTION contains the attribute for DATA_FWD_REQ." does not forbid including it at other times. Yes it is required for DATA_FWD_REQ. As for the need for a separate connect-to-PoA attribute. Power UP can be used and it will then be up to the link specific protocol to decide what actions are appropriate.

18. Yoshi Ohba 2/3 Must be satisfied: No Category: Editorial Comment # 11
Page: 138
Comment: Blank Page
Proposed Change: Remove Blank Page
Resolution Status: Accept
Resolution Detail:
Comment will be forwarded to the IEEE project editor for application.

19. Yoshi Ohba 3/3 Must be satisfied: No Category: Editorial Comment # 12
Page: 60 Sub-clause: Line #:44
Comment: It's better to mention RFC 5184 (Unified L2 Abstractions for L3-Driven Fast Handover) as an informative reference. (The General comment on the same page and line is withdrawn and replaced with this Editorial comment.)
Proposed Change: [1] Add the following sentence to Clause "The MIH_LINK_SAP primitives cover most L2 abstractions specified in RFC 5184 [B35]." [2] Add an informative reference B35 to RFC 5184 in Annex A: "[B35] IETF RFC 5184 ( ), Unified L2 Abstractions for L3-Driven Fast Handover".
Resolution Status: Principle
Resolution Detail:
Comment will be forwarded to the IEEE project editor for application. NOTE: It will not be [35] in Annex A, but appropriately placed and Annex renumbered.

20. LMSC Motion (July 2008)
To grant conditional approval, under Clause 19, to forward P802.21/D13 to RevCom
Moved: Vivek Gupta
Seconded: Bruce Kraemer
Approve: 15
Disapprove 1
Abstain: 0
Result: Motion Passes
WG Motion: 22/0/3