Internet DRAFT - draft-ietf-opsawg-data-model-doc-template
draft-ietf-opsawg-data-model-doc-template
Internet Engineering Task Force D. Harrington, Ed.
Internet-Draft Huawei Technologies (USA)
Intended status: Best Current February 11, 2008
Practice
Expires: August 14, 2008
A Template for Internet Drafts Containing Data Models
draft-ietf-opsawg-data-model-doc-template-00
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 August 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This memo contains two annotated templates for IETF documents that
contain the definition of data models. It is intended to alleviate
the work of the authors of such documents, making these more uniform
and easier to read and review, thus furthering the quality of such
documents and expediting their publication.
Harrington Expires August 14, 2008 [Page 1]
Internet-Draft Data Model Document Text Template February 2008
Note: Foreword to RFC Editor
Note to RFC Editor - throughout the templates in the appendices,
there are numerous sample requests for action by the RFC Editor that
should not be removed from the template before publication of the
template. These need to retain the RFC Editor requests to match the
boilerplate included in the template.
For simplicity, there are no notes to the RFC Editor in this document
that should be removed, except THIS section - the complete section
entitled "Note: Foreword to RFC Editor".
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . . 4
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 4
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 4
Appendix C. Text Template with Advice . . . . . . . . . . . . . . 4
Appendix D. Text Template without Advice . . . . . . . . . . . . 15
Harrington Expires August 14, 2008 [Page 2]
Internet-Draft Data Model Document Text Template February 2008
1. Introduction
This memo contains two annotated templates for IETF documents that
contain the definition of data models. It it intended to alleviate
the work of the authors of such documents, making these more uniform
and easier to read and review, thus furthering the quality of such
documents and expedite their publication.
2. Overview
The templates enclosed in this document were developed to make IETF
documents that contain data models more consistent. This makes it
easier to review the document. There are a number of MUSTs in the
document; these usually refer to IESG requirements for internet
drafts, and reviewers are likely to check for these requirements.
The template contains boilerplates for IETF data model documents.
Using the latest revision of this template should ensure that the
latest revision of the boilerplates are used, but the most up-to-date
revisions are available at http://www.ops.ietf.org/ and
http://www.rfc-editor.org/formatting.html.
The template contains sections that describe the purpose and
organization of the data model, and the relationship between this
data model and other data models. This makes it easier for reviewers
to understand the data model, which speeds the IESG approval process.
The document template does not include a template for the data model
itself. Tools to validate data models typically require that the
data model be separated from the surrounding document. The simplest
approach therefore is to develop the data model outside the document
that contains the surrounding text, and then include the data model
into the surrounding document written using this template.
An XML version of this template for use with xml2rfc is also
available at http://www.ops.ietf.org.
3. Security Considerations
This memo contans a template for editing; it has no impact on network
security.
4. IANA Considerations
This memo includes no request to IANA.
Harrington Expires August 14, 2008 [Page 3]
Internet-Draft Data Model Document Text Template February 2008
5. Contributors
This template is based on contributions from the MIB Doctors,
especially Bert Wijnen, Dan Romascanu, Juergen Schoenwaelder, Dave
Perkins, C.M.Heard and Randy Presuhn.
6. Normative References
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005.
Appendix A. Change Log
Changes from draft-harrington-text-mib-doc-template-04 to -00-
1. Changed all references to "MIB modules" to "data models"
2. Removed references to RFC4181
3. modified reference to mib-specific boilerplates to data-model
boilerplates
4. modified sections that refered to SNMP
5. rewrote sections as an envelope for the template.
Appendix B. Open Issues
Should this template be based on
draft-ietf-opsawg-operations-and-management.txt?
Should "data models" be changed to "management data models"?
Should "data models" be changed to "management information models" in
places, to reflect that there may be relationships between different
types of data models, such as Netconf data models, syslog SDEs, and
MIB modules?
need new Management Framework boilerplate
need Security Considerations for a Data Model document
need IANA boilerplate for non-MIB data models
Appendix C. Text Template with Advice
--- start of template ---
Harrington Expires August 14, 2008 [Page 4]
Internet-Draft Data Model Document Text Template February 2008
Internet Engineering Task Force Y. Name, Ed.
Internet-Draft Editor affiliation
Intended status: Historic February 11, 2008
Expires: August 14, 2008
Your data model document name
Your data model document name here
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 August 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
[[anchor1: This template is for authors of IETF specifications
containing data models. This template can be used as a starting
point to produce specifications that comply with the Operations &
Management Area guidelines for data model internet drafts.
Throughout the template, the marker "[TEMPLATE TODO]" is used as a
placeholder to indicate an element or text that requires replacement
or removal. All the places with [TEMPLATE TODO] markers should be
replaced or removed before the document is submitted.]]
Harrington Expires August 14, 2008 [Page 5]
Internet-Draft Data Model Document Text Template February 2008
This memo defines a portion of the Network Management Information
Base (NMIB) for use with network management protocols. In particular
it defines objects for managing [TEMPLATE TODO].
[[anchor2: [TEMPLATE TODO]: describe what functionality will be
managed using this data model. It can be good to mention the
protocol being managed, and whether there is a particular aspect of
the protocol to be managed, or a particular goal of the model. But
keep it brief. Remember, don't put any citations in the abstract,
and expand your acronyms.]]
Foreword to template users
This template helps authors write the surrounding text needed in a
data model internet draft, but does not provide a template for
writing the data model itself.
Throughout this template, the marker "[TEMPLATE TODO]" is used as a
reminder to the template user to indicate an element or text that
requires replacement or removal by the template user before
submission to the internet draft editor. All [TEMPLATE TODO] markers
should be resolved and removed before you submit your document to the
internet-draft editor.
For updated information on data model guidelines and templates, see
[RFC4181] and 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.
This template is not meant to be a complete list of everything needed
to write data model internet drafts, but to summarize the often-
needed basic features to get a document containing a data model
started. An important purpose of the template is to aid authors in
developing an internet draft that is laid out in a manner consistent
with other internet drafts containing data models. Internet drafts
submitted for advancement to the standards track typically require
review by various directorates and expert reviewers. This template
standardizes the layout and naming of sections, includes the
appropriate boilerplate text, and facilitates the development of
tools to automate the checking of data model internet drafts, to
speed the WG and IESG review processes.
An XML template is also available. For information on XML2RFC, see
RFC2629 [RFC2629],
http://xml.resource.org/public/rfc/html/rfc2629.html and "bis":
Harrington Expires August 14, 2008 [Page 6]
Internet-Draft Data Model Document Text Template February 2008
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html.
Also see http://xml.resource.org/authoring/README.html for 'rfc'
option strings. The benefit of using the XML version of the template
is that comments in the XML describe how to fill in each section of
the template, and then XML2RFC will generate the actual internet-
draft with your information. XML2RFC automatically handles much of
the boilerplate, references, and idnits issues for you.
[TEMPLATE TODO] THIS section, the complete section entitled "Note:
Foreword to template users" should be removed by the template user
from their document before submission.
[TEMPLATE TODO] Remove all page headings from the template document,
and replace them with the appropriate headings for your internet
draft.
Note to RFC Editor re: [TEMPLATE TODO] markers
Note to RFC Editor: When a document is developed using this template,
the editor of the document should replace or remove all the places
marked [TEMPLATE TODO] before submitting the document. If there are
still [TEMPLATE TODO] markers, please send the document back to the
editor.
Table of Contents
1. Introduction
2. The Internet-Standard Management Framework
3. Conventions
4. Overview
5. Structure of the Data Model
5.1. New Data Types
5.2. The [TEMPLATE TODO] Subtree
5.3. The Notifications Subtree
5.4. The Table Structures
6. Relationship to Other Data Models
6.1. Relationship to the [TEMPLATE TODO] Data Model
6.2. Data Models required for IMPORTS
7. Definitions
8. Security Considerations
9. IANA Considerations
10. Contributors
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Change Log
Appendix B. Open Issues
Harrington Expires August 14, 2008 [Page 7]
Internet-Draft Data Model Document Text Template February 2008
1. Introduction
This memo defines a portion of the Network Management Information
Base (NMIB) for use with network management protocols. In particular
it defines a data model for managing the [TEMPLATE TODO]
[[anchor4: [TEMPLATE TODO]: describe what functionality will be
managed using this data model. Include citations for protocol
specifications, architectures, related data models, and protocol-
specific management requirements. Provide an overview of why a data
model is appropriate for this protocol, whether there is a particular
aspect of the protocol to be managed, and how the model is expected
to be used to achieve particular goals. Highlight anything
'different' about the model. For example, a read-only data model.]]
2. The Internet-Standard Management Framework
[[anchor6: The title and text for this section has been copied from
the official boilerplate, and should not be modified unless the
boilerplate text at http;//ops.ietf.org has changed. See RFC4181
section 3.1 for a discussion of the boilerplate section.]]
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 Network Management Information Base or NMIB.
The SMIv2 MIB is a subset of the NMIB. 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). SMIv2 is described in STD
58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC
2580 [RFC2580].
NMIB objects may be accessed through other protocols, such as the
Network Configuration Protocol (Netconf). Objects in the NMIB are
defined using the mechanisms defined in the Structure of Management
Information (SMI). This memo specifies a data model that is
compliant to the [DISCUSS].
3. Conventions
[[anchor8: [TEMPLATE TODO] This boilerplate should be used if the
RFC2119 key words are used in the internet draft. The text in this
section has been copied from the official boilerplate, and should not
be modified.]]
Harrington Expires August 14, 2008 [Page 8]
Internet-Draft Data Model Document Text Template February 2008
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
4. Overview
[[anchor10: [TEMPLATE TODO] The narrative part should include an
overview section that describes the scope and field of application of
the data models defined by the specification. See RFC4181 section
3.2 for a discussion of the Narrative section.]]
5. Structure of the Data Model
[[anchor12: [TEMPLATE TODO] The narrative part SHOULD include one or
more sections to briefly describe the structure of the data models
defined in the specification.]]
5.1. New Data Types
[[anchor14: [TEMPLATE TODO] describe any data types defined in the
data model, and their purpose. It may be helpful to highlight any
textual conventions data types imported from partner documents.
Generic and Common Data Types can be found summarized at
http://www.ops.ietf.org/common-datatypes.html. [DISCUSS: need to
craete the appropriate web pages for ops.ietf.org.] If there are no
new data types defined in your data model, this section should say
so.]]
5.2. The [TEMPLATE TODO] Subtree
[[anchor16: [TEMPLATE TODO] copy this section for each subtree in the
data model, and describe the purpose of the subtree. For example,
"The fooStats subtree provides information for identifying fault
conditions and performance degradation of the foo functionality."]]
5.3. The Notifications Subtree
[[anchor18: [TEMPLATE TODO] describe the notifications defined in the
data model, and their purpose. Include a discussion of congestion
control. You might want to discuss throttling as well. See RFC2914.
If there are no notifications defined in your data model, this
section should say so.]]
5.4. The Table Structures
[[anchor20: [TEMPLATE TODO] Describe the tables in the data model,
their purpose, and their relationship to each other. Has the data
model been normalized? e.g., If the row in one table is related to a
Harrington Expires August 14, 2008 [Page 9]
Internet-Draft Data Model Document Text Template February 2008
row in another table, what happens when one of the rows is deleted?
Should the related row be deleted as well? If a row is added to one
table, does this have implications for the other tables? Consider
both directions.]]
6. Relationship to Other Data Models
[[anchor22: [TEMPLATE TODO]: The narrative part should include a
section that specifies the relationship (if any) of the data models
contained in this internet draft to other standards, particularly to
standards containing other data models. If the data models defined
by the specification import definitions from other data models or are
always implemented in conjunction with other data models, then those
facts should be noted in the narrataive section, as should any
special interpretations of objects in other data models. Note that
citations may NOT be put into the data model portions of the internet
draft, but documents used for Imported items are Normative
References, so the citations should exist in the narrative section of
the internet draft. The preferred way to fill in a REFERENCE clause
withnin a data model is of the form: "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC2434, section 2.3.]]
6.1. Relationship to the [TEMPLATE TODO] Data Model
[[anchor24: Example: The Interface data model [RFC2863] requires that
any data model which is an adjunct of the Interface data model
clarify specific areas within the Interface data model. These areas
were intentionally left vague in the Interface data model to avoid
over-constraining the data model, thereby precluding management of
certain media-types. Section 4 of [RFC2863] enumerates several areas
which a media-specific data model must clarify. The implementor is
referred to [RFC2863] in order to understand the general intent of
these areas.]]
6.2. Data Models required for IMPORTS
[[anchor26: [TEMPLATE TODO]: Citations are not permitted within a
data model, but any model mentioned in an IMPORTS clause or document
mentioned in a REFERENCE clause is a Normative reference, and must be
cited someplace within the narrative sections. If there are imported
items in the data model, such as data types, that are not already
cited, they can be cited in text here. Since relationships to other
data models should be described in the narrative text, this section
is typically used to cite models from which data types are imported.
Example: "The following data model IMPORTS objects from SNMPv2-SMI
[RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], and IF-MIB
[RFC2863]."]]
Harrington Expires August 14, 2008 [Page 10]
Internet-Draft Data Model Document Text Template February 2008
7. Definitions
[[anchor28: This section contains the actual data model(s). These
data models MUST conform to the guidelines for data modeling langauge
usage and naming conventions, as described in RFC XXXX.]]
[TEMPLATE TODO]: put your valid data model here.
A list of tools that can help automate the process of
validating data model definitions can be found at
http://tools.ietf.org
8. Security Considerations
[[anchor30: [TEMPLATE TODO] Each internet draft that defines one or
more data models MUST contain a section that discusses security
considerations relevant to those models. This section MUST be
patterned after the latest approved template (available at
http://www.ops.ietf.org/data-model-security.html).]]
[[anchor31: [TEMPLATE TODO] if your data model permits modifying
objects at runtime, including creating or deleting instances, please
include the following boilerplate paragraph, and list.the objects and
their sensitivity.]]
There are a number of management objects defined in this data model
which can be modified and/or created and/or deleted at runtime. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for such operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the structures and objects and their
sensitivity/vulnerability:
o
[[anchor32: [TEMPLATE TODO] else if there are no modifiable objects
in your data model, use the following boilerplate paragraph.]]
There are no management objects defined in this data model that can
be created, deleted, or modified at runtime. If this data model is
implemented correctly, there is no risk that an intruder can alter or
create any management objects of this data model.
[[anchor33: For all data models you must evaluate whether any
readable objects are sensitive or vulnerable (for instance, if they
might reveal customer information or violate personal privacy laws
such as those of the European Union if exposed to unathorized
parties). If so, please include the following boilerplate
paragraph.]]
Harrington Expires August 14, 2008 [Page 11]
Internet-Draft Data Model Document Text Template February 2008
Some of the readable objects in this data model may be considered
sensitive or vulnerable in some network environments. It is
important to control access to these data objects and possibly to
encrypt the values of these objects when sending them over the
network. These are the structures and objects and their sensitivity/
vulnerability:
o
o [[anchor34: [TEMPLATE TODO] you should explicitly list by name any
readable objects that are sensitive or vulnerable and the
associated security risks should be spelled out.]]
[[anchor35: [TEMPLATE TODO] The following three boilerplate
paragraphs should not be changed without very good reason. Changes
will almost certainly require justification during IESG review.]]
Versions of management protocols might not include adequate security.
Even if the network itself is secure (for example by using IPsec),
there is no control as to who on the secure network is allowed to
create, modify, or read the objects in this data model.
It is RECOMMENDED that implementers support security features
including cryptographic mechanisms for authentication, integrity
checking, confidentiality, and data access controls.
It is RECOMMENDED that operators deploy management protocols with
security features including authentication, integrity checking,
confidentiality, and data access controls.and to enable the security
features. It is then a customer/operator responsibility to ensure
that the entity giving access to an instance of this data model is
properly configured to give access only to those principals (users)
that have legitimate rights to create, modify, delete, or read the
objects in this data model.
9. IANA Considerations
[[anchor37: [TEMPLATE TODO] In order to comply with IESG policy as
set forth in http://www.ietf.org/ID-Checklist.html, every Internet-
Draft that is submitted to the IESG for publication MUST contain an
IANA Considerations section. The requirements for this section vary
depending what actions are required of the IANA. See "Guidelines for
Writing an IANA Considerations Section in RFCs" [RFC2434]. and see
RFC4181 section 3.5 for more information on writing an IANA clause
for a data model internet draft.]]
Option #1:
Harrington Expires August 14, 2008 [Page 12]
Internet-Draft Data Model Document Text Template February 2008
The data model in this document uses the following IANA
assignment recorded in the [TEMPLATE TODO] registry:
Option #2:
Editor's Note (to be removed prior to publication): the IANA is
requested to assign a value for "XXX" and to record the assignment in
the [TEMPLATE TODO] registry. When the assignment has been made, the
RFC Editor is asked to replace "XXX" (here and in the data model)
with the assigned value and to remove this note.
Note well: prior to official assignment by the IANA, an internet
draft MUST use placeholders (such as "XXX" above) rather than actual
names or numbers.
Option #3:
This memo includes no request to IANA.
10. Contributors
11. References
11.1. Normative References
[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.
11.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.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
Harrington Expires August 14, 2008 [Page 13]
Internet-Draft Data Model Document Text Template February 2008
June 1999.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005.
Appendix A. Change Log
This optional section should be removed before the internet draft is
submitted to the IESG for publication as an RFC.
Appendix B. Open Issues
[[anchor43: [TEMPLATE TODO] This list of issues listed in this
optional section should be cleared and removed, and this optional
section should be removed before the internet draft is submitted to
the IESG for publication as an RFC.]]
Author's Address
Editor name (editor)
Editor affiliation
Editor affiliation address
Editor affiliation address
Editor affiliation address
Phone: Editor address
EMail: Editor email
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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
Harrington Expires August 14, 2008 [Page 14]
Internet-Draft Data Model Document Text Template February 2008
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).
---- end of template ---
Appendix D. Text Template without Advice
--- start of template ---
Internet Engineering Task Force Y. Name, Ed.
Internet-Draft Editor affiliation
Intended status: Historic February 11, 2008
Expires: August 14, 2008
Your data model document name
Your data model document name here
Status of This Memo
By submitting this Internet-Draft, each author represents that any
Harrington Expires August 14, 2008 [Page 15]
Internet-Draft Data Model Document Text Template February 2008
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 August 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This memo defines a portion of the Network Management Information
Base (NMIB) for use with network management protocols. In particular
it defines objects for managing [TEMPLATE TODO].
Foreword to template users
This template helps authors write the surrounding text needed in a
data model internet draft, but does not provide a template for
writing the data model itself.
Throughout this template, the marker "[TEMPLATE TODO]" is used as a
reminder to the template user to indicate an element or text that
requires replacement or removal by the template user before
submission to the internet draft editor. All [TEMPLATE TODO] markers
should be resolved and removed before you submit your document to the
internet-draft editor.
For updated information on data model guidelines and templates, see
[RFC4181] and http://www.ops.ietf.org/.
Harrington Expires August 14, 2008 [Page 16]
Internet-Draft Data Model Document Text Template February 2008
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.
This template is not meant to be a complete list of everything needed
to write data model internet drafts, but to summarize the often-
needed basic features to get a document containing a data model
started. An important purpose of the template is to aid authors in
developing an internet draft that is laid out in a manner consistent
with other internet drafts containing data models. Internet drafts
submitted for advancement to the standards track typically require
review by various directorates and expert reviewers. This template
standardizes the layout and naming of sections, includes the
appropriate boilerplate text, and facilitates the development of
tools to automate the checking of data model internet drafts, to
speed the WG and IESG review processes.
An XML template is also available. For information on XML2RFC, see
RFC2629 [RFC2629],
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. The benefit of using the XML version of the template
is that comments in the XML describe how to fill in each section of
the template, and then XML2RFC will generate the actual internet-
draft with your information. XML2RFC automatically handles much of
the boilerplate, references, and idnits issues for you.
[TEMPLATE TODO] THIS section, the complete section entitled "Note:
Foreword to template users" should be removed by the template user
from their document before submission.
[TEMPLATE TODO] Remove all page headings from the template document,
and replace them with the appropriate headings for your internet
draft.
Note to RFC Editor re: [TEMPLATE TODO] markers
Note to RFC Editor: When a document is developed using this template,
the editor of the document should replace or remove all the places
marked [TEMPLATE TODO] before submitting the document. If there are
still [TEMPLATE TODO] markers, please send the document back to the
editor.
Table of Contents
1. Introduction
Harrington Expires August 14, 2008 [Page 17]
Internet-Draft Data Model Document Text Template February 2008
2. The Internet-Standard Management Framework
3. Conventions
4. Overview
5. Structure of the Data Model
5.1. New Data Types
5.2. The [TEMPLATE TODO] Subtree
5.3. The Notifications Subtree
5.4. The Table Structures
6. Relationship to Other Data Models
6.1. Relationship to the [TEMPLATE TODO] Data Model
6.2. Data Models required for IMPORTS
7. Definitions
8. Security Considerations
9. IANA Considerations
10. Contributors
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Change Log
Appendix B. Open Issues
1. Introduction
This memo defines a portion of the Network Management Information
Base (NMIB) for use with network management protocols. In particular
it defines a data model for managing the [TEMPLATE TODO]
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 Network Management Information Base or NMIB.
The SMIv2 MIB is a subset of the NMIB. 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). SMIv2 is described in STD
58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC
2580 [RFC2580].
NMIB objects may be accessed through other protocols, such as the
Network Configuration Protocol (Netconf). Objects in the NMIB are
defined using the mechanisms defined in the Structure of Management
Information (SMI). This memo specifies a data model that is
compliant to the [DISCUSS].
Harrington Expires August 14, 2008 [Page 18]
Internet-Draft Data Model Document Text Template February 2008
3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
4. Overview
5. Structure of the Data Model
5.1. New Data Types
5.2. The [TEMPLATE TODO] Subtree
5.3. The Notifications Subtree
5.4. The Table Structures
6. Relationship to Other Data Models
6.1. Relationship to the [TEMPLATE TODO] Data Model
6.2. Data Models required for IMPORTS
7. Definitions
[TEMPLATE TODO]: put your valid data model here.
A list of tools that can help automate the process of
validating data model definitions can be found at
http://tools.ietf.org
8. Security Considerations
There are a number of management objects defined in this data model
which can be modified and/or created and/or deleted at runtime. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for such operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the structures and objects and their
sensitivity/vulnerability:
o
There are no management objects defined in this data model that can
be created, deleted, or modified at runtime. If this data model is
implemented correctly, there is no risk that an intruder can alter or
create any management objects of this data model.
Harrington Expires August 14, 2008 [Page 19]
Internet-Draft Data Model Document Text Template February 2008
Some of the readable objects in this data model may be considered
sensitive or vulnerable in some network environments. It is
important to control access to these data objects and possibly to
encrypt the values of these objects when sending them over the
network. These are the structures and objects and their sensitivity/
vulnerability:
o
o
Versions of management protocols might not include adequate security.
Even if the network itself is secure (for example by using IPsec),
there is no control as to who on the secure network is allowed to
create, modify, or read the objects in this data model.
It is RECOMMENDED that implementers support security features
including cryptographic mechanisms for authentication, integrity
checking, confidentiality, and data access controls.
It is RECOMMENDED that operators deploy management protocols with
security features including authentication, integrity checking,
confidentiality, and data access controls.and to enable the security
features. It is then a customer/operator responsibility to ensure
that the entity giving access to an instance of this data model is
properly configured to give access only to those principals (users)
that have legitimate rights to create, modify, delete, or read the
objects in this data model.
9. IANA Considerations
Option #1:
The data model in this document uses the following IANA
assignment recorded in the [TEMPLATE TODO] registry:
Option #2:
Editor's Note (to be removed prior to publication): the IANA is
requested to assign a value for "XXX" and to record the assignment in
the [TEMPLATE TODO] registry. When the assignment has been made, the
RFC Editor is asked to replace "XXX" (here and in the data model)
with the assigned value and to remove this note.
Note well: prior to official assignment by the IANA, an internet
draft MUST use placeholders (such as "XXX" above) rather than actual
Harrington Expires August 14, 2008 [Page 20]
Internet-Draft Data Model Document Text Template February 2008
names or numbers.
Option #3:
This memo includes no request to IANA.
10. Contributors
11. References
11.1. Normative References
[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.
11.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.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005.
Appendix A. Change Log
This optional section should be removed before the internet draft is
submitted to the IESG for publication as an RFC.
Appendix B. Open Issues
Author's Address
Harrington Expires August 14, 2008 [Page 21]
Internet-Draft Data Model Document Text Template February 2008
Editor name (editor)
Editor affiliation
Editor affiliation address
Editor affiliation address
Editor affiliation address
Phone: Editor address
EMail: Editor email
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Harrington Expires August 14, 2008 [Page 22]
Internet-Draft Data Model Document Text Template February 2008
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
---- end of template ---
Author's Address
David Harrington (editor)
Huawei Technologies (USA)
1700 Alma Drive, Suite 100
Plano, TX 75075
USA
Phone: +1 603 436 8634
EMail: dharrington@huawei.com
Harrington Expires August 14, 2008 [Page 23]
Internet-Draft Data Model Document Text Template February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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).
Harrington Expires August 14, 2008 [Page 24]
