idnits 2.17.1 draft-dawkins-iab-rfc4441rev-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 19, 2012) is 4136 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 924 == Missing Reference: 'RFC4181' is mentioned on line 1040, but not defined == Missing Reference: 'RFC4663' is mentioned on line 1048, but not defined == Missing Reference: 'I-D ETHERNET-MIB-TRANSFER' is mentioned on line 1049, but not defined == Unused Reference: 'RFC5226' is defined on line 1012, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4441 (Obsoleted by RFC 7241) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board S. Dawkins, Ed. 3 Internet-Draft Huawei 4 Obsoletes: 4441 (if approved) P. Thaler 5 Intended status: Informational Broadcom 6 Expires: June 22, 2013 December 19, 2012 8 The IEEE 802 / IETF Relationship 9 draft-dawkins-iab-rfc4441rev-02.txt 11 Abstract 13 This document describes the standardization collaboration between 14 Project 802 of the Institute of Electrical and Electronic Engineers 15 (IEEE 802) and the Internet Engineering Task Force (IETF). This 16 document obsoletes RFC 4441. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 22, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Table of Contents 49 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4 50 2. Guidance on Collaboration . . . . . . . . . . . . . . . . . . 5 51 2.1. Organization, Participation and Membership . . . . . . . . 5 52 2.1.1. IEEE 802 Organization, Participation and Membership . 5 53 2.1.2. IETF Organization, Participation and Membership . . . 7 54 2.1.3. Cultural Differences . . . . . . . . . . . . . . . . . 8 55 2.2. Exchange of Information About Work Items . . . . . . . . . 10 56 2.2.1. How IEEE 802 is informed about active IETF work 57 items . . . . . . . . . . . . . . . . . . . . . . . . 10 58 2.2.2. How IETF is informed about active IEEE 802 work 59 items . . . . . . . . . . . . . . . . . . . . . . . . 10 60 2.2.3. How IEEE 802 is informed about proposed new IETF 61 work items . . . . . . . . . . . . . . . . . . . . . . 11 62 2.2.4. How IETF is informed about proposed new IEEE 802 63 work items . . . . . . . . . . . . . . . . . . . . . . 11 64 2.2.5. Other Mechanisms for Coordination . . . . . . . . . . 12 65 2.3. Document Access . . . . . . . . . . . . . . . . . . . . . 12 66 2.3.1. IEEE 802 Documentation System . . . . . . . . . . . . 12 67 2.3.2. Access to IETF Documents . . . . . . . . . . . . . . . 15 68 2.4. Participation in Document Review and Approval . . . . . . 15 69 2.4.1. IEEE 802 draft review and balloting processes and 70 opportunities for IETF participation . . . . . . . . . 15 71 2.4.2. IETF draft review and balloting processes and 72 opportunities for IEEE 802 participation . . . . . . . 17 73 2.5. Expert Review Processes . . . . . . . . . . . . . . . . . 18 74 2.6. Liaison Officials/Liaison Managers and Liaison 75 Statements . . . . . . . . . . . . . . . . . . . . . . . . 18 76 2.6.1. Liaison Officials/Liaison Managers . . . . . . . . . . 19 77 2.6.2. Liaison Statements . . . . . . . . . . . . . . . . . . 19 78 3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 20 79 4. Cross-Referencing Documents in IEEE 802 and IETF . . . . . . . 21 80 5. Protocol Parameter Allocation . . . . . . . . . . . . . . . . 22 81 5.1. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 5.2. IEEE Registration Authority . . . . . . . . . . . . . . . 22 83 5.3. IEEE Registration at IEEE working group level . . . . . . 23 84 5.4. Pointers to Additional Useful Information . . . . . . . . 23 85 5.4.1. IEEE 802 Information that may be useful to IETF 86 participants . . . . . . . . . . . . . . . . . . . . . 23 87 5.4.2. IETF Information that may be of use to IEEE 802 88 participants . . . . . . . . . . . . . . . . . . . . . 23 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 96 Appendix A. Current examples of this relationship . . . . . . . . 29 97 A.1. MIB Review . . . . . . . . . . . . . . . . . . . . . . . . 29 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 100 1. Introduction and Scope 102 This document provides non-normative guidance to aid in the 103 understanding of collaboration on standards development between 104 Project 802 of the Institute of Electrical and Electronics Engineers 105 (IEEE) and the Internet Engineering Task Force (IETF) of the Internet 106 Society (ISOC). Early identification of topics of mutual interest 107 will allow for constructive efforts between the two organizations 108 based on mutual respect and cooperation. 110 EDITOR'S NOTE: This version of the draft has references sections that 111 are both incomplete and bogus - I'm showing most of the references as 112 inline hyperlinks. I'll clean this up soon. 114 2. Guidance on Collaboration 116 This section describes how existing processes within the IETF and 117 IEEE 802 may be used to enable collaboration between the 118 organizations. 120 2.1. Organization, Participation and Membership 122 IEEE 802 and IETF are similar in some ways, but different in others. 123 When working on projects that are of interest to both organizations, 124 it's important to understand these similarities and differences. 126 2.1.1. IEEE 802 Organization, Participation and Membership 128 The IEEE Standards Association (IEEE-SA) is the standards setting 129 body of the IEEE. The IEEE-SA Standards Board oversees the IEEE 130 standards development process. IEEE 802 LAN/MAN Standards Committee 131 is a sponsor developing standards for networking under the IEEE-SA 132 Standards Board. 134 In IEEE 802, work is done in Working Groups operating under an 135 Executive Committee. Most Working Groups have one or more Task 136 Groups. A Task Group is responsible for a project or group of 137 projects. Each Working Group is led by a Working Group Chair. 139 The Executive Committee is comprised of the Executive Committee 140 Chair, Executive Committee Officers (e.g. Vice-Chairs, Secretaries, 141 Treasurer) and Working Group Chairs. 143 A good place to to learn more is the IEEE 802 Home Page, at 144 http://www.ieee802.org/. An IEEE 802 Orientation for new 145 participants that gives an overview of IEEE 802 process is available 146 from the home page. 148 The IEEE 802 Executive Committee and all Working Groups meet three 149 times per year at plenary sessions. Plenary sessions are held in 150 March, July and November. Most Working Groups hold interim meetings, 151 usually in January, April and September. The meeting schedule can be 152 found at http://www.ieee802.org/meeting/index.html. 154 A Study Group is a group formed to consider starting a new project 155 and, if new work is found to be suitable, to develop an IEEE Project 156 Authorization Request (PAR - similar in purpose to an IETF working 157 group charter). A Study Group may operate under a Working Group or 158 under the Executive Committee depending on whether the new work under 159 consideration falls within the scope of an existing Working Group. 160 Study Groups are expected to exist for a limited time, usually for 161 one or two plenary cycles, and must be authorized to continue at each 162 plenary if they have not completed their work. 164 Participation in IEEE 802 Working Groups is at the level of 165 individuals, i.e. participants are human beings and not companies, 166 and is open. Individuals are required to declare their affiliation 167 (i.e. any individual or entity that financially or materially 168 supports the individual's participation in IEEE 802). 170 Working Groups maintain membership rosters, with voting membership 171 attained on the basis of in-person meeting attendance. Retention of 172 voting membership generally requires continued attendance and 173 responsiveness to letter ballots. Voting membership allows one to 174 vote on motions and on Working Group Ballots of drafts. All drafts 175 are also balloted by a Sponsor Ballot pool before approval as 176 standards. Joining a Sponsor Ballot pool does not require 177 participation in meetings. One does not need to be a voter to 178 comment on drafts and the Working Group is required to consider and 179 respond to all comments submitted during Working Group and Sponsor 180 ballots. 182 To foster ongoing communication between IEEE 802 and IETF, it is 183 important to identify and establish contact points within each 184 organization. Contact points on the IEEE side may include: 186 IEEE Working Group Chair: An IEEE Working Group chair is an 187 individual who is assigned to lead the work of IEEE in a 188 particular area. IEEE Working Group chairs are elected by 189 the Working Group and confirmed by the Executive Committee 190 for a 2 year term. Collaboration here is provides a stable 191 contact point for work between the two organizations for a 192 given topic. 194 IEEE Task Group (or Task Force) Chair: An IEEE Task Group chair is 195 an individual who is assigned to lead the work on a 196 specific project or group of projects within a Working 197 Group. Task Group Chairs often serve for the duration of a 198 project. Collaboration here is beneficial to ensure that 199 work on a particular project is coordinated. 201 IEEE Study Group Chair: An IEEE Study Group Chair is an individual 202 assigned to lead consideration of new work and development 203 of an IEEE Project Authorization Request (PAR). 204 Collaboration here is useful for providing input on the 205 scope of new work and to begin coordination. 207 IEEE Liaisons: It may be beneficial to establish liaisons as 208 additional contact points for specific topics of mutual 209 interest. These contact points should be established early 210 in the work effort. The IEEE and IETF projects may select 211 the same individual as their contact point, but this is not 212 required, so that two individuals each serve as contact 213 points for one project participating in the liaison 214 relationship. 216 Informal Contact points: Other informal contacts can provide useful 217 collaboration points. These include project editors who 218 are responsible for editing the drafts and work with the 219 Task Group Chairs to lead tracking and resolution of 220 issues. Joint members who are active in both the IEEE and 221 IETF projects in an area can also aid in collaboration. 223 2.1.2. IETF Organization, Participation and Membership 225 In the IETF, work is done in working groups (WGs), mostly through 226 open, public mailing lists rather than face-to-face meetings. WGs 227 are organized into areas, each area being managed by two co-area 228 directors. Collectively, the area directors comprise the Internet 229 Engineering Steering Group (IESG). 231 IETF meets in plenary session three times per year. Some working 232 groups have additional interim meetings, which may be either face-to- 233 face or "virtual", but this is not true for most IETF working groups, 234 at any given time. The goal is to do work on mailing lists, 235 reserving face-to-face sessions for topics that have not been 236 resolved through previous mailing list discussion. Information about 237 plenary meetings is available at 238 http://www.ietf.org/meeting/upcoming.html. Information about working 239 group interim meetings is available on the IETF-Announce mailing list 240 (see http://www.ietf.org/list/announcement.html) for archives and 241 subscription information). 243 Participation in the IETF is open to anyone (technically, anyone with 244 access to e-mail sufficient to allow subscription to one or more IETF 245 mailing lists). All IETF participants act as individuals. There are 246 a small number of IETF procedures that recognize organizations that 247 may sponsor IETF participants, but these are organizational and do 248 not apply to the standard specification process itself. There is no 249 concept of "IETF membership". 251 A good place to to learn more is the IETF Home Page, at 252 http://www.ietf.org/, and especially the "About the IETF" page at 253 http://www.ietf.org/about, selectable from the IETF Home Page. 255 To foster ongoing communication between IEEE 802 and IETF, it is 256 important to identify and establish contact points within each 257 organization. Contact points on the IETF side may include: 259 IETF Area Director: An IETF area director is the individual 260 responsible for overseeing a major focus of activity (an 261 "Area"). These positions are relatively long- term (of 262 several years) and offer the stability of contact points 263 between the two organizations for a given topic. 265 IETF Working Group Chair: An IETF working group chair is an 266 individual who is assigned to lead the work on a specific 267 task within one particular area. These positions are 268 working positions (of a year or more) that typically end 269 when the work on a specific topic ends. Collaboration here 270 is very beneficial to ensure the actual work gets done. 272 Other Contact Points: It may be beneficial to establish additional 273 contact points for specific topics of mutual interest. 274 These contact points should be established early in the 275 work effort, and in some cases the contact point identified 276 by each organization may be the same individual. 278 Note: The current list of IETF area directors and working group 279 chairs can be found in the IETF working group charters, at 280 http://datatracker.ietf.org/wg/. 282 2.1.3. Cultural Differences 284 It's worth noting that IEEE 802 and IETF have cultures that are 285 similar, but not identical. Some of the differences include: 287 IEEE 802 Working Groups and IETF Working Groups: Both IEEE 802 and 288 IETF use the term "Working group", but "working groups" 289 means two very different things in the two organizations. 290 IEEE 802 working groups are large, long-lived, and 291 relatively broadly scoped. IEEE 802 working groups are 292 more similar to IETF Areas than to IETF working groups, 293 which tend to be short-lived and narrowly chartered. 295 Consensus and Rough Consensus: Both organizations make decisions 296 based on consensus, but in the IETF, "consensus" means 297 "rough consensus". In practice, this means that a large 298 part of the community being asked needs to agree. Not 299 everyone has to agree, but if you disagree, you'll need to 300 convince other people of your point of view. If you're not 301 able to do that, you'll be "in the rough" when "rough 302 consensus" is declared. 304 Rough Consensus and Running Code: David Clark coined the phrase "we 305 believe in rough consensus and running code" in 1992, to 306 explain IETF culture. Although that's not always true 307 today, the existence of "running code" as a proof of 308 feasibility for a proposal often carries weight during 309 technical discussions. IEEE 802 standards may be less 310 amenable to one-off implementation, whether as hardware or 311 as software. 313 Voting: Both organizations use voting as a decision-making tool, 314 but IEEE 802 uses voting within working groups, while IETF 315 working groups do not. The IESG does ballot documents when 316 considering them for publication, and working group chairs 317 may ask for a "show of hands" or "take a hum" to judge 318 backing for a proposal, but IETF working groups don't vote. 320 Balance between mailing lists and meetings: Both organizations make 321 use of mailing lists, but IETF working groups really can't 322 get anything done without mailing lists, which is where 323 work can continue between formal meetings. The IETF 324 requires all decisions to be made (or, often in practice, 325 confirmed) on mailing lists - final decisions aren't made 326 in meetings. It's also worth noting that IETF working 327 group sessions are much shorter than IEEE 802 working group 328 sessions - it's not unusual for an IETF working group to 329 meet once or twice in a plenary meeting, for a maximum of 330 two and a half hours per session. Some working groups may 331 not meet at all in plenary, and others may have a single 332 one-hour session. 334 Interim meetings: Both organizations use interim meetings (between 335 plenary meetings), but this is more common for IEEE 802 336 working groups than for IETF working groups, which schedule 337 interim meetings on an as-needed basis. While the IETF 338 interim meetings may be face-to-face or virtual, the IEEE 339 802 interim meetings are face-to-face only. Many IEEE 802 340 WGs hold regularly interim meetings three times a year in 341 the middle of the intervals between the Plenary meetings. 342 The schedules and location of these meetings are typically 343 known many months in advance. 345 Remote participation: Because the IETF doesn't make decisions at 346 face-to-face meetings, it's not strictly necessary to 347 attend face-to-face meetings at all! Some significant 348 contributors don't attend most face-to-face IETF meetings, 349 although if you want to find collaborators on a proposal 350 for new work, or solicit backing for your ideas, you'll 351 probably find that easier in a face-to-face conversation, 352 often in a hallway and sometimes in a bar. IEEE 802 353 significant contributors almost always attend face-to-face 354 meetings. Participation in IEEE 802 meetings is a 355 condition for WG membership. 357 Working group autonomy: Both IEEE 802 and IETF allow working groups 358 considerable autonomy (within the documented process) in 359 getting work done. It's worth noting that there may be 360 differences between two IEEE 802 working groups, or between 361 two IETF working groups, in addition to differences between 362 an IEEE 802 working group and an IETF working group. 364 2.2. Exchange of Information About Work Items 366 The following sections outline a process that can be used to enable 367 each group to be informed about the other's active and proposed new 368 work items. 370 2.2.1. How IEEE 802 is informed about active IETF work items 372 The responsibility is on individual IEEE 802 working groups to review 373 the current IETF working groups to determine if there are any topics 374 of mutual interest. Working group charters and active Internet- 375 Drafts can be found on the IETF web site 376 (http://datatracker.ietf.org/wg/). If an IEEE 802 working group 377 identifies a common area of work, the IEEE 802 working group 378 leadership should contact both the IETF working group chair and the 379 area director(s) responsible. This may be accompanied by a formal 380 liaison statement (see Section 2.6.2). 382 2.2.2. How IETF is informed about active IEEE 802 work items 384 IEEE Working Group status reports are published at the beginning and 385 end of each plenary at http://ieee802.org/minutes on the IEEE 802 386 website. Each Working Group includes a list of their active projects 387 and the status. 389 The charter of an IEEE 802 project is defined in an approved Project 390 Authorization Request (PAR). PARs are accessible in IEEE Standards 391 myProject, at https://development.standards.ieee.org/my-site. Access 392 requires an IEEE web account which is free and has no membership 393 requirement. 395 In myProject, a search on "View Active PARs" for 802 will bring up a 396 list of all active IEEE 802 PARs. 398 The responsibility is on individual IETF working groups to 399 periodically review the information on the IEEE 802 web site to 400 determine if there is work in progress of mutual interest. 402 If an IETF working group identifies a common area of work or a need 403 for coordination, the working group leadership should contact the 404 IEEE 802 Working Group chair and Task Group chair. This may be 405 accompanied by a formal liaison statement (see Section 2.6.2). 407 2.2.3. How IEEE 802 is informed about proposed new IETF work items 409 The IETF maintains a mailing list for the distribution of proposed 410 new work items among standards development organizations. Many such 411 items can be identified in proposed Birds-of-a-Feather (BOF) 412 sessions, as well as draft charters for working groups. The IETF 413 forwards all such draft charters for all new and revised working 414 groups and BOF session announcements to the IETF new-work mailing 415 list. An IEEE 802 mailing list is subscribed to this list. 416 Leadership of the IEEE working groups may subscribe to this IEEE 802 417 mailing list, which is maintained by the Executive Committee (EC). 419 Each IEEE 802 Working Group will delegate at least one expert to 420 subscribe to this list and be ready to dispatch any information 421 relevant for their activity. This will enable the IEEE 802 working 422 groups to monitor the new work items for possible overlap or interest 423 to their IEEE 802 working group. It is expected that this mailing 424 list will see a few messages per month. 426 Each IEEE 802 working group chair, or designated representative, may 427 provide comments on these charters by responding to the IESG mailing 428 list at iesg@ietf.org clearly indicating their IEEE 802 position and 429 the nature of their concern. Plain-text email is preferred on the 430 IESG mailing list. 432 It should be noted that the IETF turnaround time for new working 433 group charters can be as short as two weeks. As a result, the IETF 434 Announce mailing list should be monitored consistently. 436 2.2.4. How IETF is informed about proposed new IEEE 802 work items 438 An IEEE project is initiated by approval of a Project Authorization 439 Request (PAR) which includes a description of the scope of the work. 440 Any IEEE 802 PARs which introduce new functionality are required to 441 be available for review no less than 30 days prior to the Monday of 442 the IEEE 802 plenary session where they will be considered. 444 IEEE considers Five Criteria when deciding whether to approve new 445 work: Broad Market Potential, Compatibility, Distinct Identity, 446 Technical Feasibility and Economic Feasibility. The criteria are 447 defined in the IEEE 802 LAN/MAN Standards Committee (LMSC) Operations 448 Manual. The PARs are accompanied by responses on the 5 Criteria. 450 Each Area Director shall ensure that at least one person is 451 designated to periodically review relevant PAR and 5 Criteria 452 information to determine if there is proposed work of mutual 453 interest. 455 Any comments on proposed PARs should be submitted to the Working 456 Group chair and copied to the Executive Committee chair by e-mail not 457 later than 5:00 PM Tuesday of the plenary session (in the time zone 458 where the plenary is located). 460 2.2.5. Other Mechanisms for Coordination 462 From time to time, IEEE 802 and IETF may agree to use additional 463 mechanisms for coordination between the two groups. 465 Examples of such mechanism are periodic conference calls between the 466 representatives of the IETF and IEEE 802 leadership teams, and 467 working documents that list the areas of shared interests between the 468 two organizations, status and action items relative to these areas. 469 At the time of writing, such a document was maintained and included 470 about 20 topics being actively discussed, with more expected. Such 471 documentation helps focusing on principles and not trying to design a 472 complete process for each topic. 474 2.3. Document Access 476 During the course of IEEE 802 and IETF collaboration, it is important 477 to share internal documents among the technical working groups. In 478 addition, draft standards, Internet Drafts, and RFCs may also be 479 distributed. 481 2.3.1. IEEE 802 Documentation System 483 Each IEEE 802 standardization project is assigned to a Working Group 484 (WG) for development. In IEEE 802, the working methods of the WGs 485 vary in detail. The documentation system is one area in which WG 486 operations differ, based on varying needs and traditions. In some 487 cases, the WGs assign the core development to a subgroup (typically 488 known as a Task Group or Task Force), and the documentation 489 procedures may vary among the subgroups as well. Prior to project 490 authorization, or on topics not directly related to development of a 491 standard, the WG may consider and develop documents itself, or using 492 other subgroups (standing committees, ad hocs, etc.). 494 IEEE 802 also supports Technical Advisory Groups (TAGs) that conduct 495 business and develop documents, although not standards. References 496 here to WGs apply to TAGs as well. 498 In addition to allowing IETF participants to access documentation 499 resources within IEEE 802, IEEE 802 can also make selected IEEE 802 500 documents at any stage of development available to the IETF by 501 attaching them to a formal liaison statement. Although a 502 communication can point to a URL where a non-ASCII document (e.g., 503 Word) can be downloaded, attachments in proprietary formats to an 504 IETF mailing list are discouraged. 506 2.3.1.1. The role of the IEEE 802 Documentation System in document 507 development 509 In general, development of standards is IEEE 802 is contribution- 510 driven. Content toward draft standards is submitted to WGs by 511 individual participants, or groups of participants. Content toward 512 other group documents (such as, for example, external communication 513 statements or foundation documents underlying a draft standard) might 514 also be contribution-driven. At some point, the group assembles 515 contributed material to develop group documents, and revision takes 516 place within group meetings or by assignment to editors. For the 517 most part, the contributions toward discussion as well as the group 518 documents (including minutes and other reports) are openly available 519 to the public. 521 2.3.1.2. Access to internal IEEE 802 Working Group Documents 523 Many IEEE 802 groups use a documentation system provided by IEEE and 524 known as "Mentor". The list of these groups is available at the IEEE 525 802 Mentor Home Page: https://mentor.ieee.org/802". Mentor has some 526 particularly notable aspects: 528 EDITOR'S NOTE: We had a suggestion to trim some of this information. 529 Pat to consider and provide revised text. 531 1. The documentation system is structured and ordered, with 532 documentation tags and unique numbering and revisioning. 534 2. On-line documentation is available. 536 3. Generally speaking, the archives are publicly and freely 537 available. 539 4. Limited search functionality is provided, and publicly-available 540 search engines index the data. 542 5. The ability to submit documents to Mentor is limited but is 543 generally available to any interested party. An IEEE Account is 544 required but can be easily and freely established using the IEEE 545 Account Request page, at 546 http://www.ieee.org/go/create_web_account. If submission is 547 protected, the privilege can be requested via the Mentor system 548 (using the "Join group" link on each WG Mentor page) and would 549 typically be granted by the WG documentation manager in a manual 550 approval. 552 6. Submitted documents are immediately available to the general 553 public at the same instant they become available for 554 consideration by the group. 556 In most cases, WGs that use the Mentor system use it exclusively, so 557 that any substantive document will be available through the system. 558 In a few cases (for example, the IEEE 802 Executive Committee), 559 document distribution is by multiple means (including an email 560 reflector), so it may be difficult to compile a complete set of 561 documents. 563 Some WGs do not use the Mentor system. In this case, documents are 564 nevertheless generally publically available and indexed. Typically, 565 the index may be presented via a human-managed web site. In such 566 cases, the contributions may be submitted via email to a document 567 manager, so they may not be immediately available to the public. For 568 WGs not using the Mentor system, it should be relatively 569 straightforward to find documents of interest by reviewing the 570 group's main web page. These web page addresses follow this 571 convention: the IEEE 802.1 main web page is at http://ieee802.org/1, 572 while the IEEE 802.11 main web page is at http://ieee802.org/11 - in 573 other words, the one-digit or two- digit numerical desigation for the 574 WG or TAG appears as the "path" in the URL. 576 In some cases, links to documents may be available only by reviewing 577 the WG or subgroup meeting minutes. 579 2.3.1.3. Submission of Contributions to IEEE 802 Working Groups 581 IEEE 802 Working Groups are open to contribution. In many cases, a 582 WG or subgroup will issue a call for contributions with a specific 583 technical solicitation, including deadlines and submission 584 instructions. Some groups maintain specific submission procedures 585 and specify a contribution cover sheet to clarify the status of the 586 contribution. 588 2.3.1.4. Access to IEEE 802 Working Group Drafts 590 The IEEE owns the copyright to draft standards developed within IEEE 591 standardization projects. As a result, such drafts are never made 592 publicly available. The IEEE-SA grants permission for an IEEE draft 593 standard to be distributed without charge to the participants for 594 that IEEE standards development project. Typically, such 595 distribution is on the Internet under password protection, with the 596 password provided to members of the participating WG. Requests to 597 the relevent WG chair for access to a draft for purposes of 598 participation in the project are typically granted. 600 2.3.1.5. Access to IEEE 802 Standards 602 IEEE standards, once approved, are published and made available for 603 sale. They can be purchased from the IEEE Standards Store, at 604 http://www.techstreet.com/ieeegate.html. They are also available 605 from other outlets, including the IEEE Xplore digital library, at 606 http://ieeexplore.ieee.org. 608 The Get IEEE 802 program, at http://standards.ieee.org/about/get, 609 grants public access to download individual IEEE 802 standards at no 610 charge. IEEE 802 standards are added to the Get IEEE 802 program six 611 months after publication. 613 2.3.2. Access to IETF Documents 615 IETF Internet-Drafts may be located using IETF "Datatracker" inteface 616 at https://datatracker.ietf.org, or via the IETF tools site at 617 http://tools.ietf.org. RFCs may be located at either of the above, 618 or at via the RFC Editor site at http://www.rfc-editor.org. 620 It should be recognized that the official/athoritative versions of 621 all IETF documents are in ASCII. 623 2.4. Participation in Document Review and Approval 625 EDITOR'S NOTE: we discussed moving part of this section to Expert 626 Review. That's not a small change, so I'll wait until people have a 627 chance to think about it, before proposing text. 629 During the course of IEEE 802 and IETF collaboration, it is important 630 for technical experts to review documents of mutual interest and, 631 when appropriate, to provide review comments to the approving body as 632 the document moves through the approval process. 634 2.4.1. IEEE 802 draft review and balloting processes and opportunities 635 for IETF participation 637 IEEE 802 drafts are reviewed and balloted at multiple stages in the 638 draft. Any ballot comments received from non-voters before the close 639 of the ballot are required to be considered in the comment resolution 640 process. 642 IEEE 802 draft reviews and ballots sometimes produce a large volume 643 of comments. In order to handle them efficiently, spreadsheets or a 644 comment database tool are used. It is highly recommended that 645 balloters and others submitting comments do so with a file that can 646 be imported into these tools. A file with the correct format is 647 normally referenced in the ballot announcement or can be obtained 648 from the Editor, Task Group Chair or Working Group Chair responsible 649 for the project. Comments on a draft should be copied to the Editor, 650 Task Group Chair and Working Group Chair. 652 2.4.1.1. Task Group Review 654 During draft development, informal task group reviews (task group 655 ballots) are conducted. Though these are called "ballots" by some 656 Working Groups, the focus is on collecting and resolving comments on 657 the draft rather than on trying to achieve a specific voting result. 659 2.4.1.2. Working Group ballot 661 Once the draft is substantially complete, Working Group ballots are 662 conducted. Working Group voting members are entitled and required to 663 vote in Working Group ballots. Any disapprove votes are required to 664 be accompanied by comments that indicate what the objection is and a 665 proposed resolution. Approve votes may also be accompanied by 666 comments. The comments submitted with a disapprove vote may be 667 marked to indicate which comments "be satisfied" to change the vote. 669 Initial Working Group ballots are at least 30 days. Recirculation 670 ballots to review draft changes and comment resolutions are at least 671 10 days. 673 2.4.1.3. Sponsor Ballot 675 When a draft has successfully completed Working Group ballot, it 676 proceeds to Sponsor ballot. One may participate in IEEE 802 Sponsor 677 Ballots with an individual membership in the IEEE Standards 678 Association (IEEE-SA) or by paying a per-ballot fee. (See IEEE-SA 679 membership.) Participants are also required to state their 680 affiliation and the category of their relationship to the scope of 681 the standards activity (e.g. producer, user, general interest). 683 Note to the reader: The yearly cost of membership in the IEEE-SA is 684 generally about the same or less as the per-ballot fee, so it is 685 generally more economical to join the IEEE-SA. 687 Information about IEEE-SA membership can be found at 688 http://standards.ieee.org/membership/ 690 Sponsor ballot is a public review. An invitation is sent to any 691 parties known to be interested in the subject matter of the ballot. 692 One can indicate interest in IEEE myProject. An IEEE web account 693 freely available, and is required for login. To select interest 694 areas, go to the Projects tab and select Manage Activity Profile and 695 check any areas of interest. IEEE 802 projects are under Computer 696 Society; LAN/MAN Standards Committee. 698 The Sponsor Ballot pool is formed from those that accept the 699 invitation during the invitation period. 701 Editor's note: add URL for myProject is 702 development.standards.ieee.org to references. 704 Any "disapprove" votes are required to be accompanied by comments 705 that indicate what the objection is, along with a proposed 706 resolution. Approve votes may also be accompanied by comments. The 707 comments submitted with a disapprove vote may be marked to indicate 708 which comments need to "be satisfied" for the commenter to change the 709 vote from "disapprove". 711 Initial Sponsor ballot are open for at least 30 days. Recirculation 712 ballots to review draft changes and proposed comment resolutions are 713 at least 10 days. 715 Editor's note: check that all groups accept the same file format and 716 try to find a place to post a blank .CSV file for download. Pat's 717 action 719 2.4.2. IETF draft review and balloting processes and opportunities for 720 IEEE 802 participation 722 The IETF Working Group Process is defined in BCP-25. The overall 723 IETF standards process is defined in BCP-9. 725 As noted in , IETF working groups do not "ballot", but the 726 IESG does, as part of considering documents for approval. 728 Technical contributions are welcome at any point in the IETF document 729 review and approval process, but there are some points where 730 contribution is more likely to be effective. 732 1. When a working group is considering adoption of an individual 733 draft. Adoption is often signaled on the working group's mailing 734 list. 736 2. When a working group issues a "Working Group Last Call" ("WGLC") 737 for a draft. Although this is not a mandatory step in the 738 document review and approval process for Internet-Drafts, most 739 IETF working groups do issue WGLCs for most working group 740 documents. WGLC would be signaled on the working group's mailing 741 list. 743 3. When the Internet Engineering Steering Group issues an "IETF Last 744 Call" ("Last Call") for a draft. This is similar in spirit to 745 WGLC, but is a request for review and approval that is addressed 746 to the larger IETF community. IETF Last Call is signaled on the 747 IETF-Announce Mailing List, and comments and feedback are 748 ordinarily directed to the IETF Discussion Mailing List. 750 In practice, earlier input is more likely to be effective input. 751 IEEE 802 participants who are interested in work within the IETF 752 should be monitoring that work and providing input long before 753 Working Group Last Calls and IETF Last Calls, for best results. 755 Some IETF working group charters direct the working group to 756 communicate with relevant IEEE 802 task groups. 758 2.5. Expert Review Processes 760 With the number of areas of cooperation between IEEE 802 and IETF 761 increasing, the document review process has extended beyond the 762 traditional subjects of SMI MIB modules and AAA described in 763 [RFC4441]. The IESG members use expert reviews as a means to solicit 764 the opinion of specialized experts on specific aspects of documents 765 in IESG review (examples include security, MIB doctors, or congestion 766 management reviews). Area Directors may also require expert reviews 767 from IEEE 802 or IEEE 802 Working Groups when it becomes clear that 768 the Internet-Draft has implications for some area of IEEE 802's 769 responsibility and expertise. 771 IETF participants can comment as part of the IEEE 802 ballot process, 772 regardless of their voting status within IEEE 802. Comments must be 773 composed in the format specified for the ballot, and submitted by the 774 ballot deadline. 776 2.6. Liaison Officials/Liaison Managers and Liaison Statements 778 EDITOR'S NOTE: This section is written mostly from an IETF 779 perspective. If there are helpful things to say about IEEE 802 780 liaison processes, that would be great to add. :-) 782 Both IEEE 802 and IETF work best when people participate directly in 783 work of mutual interest, but that's not always possible, and 784 individuals speaking as individuals may not provide effective 785 communication between the two SDOs. From time to time, it may be 786 appropriate for a technical body in one SDO to communicate as a body 787 with a technical body in the other SDO. This section describes the 788 mechanisms used to provide formal communication between the two 789 organizations, should that become necessary. 791 The Internet Architecture Board (IAB) is responsible for liaison 792 relationship oversight for the IETF. 794 The reader should note that the role of a liaison official (called a 795 "Liaison Manager" in the IETF) in both IEEE 802 and IETF is not to 796 "speak for" the appointing organization. A liaison official is most 797 helpful in insuring that neither organization is surprised by what's 798 happening in the other organization, helping to identify the right 799 people to be talking to in each organization, and making sure that 800 formal liaison statements don't "get lost" between the two 801 organizations. The IAB's guidance to liaison managers is available 802 in http://tools.ietf.org/html/rfc4691. 804 2.6.1. Liaison Officials/Liaison Managers 806 The IAB appoints IETF Liaison Managers using the process described in 807 http://tools.ietf.org/html/rfc4052. The current list of the IETF's 808 liaison relationships, and the liaison officials responsible for each 809 of these relationships is available at 810 http://www.ietf.org/liaison/managers.html. 812 2.6.2. Liaison Statements 814 The IETF process for sending and receiving liaison statements is 815 defined at http://tools.ietf.org/html/rfc4053. 817 3. Mailing Lists 819 All IETF working groups and all IEEE 802 Working Groups have 820 associated mailing lists. Most IEEE 802 Task Groups also have 821 mailing lists, but in some cases, e.g.the IEEE 802.1 Working Group, 822 the Working Group mailing list is used for any Task Group matters. 824 In the IETF, the mailing list is the primary vehicle for discussion 825 and decision-making. It is recommended that IEEE 802 experts 826 interested in particular IETF working group topics subscribe to and 827 participate in these lists. IETF WG mailing lists are open to all 828 subscribers. The IETF working group mailing list subscription and 829 archive information are noted in each working group's charter page. 831 In IEEE 802, mailing lists are typically used for meeting logistics, 832 ballot announcements, reports and some technical discussion. Most 833 decision making is at meetings, but in cases where a decision is 834 needed between meetings, it may be done over the mailing list. Most 835 technical discussion occurs at meetings and by generating comments on 836 drafts which are compiled with responses in comment resolution 837 documents. 839 Most IEEE 802 mailing lists are open to all subscribers. For the few 840 IEEE 802 mailing lists that are not open, please see the working 841 group chair to arrange for access to the mailing list. 843 4. Cross-Referencing Documents in IEEE 802 and IETF 845 IETF and IEEE 802 each recognize the standards defined by the other 846 and therefore do not have issues with cross-referencing each other's 847 standards. 849 IETF specifications may reference IEEE 802 work in progress, but 850 these references would be labeled as "Work in Progress", and if the 851 references are Normative, this would block publication of the 852 referring specification until the reference is available in a stable 853 form. 855 IEEE standards may reference non-expired Internet-Drafts, but this 856 should be avoided if at all possible. 858 EDITOR'S NOTE: The plan used to be that IETF Internet-Drafts expired 859 after 6 months, AND WERE NO LONGER RETRIEVABLE - but now, expired 860 drafts are still available without a subpoena. Do we think Internet- 861 Drafts now qualify for IEEE 802 use? We'll talk ... 863 When an IEEE Standard is revised, it normally retains the same number 864 and the date is updated. Therefore, IEEE Standards are dated with 865 the year of approval, e.g IEEE Std 802.1Q-2011. There are two ways 866 of referencing IEEE Standards: undated and dated references. IEEE 867 practice allows undated reference to be used when referencing a whole 868 standard. An undated reference indicates that the most recent 869 version of the standard should be used. A dated reference refers to 870 a specific revision of an IEEE standard. Since clauses, subclauses, 871 tables, figures, etc. may be renumbered when a standard is revised, a 872 dated reference should be used when citing specific items in a 873 standard. 875 Informative references in IEEE Standards are placed in a bibliograpy, 876 so may point to either approved IETF standards or IETF Internet- 877 Drafts, if necessary. 879 5. Protocol Parameter Allocation 881 Both IEEE 802 and IETF maintain registries of assigned protocol 882 parameters, and some protocol parameters assigned in one organization 883 are of interest to the other organization. This section describes 884 the way each organization registers protocol parameters. 886 5.1. IANA 888 The IETF uses the Internet Assigned Numbering Authority (IANA) as a 889 central authority that administers registries for protocol parameter 890 allocations. The overarching document describing this is RFC 5226. 891 RFC 5342 discusses use of IEEE 802-specific IANA parameters in IETF 892 protocols and specifies IANA considerations for allocation of code 893 points under the IANA OUI (Organizationally Unique Identifier). 895 5.2. IEEE Registration Authority 897 EDITOR'S NOTE: This section is focused on one (important) specific 898 example - we need text that describes the RAC and general operation 899 first. We have asked Glenn Parson to provide text here. 901 EtherType Allocation - The IEEE Registration Authority (IEEE RA) 902 assigns Ethertypes with oversight from the IEEE Registration 903 Authority Committee (IEEE RAC). (See 904 http://standards.ieee.org/develop/regauth/ethertype/.) Some IETF 905 protocol specification make use of Ethertypes. All Ethertype 906 requests are subject to review by a consultant to the IEEE RA 907 followed by IEEE RAC confirmation. 909 Since Ethertypes are a fairly scarce resource, the IEEE RAC will not 910 assign a new Ethertype to a new IETF protocol specification until the 911 IESG has approved the protocol specification for publication as an 912 RFC. In exceptional cases, the IEEE RA is willing to consider "early 913 allocation" of an Ethertype for an IETF protocol that is still under 914 development as long as the request comes from, and has been vetted 915 by, the IESG. 917 To let the IEEE RAC know that the IESG has approved the request for 918 an Ethernet assignment for an IETF protocol, all future requests for 919 assignment of Ethertypes for IETF protocols will be made by the IESG. 921 Note that playpen Ethertypes have been assigned in IEEE 802 [1] for 922 use during protocol development and experimentation. 924 [1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001). IEEE 925 standard for Local and Metropolitan Area Networks: Overview and 926 Architecture -- Amendment 1: Ethertypes for Prototype and Vendor- 927 Specific Protocol Development. 929 While a fee is normally charged by IEEE 802 for the allocation of an 930 EtherType, IEEE 802 will consider waiving the fee for allocations 931 relating to an IETF standards track document, based on a request from 932 the IESG. 934 5.3. IEEE Registration at IEEE working group level 936 Need text here - don't need to say much about this, but do need to 937 say that these registrations exist. 939 5.4. Pointers to Additional Useful Information 941 This section provides pointers to additional useful information for 942 paricipants in IEEE 802 and IETF. 944 5.4.1. IEEE 802 Information that may be useful to IETF participants 946 IEEE Home Page: http://ieee802.org/ 948 IEEE 802 policies and procedures: http://ieee802.org/devdocs.shtml" 950 5.4.2. IETF Information that may be of use to IEEE 802 participants 952 Information on IETF procedures may be found in the documents in the 953 informative references, and URLs below. 955 Note: RFCs do not change after they are published. Rather, they are 956 either obsoleted or updated by other RFCs. Such updates are tracked 957 in the rfc-index.txt file. 959 Current list and status of all IETF RFCs: 960 ftp://ftp.ietf.org/rfc/rfc-index.txt 962 Current list and description of all IETF Internet-Drafts: 963 ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt 965 Current list of IETF working groups and their Charters: 966 http://www.ietf.org/dyn/wg/charter.html (includes area directors and 967 chair contacts, mailing list information, etc.) 969 Current list of registered BOFs: http://trac.tools.ietf.org/bof/trac/ 971 RFC Editor pages about publishing RFCs: 972 http://www.rfc-editor.org/index.html (including available tools and 973 lots of guidance) http://www.rfc-editor.org/pubprocess.html is 974 particularly helpful. 976 Current list of liaison statements: 977 https://datatracker.ietf.org/liaison/ 979 IETF Intellectual Property Rights Policy and Notices: 980 http://www.ietf.org/ipr/ 982 The Tao of the IETF: http://www.ietf.org/tao.html (A Novice's Guide 983 to the Internet Engineering Task Force) 985 6. IANA Considerations 987 This document requests no actions by IANA. 989 7. Security Considerations 991 Documents that describe cooperation procedures, like this one, have 992 no direct Internet security implications. 994 8. Acknowledgements 996 This document borrows massive amounts of text, including much of its 997 structure, from [RFC6756]. Additional text was borrowed from 998 [RFC4441]. We are grateful to the authors and editors of both these 999 predecessor documents. 1001 This document was assembled by a drafting team of participants from 1002 both IEEE 802 and IETF. The drafting team members were Dan 1003 Romascanu, Dorothy Stanley, Eric Gray, Patricia Thaler, Roger Marks, 1004 Ross Callon, Spencer Dawkins, and Subir Das. 1006 We also thank Bernard Aboba for providing review comments. 1008 9. References 1010 9.1. Normative References 1012 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1013 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1014 May 2008. 1016 [RFC6756] Trowbridge, S., Lear, E., Fishman, G., and S. Bradner, 1017 "Internet Engineering Task Force and International 1018 Telecommunication Union - Telecommunication 1019 Standardization Sector Collaboration Guidelines", 1020 RFC 6756, September 2012. 1022 9.2. Informative References 1024 [RFC4441] Aboba, B., "The IEEE 802/IETF Relationship", RFC 4441, 1025 March 2006. 1027 Appendix A. Current examples of this relationship 1029 A.1. MIB Review 1031 Historically the MIB modules for IEEE 802.1 and IEEE 802.3 were 1032 developped in the IETF Bridge MIB and Hub MIB Working Groups 1033 respectively. With travel budgets under pressure, it has become 1034 increasingly difficult for companies to fund employees to attend both 1035 IEEE 802 and IETF meetings. As a result, an alternative was found to 1036 past arrangements that involved chartering MIB work items within an 1037 IETF WG by transferring the work to IEEE 802 with expert support for 1038 MIB review from the IETF. In order to encourage wider review of MIBs 1039 developed by IEEE 802 WGs, it is recommended that MIB modules 1040 developed in IEEE 802 follow the MIB guidelines [RFC4181]. An IEEE 1041 802 group may request assignment of a 'MIB Doctor' to assist in a MIB 1042 review by contacting the IETF Operations and Management Area 1043 Director. 1045 By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing 1046 the SNMP quality control process, the IETF and IEEE 802 seek to 1047 ensure quality while decreasing overhead. The process of transfer of 1048 the MIB work from the IETF to IEEE 802 is documented in [RFC4663] and 1049 in [I-D ETHERNET-MIB-TRANSFER]. 1051 Authors' Addresses 1053 Spencer Dawkins (editor) 1054 Huawei Technologies 1055 1547 Rivercrest Blvd. 1056 Allen, TX 75002 1057 USA 1059 Email: spencer@wonderhamster.org 1061 Patricia Thaler 1062 Broadcom Corporation 1063 5025 Keane Drive 1064 Carmichael, CA 95608 1065 USA 1067 Email: pthaler@broadcom.com