copyrights (as described in Section 3.7) and IEEE copyrights must
be included.
o Section 3.8 (Intellectual Property) does not apply and may be
replaced with a notice reflecting the intellectual property rules
of the IEEE.
o Sections 4.1 and 4.2 apply as in the IETF document.
o Section 4.3 (Naming Hierarchy) applies with changes related to the
OID root of the IEEE 802.1 MIB modules.
o Sections 4.4 to 4.8 apply as in the IETF document
o Section 4.9 applies, but some interesting problems may arise if
IETF-designed modules are being taken over and continued by the
IEEE. In order to comply to the requirement, the IEEE should
continue to work and maintain the MIB module in the IETF OID
space.
An IETF MIB document template that contains all the required
sections, following RFC Editor guidelines and the MIB review
guidelines, is under development to help editors get started
developing a MIB module document. The template will help MIB Doctors
check new MIB modules more efficiently by providing the most up-to-
date MIB module boilerplate, with sections in the preferred order,
suggestions for what to include in certain sections, and the
references required to support boilerplate text. It is recommended
that the IEEE 802.1 WG establish a comparable template, following the
IEEE editing guidelines and the RFC4181 guidelines, where
appropriate.
Such an IEEE template could simply be the management clause of an
802.1 document, to be filled in with technology-specific information.
In 802.1AB, the MIB clause was restructured to include modified IETF
boilerplates and security considerations. This might be a good start
on such an IEEE template. It would be helpful to MIB Doctors and
editors if the unmodified template was available in ASCII format for
automated comparison to a document in development, to verify that the
appropriate boilerplate text is being used.
When the 802.1 WG creates a PAR for 802.1 Bridge MIB maintenance, the
creation of such a template might be included in the PAR.
The IETF MIB documents include the following text relative to the
Internet Management Framework as part of the standard boilerplate:
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to Section 7
of RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store,
termed the Management Information Base, or MIB. MIB objects are
generally accessed through the Simple Network Management Protocol
(SNMP). Objects in the MIB are defined using the mechanisms
defined in the Structure of Management Information (SMI). This
memo specifies a MIB module that is compliant to the SMIv2, which
is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579
[RFC2579], and STD 58, RFC 2580 [RFC2580].
It is recommended that the IEEE 802.1 standards that contain MIB
modules include a similar sub-section in the MIB section of the IEEE
document, and the appropriate references in their reference section.
If IEEE 802.1 WG wants to craft its own guidelines, based on RFC4181,
it will need to get the author’s permission.
5.3. Review Format
The 802.1 WG uses a template for comments, in the following format,
so the onus to provide new text is on the reviewer, not on the
editor.
NAME:
COMMENT TYPE:
[E=Editorial, ER=Editorial Required]
[T=Technical, TR=Technical Required]
CLAUSE:
PAGE:
LINE:
COMMENT START:
COMMENT END:
SUGGESTED CHANGES START:
SUGGESTED CHANGES END:
MIB Doctor reviews in the IETF are typically done in simple text
email and often contain a long list of review comments. MIB Doctor
reviews sometimes raise a general design issue rather than an issue
with specific text, and some MIB Doctor comments refer to "global"
problems, such as many objects that do not specify persistence
requirements.
For global problems, IETF MIB Doctors are not required to provide the
replacement text for each of these instances when doing 802.1 MIB
module reviews. For example, if the naming of objects does not
follow recommended conventions throughout the document, the MIB
Doctor can point out the relevant clause in RFC4181 without
suggesting each replacement object name. This is an important
concession to the IETF MIB Doctors, to better suit the nature of
their reviews, even though this puts the onus on the editor to fix
the problem without explicit suggested changes.
During the transition, the chair and vice-chair of the 802.1 WG are
willing to accept simple emails, as long as they give enough
information to understand what the problem is and how to fix it. The
comments should include a problem description, a suggested
resolution, and a page and line number. It would be helpful if
comments are submitted in the preferred format, since this makes it
easier for the editor to understand exactly what is being requested,
to log the comment for review, and to review the comment in the
meeting environment. The majority of MIB comments can usually be
handled outside the official balloting process.
5.4. Review Weight
In the IETF, MIB Doctor review happens as part of the process of
approving a standard. When a document is submitted to the IESG for
approval as a standard, the area director/IESG requests a MIB Doctor
review. Failure to pass the review can stop forward progress of a
document in the standardization process at the discretion of the area
director. MIB Doctors take their role seriously and perform detailed
reviews.
In the IEEE, the board that approves a standard is separate from the
802.1 WG, and the reviews MIB Doctors will do according to this
transition plan are done within the 802.1 WG. So a MIB Doctor review
in the 802.1 WG is akin to an IETF WG chair asking for a MIB Doctor
to sanity-check the work, rather than to a formal "MIB Doctor
review".
Formally, comments from any origin carry the same weight in 802.1;
even voting status in the WG doesn’t make one’s comments more weighty
than those of a non-voter. The 802.1 WG is not permitted to ignore
any comments, regardless of origin. Serious comments are always
taken seriously and never ignored.
The IEEE typically requires that comments be officially submitted in
a specific format, including proposed replacement text, which is then
reviewed at the meetings, and the decisions are documented in
disposition documents. These comments and dispositions are available
from the 802.1 private website. IETF participants can be given the
password to the website by the 802.1 WG chair, so that they can see
previous and current comments and dispositions.
We should not give the impression that the IEEE documents have
received the organized, coordinated, and formalized MIB Doctor review
as done in the IETF, if such review is done on an ad hoc basis, and
not necessarily as part of the advancement process. We need to be
clear what is said, because the phrase "This document has passed MIB
Doctor review" has quite some weight in the IETF. We need to clarify
whether to describe the reviews done as having been done by an "IETF
MIB Doctor" or "IEEE 802 MIB Doctor", or by a generic "MIB Doctor".
MIB Doctor reviews be copied to the document editor, and to the 802.1
chair.
6. Communicating the Transition Plan
The transition plan was discussed in the Bridge MIB WG at IETF61 and
included a presentation, "Bridge MIB Transition to IEEE 802.ppt",
available in the proceedings.
The intent to transition was also posted on the Bridge MIB WG mailing
list during notices of the Bridge MIB WG closure, including the WG
Action announcement of February 15, 2006.
The transition was discussed with the 802.1 WG at the San Antonio,
San Francisco, and Garden Grove meetings. Presentations are
available in http://www.ieee802.org/1/files/public/docs2004/
new-bridge-mib-transition-1104.ppt, http://www.ieee802.org/1/files/
public/docs2005/liaison-ietf-congdon-0705.pdf, and
http://www.ieee802.org/1/files/public/docs2005/
liaison-ietf-congdon-0905.pdf.
7. Security Considerations
This document describes a plan to transition MIB module
responsibility from the IETF Bridge MIB WG to the IEEE 802.1 WG. It
does not impact security.
8. IANA Considerations
Although this document discusses issues related to IANA assignment of
OIDs, no IANA actions are required by this document.
9. Intellectual Property Considerations
On November 29, 2005, a teleconference was held that included Jorge
Contreras, Scott Bradner, Bernard Aboba, Bert Wijnen, and David
Harrington, to discuss the Intellectual Property Issues. The
following is a summary of the conclusions:
The IETF/ISOC gets a non-exclusive copyright license from RFC authors
so that the IETF can publish RFCs, let third parties translate RFCs
into other languages, let third parties reproduce RFCs as-is and
create derivative works within the IETF standard process. The
author(s) retain all of their rights other than the right to withdraw
the permission for the IETF to do the above.
If anyone (including the IEEE) wants to reproduce any RFC as-is, he
or she can do so without any specific permission, but it has to be
"as-is" (and that includes the ISOC copyright notice) since the right
for third parties to reproduce RFCs is part of the rights the IETF
gets from the author(s).
The author(s) of a RFC can tell another group (e.g., the IEEE) that
the other group can produce its own versions of the RFC, since the
IETF does not get from the author(s) the right to stop them from
doing so.
If the author(s) give another group the permission to create
derivative works, this has nothing (legally) to do with the IETF,
since the agreement is just between the author(s) and the other
group. Because of that, there is no reason for an ISOC copyright to
appear, since the new document is not an IETF document. It would be
nice if the other group were to include a note to say that their
document is based on RFC XXXX, and the authors can insist on that if
they want to, but the IETF has no formal role in granting
permissions, so the IETF cannot require the pointer to the RFC.
There is a desire to ensure that the IETF has sufficient rights to do
derivatives of its own works. If the IETF decides, as part of a
liaison arrangement with another SDO, to hand over maintenance of a
specification to them, and if the authors give the other SDO
permission to create derivative works, the IETF still retains the
permission granted by the authors to create derivative works within
the IETF standard process.
The IETF strongly recommends that any derivative works developed by
another standards body DO acknowledge that the work builds on prior
IETF work, with reference to the RFC(s) the work derives from. MIB
modules compliant to the IETF Best Current Practices documented in
RFC4181 contain REVISION clauses that document how/where earlier
versions were published.
On January 11, 2006, another teleconference was held, to review the
legal issues with Claudio M. Stanziola, the IEEE Standards
Association Manager of Standards Intellectual Property. As a result
of that discussion, the IETF Legal Counsel on IPR matters has crafted
a sample document that other SDOs may use as a guideline for
producing their own documents on "how to ask the question" to solicit
authors’ permissions. The template is included in this document in
Appendix B.
Appendix A. Contributors
Dan Romascanu
Avaya
Atidim Technology Park, Bldg. #3
POB 58173
Tel Aviv, 61581
Israel
Phone +972 3-645-8414
EMail: dromasca@avaya.com
Tony Jeffree
Chair, 802.1 WG
11A Poplar Grove
Sale
Cheshire M33 3AX
UK
Phone: +44 161 973 4278
EMail: tony@jeffree.co.uk
Paul Congdon
Vice Chair, 802.1 WG
Hewlett Packard Company
HP ProCurve Networking
8000 Foothills Blvd, M/S 5662
Roseville, CA 95747
US
Phone: +1 916 785 5753
EMail: paul.congdon@hp.com
Bert Wijnen
Lucent Technologies
Schagen 33
3461 GL Linschoten
NL
Phone: +31-348-407-775
EMail: bwijnen@lucent.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Phone: +1 425 818 4011
EMail: bernarda@microsoft.com
Appendix B. Sample Text for IEEE to Request Rights from Authors
> "Dear Author,
The IEEE P802.1 working group wishes to incorporate portions of IETF
RFC XXXX (specifically YYY MIB modules) as part of IEEE Draft
Standard P802.1 and to develop, modify and evolve such portions as
part of the IEEE standardization process.
Because the authors of contributions to the IETF standards retain
most intellectual property rights with respect to such contributions
under IETF policies in effect during the development of RFC XXXX, and
because you are an author of said document, the IEEE hereby requests
that you kindly agree to submit your contributions in RFC XXXX to the
IEEE for inclusion in IEEE P802.1. Please note that IETF is aware of
and supports this request.
Attached hereto, please find a copyright permission letter template
that we ask you kindly to sign and return, granting the
aforementioned rights to the IEEE.
Sincerely yours, IEEE"
References
Normative References
[RFC1525] Decker, E., McCloghrie, K., Langille, P., and A.
Rijsinghani, "Definitions of Managed Objects for
Source Routing Bridges", RFC 1525, September 1993.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP
78, RFC 3978, March 2005.
[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed
Objects for Bridges", RFC 4188, September 2005.
[RFC4318] Levi, D. and D. Harrington, "Definitions of
Managed Objects for Bridges with Rapid Spanning
Tree Protocol", RFC 4318, December 2005.
[RFC4363] Levi, D. and D. Harrington, "Definitions of
Managed Objects for Bridges with Traffic Classes,
Multicast Filtering, and Virtual LAN Extensions",
RFC 4363, January 2006.
Informative References
[IEEE802.1AB] "IEEE Std 802.1AB-2005, Standard for Local and
metropolitan area networks - Station and Media
Access Control Connectivity Discovery", IEEE Std
802.1AB-2005 IEEE Std, 2005.
[IEEE802.1AE] "IEEE P802.1AE-2006, Draft Standard for Local and
metropolitan area networks - Media Access Control
(MAC) Security.", http://www.ieee802.org/1/files/
private/ae-drafts/d4/802-1ae-d4-0.pdf IEEE Draft,
January 2006.
[IEEE.802b] Institute of Electrical and Electronics Engineers,
"Local and Metropolitan Area Networks: Overview
and Architecture, Amendment 2: Registration of
Object Identifiers", IEEE Standard 802, 2004.
[PAR-IEEE802.1ah] "http://standards.ieee.org/board/nes/
projects/802-1ah.pdf", 802-1ah IEEE PAR, December
2004.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2
(SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579,
April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC
2580, April 1999.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers
of MIB Documents", BCP 111, RFC 4181, September
2005.
Author’s Address
David Harrington (editor)
Effective Software Consulting
Harding Rd
Portsmouth NH
USA
Phone: +1 603 436 8634
EMail: dbharrington@comcast.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).