July 2010 doc.: IEEE 802.11-10/0xxxr0 IEEE 802 JTC1 Standing Committee Summary of SC6/IEEE 802 agreement issue 13 March 2012 Authors: Andrew Myles, Cisco.

Slides:



Advertisements
Similar presentations
Doc.: IEEE /0194r0 Submission Jan 2015 Andrew Myles, CiscoSlide 1 IEEE 802 JTC1 SC closing report (Jan 2015) Date: Authors:
Advertisements

Doc.: IEEE /1454r7 Submission March 2013 IEEE 802 JTC1 Standing Committee Proposal for SC6 contribution process 20 March 2013 Haasz et al, IEEESlide.
Submission February 2014 Slide 1 IEEE 802 Response to FDIS comments on IEEE 802.1AR 20 March 2014 Authors: NameCompanyPhone .
Slide 1 IEEE 802 Response to FDIS comments on IEEE 802.1AS 20 March 2014 Authors: NameCompanyPhone .
Slide 1 IEEE 802 Response to FDIS comments on IEEE 802.1AS 18 March 2014 Authors: NameCompanyPhone .
DICOM to ISO-DICOM Report to joint ISO TC215/WG2 – DICOM WG10 meeting January 24, 2004, San Diego.
Doc.: IEEE /0795r2 Submission July 2014 The China NB contributed a variation on the “usual comment” on IEEE China NB comment on
Doc.: IEEE /0858r0 Submission July 2008 Jesse Walker, Intel CorporationSlide 1 IEEE 802 Presentation for Xi’an Meeting Date: Authors:
Doc.: IEEE /0173r0 Submission Jan 2010 Andrew Myles, CiscoSlide 1 Closing Report Date: Authors:
Doc.: IEEE /0355r0 Submission Mar 2010 Andrew Myles, CiscoSlide 1 JTC1 ad hoc March 2010 agenda 5 March 2010 Authors:
Doc.: IEEE /1454r0 Submission Jan 2013 IEEE 802 JTC1 Standing Committee Proposal for SC6 contribution process 15 January 2013 Haasz et al, IEEESlide.
July 2010 doc.: IEEE /0xxxr0 Proposed liaison presentation to SC6 in relation to the identifier conflict issue 9 May 2011 Authors: Andrew Myles,
September Session Chair’s Supplementary Material
IEEE 802 JTC1 Standing Committee Proposal for SC6 contribution process
EC Motions Package Authors: Date: October 2016
EC Motions Package Authors: Date: October 2016
July Plenary EC Closing Motions Package
IEEE 802 EC July Motions Date: Authors: Name
July 2010 doc.: IEEE /0xxxr0 IEEE 802 JTC1 Standing Committee Motions for WG mid-session plenary 9 May 2017 Authors: Name Company Phone.
IEEE 802 Process for Interactions with ISO/IEC JTC 1/SC 6
Proposal for ETSI BRAN to restrict blocking energy
JTC1 ad hoc closing report (July 11)
IEEE 802 JTC1 Standing Committee formalization proposal
IEEE 802 JTC1 Standing Committee Nov 2017 motions for EC
IEEE 802 JTC1 Standing Committee July 2018 opening report for EC
IEEE 802 status report for ISO/IEC JTC1/SC6 meeting on 30 Oct 2017
IEEE 802 JTC1 Standing Committee March 2012 agenda
IEEE 802 JTC1 Standing Committee Proposal for SC6 contribution process
IEEE 802 JTC1 Standing Committee Nov 2017 opening report for EC
Working Group November Plenary EC Closing Motion
IEEE 802 JTC1 Standing Committee Proposal for SC6 contribution process
IEEE 802 JTC1 Standing Committee July 2017 opening report for EC
July 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: ISO/IEC JTC1 SC6 Liaison Report Date Submitted:
July Plenary EC Closing Motions Package
IEEE 802 Process for Interactions with ISO/IEC JTC 1/SC 6
July 2010 doc.: IEEE /0xxxr0 Responses to JTC1 NBs to comments made on FDIS ballots on IEEE ac & IEEE af 17 July 2015 Authors: Name.
July 2010 doc.: IEEE /0xxxr0 Responses to JTC1 NBs to comments made on FDIS ballots on IEEE ac & IEEE af 17 July 2015 Authors: Name.
IEEE 802 JTC1 Standing Committee Proposal for SC6 contribution process
IEEE 802 JTC1 Standing Committee July 2018 opening report for EC
IEEE 802 JTC1 Standing Committee July 2018 (San Diego) closing report
JTC1 Ad Hoc Sept 2009 Closing Report
November 2013 doc.: IEEE /1381r0 Telecommunications and Information Exchange Between Systems ISO/IEC JTC 1/SC 6 Document Number: 6N15925 Date:
July 2010 doc.: IEEE /0xxxr0 Proposed liaison presentation to SC6 in relation to liaisons between IEEE WG and ISO/IEC JTC1/SC 9 May 2011.
November Session Chair’s Supplementary Material
IEEE 802 JTC1 Standing Committee July 2018 opening report for EC
IEEE 802 JTC1 Standing Committee Mar 2017 closing report
JTC1 Ad Hoc January 2009 Closing Report
September Session Chair’s Supplementary Material
IEEE 802 Process for Interactions with ISO/IEC JTC 1/SC 6 & 7
August 2005 doc.: IEEE /1166r0 Sept 08
July 2010 doc.: IEEE /0735r2 Proposed liaison presentation to SC6 in relation to liaisons between IEEE WG and ISO/IEC JTC1/SC 9 May 2011.
July 2010 doc.: IEEE /0xxxr0 Proposed liaison presentation to SC6 in relation to liaisons between IEEE WG and ISO/IEC JTC1/SC 9 May 2011.
IEEE 802 JTC1 Standing Committee LS Recommendation
IEEE 802 JTC1 Standing Committee March 2012 agenda
IEEE 802 2nd Vice Chair last name at ieee dot org
Response to ISO/IEC JTC1/SC6
IEEE 802 JTC1 Standing Committee March 2019 (Vancouver) closing report
September 2006 September 2006 IEEE 802 LMSC recommendation to ISO/IEC JTC1/SC6 for the review of & related documents 25 September 2006 Version.
September 2006 September 2006 IEEE 802 LMSC recommendation to ISO/IEC JTC1/SC6 for the review of & related documents 4 September 2006 Version.
IEEE 802 JTC1 Standing Committee March 2012 agenda
July 2011 Closing Plenary Motions
July Session Chair’s Supplementary Material
IEEE 802 JTC1 Standing Committee Proposal for SC6 contribution process
JTC1 ad hoc closing report (May11)
July Session Chair’s Supplementary Material
Bob Heile Chair, , Wireless Specialty Networks
November 2010, Motions for the EC
IEEE 802 JTC1 Standing Committee Mar 2017 closing report
IEEE 802 JTC1 Standing Committee July 2018 opening report for EC
Presentation transcript:

