idnits 2.17.1 draft-harrington-8021-mib-transition-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 908. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 919. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 932. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 30, 2006) is 6541 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3410' is mentioned on line 548, but not defined == Missing Reference: 'RFC2578' is mentioned on line 556, but not defined == Missing Reference: 'RFC2579' is mentioned on line 556, but not defined == Missing Reference: 'RFC2580' is mentioned on line 557, but not defined == Unused Reference: 'IEEE802.1AB' is defined on line 772, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Bridge MIB WG D. Harrington, Ed. 3 Internet-Draft Effective Software Consulting 4 Intended status: Informational May 30, 2006 5 Expires: December 1, 2006 7 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG 8 draft-harrington-8021-mib-transition-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 1, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document describes the plan to transition responsibility for 42 bridging-related MIB modules from the IETF Bridge MIB Working Group 43 to the IEEE 802.1 Working Group, which develops the bridging 44 technology the MIB modules are designed to manage. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. New IEEE MIB Work . . . . . . . . . . . . . . . . . . . . . . 4 51 2.1. New MIB PARs . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.2. IEEE MIB Modules in ASCII format . . . . . . . . . . . . . 4 53 2.3. OID Registration for New MIB Modules . . . . . . . . . . . 5 54 3. Current Bridge MIB WG Documents . . . . . . . . . . . . . . . 6 55 3.1. Transferring Current Bridge MIB WG Documents . . . . . . . 6 56 3.2. Updating IETF MIB Modules . . . . . . . . . . . . . . . . 7 57 3.3. Clarifications on Variables Mapping and Compliance . . . . 8 58 4. Mailing List Discussions . . . . . . . . . . . . . . . . . . . 9 59 5. IETF MIB Doctor Reviews . . . . . . . . . . . . . . . . . . . 9 60 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 61 5.2. Review Guidelines . . . . . . . . . . . . . . . . . . . . 10 62 5.3. Review Format . . . . . . . . . . . . . . . . . . . . . . 13 63 5.4. Review Weight . . . . . . . . . . . . . . . . . . . . . . 14 64 6. Communicating the Transition Plan . . . . . . . . . . . . . . 15 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 9. Intellectual Property Considerations . . . . . . . . . . . . . 15 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 71 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 18 72 Appendix B. Sample text for IEEE to request rights from 73 authors . . . . . . . . . . . . . . . . . . . . . . . 19 74 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 19 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 Intellectual Property and Copyright Statements . . . . . . . . . . 21 78 1. Introduction 80 This document describes the plan to transition responsibility for 81 bridging-related MIB modules from the IETF Bridge MIB WG to the IEEE 82 802.1 WG, which develops the bridging technology the MIB modules are 83 designed to manage. The current Bridge MIB WG documents are: 84 o "Definitions of Managed Objects for Bridges" [RFC4188], 85 o "Definitions of Managed Objects for Bridges with Rapid Spanning 86 Tree Protocol" [RFC4318] 87 o "Definitions of Managed Objects for Bridges with Traffic Classes, 88 Multicast Filtering and Virtual LAN Extensions" [RFC4363], and 89 o Definitions of Managed Objects for Source Routing Bridges 90 [RFC1525] 92 This document is meant to establish some clear expectations between 93 IETF and IEEE about the transition of Bridge MIB WG MIB modules to 94 the IEEE 802.1 WG, so that the plan can be reviewed by the IESG, IAB, 95 IETF, and IEEE. There might be some case-by-case situations that 96 arise, which will be handled by the appropriate liaisons, but this 97 document describes the general strategy. 99 1.1. Motivation 101 Having SNMP MIB modules to provide management functionality for its 102 technologies is important for the 802.1 community, so it needs to 103 charter this work as part of the Project Authorization Requests 104 (PARs) for each new project, to ensure that resources are being 105 mobilized for execution. This is also true with respect to MIB 106 support for already completed 802.1 projects - maintenance projects 107 need to include the development of SNMP MIB modules. 109 The IESG has mandated that IETF WGs that produce a protocol are also 110 required to develop the corresponding MIB module rather than leaving 111 that to "the SNMP experts" to do later. Part of the motivation was 112 obviously to make the protocols more manageable, but part of the 113 motivation was also balancing the workload better and getting the 114 content experts more involved in the management design. If such work 115 comes into the IETF from other standards development organizations 116 (SDOs), then we encourage the other SDO to bring in subject matter 117 expertise to work with us, or, even better, to take the lead 118 themselves. 120 The manpower problem is certainly an aspect that is relevant. IEEE 121 802 MIB documents could be developed in the IETF, but only if the 122 subject matter experts come to IETF to actually participate (lead) 123 the work. The content experts need to be more involved in the MIB 124 module development, and resources need to be dedicated to completing 125 the work, whether editing is done in the IEEE or the IETF. The IETF 126 is OK with other organizations (like IEEE 802) doing MIB documents 127 themselves, and the IETF offers to help review them from an SNMP/MIB/ 128 SMI perspective. This is true even after the transition, since 129 quality MIB modules are important to smooth management of the 130 Internet and the technologies it runs on. 132 2. New IEEE MIB Work 134 2.1. New MIB PARs 136 The IEEE-SA Standards Board New Standards Committee (NesCom) deals 137 with the Projects Approval Requests - see 138 http://standards.ieee.org/board/nes/. PARs are roughly the 139 equivalent of IETF Working Group Charters, and include information 140 concerning the scope, purpose, and justification for standardization 141 projects. 143 Following early discussions concerning the transfer of MIB work from 144 the IETF Bridge MIB WG to the IEEE 802.1 WG, the development of SMIv2 145 MIB modules associated with IEEE 802.1 projects has been included 146 within the scope of the work of new projects. 148 The latest Project Approval Requests (PAR) of the 802.1 projects 149 starting with the P802.1ah - Provider Backbone Bridges - approved in 150 December 2004 include explicit text on this respect. 152 For example the PAR form of the IEEE 802.1ah - Provider Backbone 153 Bridges [PAR-IEEE802.1ah] includes in Section 13 - "Scope of Proposed 154 Project" an explicit reference to 'support management including 155 SNMP'. 157 Although it is not mandatory for the MIB development work to be 158 specified explicitly in a new PAR to have the work done - see work 159 done in IEEE 802.1AB [IEEE802.1AB]and IEEE 802.1AE [IEEE802.1AE]- it 160 is recommended that IEEE 802.1 WG PARs include explicit wording in 161 the scope section wherever there is need for MIB development as part 162 of the standard. 164 Since the IETF Bridge MIB WG does not intend to develop MIB modules 165 in the future, submitters of new work in the bridge management space 166 should be directed to the IEEE 802.1 WG, and to recommend they not 167 publish their proposed MIB modules as Internet-Drafts. 169 2.2. IEEE MIB Modules in ASCII format 171 Having MIB modules be made freely and openly available in an ASCII 172 format will be a critical factor in having the SNMP community accept 173 the transfer of 802.1 MIB development from IETF Bridge MIB WG to IEEE 174 802.1 WG. While 802.1 can certainly decide to publish MIB modules 175 only in the PDF format that they use for their documents without 176 publishing an ASCII version, most network management systems can 177 import a MIB module that is in ASCII format but not one in PDF 178 format. Not publishing an ASCII version of the MIB module would 179 negatively impact implementers and deployers of MIB modules, and 180 would make IETF review of MIB modules more difficult. 182 The 802.1 WG web site requires a password for access to standards in 183 development. The WG has started making the MIB module portion of 184 their documents available as separate ASCII files during project 185 development, and allowing IETF participants to access these documents 186 for pre-standard review purposes. 188 IEEE 802 has a policy that approved specifications are available for 189 a fee for the first six months after approval, and freely available 190 six months after they are approved. Once the specification is 191 approved, the ASCII version of the MIB module is made freely 192 available on the 802.1 WG website (see 193 http://www.ieee802.org/1/files/public/MIBs/ or 194 http://www.ieee802.org/1/pages/MIBS.html). 196 There may be some issues about what gets included in the freely 197 available specification. The SMIv2 MIB module alone will probably be 198 insufficient; some discussion of the structure of the MIB, the 199 relationship to other MIB modules, and security considerations will 200 also need to be made available to ensure appropriate implementation 201 and deployment of the MIB module within the Internet environment. 202 For most implementers, the freely available specification six months 203 after approval will be adequate. 205 2.3. OID Registration for New MIB Modules 207 The IETF and IEEE 802 have separate registration branches (arcs) in 208 the OID tree. The Bridge MIB modules are registered under the IETF 209 branch, and some assignments are maintained by IANA. The 210 administration of the IEEE 802 arc is documented in [IEEE.802b]. 212 As the IEEE 802.1 WG updates the IEEE 802.1 standards, the changes 213 may include needed modifications to supplement the existing tables. 214 This can be handled by developing an IEEE MIB module that augments 215 the existing tables, or reuses the indexing of the existing tables. 216 The new modules can be registered under the 802.1 registration 217 branch, as was done with the 802.1X MIB module. 219 When the changes only require the additional of one or two objects to 220 the existing MIB modules, it may seem simpler for the 802.1 WG to 221 define additional managed objects within the IANA-controlled 222 registration tree. This approach is not recommended because of the 223 difficulties of coordinating the changes between the two 224 organizations, and working the changes through the processes while 225 trying to remain timely for each organization. Such additions would 226 probably require approval by the Area Directors of Operations and 227 Management after IETF MIB Doctor review. This would create 228 dependencies between the work of the two organizations, and it might 229 generate special cases for IANA to prevent the IEEE being bogged down 230 by IETF processes. 232 The approach of developing an IEEE MIB module and defining a new 233 compliance clause is simpler than dealing with such dependencies. 235 We need a balance between disruption to existing implementations and 236 efficiency in making changes. Keeping the existing trees in their 237 place minimizes disruption to existing implementations. 239 3. Current Bridge MIB WG Documents 241 3.1. Transferring Current Bridge MIB WG Documents 243 While reviewing the legal issues associated with transferring Bridge 244 MIB WG documents to the IEEE 802.1 WG, it was concluded that the IETF 245 does not have sufficient legal authority to make the transfer without 246 the consent of the document authors. 248 RFC1286, RFC1493 and RFC1525 apparently precede any specific IETF 249 document describing the copyright and intellectual property rights 250 that authors grant to the IETF. RFC2674 falls under RFC 2026 251 [RFC2026] rules. The three recent updates, [RFC4188], [RFC4318], and 252 [RFC4363] fall under BCP 78, as documented in RFC3978 [RFC3978]. 254 To permit them to perform maintenance of and the development of 255 derivations works from documents containing the BRIDGE-MIB [RFC4188] 256 and the P-BRIDGE-MIB and Q-BRIDGE-MIB [RFC4363] and RSTP-MIB 257 [RFC4318], the IEEE 802.1 WG will need to get permission from the 258 authors and/or the companies to whom the authors have assigned their 259 intellectual property rights in these documents. 261 The IETF legal counsel for IPR matters and the IEEE Standards 262 Association Manager of Standards Intellectual Property have agreed 263 upon a sample letter for use by the IEEE 802.1 WG to request the 264 necessary permissions from the authors, which is shown in Appendix B. 265 The Bridge MIB WG chairs reviewed the author lists for the documents 266 and provided the list of authors and their last known addresses and 267 the documents with which they were associated to the IEEE Standards 268 Association Manager of Standards Intellectual Property. 270 The IETF will retain all the rights granted at the time of 271 publication in the published RFCs. 273 3.2. Updating IETF MIB Modules 275 The updates to the Bridge MIB WG documents addresssed changes 276 documented in 802.1t, 802.1u, 802.1v, and 802.1w. These amendments 277 were merged with 802.1D-1998 by the IEEE 802.1 WG to form 802.1D- 278 2004. The Bridge MIB WG did not address changes that resulted from 279 that merger of documents. 281 The 802.1 WG will need to work through the management objects in the 282 existing documents to determine whether they are consistent with new 283 emerging specifications, including 802.1D-2004. During the final 284 work on these documents in the Bridge MIB WG, there were some issues 285 that we decided not to resolve and to allow them to be dealt with as 286 part of the future work in the 802.1 WG. 288 Work on the following items was deferred to the IEEE: 289 o the 'autoEdgePort' parameter (802.1D-2004 clause 17.3.3) 290 o the BridgeID object 291 o references to 802.1D-1998 were not updated to 802.1D-2004 292 o some objects in RFC4363 may have been obsoleted in 802.1D-2004 293 o Description of dot1dPortOutboundAccessPriority seems wrong, but it 294 followed the description in 802.1D-1998. 295 o An issue was raised concerning dot1dTpPortInFrames and 296 dot1dTpPortOutFrames. This is an issue left over from RFC 1493. 298 It was thought that the IEEE might be able to write separate 299 documents containing updates to their technologies, such as 802.1Q, 300 and include a separate MIB module to augment the IETF MIB modules. 301 However, recent changes to the IEEE standards are expected to require 302 changing the way the MIB tables are INDEXED, which is not allowed 303 under SMI rules, so the IEEE will need to rewrite the MIB modules, 304 and assign object identifiers under the ieee802 branch. 306 For backwards compatibility, the existing IETF documents will still 307 be valid and remain unchanged. 309 If an 802.1 WG document must update or obsolete the IETF version of a 310 Bridge MIB document, the 802.1 WG can create and submit an internet- 311 draft to the IESG to be published as an RFC that points to the openly 312 available IEEE copy and the IEEE standard. The IESG would need to 313 approve the publication of the RFC. The RFC status would be 314 reflected in the RFC-INDEX and also in the database so it will be 315 reflected on the RFC-Editor web page, so we don't have a problem with 316 synchronization between the copies being published. 318 3.3. Clarifications on Variables Mapping and Compliance 320 As the 802.1 WG handles the MIB development, the IEEE-standard 321 "managed variables" and the associated IEEE MIB module objects will 322 probably correspond, as many existing BRIDGE-MIB objects already 323 correspond to 802.1 management variables, such as these from 802.1Q. 325 Virtual Bridge MIB object IEEE 802.1Q-2003 Reference 327 dot1qBase 328 dot1qVlanVersionNumber 12.10.1.1 read bridge vlan config 329 dot1qMaxVlanId 12.10.1.1 read bridge vlan config 330 dot1qMaxSupportedVlans 12.10.1.1 read bridge vlan config 331 dot1qNumVlans 332 dot1qGvrpStatus 12.9.2.1/2 read/set garp 333 applicant controls 335 IEEE allows definitions to be clarified in a manner that can actually 336 alter the semantics of a managed variable somewhat, such as by 337 changing the range. SMI rules generally prevent changing the 338 semantics of defined MIB objects without obsoleting the current 339 object and replacing it with an object with a new descriptor and OID 340 registration. It is expected that, once both an IEEE MIB definition 341 and the "managed variable" descriptions are in the same document, 342 this problem will go away, as IEEE can update both at the same time 343 in the approved manner. 345 The need to fix a description in an IETF Bridge MIB module in a 346 manner that would not be SMI legal would precipitate the need to 347 define an IEEE MIB module, which might copy and replace the whole 348 IETF MIB module, or just add the necessary objects. Copying the IETF 349 MIB module and changing the descriptors and reassigning new IEEE OIDs 350 would not be backwards compatible, and existing applications would 351 need to be updated to access the new objects, so it is recommended 352 that the IETF MIB module not be copied and modified unless really 353 necessary. 355 The current practice in the 802.1 WG is to define the management 356 variables and then a mapping table to associated MIB module objects 357 (as shown above). The 802.1 WG could redefine the mapping from an 358 IEEE managed variable to a new IEEE MIB object if the 802.1 359 management variable semantics changed, thus allowing the 802.1 WG to 360 'do it right' by SMI rules, supplementing the old MIB object with a 361 new one. An updated mapping would be reflected in the compliance 362 clause of the supplemental SMIv2 MIB module; it may be desirable to 363 document the old mapping information in the description clause of the 364 new object in the SMIv2 MIB module. 366 Often the mapping of 802 variables to MIB objects isn't and doesn't 367 have to be a 1:1 mapping. In the future 802.1 variables may be 368 invented with Web-based services in mind, but today the primary focus 369 is on SNMP usage, and incorporating MIB modules into the specs 370 themselves will likely further that focus. The level of redirection 371 that exists today between 802 variables and MIB objects might be 372 useful for the transition process when changing 802.1 management 373 variable semantics and supplementing MIB objects. 375 The existing Bridge documents represent the current state of bridging 376 management, and the documents contain compliance clauses describing 377 the current requirements to be compliant to the IETF standards. As 378 the IEEE develops addition MIB modules, new compliance clauses will 379 define the new "state of the art", without needing to obsolete the 380 old MIB objects or the old compliance clauses. Therefore, the plan 381 is that the current Bridge MIB modules will be "frozen in time", and 382 updated only via the development of independent MIB modules by the 383 802.1 WG. 385 4. Mailing List Discussions 387 The Bridge MIB WG has completed its documents, and the WG has been 388 closed. 390 The mailing list will remain open for a while. The mailing list 391 administrators will discourage discussion of ongoing IEEE MIB module 392 work on the Bridge MIB WG list and ask that the discussion be moved 393 to the IEEE list, with a notice comparable to: 395 This work is out of scope for the Bridge MIB WG mailing list. 396 The appropriate mailing list for IEEE 802.1 MIB module discussion 397 is STDS-802-1-L@listserv.ieee.org. 398 To subscribe to the STDS-802-1-L list, go to 399 http://www.ieee802.org/1/email-pages/ 400 To see the general information about 802,1, including how they 401 work and how to participate, go to http://www.ieee802.org/1/ 402 To see presentations on the technology, go to 403 http://www.ieee802.org/1/files/public/ and look in the docs2004, 404 docs2005, and docs2006 directories. 406 5. IETF MIB Doctor Reviews 407 5.1. Introduction 409 The leaders of the Bridge MIB WG, 802.1 WG, IETF O&M area, and IEEE 410 802 project have discussed having IETF MIB Doctors review IEEE 802 411 developed MIB modules. This is a loose offering. 413 The expectation is that IETF will maintain a group of MIB Doctors who 414 can review IEEE 802 developed MIB modules, when a MIB Doctor is 415 available and willing to do such review. It is the choice of 416 individual MIB Doctors to provide technical advice and MIB Doctor 417 reviews, and it is the willingness of the 802.1 editors and the 418 support of the 802.1 chairs that determine whether the advice is 419 accepted or not. This is not as formalized as in the IETF. 421 In the IETF, the O&M area directors get "pushed" by other area 422 directors to have MIB module documents reviewed by MIB Doctors when 423 they start to come to WG Last Call, IETF Last Call, and certainly no 424 later than when they appear on the IESG agenda. This demand requires 425 prioritization of requests for MIB Doctor reviews by the area 426 directors and prioritization by MIB Doctors when deciding whether to 427 accept a request to review documents. 429 When there are many IETF MIB documents in the queue and an IEEE MIB 430 module document comes along for review, it will be the choice of the 431 individual MIB Doctors whether to accept such a request, and how to 432 prioritize their work. 434 It will be helpful to MIB Doctors if the 802.1 chair requests a 435 review early in development, after a MIB module design has been 436 established but before an editor has done much detailing of the MIB 437 module, so a MIB Doctor can ensure that the table relationships and 438 indexing are reasonable. Then it will be helpful if the 802.1 chair 439 requests reviews only for important ballots, such as sponsor ballots, 440 rather than for every revision. 442 It is recommended that the 802.1 WG establish their own MIB Doctor 443 review team, to provide a review of MIB modules and to resolve most 444 issues before requesting a review from the IETF MIB Doctors. This 445 will help the 802.1 WG avoid delays caused by dependency on IETF MIB 446 Doctors, and pre-reviewed documents will make it easier for an IETF 447 MIB Doctor to find time to perform a requested review. The IETF is 448 willing to make a loose offering to help the 802.1 WG establish and 449 train such an IEEE MIB Doctor team. 451 5.2. Review Guidelines 453 The IETF has developed Guidelines for Authors and Reviewers of MIB 454 Documents [RFC4181], so authors and other WG members can check their 455 document against the guidelines before requesting a MIB Doctor 456 review. The 802.1 WG editor should utilize the RFC4181 guidelines 457 before requesting a MIB Doctor review. 459 RFC4181 also intended to help editors by guiding MIB Doctors, so 460 reviews by different MIB Doctors will remain fairly consistent. Each 461 MIB Doctor has their own "pet peeves", and RFC4181 can help an editor 462 know whether a review point is based on the consensus of the MIB 463 Doctors, or a pet peeve. 465 Many SMI constraints and IETF editing constraints and best current 466 practices are discussed in RFC4181. However, many aspects of good 467 MIB design (e.g. table fate-sharing, good index choices, etc.) are 468 more art than science, and are not discussed in the guidelines. 469 Those might be more useful to other SDOs (and IETF editors) than 470 guidelines relating to IETF boilerplate requirements. The MIB 471 Doctors have discussed starting a design guidelines document. 473 RFC4181 was used when reviewing the 802.1AB [IEEE802.1AB]and 802.1AE 474 [IEEE802.1AE] documents. During those reviews, there were some 475 anomalies about the IEEE use of the guidelines that we need to 476 evaluate further. 478 For example, in the IETF boilerplates, some of the terms have 479 different meaning in IETF and IEEE, and different editing style 480 guidelines are being used by the different bodies. It would be good 481 to develop an 802 MIB boilerplate that is consistent with the IETF 482 boilerplate, in purpose if not in terminology. 484 The IETF uses [RFC4181] as a reference document for IETF documents 485 containing MIB modules. It is recommended that in time IEEE 802.1 WG 486 develop their own guidelines for IEEE MIB modules review. Until this 487 happens Section 3 (General Documentation Guidelines) and Section 4 488 (SMIv2 Guidelines) in RFC4181 can be used with the following 489 exceptions and modifications: 490 o In the introductory paragraphs of Section 3, the list of sections 491 that must be included in a MIB document should be adapted to the 492 IEEE needs and style guide. 493 o Sections 3.1 to 3.4 apply as in the IETF document, with the 494 mention that the IETF boilerplate could be edited to comply to the 495 IEEE needs and style guide 496 o Section 3.5 (IANA Considerations Section) does not apply, but may 497 be replaced by a section with IEEE recommendations on naming and 498 OID space assignments 499 o Sections 3.6 does not apply 500 o Section 3.7 (Copyright notices) does not apply and may be replaced 501 with text corresponding to the IEEE copyright rules. The 502 exception is the case where a document was originally issued by 503 the IETF, and then taken over by the IEEE, in which case, unless 504 otherwise agreed by the document authors, notices concerning the 505 IETF copyrights (as described in the current section 3.7) and IEEE 506 copyrights must be included. 507 o Section 3.8 (Intellectual Property) does not apply and may be 508 replaced with a notice reflecting the intellectual property rules 509 of the IEEE 510 o Sections 4.1 and 4.2 apply as in the IETF document 511 o Section 4.3 (Naming Hierarchy) applies with changes related to the 512 OID root of the IEEE 802.1 MIB modules 513 o Sections 4.4 to 4.8 apply as in the IETF document 514 o Section 4.9 applies, but some interesting problems may arise if 515 IETF designed modules are being taken over and continued by the 516 IEEE. In order to comply to the requirement the IEEE should 517 continue to work and maintain the MIB module in the IETF OID 518 space. 520 An IETF MIB document template that contains all the required 521 sections, following RFC Editor guidelines and the MIB review 522 guidelines, is under development to help editors get started 523 developing a MIB module document. The template will help MIB Doctors 524 check new MIB modules more efficiently by providing the most up-to- 525 date MIB module boilerplate, with sections in the preferred order, 526 suggestions for what to include in certain sections, and the 527 references required to support boilerplate text. It is recommended 528 that the IEEE 802.1 WG establish a comparable template, following the 529 IEEE editing guidelines and the RFC4181 guidelines where appropriate. 531 Such an IEEE template could simply result in being the management 532 clause of an 802.1 document, to be filled in with technology-specific 533 information. In 802.1AB, the MIB clause was restructured to include 534 modified IETF boilerplates and security considerations. This might 535 be a good start on such an IEEE template. It would be helpful to MIB 536 Doctors and editors if the unmodified template was available in ASCII 537 format for automated comparison to a document in development, to 538 verify that the appropriate boilerplate text is being used. 540 When the 802.1 WG creates a PAR for 802.1 Bridge MIB maintenance, the 541 creation of such a template might be included in the PAR. 543 The IETF MIB documents include the following text relative to the 544 Internet Management Framework as part of the standard boilerplate: 546 For a detailed overview of the documents that describe the current 547 Internet-Standard Management Framework, please refer to section 7 of 548 RFC 3410 [RFC3410]. 550 Managed objects are accessed via a virtual information store, termed 551 the Management Information Base or MIB. MIB objects are generally 552 accessed through the Simple Network Management Protocol (SNMP). 553 Objects in the MIB are defined using the mechanisms defined in the 554 Structure of Management Information (SMI). This memo specifies a 555 MIB module that is compliant to the SMIv2, which is described in 556 STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 557 STD 58, RFC 2580 [RFC2580]. 559 It is recommended that the IEEE 802.1 standards that contain MIB 560 modules include a similar sub-section in the MIB section of the IEEE 561 document, and the appropriate references in their reference section. 563 If IEEE 802.1 WG wants to craft their own guidelines based on 564 RFC4181, they will need to get the author's permission. 566 5.3. Review Format 568 The 802.1 WG uses a template for comments, in the following format, 569 so the onus to provide new text is on the reviewer, not the editor. 571 NAME: 572 COMMENT TYPE: 573 [E=Editorial, ER=Editorial Required] 574 [T=Technical, TR=Technical Required] 575 CLAUSE: 576 PAGE: 577 LINE: 578 COMMENT START: 579 COMMENT END: 580 SUGGESTED CHANGES START: 581 SUGGESTED CHANGES END: 583 MIB Doctor reviews in the IETF are typically done in simple text 584 email, and often contain a long list of review comments. MIB Doctor 585 reviews sometimes raise a general design issue rather than an issue 586 with specific text, and some MIB Doctor comments refer to "global" 587 problems, such as many objects that do not specify persistence 588 requirements. 590 For global problems, IETF MIB Doctors are not required to provide the 591 replacement text for each of these instances when doing 802.1 MIB 592 module reviews. For example, if the naming of objects does not 593 follow recommended conventions throughout the document, the MIB 594 Doctor can point out the relevant clause in RFC4181 without 595 suggesting each replacement object name. This is an important 596 concession to the IETF MIB Doctors, to better suit the nature of 597 their reviews, even though this puts the onus on the editor to fix 598 the problem without explicit suggested changes. 600 During the transition, the chair and vice-chair of the 802.1 WG are 601 willing to accept simple emails, as long as they give enough 602 information to understand what the problem is and how to fix it. The 603 comments should include a problem description, a suggested 604 resolution, and a page and line number. It would be helpful if 605 comments are submitted in the preferred format, since this makes it 606 easier for the editor to understand exactly what is being requested, 607 to log the comment for review, and to review the comment in the 608 meeting environment. The majority of MIB comments can usually be 609 handled outside of the official balloting process. 611 5.4. Review Weight 613 In the IETF, MIB Doctor review happens as part of the process of 614 approving a standard. When a document is submitted to the IESG for 615 approval as a standard, the area director/IESG requests a MIB Doctor 616 review. Failure to pass the review can stop forward progress of a 617 document in the standardization process at the discretion of the area 618 director. MIB Doctors take their role seriously and perform detailed 619 reviews. 621 In the IEEE, the board that approves a standard is separate from the 622 802.1 WG, and the reviews MIB Doctors will do based on this 623 transition plan are done within the 802.1 WG. So a MIB Doctor review 624 in the 802.1 WG is akin to an IETF WG chair asking for a MIB Doctor 625 to sanity-check the work, rather than a formal "MIB Doctor review". 627 Formally, comments from any origin carry the same weight in 802.1; 628 even voting status in the WG doesn't make your comments more weighty 629 than a non-voter. The 802.1 WG is not permitted to ignore any 630 comments, regardless of origin. Serious comments are always taken 631 seriously and never ignored. 633 The IEEE typically requires comments to be officially submitted in a 634 specific format, including proposed replacement text, which is then 635 reviewed at the meetings, and the decisions are documented in 636 disposition documents. These comments and dispositions are available 637 from the 802.1 private website. IETF participants can be given the 638 password to the website by the 802.1 WG chair, so they can see 639 previous and current comments and dispositions. 641 We should not give the impression that the IEEE documents have 642 received the organized, coordinated, and formalized MIB Doctor review 643 as done in the IETF, if such review is done on an ad-hoc basis, and 644 not necessarily as part of the advancement process. We need to be 645 clear what is said, because the phrase "This document has passed MIB 646 Doctor review" has quite some weight in the IETF. We need to clarify 647 whether to describe the reviews done as having been done by an "IETF 648 MIB Doctor" or "IEEE 802 MIB Doctor", or a generic "MIB Doctor". 650 MIB Doctor reviews be copied to the document editor, and to the 802.1 651 chair 653 6. Communicating the Transition Plan 655 The transition plan was discussed in the Bridge MIB WG at IETF61, and 656 included a presentation "Bridge MIB Transition to IEEE 802.ppt" 657 available in the proceedings. 659 The intent to transition was also posted on the Bridge MIB WG mailing 660 list during notices of the Bridge MIB WG closure, including the WG 661 Action announcement of February 15, 2006. 663 The transition was discussed with the 802.1 WG at the San Antonio, 664 San Francisco, and Garden Grove meetings. Presentations are 665 available in http://www.ieee802.org/1/files/public/docs2004/ 666 new-bridge-mib-transition-1104.ppt, http://www.ieee802.org/1/files/ 667 public/docs2005/liaison-ietf-congdon-0705.pdf, and http:// 668 www.ieee802.org/1/files/public/docs2005/ 669 liaison-ietf-congdon-0905.pdf. 671 7. Security Considerations 673 This document describes a plan to transition MIB module 674 responsibility from the IETF Bridge MIB WG to the IEEE 802.1 WG. It 675 does not impact security. 677 8. IANA Considerations 679 Although this document discusses issues related to IANA assignment of 680 OIDs, no IANA actions are required by this document. 682 9. Intellectual Property Considerations 684 On November 29, 2005, a teleconference was held that included Jorge 685 Contreras, Scott Bradner, Bernard Aboba, Bert Wijnen, and David 686 Harrington, to discuss the Intellectual Property Issues. The 687 following is a summary of the conclusions: 689 The IETF/ISOC gets a non-exclusive copyright license from RFC authors 690 so that the IETF can publish RFCs, let third parties translate RFCs 691 into other languages, let third parties reproduce RFCs as-is and to 692 create derivative works within the IETF standard process. The 693 author(s) retain all their rights other than the right to withdraw 694 the permission for the IETF to do the above. 696 If anyone (including the IEEE) wants to reproduce any RFC as-is they 697 can do so without any specific permission - but it has to be "as-is" 698 and that includes the ISOC copyright notice - since the right for 699 third parties to reproduce RFCs is part of the rights the IETF gets 700 from the author(s). 702 The author(s) of a RFC can tell another group (e.g., the IEEE) that 703 the other group can produce their own versions of the RFC if the 704 author(s) want to since the IETF does not get from the author(s) the 705 right to stop them from doing so. 707 If the author(s) give another group the permission to create 708 derivative works, this has nothing (legally) to do with the IETF 709 since the agreement is just between the author(s) and the other 710 group. Because of that, there is no reason for an ISOC copyright to 711 appear since the new document is not an IETF document. It would be 712 nice if the other group were to include a note to say that their 713 document is based on RFC XXXX, and the author(s) can insist on that 714 if they want but the IETF has no formal role in the granting of 715 permissions so the IETF cannot require the pointer to the RFC. 717 There is a desire to ensure that the IETF has sufficient rights to do 718 derivatives of its own works. If the IETF decides, as part of a 719 liaison arrangement with another SDO, to hand over maintenance of a 720 specification to them, and the authors give the other SDO permission 721 to create derivative works, the IETF still retains the permission 722 granted by the authors to create derivative works within the IETF 723 standard process. 725 The IETF strongly recommends that any derivative works developed by 726 another standards body DO acknowledge that the work builds on prior 727 IETF work, with reference to the RFC(s) the work derives from. MIB 728 modules compliant to the IETF Best Current Practices documented in 729 RFC4181 contain REVISION clauses that document how/where earlier 730 versions were published. 732 On January 11, 2006, another teleconference was held, to review the 733 legal issues with Claudio M. Stanziola, the IEEE Standards 734 Association Manager of Standards Intellectual Property. As a result 735 of that discussion, the IETF Legal Counsel on IPR matters has crafted 736 a sample document that other SDOs may use as a guideline for 737 producing their own documents on "how to ask the question" to solicit 738 authors' permissions, and the template is included in this document 739 in Appendix B. 741 10. References 743 10.1. Normative References 745 [RFC1525] Decker, E., McCloghrie, K., Langille, P., and A. 746 Rijsinghani, "Definitions of Managed Objects for Source 747 Routing Bridges", RFC 1525, September 1993. 749 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 750 3", BCP 9, RFC 2026, October 1996. 752 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 753 RFC 3978, March 2005. 755 [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects 756 for Bridges", RFC 4188, September 2005. 758 [RFC4318] D.Levi and D.Harrington, "Definitions of Managed Objects 759 for Bridges with Rapid Spanning Tree Protocol", RFC 4318, 760 December 2005. 762 [RFC4363] Levi, D. and D. Harrington, "Definitions of Managed 763 Objects for Bridges with Traffic Classes, Multicast 764 Filtering, and Virtual LAN Extensions", RFC 4363, 765 January 2006. 767 10.2. Informative References 769 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 770 Documents", BCP 111, RFC 4181, September 2005. 772 [IEEE802.1AB] 773 "IEEE Std 802.1AB-2005, Standard for Local and 774 metropolitan area networks - Station and Media Access 775 Control Connectivity Discovery", IEEE Std 802.1AB- 776 2005 IEEE Std, 2005. 778 [IEEE802.1AE] 779 "IEEE P802.1AE-2006, Draft Standard for Local and 780 metropolitan area networks - Media Access Control (MAC) 781 Security.", http://www.ieee802.org/1/files/private/ 782 ae-drafts/d4/802-1ae-d4-0.pdf IEEE Draft, January 2006. 784 [PAR-IEEE802.1ah] 785 "http://standards.ieee.org/board/nes/projects/ 786 802-1ah.pdf", 802-1ah IEEE PAR, December 2004. 788 [IEEE.802b] 789 Institute of Electrical and Electronics Engineers, "Local 790 and Metropolitan Area Networks: Overview and Architecture, 791 Amendment 2: Registration of Object Identifiers", 792 IEEE Standard 802, 2004. 794 Appendix A. Contributors 796 Dan Romascanu 797 Avaya 798 Atidim Technology Park, Bldg. #3 799 Tel Aviv, 61131 800 Israel 801 +972 3-645-8414 802 dromasca@avaya.com 804 Tony Jeffree 805 Chair, 802.1 WG 806 11A Poplar Grove 807 Sale 808 Cheshire M33 3AX 809 UK 810 +44 161 973 4278 811 tony@jeffree.co.uk 813 Paul Congdon 814 Vice Chair, 802.1 WG 815 Hewlett Packard Company 816 HP ProCurve Networking 817 8000 Foothills Blvd, M/S 5662 818 Roseville, CA 95747 819 US 820 +1 916 785 5753 821 paul.congdon@hp.com 823 Bert Wijnen 824 Lucent Technologies 825 Schagen 33 826 3461 GL Linschoten 827 NL 828 +31-348-407-775 829 bwijnen@lucent.com 831 Bernard Aboba 832 Microsoft Corporation 833 One Microsoft Way 834 Redmond, WA 98052 835 US 836 +1 425 818 4011 837 bernarda@microsoft.com 839 Appendix B. Sample text for IEEE to request rights from authors 841 > "Dear Author, 843 The IEEE P802.1 working group wishes to incorporate portions of IETF 844 RFC XXXX (specifically YYY MIB modules) as part of IEEE Draft 845 Standard P802.1 and, to develop, modify and evolve such portions as 846 part of the IEEE standardization process. 848 Because the authors of contributions to the IETF standards retain 849 most intellectual property rights with respect to such contributions 850 under IETF policies in effect during the development of RFC XXXX and, 851 because you are an author of said document, the IEEE hereby requests 852 that you kindly agree to submit your contributions in RFC XXXX to the 853 IEEE for inclusion in IEEE P802.1. Please note that IETF is aware of 854 and supports this request. 856 Attached hereto, please find a copyright permission letter template 857 that we ask you to kindly sign and return, granting the afore 858 mentioned rights to the IEEE. 860 Sincerely yours, IEEE" 862 Appendix C. Change Log 864 [RFCEditor: please remove the change log before publication] 866 Changes from -00- 867 removed uncited references 868 fixed some citations 869 (re-)moved sections on updating OIDs, IANA OID Registration, and 870 mailing list usage, comment formats 871 updated MIB Doctor review section 872 updated clarifications section 873 updated URLs for presentations about the transition 874 updated Intellectual Property section based on teleconference with 875 IETF legal counsel 876 updated IEEE references 877 removed empty history section 878 rewrote the "Updating IETF MIB Modules" section 879 added appendix with sample letter to authors 880 removed sections no longer needed after discussions with legal 881 counsel 883 Author's Address 885 David Harrington (editor) 886 Effective Software Consulting 887 Harding Rd 888 Portsmouth NH 889 USA 891 Phone: +1 603 436 8634 892 Email: dbharrington@comcast.net 894 Full Copyright Statement 896 Copyright (C) The Internet Society (2006). 898 This document is subject to the rights, licenses and restrictions 899 contained in BCP 78, and except as set forth therein, the authors 900 retain all their rights. 902 This document and the information contained herein are provided on an 903 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 904 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 905 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 906 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 907 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 908 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 910 Intellectual Property 912 The IETF takes no position regarding the validity or scope of any 913 Intellectual Property Rights or other rights that might be claimed to 914 pertain to the implementation or use of the technology described in 915 this document or the extent to which any license under such rights 916 might or might not be available; nor does it represent that it has 917 made any independent effort to identify any such rights. Information 918 on the procedures with respect to rights in RFC documents can be 919 found in BCP 78 and BCP 79. 921 Copies of IPR disclosures made to the IETF Secretariat and any 922 assurances of licenses to be made available, or the result of an 923 attempt made to obtain a general license or permission for the use of 924 such proprietary rights by implementers or users of this 925 specification can be obtained from the IETF on-line IPR repository at 926 http://www.ietf.org/ipr. 928 The IETF invites any interested party to bring to its attention any 929 copyrights, patents or patent applications, or other proprietary 930 rights that may cover technology that may be required to implement 931 this standard. Please address the information to the IETF at 932 ietf-ipr@ietf.org. 934 Acknowledgment 936 Funding for the RFC Editor function is provided by the IETF 937 Administrative Support Activity (IASA).