[xml2rfc] living on the edge
mrose at dbc.mtview.ca.us (Marshall Rose) Tue, 27 September 2005 19:50 UTC
From: "mrose at dbc.mtview.ca.us"
Date: Tue, 27 Sep 2005 19:50:30 +0000
Subject: [xml2rfc] living on the edge
Message-ID: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us>
X-Date: Tue Sep 27 19:50:30 2005
http://xml.resource.org/experimental.html >From pekkas at netcore.fi Wed Sep 28 09:52:44 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue Sep 27 22:53:07 2005 Subject: [xml2rfc] living on the edge In-Reply-To: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us> References: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us> Message-ID: <Pine.LNX.4.61.0509280852010.16610@netcore.fi> On Wed, 28 Sep 2005, Marshall Rose wrote: > http://xml.resource.org/experimental.html Could a link be appropriate on the front page? I'll want to use the experimental form but I'll forget the URL otherwise :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >From charles_levert at gna.org Wed Sep 28 11:24:25 2005 From: charles_levert at gna.org (Charles Levert) Date: Wed Sep 28 07:24:30 2005 Subject: living on the edge [xml2rfc] In-Reply-To: <Pine.LNX.4.61.0509280852010.16610@netcore.fi> References: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us> <Pine.LNX.4.61.0509280852010.16610@netcore.fi> Message-ID: <20050928142425.GA19442@localhost.localdomain> * On Wednesday 2005-09-28 at 08:52:44 +0300, Pekka Savola wrote: > On Wed, 28 Sep 2005, Marshall Rose wrote: > >http://xml.resource.org/experimental.html > > Could a link be appropriate on the front page? I'll want to use the > experimental form but I'll forget the URL otherwise :) Look closer. There might just be one already! :-) >From dbharrington at comcast.net Wed Sep 28 14:17:20 2005 From: dbharrington at comcast.net (David B Harrington) Date: Wed Sep 28 21:16:42 2005 Subject: [xml2rfc] living on the edge In-Reply-To: <ADA60244-D6DE-4CE3-90F6-DCDC80ADACDA@dbc.mtview.ca.us> Message-ID: <200509281717.j8SHHGiM025566@drakken.dbc.mtview.ca.us> Hi, Thank you, this works fairly well to meet the 2223bis rules. I found two anomalies: 1) if strict=="yes", xml2rfc complains about finding <references> at a line number that actually has the </back> tag on it. (and <references> actually has a number of appendices between it and <back> 2) appendices can now be inserted before <references>, but references still get numbered. In 2223bis, the references are not numbered (although section 7.4f seems to indicate numbering. Attached are the XML and TXT output documents I used. Thanks for a wonderful tool, David Harrington dbharrington@comcast.net > -----Original Message----- > From: xml2rfc-bounces@dbc.mtview.ca.us > [mailto:xml2rfc-bounces@dbc.mtview.ca.us] On Behalf Of Marshall Rose > Sent: Tuesday, September 27, 2005 10:50 PM > To: xml2rfc mailing list > Subject: [xml2rfc] living on the edge > > http://xml.resource.org/experimental.html > _______________________________________________ > xml2rfc mailing list > xml2rfc@lists.xml.resource.org > http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc > -------------- next part -------------- A non-text attachment was scrubbed... Name: draft-harrington-xml2rfc-mib-template-01.xml Type: text/xml Size: 44788 bytes Desc: not available Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20050928/7bf43517/draft-harrington-xml2rfc-mib-template-01-0001.xml -------------- next part -------------- Internet Engineering Task Force D. Harrington, Ed. Internet-Draft Effective Software Consulting Expires: April 1, 2006 September 28, 2005 A Template for XML2RFC MIB Module Documents draft-harrington-xml2rfc-mib-template-00.txt Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 1, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the SAMPLE protocol. [ATTN: describe what functionality will be managed using this MIB module, such as the SAMPLE protocol.] Foreword For updated information on MIB module guidelines and templates, see Harrington Expires April 1, 2006 [Page 1] Internet-Draft MIB Module Template September 2005 http://www.ops.ietf.org/. For information on writing internet drafts or RFCs, see http://www.ietf.org/ietf/1id-guidelines.txt and RFC2223(bis), and look at http://www.ietf.org/ID-Checklist.html for issues to note when writing drafts. For information on XML2RFC, see RFC2629(bis), http://xml.resource.org/public/rfc/html/rfc2629.html and "bis": http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html. Also see http://xml.resource.org/authoring/README.html for 'rfc' option strings. You don't need to have any other tools than a 'notepad' or your favourite editor to write xml2rfc drafts. You can use the web interface at http://xml.resource.org for processing. The benefit of using xml editors is mostly catching those missing tags which the processor will warn you about, but you don't need to worry about the editors when getting started. This template is not meant to be a conclusive list of everything, but summarize the often-needed basic features to get one started. ATTN: please remove this Forward prior to publication. Harrington Expires April 1, 2006 [Page 2] Internet-Draft MIB Module Template September 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Internet-Standard Management Framework . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 5 5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 5 5.2. The sample Group . . . . . . . . . . . . . . . . . . . . . 5 5.3. The sample999 Group . . . . . . . . . . . . . . . . . . . 5 5.4. The Notifications Group . . . . . . . . . . . . . . . . . 5 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 6 6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . 6 6.2. Relationship to the IF-MIB . . . . . . . . . . . . . . . . 6 6.3. MIB modules required for Imports . . . . . . . . . . . . . 6 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Changes from RFC BBBB (the previous RFC for this specification) . . . . . . . . . . . . . . . . . . . 14 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Harrington Expires April 1, 2006 [Page 3] Internet-Draft MIB Module Template September 2005 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the SAMPLE protocol, defined in "The SAMPLE Protocol" [RFC_CCCC] [ATTN: describe what functionality will be managed using this MIB module.] 2. The Internet-Standard Management Framework 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]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 4. Overview This document provides analysis of application performance as experienced by end-users. SAMPLE performance measurement measures the quality of service delivered to end-users by the SAMPLE Protocol. With this perspective, a true end-to-end view of the IT infrastructure results, combining the performance of the SAMPLE Protocol as well as any positive or negative interactions between multiple entities using the SAMPLE Protocol. Despite all the technically sophisticated ways in which networking and system resources can be measured, human end-users perceive only two things about an application: availability and responsiveness. Harrington Expires April 1, 2006 [Page 4] Internet-Draft MIB Module Template September 2005 Availability - The percentage of the time that the application is ready to give a user service. Responsiveness - The speed at which the application delivers the requested service. A transaction is an action initiated by a user that starts and completes a distributed processing function. A transaction begins when a user initiates a request for service (i.e., pushing a submit button) and ends when the work is completed (i.e., information is provided or a confirmation is delivered). A transaction is the fundamental item measured by the SAMPLE MIB. blah, blah, blah, blah ... 5. Structure of the MIB Module 5.1. Textual Conventions Generic and Common Textual Conventions can be found summarized at http://www.ops.ietf.org/mib-common-tcs.html Objects in this MIB module are arranged into groups. Each group is organized as a set of related objects. The overall structure and assignment of objects to their groups, and the intended purpose of each group, is shown below. 5.2. The sample Group This group contains the objects which are applicable to all types of entities implementing the SAMPLE protocol.. This group provides information for identifying fault conditions and performance degradation. 5.3. The sample999 Group This group contains the objects that denote the entity's state with respect to the sample999 features of the SAMPLE Protocol. Object s have been defined to enable/disable and control the Sample999 feature set, as well as to monitor the traffic transmitted or received via the Sample999 feature. 5.4. The Notifications Group This group contains notifications to alert other entities to events which could alter the operational behavior of the entity in a network Harrington Expires April 1, 2006 [Page 5] Internet-Draft MIB Module Template September 2005 utilizing the SAMPLE Protocol. 6. Relationship to Other MIB Modules Some management objects defined in other MIB modules are applicable to an entity implementing this MIB. In particular, it is assumed that an entity implementing the SAMPLE-MIB module will also implement the 'system' group of the SNMPv2-MIB [RFC3418] and the 'interfaces' group of the IF-MIB [RFC2863]. 6.1. Relationship to the SNMPv2-MIB The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The 'system' group provides identification of the management entity and certain other system-wide data. The SAMPLE-MIB does not duplicate those objects. 6.2. Relationship to the IF-MIB In the SNMPv2-MIB [RFC3418], the 'system' group is defined as being mandatory for all systems. Thus, those objects apply to the entity as a whole irrespective of whether the entity's sole functionality is bridging, or whether bridging is only a subset of the entity's functionality. 6.3. MIB modules required for Imports The following MIB module IMPORTS objects from XXX-MIB [RFCxxxx], YYY- MIB [RFCyyy] and also REFERENCEs documents AAAA [RFCaaaa] and BBBB [RFCbbbb] 7. Definitions SAMPLE-MIB DEFINITIONS ::= BEGIN -- ---------------------------------------------------------- -- -- MIB for SAMPLE devices -- ---------------------------------------------------------- -- IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32, TimeTicks, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, MacAddress FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP Harrington Expires April 1, 2006 [Page 6] Internet-Draft MIB Module Template September 2005 FROM SNMPv2-CONF InterfaceIndex FROM IF-MIB ; sampleMIB MODULE-IDENTITY LAST-UPDATED "200410220000Z" ORGANIZATION "IETF SAMPLE MIB Working Group" CONTACT-INFO "Email: ietfmibs@ops.ietf.org (Editor) Tel: Email: Postal: Send comments to <ietfmibs@ops.ietf.org>" DESCRIPTION "A sample MIB module for managing devices that support a SAMPLE protocol. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices. -- RFC Ed.: replace XXXX with actual RFC number and remove this note " REVISION "200509020000Z" -- 27 September 2005 DESCRIPTION "Third revision, published as part of RFC XXXX. The MIB module has been converted to SMIv2 format. Conformance statements have been added and some description and reference clauses have been updated. The object sampleObject999 was added to support SAMPLE v3 and the permissible values of samplePriority and samplePortPriority have been clarified for entities supporting SAMPLE v2. The interpretation of sampleLastChange has been clarified for entities supporting the foo feature of SAMPLE v2." REVISION "199307310000Z" DESCRIPTION "Second revision, published as part of RFC BBBB." REVISION "199112310000Z" Harrington Expires April 1, 2006 [Page 7] Internet-Draft MIB Module Template September 2005 DESCRIPTION "Initial revision, published as part of RFC AAAA." ::= { mib-2 YYYY } -- ---------------------------------------------------------- -- -- Suggested OID layout -- ---------------------------------------------------------- -- sampleNotifications OBJECT IDENTIFIER ::= { sampleMIB 0 } sampleObjects OBJECT IDENTIFIER ::= { sampleMIB 1 } sampleConformance OBJECT IDENTIFIER ::= { sampleMIB 2 } sampleCompliances OBJECT IDENTIFIER ::= { sampleConformance 1 } sampleGroups OBJECT IDENTIFIER ::= { sampleConformance 2 } -- ---------------------------------------------------------- -- -- Textual Conventions -- ---------------------------------------------------------- -- -- All representations of MAC addresses in this MIB Module use, -- as a textual convention, the data type MacAddress, defined in -- SNMPv2-TC. -- Similarly, all representations of Sample-Id in this MIB -- module use, as a textual convention, the data type: SampleId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Sample-Identifier as used in the Sample Protocol to uniquely identify an entity. Its first two octets (in network byte order) contain a sample value and its last 6 octets contain the MAC address used to refer to an entity in a unique fashion (typically, the numerically smallest MAC address of all ports on the entity)." SYNTAX OCTET STRING (SIZE (8)) -- ---------------------------------------------------------- -- -- the sample1 group -- ---------------------------------------------------------- -- sample1 OBJECT IDENTIFIER ::= { sampleObjects 1 } sample1Address OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION Harrington Expires April 1, 2006 [Page 8] Internet-Draft MIB Module Template September 2005 "The MAC address used by this entity when it must be referred to in a unique fashion. It is recommended that this be the numerically smallest MAC address of all ports that belong to this entity. However it is only required to be unique. When concatenated with samplePriority a unique Sample Identifier is formed which is used in the Sample Protocol." REFERENCE "RFC CCCC clauses 14.4.1.1.3 and 7.12.5" ::= { sample1 1 } -- ---------------------------------------------------------- -- -- the sample999 group -- ---------------------------------------------------------- -- sample999 OBJECT IDENTIFIER ::= { sampleObjects 1 } sample999Address OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The MAC address used by this entity when it must be referred to in a unique fashion. It is recommended that this be the numerically smallest MAC address of all ports that belong to this entity. However it is only required to be unique. When concatenated with samplePriority a unique Sample Identifier is formed which is used in the Sample Protocol." REFERENCE "RFC CCCC clauses 14.4.1.1.3 and 7.12.5" ::= { sample999 1 } -- ---------------------------------------------------------- -- -- Notifications for use by Sample entities -- ---------------------------------------------------------- -- sampleNewRoot NOTIFICATION-TYPE -- OBJECTS { } STATUS current DESCRIPTION "This notification indicates that the sending entity has become the new root of the Sample Protocol coordination." ::= { sampleNotifications 1 } Harrington Expires April 1, 2006 [Page 9] Internet-Draft MIB Module Template September 2005 sampleLastChange NOTIFICATION-TYPE -- OBJECTS { } STATUS current DESCRIPTION "This notification is sent by an entity when any of its configured ports transitions from the Sample1 state to the Sample2 state, or from the Sample2 state to the Sample1 state. The notification is not sent if a sampleNewRoot notification is sent for the same transition." ::= { sampleNotifications 2 } - ---------------------------------------------------------- -- -- Sample MIB - Conformance Information -- ---------------------------------------------------------- -- - ---------------------------------------------------------- -- -- the sample999 group -- ---------------------------------------------------------- -- sample1Group OBJECT-GROUP OBJECTS { sample1Address } STATUS current DESCRIPTION "Sample1 information for this device." ::= { sampleGroups 1 } - ---------------------------------------------------------- -- -- the sample999 group -- ---------------------------------------------------------- -- sample999Group OBJECT-GROUP OBJECTS { sample999Address } STATUS current DESCRIPTION "Sample999 information for this device." ::= { sampleGroups 2 } -- ---------------------------------------------------------- -- -- The Sample Notification Group -- ---------------------------------------------------------- -- Harrington Expires April 1, 2006 [Page 10] Internet-Draft MIB Module Template September 2005 sampleNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { SampleNewRoot, sampleLastChange } STATUS current DESCRIPTION "Group of objects describing notifications." ::= { sampleGroups 2 } -- ---------------------------------------------------------- -- -- compliance statements -- ---------------------------------------------------------- -- sampleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for device support of Sample services. This supports the Sample999 features of the Sample Protocol" MODULE MANDATORY-GROUPS { sample1Group, sample999Group, sampleNotificationsGroup } GROUP sample1Group DESCRIPTION "Implementation of this group is mandatory." GROUP sample1Group DESCRIPTION "Implementation of this group is mandatory." GROUP sampleNotificationsGroup DESCRIPTION "Implementation of this group is mandatory." ::= { sampleCompliances 1 } sampleBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for devices supporting only Sample1 management" MODULE Harrington Expires April 1, 2006 [Page 11] Internet-Draft MIB Module Template September 2005 MANDATORY-GROUPS { sample1Group } GROUP sample1Group DESCRIPTION "Implementation of this group is mandatory for entities that support the Sample1 Protocol." ::= { sampleCompliances 2 } END 8. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Harrington Expires April 1, 2006 [Page 12] Internet-Draft MIB Module Template September 2005 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. IANA Considerations Option #1: The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- sampleMIB { mib-2 XXX } Option #2: Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for "XXX" under the 'mib-2' subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace "XXX" (here and in the MIB module) with the assigned value and to remove this note. Note well: prior to official assignment by the IANA, a draft document MUST use placeholders (such as "XXX" above) rather than actual numbers. See Section 4.5 for an example of how this is done in a draft MIB module. Option #3: This memo includes no request to IANA. Harrington Expires April 1, 2006 [Page 13] Internet-Draft MIB Module Template September 2005 10. Contributors This work is based on contributions from the MIb Doctors, including Dave Perkins and C.M.Heard for the section organization and Bert Wijnen for the 'include' statement format. 11. Acknowledgements Thanks to Marshall Rose for developing the XML2RFC format. Pekka Savola developed an XML2RFC template, upon which the MIB module template is based. Appendix A. Changes from RFC BBBB (the previous RFC for this specification) The following changes have been made from RFC BBBB. 1. Translated the MIB definitions to use SMIv2. This includes the introduction of conformance statements. ASN.1 type definitions have been converted into textual-conventions and several units clauses were added. 2. The sample999 group was added. 3. Permissible values for samplePriority have been clarified. 4. Interpretation of sampleLastChange has been clarified. 5. Updated the introductionary boilerplate text, the security considerations section and the references to comply with the current IETF standards and guidelines. 6. Additions and clarifications in various description clauses. Appendix B. Open Issues This list of open issues should be cleared and removed before this document hits the IESG. 1. Contributor addresses need to be updated 2. The interaction of sample1 and sample999 behaviors needs to be clarified. Harrington Expires April 1, 2006 [Page 14] Internet-Draft MIB Module Template September 2005 12. References 12.1. Normative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC_CCCC] Harrington, D., "SAMPLE Protocol Document", RFC CCCC, December 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "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. 12.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Harrington Expires April 1, 2006 [Page 15] Internet-Draft MIB Module Template September 2005 Author's Address David Harrington (editor) Effective Software Consulting 50 Harding Rd Portsmouth, NH 03801 USA Phone: +1 603 436 8634 EMail: dbharrington@comcast.net Full Copyright Statement Copyright (C) The Internet Society (2005). 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 Harrington Expires April 1, 2006 [Page 16] Internet-Draft MIB Module Template September 2005 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 currently provided by the Internet Society. Harrington Expires April 1, 2006 [Page 17]
- [xml2rfc] living on the edge Marshall Rose
- living on the edge [xml2rfc] Charles Levert
- living on the edge [xml2rfc] Charles Levert
- living on the edge [xml2rfc] David B Harrington
- [xml2rfc] living on the edge Bill Fenner
- living on the edge [xml2rfc] Bill Fenner
- [xml2rfc] living on the edge David B Harrington
- living on the edge [xml2rfc] Charles Levert
- living on the edge [xml2rfc] Bill Fenner