doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 1 Discussion of issues related to the submission of D13.0 to RevCom

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 2 The draft must be recirculated before submission to RevCom Situation Complication Answer Alternative The WG was intending to send D13.0 to RevCom for ratification in Sept 08 & is now planning to do so in Dec 08 despite protests of outstanding valid comments However, the draft cannot reasonably be submitted to RevCom without at least one more recirculation The draft should be recirculated (possibly twice) as soon as possible, which will avoid any delay A long and painful procedural argument!  , 802 EC, WG and TGv need to make decisions between these alternatives … Next steps

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 3 The WG was intending to send D13.0 to RevCom for ratification in Sept 08 … The SB recirculation on D13.0 completed on 14 Aug 08 –The vote was Yes – 126 (96%), No, 5, Abstain – 11 –12 comments were submitted The WG Technical Editor provided resolutions to these comments on 14 Aug 08 –See SB_Recirc_6_Comments –It appears these responses were not considered by the WG –No changes were made to the draft as a result of these responses The WG Chair announced that the draft would be submitted to RevCom based on the Conditional Approval from the 802 EC –He announced it would be submitted to the July 08 RevCom meeting but actually meant the Sept 08 RevCom meeting

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 4 … and is now planning to do so in Dec 08 despite protests of outstanding valid comments It now appears the draft will be submitted to the RevCom meeting in Dec 08 –It transpired that the deadline had been missed for the draft to be placed on the RevCom meeting agenda in Sept 08 –The WG Chair has not yet confirmed his plans to submit the draft to RevCom –The agenda deadline for the Dec RevCom meeting is 20 Oct 08 Andrew Myles asserted on 18 Aug 08 that he believed the conditions had not been met because there were outstanding & unresolved valid comments On 20 Aug, the WG Chair invited Andrew Myles to address the WG in Sept WG meeting –He also noted that “It seems highly unlikely at this point that WG will agree to this change” –Andrew Myles will be presenting to the on 8 Sep 08 in the session after lunch

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 5 The draft cannot reasonably be submitted to RevCom without at least one more recirculation Valid comments remain open & unresolved Principles have been applied inconsistently by the WG WG has been “non responsive” to requests to include the location functionality defined by v, which means comments are open & unresolved The claim that only “approved standards” can be referenced by is inconsistent with the latest draft, which includes material from u (an “unapproved standard”)

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide WG has been “non responsive” to requests to include the location functionality defined by v … SBCommentResponse D11.0 Include provision for location functionality defined in v Not possible until v is an “approved standard” Comment status Open, until the next SB D12.0 Repeated request, asking how u features can be included given it is not “approved standard” Ignored comment by repeating that only “approved specifications” can be included Open, until the next SB D12.0 Repeated request, and also suggested the inclusion of an IETF reference Ignored request, & denied IETF suggestion by repeating only “approved standards” can be included Open, until the next SB D13.0 Repeated request, and noted incomplete response in last SB Ignored “incomplete” response comment, & incorrectly asserted the issue had been dealt with Open, until the next SB Response stat. Valid Non responsive … which means the comment is open & unresolved

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 7 The SB on D11.0 established that only features from “approved standards” may be included in Ballot SB (recirc 4) on D11.0 CID Request A request was made in the SB on D4.0 to include provision for location functionality defined in v Response REJECT It was noted that the functionality could not be included because v was not an “approved standard” It was noted that “ LCI” was allowed because it was part of k, which “is an approved standard” Commentary k become an “approved standard” on 9 May 2008, which means the response was correct at the time it was written, although possibly not at the time “ LCI was first included” This response set the “standard” of inclusion of features into , ie the feature must be part of an “approved standard” Note that reaching 75% in LB or SB does not mean a standard is “approved”, rather it means the draft may be forwarded to the next step in the process

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 8 The SB on D12.0 emphasised that only features from “approved standards” may be included in … Ballot SB (recirc 5) on D12.0 CID Request The request from SB (recirc 4) on D11.0 to include provision for location functionality defined in v was repeated The commenter also challenged the response to the comment in SB (recirc 4) on D11.0 by asking how features from u were cited, when they had not even reached 75% in WG LB Response REJECT It was noted that the functionality would only be included when “the specification is approved” Commentary This response emphasised the principle that a feature should only be included when it defined by “approved standard” The response was actually “non- responsive” because it did not attempt to explain how u features were included before they had even reached 75% in WG LB … and the WG was “non responsive” when explaining the inclusion of u features

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 9 The SB on D12.0 emphasised that only features from “approved standards” may be included in … Ballot SB (recirc 5) on D12.0 CID Request The request from SB (recirc 4) on D11.0 to include provision for location functionality defined in v was repeated The commenter also suggested adding "SIP LbyR" with a citation to an IETF draft Response REJECT It was noted that the cited IETF document was only a draft and not a standard Commentary This response emphasises again the principle that a feature should only be included when it defined by “approved standard” The response was actually “incomplete” because it did not address the first part of the comment in any way It has been argued that the first part had already been dealt with by CID in the SB on D11.0; however, that response was challenged by CID in the SB on D12.0 and so the issue is still open … and the WG did not respond fully to all comments

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 10 The SB on D13.0 continued to fail to address the issues raised in comments Ballot SB (recirc 6) on D13.0 CID Request The request from SB (recirc 4) on D11.0 and SB (recirc 5) on D12.0 to include provision for location functionality defined in v was repeated It was noted that the response to CID in SB (recirc 5) on D12.0 related to this topic was incomplete Response REJECT It was asserted that the comment was rejected previously Commentary The part of the comment relating to the incomplete response in the SB on D12.0 was ignored The assertion that the request to include provision for location functionality defined in v was previously rejected is incomplete because previous responses have been either incomplete or non responsive … and falsely asserted that the location issue has been properly dealt with

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 11 The claim that only “approved standards” can be referenced is inconsistent with D13.0 The WG have asserted on a number of occasions in response to ballot comments that only features from “approved standards” can be referenced –An “approved standard” must be interpreted as when RevCom ratifies a documents as a “standard”; before ratification the document is not a “standard”, merely a draft However, D13.0 contains many references to u, which is not an “approved standard” –One could argue that u is an “approved (by the WG) draft” because it (very) recently reached the 75% threshold in a WG LB –However, u has not even been considered by the Sponsor Pool and so any “approval” is at a remarkably low level The draft is thus inconsistent with the principles repeated on numerous occasion by the WG, leaving the WG with a few obvious choices: –Change the “principle”, thus allowing references to v –Maintain the “principle”, but remove all references to u

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 12 The draft should be recirculated (possibly twice) as soon as possible … The fastest way of getting ratified is to send a “clean” set of supporting documents to RevCom that demonstrate all open issues have been properly resolved from a procedural perspective Knowing all open issues have been properly resolved will provide RevCom with confidence that: –All technical issues have been properly considered –Any technical inconsistencies have either been removed or justified The particular open issue that needs to be considered is should the location functionality defined by v be referenced by ? –This author believes the answer is yes, but would like to see the question considered on it merits and not ignored or responded to with inconsistent arguments! Two recirculation's may be required to clean up the procedural “mess” –The first to make the requested change or provide a consistent rejection –The second may be required to respond to comments about the change or confirm the rejection

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 13 … which will avoid any delay It is still possible to get on the RevCom agenda for the December meeting with two (or even three) recirculation's –A final draft has to be placed on the RevCom agenda by 20 Oct 08 –This leaves plenty of time for two recirculation's –Indeed, a third recirculation is possible and allowed under LMSC rules after the deadline

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 14 Location functionality defined by v should be referenced by The current draft refers only to LCI However, this mechanism only provides GPS coordinates The draft does NOT allow for the use of other mechanisms commonly used in the industry today, including: –CIVIC –Location By Reference. Indeed, for emergency services and other location technologies the CIVIC address format and location by reference are mandatory v adds both capabilities, completing the work started in k. Given the precedent established in the draft of allowing references to unapproved drafts, there is an excellent technical case to allow references to these important v features

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 15 The alternative to a recirculation of is a long & potentially painful procedural argument WG could continue with their plan to submit to RevCom However, it is likely that a formal protest will be entered that claims there are valid, reasonable and unresolved comments It is unknown how RevCom might respond to these procedural issues At the very least, it will take time to resolve the issues and substantially delay the ratification of –Ratification could easily slip to the next RevCom meeting in March 2009 This is in the interest of no one!

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 16 Various groups need to decide what to do next … WG has choices Make requested changes and then send to recirculation immediately Send to recirculation immediately Ignore the issue and risk the outcome of a protest to RevCom … TGv has choices Support the early introduction of v technology by recommending that the Chair raise the issue in 802 ExCom … WG has choices Support the proposal to stop going to RevCom, possibly by asking the Chair to raise the issue in 802 ExCom … 802 ExCom has choices Intervene by withdrawing Conditional Approval … The author has choices Protest to WG Chair – done Protest to 802 ExCom Protest to RevCom …

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 17 … but what we should be doing is ensuring can be as good as it can be! Lets not get into a “procedural hell” … it just wastes everyone's time and creates substantial ill will! –All it will prove is that we have poorly written rules  Rather we need to focus establishing “consensus” that deserves to be an “approved standard” –ISO defines consensus as “General agreement, characterised by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments. Consensus need not imply unanimity” In this case we have sustained opposition on substantial issues Let us take the time to consider these issues seriously by accepting or rejecting the comments with resolutions that are complete and consistent Is this an unreasonable request?

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 18 Annex containing the relevant comments and responses from the SB’s on D11.0, D12.0 and D13.0

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 19 CID in SB (recirc 4) on D11.0 CID Comment Clause: Annex C.3.8, Page: 203, Line: 6-28) There is an entry for LCI in the table, but this does not address new capabilities coming in v. Suggested change Change "IEEE LCI" to "IEEE "; add a new type as "LbyR with IEEE ". Note that v supports both methods. Response No change. LCI is covered by IEEE k which is an approved standard. IEEE P802.11v is not. It is better to include future items at a future time (i.e, when v is approved) Actual text

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 20 CID in SB (recirc 5) on D12.0 CID Comment pp245, line45-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, "IEEE P802.11v is not. It is better to include future items at a future time (i.e, when v is approved)". This does not make sense to me since WG was quite willing to cite u before it reach 75% approval rate Suggested change Change "IEEE LCI" to "IEEE "; add a new type as "LbyR with IEEE ". Note that v supports both methods. Response The WG will add in the corresponding type once the specification is approved. Actual text

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 21 CID in SB (recirc 5) on D12.0 CID Comment P245L45-65: Annex F: There is an entry for LCI in the table, but this does not address new capabilities coming in v. Suggested change Change "IEEE LCI" to "IEEE "; add a new type as "LbyR with IEEE ". Note that v supports both methods. Add the following: "Add SIP LbrR" with the following citation: Response The IETF draft is an individual submission in the IETF and is not a standard documents yet. Actual text

doc.: IEEE /1068r0 Submission Sept 08 Andrew Myles (Cisco)Slide 22 CID in SB (recirc 6) on D13.0 CID Comment 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 Suggested change Change "IEEE LCI" to "IEEE "; add a new type as "LbyR with IEEE ". Note that v supports both methods. Response The v comment was rejected previously, no need to address it again Actual text