1 / 22

Discussion of issues related to the submission of 802.21 D13.0 to RevCom

Discussion of issues related to the submission of 802.21 D13.0 to RevCom. The 802.21 draft must be recirculated before submission to RevCom. Situation.

vilmos
Download Presentation

Discussion of issues related to the submission of 802.21 D13.0 to RevCom

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Discussion of issues related tothe submission of 802.21 D13.0 to RevCom Andrew Myles (Cisco)

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

  3. The 802.21 WG was intending to send 802.21 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 802.21 WG Technical Editor provided resolutions to these comments on 14 Aug 08 • See 21-08-0248-00-0000-SB_Recirc_6_Comments • It appears these responses were not considered by the 802.21 WG • No changes were made to the draft as a result of these responses • The 802.21 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 Andrew Myles (Cisco)

  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 802.21 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 802.21 WG Chair invited Andrew Myles to address the 802.21 WG in Sept WG meeting • He also noted that “It seems highly unlikely at this point that 802.21 WG will agree to this change” • Andrew Myles will be presenting to the 802.21 on 8 Sep 08 in the session after lunch Andrew Myles (Cisco)

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

  6. 802.21 WG has been “non responsive” to requests to include the location functionality defined by 802.11v … SB Comment Response Response stat. Comment status D11.0 Include provision for location functionality defined in 802.11v Not possible until 802.11v is an “approved standard” Valid Open, until the next SB D12.0 Repeated request, asking how 802.11u features can be included given it is not “approved standard” Ignored comment by repeating that only “approved specifications” can be included Non responsive 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 Non responsive 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 Non responsive Open, until the next SB … which means the comment is open & unresolved Andrew Myles (Cisco)

  7. Ballot SB (recirc 4) on D11.0 CID 4471100023 Request A request was made in the SB on D4.0 to include provision for location functionality defined in 802.11v Response REJECT It was noted that the functionality could not be included because 802.11v was not an “approved standard” It was noted that “802.11 LCI” was allowed because it was part of 802.11k, which “is an approved standard” Commentary 802.11k 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 “802.11 LCI was first included” This response set the “standard” of inclusion of features into 802.21, 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 The SB on D11.0 established that only features from “approved standards” may be included in 802.21 Andrew Myles (Cisco)

  8. Ballot SB (recirc 5) on D12.0 CID 4564600023 Request The request from SB (recirc 4) on D11.0 to include provision for location functionality defined in 802.11v was repeated The commenter also challenged the response to the comment in SB (recirc 4) on D11.0 by asking how features from 802.11u 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 802.11u features were included before they had even reached 75% in WG LB The SB on D12.0 emphasised that only features from “approved standards” may be included in 802.21 … … and the WG was “non responsive” when explaining the inclusion of 802.11u features Andrew Myles (Cisco)

  9. Ballot SB (recirc 5) on D12.0 CID 4566300023 Request The request from SB (recirc 4) on D11.0 to include provision for location functionality defined in 802.11v 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 4471100023 in the SB on D11.0; however, that response was challenged by CID 4564600023 in the SB on D12.0 and so the issue is still open The SB on D12.0 emphasised that only features from “approved standards” may be included in 802.21 … … and the WG did not respond fully to all comments Andrew Myles (Cisco)

  10. Ballot SB (recirc 6) on D13.0 CID 4643700023 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 802.11v was repeated It was noted that the response to CID 4566300023 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 802.11v was previously rejected is incomplete because previous responses have been either incomplete or non responsive The SB on D13.0 continued to fail to address the issues raised in comments … and falsely asserted that the location issue has been properly dealt with Andrew Myles (Cisco)

  11. The claim that only “approved standards” can be referenced is inconsistent with 802.21 D13.0 • The 802.21 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, 802.21 D13.0 contains many references to 802.11u, which is not an “approved standard” • One could argue that 802.11u is an “approved (by the 802.11 WG) draft” because it (very) recently reached the 75% threshold in a WG LB • However, 802.11u has not even been considered by the Sponsor Pool and so any “approval” is at a remarkably low level • The 802.21 draft is thus inconsistent with the principles repeated on numerous occasion by the 802.21 WG, leaving the 802.21 WG with a few obvious choices: • Change the “principle”, thus allowing references to 802.11v • Maintain the “principle”, but remove all references to 802.11u Andrew Myles (Cisco)

  12. The 802.21 draft should be recirculated (possibly twice) as soon as possible … • The fastest way of getting 802.21 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 802.11v be referenced by 802.21? • 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 Andrew Myles (Cisco)

  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 Andrew Myles (Cisco)

  14. Location functionality defined by 802.11v should be referenced by 802.21 • The current 802.21 draft refers only to 802.11 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 • 802.11v adds both capabilities, completing the work started in 802.11k. • Given the precedent established in the 802.21 draft of allowing references to unapproved drafts, there is an excellent technical case to allow references to these important 802.11v features Andrew Myles (Cisco)

  15. The alternative to a recirculation of 802.21 is a long & potentially painful procedural argument • 802.21 WG could continue with their plan to submit 802.21 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 802.21 • Ratification could easily slip to the next RevCom meeting in March 2009 • This is in the interest of no one! Andrew Myles (Cisco)

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

  17. … but what we should be doing is ensuring 802.21 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 802.21 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? Andrew Myles (Cisco)

  18. Annex containing the relevant comments and responses from the SB’s on D11.0, D12.0 and D13.0 Andrew Myles (Cisco)

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

  20. CID 4564600023 in SB (recirc 5) on D12.0 • CID • 4564600023 • Comment • pp245, line45-65: Annex F: There is an entry for 802.11 LCI in the table, but this does not address new capabilities coming in 802.11v. • 802.21 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 802.11v is approved)". This does not make sense to me since 802.21 WG was quite willing to cite 802.11u before it reach 75% approval rate • Suggested change • Change "IEEE 802.11 LCI" to "IEEE 802.11"; add a new type as "LbyR with IEEE 802.11". Note that 802.11v supports both methods. • Response • The WG will add in the corresponding type once the specification is approved. Actual text Andrew Myles (Cisco)

  21. CID 4566300023 in SB (recirc 5) on D12.0 • CID • 4566300023 • Comment • P245L45-65: Annex F: There is an entry for 802.11 LCI in the table, but this does not address new capabilities coming in 802.11v. • Suggested change • Change "IEEE 802.11 LCI" to "IEEE 802.11"; add a new type as "LbyR with IEEE 802.11". Note that 802.11v supports both methods. Add the following: "Add SIP LbrR" with the following citation: http://www.ietf.org/internet-drafts/draft-polk-sip-location-get-00.txt • Response • The IETF draft is an individual submission in the IETF and is not a standard documents yet. Actual text Andrew Myles (Cisco)

  22. CID 4643700023 in SB (recirc 6) on D13.0 • CID • 4643700023 • Comment • In the last ballot I commented on P245L45-65: Annex F: There is an entry for 802.11 LCI in the table, but this does not address new capabilities coming in 802.11v. • 802.21 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 802.11 LCI" to "IEEE 802.11"; add a new type as "LbyR with IEEE 802.11". Note that 802.11v supports both methods. • Response • The 802.11v comment was rejected previously, no need to address it again Actual text Andrew Myles (Cisco)

More Related