July 2010 doc.: IEEE 802.11-10/0xxxr0 IEEE 802 JTC1 Standing Committee Summary of SC6/IEEE 802 agreement issue 13 March 2012 Authors: Andrew Myles, Cisco Andrew Myles, Cisco

The proposal that only IEEE 802 “maintain, alter and extend” ISO/IEC 8802 standards was controversial The IEEE 802 liaison indicated that IEEE 802 would be willing to submit standards (particularly 802.1 and 802.3) to ISO/IEC under certain conditions “…it is essential that ISO/IEC JTC1/SC6 agrees that the responsibility to maintain, alter or extend the functionality of IEEE 802 standards ratified by ISO/IEC remains solely with IEEE 802” This condition was particularly controversial among most NBs The main issue of contention appeared to revolve around the definition of “extend”; many NBs considered a restriction of extensions as limiting SC6’s ability to do their normal work Andrew Myles, Cisco

The SC6 NBs had a variety of objections to the proposed IEEE condition China NB will probably object Stated that they believe it is based on a misinterpretation of “one standard worldwide” Objected to the “alter” and “extend” conditions Suspected it violates anti-trust laws – will need legal advuce Suspected it contradicts ISO/IEC Directives – will need to ask staff UK NB had some concerns Stated it was unreasonable to limit “extensions” by SC6, on the basis that any document that normatively referenced an 8802 standard could be considered an extension Swiss NB had not reviewed Stated they had not seen the liaison in time Andrew Myles, Cisco

SC6 ultimately decided on a process to help resolve issues related to the IEEE 802 proposal Resolution 6.1.4 SC 6 instructs its Secretariat to forward the following liaison statement to IEEE 802: “SC6 appreciates and acknowledges IEEE 802’s proposal (6N15106) for an agreement. SC 6 will forward an initial list of related questions from its NBs and LO to IEEE 802 by 2012-03-09 SC 6 requests a response and a draft MoU from IEEE 802 by 2012-05-01. A second list of questions will be provided to IEEE 802 by 2012-07-01 SC 6 requests a response and updated MoU from IEEE 802 by 2012-08-01.” Approved unanimously Andrew Myles, Cisco

Additional questions were received from two SC6 NBs by the 7 March deadline Questions were received from China NB Questions were received from Swiss NB Andrew Myles, Cisco

The key issue appears to be the proposed limitation on “extensions” Some NB interpreted extensions to mean anything that normatively referenced an ISO/IEC 8802 standard ie anything that relied on an ISO/IEC 8802 standard This probably was not the intent of the IEEE 802.1 and 802.3 WGs given that they would presumably like their standards to be used and referenced by other standards in the normal way This suggests a tighter definition of “extend” is required to: Meet the needs of IEEE 802.1 and 802.3 WGs Mitigate the concerns of SC6 NBs Andrew Myles, Cisco

The WAPI experience provides a good base on which to understand & define “extend” Many people objected to WAPI for many reasons; one major objection was that it replaced integral elements of the IEEE 802.11 specification In particular, it did so by making changes to the IEEE 802.11 standard in an uncontrolled way eg WAPI made changes to element IDs, status codes and error codes without any reference to the IEEE 802.11 ANA eg the WAPI spec made changes to parts of the standards that were never intended to be changed by SDOs other than IEEE 802.11 This process would have diminished the ongoing integrity of IEEE 802.11 by spreading the specification into multiple documents, under the control of different SDOs The key problem with WAPI is that it made changes to IEEE 802.11 by using internal, and sometimes undefined, interfaces in IEEE 802.11; it did not use external, well defined interfaces! Andrew Myles, Cisco

An “extension” could be defined as any specification that relies on 802 internal interfaces An external interface is one that is explicitly defined for interfacing with other standards eg MAC SAP (802.11-2012, 5.2) eg MLME SAP (802.11-2012, 6.3) An internal interface is one that is not an external interface An “extension” to an IEEE 802 standard could then be defined as a specification that uses an internal interface of the IEEE 802 standard This definition should make most parties happy The UK NBs concern should be mitigated because appropriate normative referencing is possible The IEEE 802.1 and 802.3 WG’s fears should be mitigated because they would retain sole responsibility for their standards The China NB’s concerns may or may not be mitigated Andrew Myles, Cisco

Could IEEE 802 object, using the proposed conditions, to: A constraint on “extensions” to IEEE 802 standards will not allow IEEE 802 to object to replacements in SC6 ISO/IEC JTC1/SC6 is an independent SDO and should generally not be restricted from doing work that does not “maintain, alter or extend” IEEE 802 standards This means that SC6 would be free to define complete replacements for IEEE 802 standards and long as they did not “alter or extend” them Could IEEE 802 object, using the proposed conditions, to: EUHT, which is a competitor to 802.11ac No TLSec and TePA-AC , which are competitors to 802.1X/AE No UHT, which is an extension of 802.11n Yes WAPI, which is an extension to 802.11 Yes Andrew Myles, Cisco

IEEE 802 JTC1 SC has recommended answers to SC6 questions and a draft agreement Motion The IEEE 802 JTC1 SC recommends to IEEE 802 EC that: Pages 52-64 of 0299r6 be liaised to SC6 as responses to the questions from SC6 in N15226 and N15227, pending review and modification by IEEE SA of the answer to the question on page 63 The draft agreement on page 72 of 0299r6 be liaised to SC6 Bruce Kraemer be given authority to make editorial changes before arranging for the liaison of the final versions of the answers and draft agreement Moved: Mike Montemurro Seconded: Dorothy Stanley Vote: 7/0/0 (motion passes) Note: the page numbers refer to 11/12-0299r6; the page numbers in following slides are in top left corner Andrew Myles, Cisco

The IEEE 802 developed a draft SC6/IEEE 802 agreement IEEE 802 and SC6 agree that: Best practice indicates a single SDO should have responsibility for developing or maintaining a standard, albeit in cooperation with all relevant stakeholders IEEE 802 will have sole responsibility for developing, maintaining, altering and extending all IEEE 802 standards and any ISO/IEC 8802 equivalents An extension is defined as functionality that makes use of internal interfaces in an IEEE 802 standard not intended for use by other SDOs SC6 may request clarification from IEEE 802 as to whether a particular interface in an IEEE 802 standard is an internal interface SC6 may request that IEEE 802 define any external interfaces required to enable SC6 to define additional functionality for ISO/IEC 8802 standards IEEE 802 will consult with SC6 as necessary to produce IEEE 802 standards and their ISO/IEC 8802 equivalents that reflect the needs of a broad range of stakeholders Andrew Myles, Cisco

S52 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Question from Swiss NB At what stage(s) and for what comment period will the IEEE 802 group provide drafts for comment, and how will IEEE handle the comments resolution? Answer from IEEE 802 For standards that are going to be submitted to ISO/IEC JTC1 for fast-track adoption under the PSDO agreement, the IEEE 802 WGs will provide drafts to SC6 as soon as those drafts are sent to IEEE Sponsor Ballot. This is the process that has been used by IEEE 802.11 WG over the last year or so. In some cases, the IEEE 802 WGs may provide drafts to SC6 at earlier stages of their development cycle. ... continued Andrew Myles, Cisco

S52 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Answer from IEEE 802 (continued) IEEE 802 WGs are required to consider and resolve comments on drafts received from any source. It is more likely any comments will have an impact on the draft development if they are provided within the IEEE Sponsor Ballot timeframes. However, the IEEE 802 WGs will also consider and resolve comments received after these deadlines. If comments are received too late to be considered during the development of a standard then they will be considered during the maintenance process. Andrew Myles, Cisco

S53 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Question from Swiss NB Does the IEEE 802 group grant SC6 the right to develop standards competing with and making reference to IEEE 802 standards? Answer from IEEE 802 IEEE 802 has no position on granting any rights to other SDOs. However, IEEE 802 would like agreement that SC6 will not develop standards that maintain, alter or extend existing IEEE 802 standards. In this context “extend” means to define functionality that makes use of internal interfaces in the IEEE 802 standards. These internal interfaces were never intended to support parallel changes by multiple SDOs. ... continued Andrew Myles, Cisco

S53 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Answer from IEEE 802 (continued) The restriction on maintenance, alterations and extensions is beneficial to the entire industry because it promotes the ongoing integrity of IEEE 802 standards by focusing ongoing development in a single SDO, thus supporting continuing interoperability. Of course, IEEE 802 has no objections to any SDO defining new functionality and standards that reference IEEE 802 standards in a way that makes use of the external interfaces to IEEE 802 standards. These interfaces were defined for exactly this purpose. SC6 is encouraged to ask IEEE 802 for clarification as to whether a particular interface is internal or external. SC6 may also request that IEEE 802 define any external interfaces required to enable work in SC6 Andrew Myles, Cisco

S54 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Question from Swiss NB How shall project editors for IEEE 802 standards in the scope of SC6 submitted to ISO be installed to conform to IEEE requirements as well as to the ISO/IEC Directives and the JTC1 Supplements? Answer from IEEE 802 IEEE 802 will submit IEEE 802 standards for ISO/IEC ratification using the PSDO fast track process. Under this process no technical or maintenance work is required in SC6; therefore there is no need for an SC6 Project Editor to be appointed. An ISO/IEC staff editor is responsible for the publication process. Andrew Myles, Cisco

S55 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Question from Swiss NB Would the IEEE 802 group be ready to comment on New Work Item Proposals and standard drafts received from SC6? Answer from IEEE 802 Yes, IEEE 802 is always ready to comment on any documents received from SC6 within the scope of IEEE 802. In recent times, IEEE 802 has demonstrated its willingness to comment on SC6 documents on multiple occasions including documents related to: WAPI TLSec TePA-AC UHT/EUHT Andrew Myles, Cisco

S56 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Question from Swiss NB Would the IEEE 802 group be ready to participate to joint Study Groups and projects? Answer from IEEE 802 IEEE 802 is always willing to work with other SDOs, including SC6, in joint study groups or projects where it provides value for all parties. However, evaluations of value must be undertaken based on the merits of each proposal. Andrew Myles, Cisco

S57 The IEEE 802 JTC1 SC will discuss possible answers to the SC6 in relation to the proposed agreement Question from China NB Will IEEE agree to state in the agreement that SC6 may propose to revise the ISO/IEC standards originated in IEEE? Answer from IEEE 802 Note: this question is answered from the perspective of IEEE 802 and not IEEE. Under the PSDO agreement between ISO and IEEE, SC6 is able to make a proposal to revise an ISO/IEC 8802 standard derived from an IEEE 802 standard. On this basis, there is no need to reiterate this possibility in any new agreement between SC6 and IEEE 802. ... continued Andrew Myles, Cisco

S57 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Answer from IEEE 802 (continued) However, IEEE 802 is unlikely to agree to any proposal for SC6 to revise an ISO/IEC 8802 standard because we believe it is better for IEEE 802 revisions and their ISO/IEC 8802 equivalents to be developed within IEEE 802 using our normal processes. We note that under the PSDO, copyright permission would be required from IEEE before SC6 could undertake any revision independently Andrew Myles, Cisco

S58 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Question from China NB Document 6N15106 requests that the right to “extend the functionality of IEEE 802 standards ratified by ISO/IEC remains solely with IEEE 802. What does it mean to “extend the functionality?” Please provide examples and consider how this clause would impact on technology innovation and the principle of open standards. Answer from IEEE 802 IEEE 802 is requesting that SC6 does not “extend the functionality of IEEE 802 standards”. IEEE 802 defines an “extension” as additional functionality that makes use of internal interfaces in the IEEE 802 standards. These internal interfaces were never intended to support changes by multiple SDOs. ... continued Andrew Myles, Cisco

S59 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Answer from IEEE 802 (continued) Other SDOs are encouraged to make use of external interfaces in IEEE 802 standards. For example, an external interface in IEEE 802.11 is the MAC SAP SC6 is encouraged to ask IEEE 802 for clarification as to whether a particular interface is an external interface. SC6 may also request IEEE 802 to define additional external interfaces to enable work in SC6.. WAPI is an example of an “extension” that requires the use of internal IEEE 802.11 interfaces and so falls within the responsibility of IEEE 802. EUHT and TLSec would probably be defined as independent competitors to existing IEEE 802 standards and thus would not be covered by the proposed agreement. The restriction on SC6 developing extensions of IEEE 802 standards has no impact on innovation because the innovations can still occur within IEEE 802’s open and transparent standards development process. Andrew Myles, Cisco

S60 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Questions from China NB Would IEEE believe that other ISO/IEC member bodies would enjoy the same rights claimed by IEEE? Answer from IEEE 802 Note: this question is answered from the perspective of IEEE 802. IEEE 802 is asserting the sole responsibility to maintain, alter and extend standards developed by IEEE 802. This is consistent with the widely understood best practice that a single organisation should have sole responsibility for developing or maintaining standards, albeit in cooperation with other stakeholders. This principle supports the ongoing integrity of the standard. Andrew Myles, Cisco

S61 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Question from China NB Will IEEE object to ISO/IEC standard and project proposals making normative references to ISO/IEC standards originated from IEEE (IIIS)? Answer from IEEE 802 Note: this question is answered from the perspective of IEEE 802 IEEE 802 encourages any SDO or other organisation to make normative references to ISO/IEC 8802 standards derived from IEEE 802 standards. However, in making such references, those SDOs and other organisations should respect the ongoing integrity of the standards by only using the interfaces defined in the standards that are intended for external use. SC6 is encouraged to ask IEEE 802 for clarification as to whether a particular interface is internal or external. SC6 may also request IEEE 802 to define any external interfaces required to enable work in SC6. Andrew Myles, Cisco

S62 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Question from China NB Will IEEE allow ISO/IEC standards to make normative references to IEEE only standards that have not and will not be submitted to ISO/IEC for international standardization? Answer from IEEE 802 Note: this question is answered from the perspective of IEEE 802. IEEE 802 encourages ISO/IEC to make normative references to IEEE 802 standards. However, in making such references, ISO/IEC should respect the ongoing integrity of the IEEE 802 standards by only using the interfaces defined in the IEEE 802 standards that are intended for external use. SC6 is encouraged to ask IEEE 802 for clarification as to whether a particular interface is internal or external. SC6 may also request IEEE 802 to define any external interfaces required to enable work in SC6.. Andrew Myles, Cisco

S63 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Question from China NB Can national standards adopt IEEE originated ISO/IEC standards into national standards with modifications for suit for local needs? Answer from IEEE 802 Note: this question is answered from the perspective of IEEE 802 ISO/IEC member bodies may adopt ISO/IEC 8802 standards modified to suit local needs as national standards. However, such national standards cannot be considered or proposed as international standards without permission from the IEEE. They must also maintain the IEEE copyright notices in the national standard version. It is worthwhile noting that the IPR statements made to IEEE in relation to the IEEE 802 standard will not apply to the modified national standard. Andrew Myles, Cisco

S64 The IEEE 802 JTC1 SC developed answers to the SC6 in relation to the proposed agreement Question from China NB What would IEEE do if IEEE’s standards in development are found having contradictions with existing ISO/IEC standards? Answer from IEEE 802 Note: this question is answered from the perspective of IEEE 802 “Contradictions” is not defined clearly in the ISO/IEC Directives and so the IEEE 802 are unable to comment on this aspect of the question. We would appreciate clarification of the question. Andrew Myles, Cisco