idnits 2.17.1 draft-ietf-ccamp-gmpls-tc-mib-09.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 380. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 2005) is 6768 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RCF2578' is mentioned on line 102, but not defined == Missing Reference: 'RFC2434' is mentioned on line 265, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3946 (Obsoleted by RFC 4606) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Thomas D. Nadeau, Ed. 3 Internet Draft Cisco Systems, Inc. 4 Proposed Status: Standards Track 5 Expires: April 2006 Adrian Farrel, Ed. 6 Old Dog Consulting 8 October 2005 10 Definitions of Textual Conventions for Generalized Multiprotocol 11 Label Switching (GMPLS) Management 13 draft-ietf-ccamp-gmpls-tc-mib-09.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be 36 accessed at http://www.ietf.org/shadow.html. 38 Abstract 40 This document defines a Management Information Base (MIB) module 41 which contains Textual Conventions to represent commonly used 42 Generalized Multiprotocol Label Switching (GMPLS) management 43 information. The intent is that these TEXTUAL CONVENTIONS (TCs) will 44 be imported and used in GMPLS related MIB modules that would 45 otherwise define their own representations. 47 Table of Contents 49 1. Introduction ...................................... 2 50 2. The Internet-Standard Management Framework ........ 2 51 3. GMPLS Textual Conventions MIB Definitions ......... 3 52 4. Security Considerations ........................... 6 53 5. IANA Considerations ............................... 6 54 6. References ........................................ 6 55 6.1. Normative References ............................ 6 56 6.2. Informative References .......................... 7 57 7. Acknowledgements .................................. 7 58 8. Contact Information ............................... 7 59 9. Intellectual Property Considerations .............. 8 60 10. Full Copyright Statement ......................... 9 62 1. Introduction 64 This document defines a MIB module which contains Textual Conventions 65 for Generalized Multiprotocol Label Switching (GMPLS) networks. These 66 Textual Conventions should be imported by MIB modules which manage 67 GMPLS networks. 69 This MIB module supplements the MIB module in [RFC3811] that defines 70 Textual Conventions for Multiprotocol Label Switching (MPLS) 71 Management. [RFC3811] may continue to be used without this MIB module 72 in networks that support only MPLS. 74 Comments should be made directly to the CCAMP mailing list at 75 ccamp@ops.ietf.org. 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in BCP 14, RFC 2119, 80 reference [RFC2119]. 82 For an introduction to the concepts of GMPLS, see [RFC3945]. 84 2. The Internet-Standard Management Framework 86 For a detailed overview of the documents that describe the current 87 Internet-Standard Management Framework, please refer to section 7 of 88 RFC 3410 [RFC3410]. 90 Managed objects are accessed via a virtual information store, termed 91 the Management Information Base or MIB. MIB objects are generally 92 accessed through the Simple Network Management Protocol (SNMP). 93 Objects in the MIB are defined using the mechanisms defined in the 94 Structure of Management Information (SMI). This memo specifies a MIB 95 module that is compliant to the SMIv2, which is described in STD 58, 96 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 97 [RFC2580]. 99 3. GMPLS Textual Conventions MIB Definitions 101 This MIB module makes references to the following documents. 102 [RCF2578], [RFC2579], [RFC3471], [RFC3946] and [RFC3811]. 104 GMPLS-TC-STD-MIB DEFINITIONS ::= BEGIN 106 IMPORTS 107 MODULE-IDENTITY 108 FROM SNMPv2-SMI -- RFC2578 109 TEXTUAL-CONVENTION 110 FROM SNMPv2-TC -- RFC2579 111 mplsStdMIB 112 FROM MPLS-TC-STD-MIB -- RFC3811 113 ; 115 gmplsTCStdMIB MODULE-IDENTITY 116 LAST-UPDATED 117 "200510130001Z" -- 13 October 2005 00:00:01 GMT 118 ORGANIZATION 119 "IETF Common Control And Measurement Plane (CCAMP) Working Group" 120 CONTACT-INFO 121 " Thomas D. Nadeau 122 Cisco Systems, Inc. 123 Email: tnadeau@cisco.com 125 Adrian Farrel 126 Old Dog Consulting 127 Email: adrian@olddog.co.uk 129 Comments about this document should be emailed direct to the 130 CCAMP working group mailing list at ccamp@ops.ietf.org" 131 DESCRIPTION 132 "Copyright (C) The Internet Society (2005). This version of 133 this MIB module is part of RFC XXX; see the RFC itself for 134 full legal notices. 135 -- RFC Editor. Please replace XXX above with the correct RFC number and 136 -- remove this note. 138 This MIB module defines TEXTUAL-CONVENTIONs for concepts used in 139 Generalized Multiprotocol Label Switching (GMPLS) networks." 140 REVISION 141 "200510130001Z" -- 13 October 2005 00:00:01 GMT 142 DESCRIPTION 143 -- RFC Editor: Please see the IANA Considerations Section. 144 -- This MIB module is contained in the OID sub-tree 145 -- rooted at mplsStdMIB. 146 "Initial version published as part of RFC XXX." 147 ::= { mplsStdMIB YYY } 149 -- RFC Editor. Please replace XXX above with the correct RFC number and 150 -- remove this note. 152 -- RFC Editor. Please replace YYY above with the OID assigned by IANA 153 -- and remove this note 155 GmplsFreeformLabelTC ::= TEXTUAL-CONVENTION 156 STATUS current 157 DESCRIPTION 158 "This Textual Convention can be used as the syntax of an object 159 that contains any GMPLS label. Objects with this syntax can be 160 used to represent labels that have label types that are not 161 defined in any RFCs. The freeform GMPLS Label may also be used 162 by systems that do not wish to represent labels that have 163 label types defined in RFCs using type-specific syntaxes." 164 REFERENCE 165 "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling 166 Functional Description, RFC 3471, section 3.2." 167 SYNTAX OCTET STRING (SIZE (0..64)) 169 GmplsLabelTypeTC ::= TEXTUAL-CONVENTION 170 STATUS current 171 DESCRIPTION 172 "Determines the interpretation that should be applied to an 173 object that encodes a label. The possible types are: 175 gmplsMplsLabel(1) - The label is an MPLS packet, cell, 176 or frame label and is encoded as 177 described for the Textual 178 Convention MplsLabel defined in 179 RFC 3811. 181 gmplsPortWavelengthLabel(2) - The label is a port or wavelength 182 label as defined in RFC 3471. 184 gmplsFreeformLabel(3) - The label is any form of label 185 encoded as an OCTET STRING using 186 the Textual Convention 187 GmplsFreeformLabel. 189 gmplsSonetLabel(4) - The label is a SONET label as 190 defined in RFC 3946. 192 gmplsSdhLabel(5) - The label is an SDH label as 193 defined in RFC 3946. 195 gmplsWavebandLabel(6) - The label is a waveband label as 196 defined in RFC 3471." 197 REFERENCE 198 "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling 199 Functional Description, RFC 3471, section 3. 200 2. Definition of Textual Conventions and for Multiprotocol Label 201 Switching (MPLS) Management, RFC 3811, section 3. 202 3. Generalized Multi-Protocol Label Switching (GMPLS) Extensions 203 for Synchronous Optical Network (SONET) and Synchronous 204 Digital Hierarchy (SDH) Control, RFC 3946, section 3." 205 SYNTAX INTEGER { 206 gmplsMplsLabel(1), 207 gmplsPortWavelengthLabel(2), 208 gmplsFreeformGeneralizedLabel(3), 209 gmplsSonetLabel(4), 210 gmplsSdhLabel(5), 211 gmplsWavebandLabel(6) 212 } 214 GmplsSegmentDirectionTC ::= TEXTUAL-CONVENTION 215 STATUS current 216 DESCRIPTION 217 "The direction of data flow on an LSP segment with respect to the 218 head of the LSP. 220 Where an LSP is signaled using a conventional signaling 221 protocol, the 'head' of the LSP is the source of the signaling 222 (also known as the ingress) and the 'tail' is the destination 223 (also known as the egress). For unidirectional LSPs, this 224 usually matches the direction of flow of data. 226 For manually configured unidirectional LSPs the direction of the 227 LSP segment matches the direction of flow of data. For manually 228 configured bidirecitonal LSPs, an arbitrary decision must be 229 made about which LER is the 'head'." 230 SYNTAX INTEGER { 231 forward(1), -- data flows from head-end of LSP toward tail-end 232 reverse(2) -- data flows from tail-end of LSP toward head-end 233 } 235 END 237 4. Security Considerations 239 This module does not define any management objects. Instead, it 240 defines a set of textual conventions which may be used by other GMPLS 241 MIB modules to define management objects. 243 Meaningful security considerations can only be written in the MIB 244 modules that define management objects. Therefore, this document has 245 no impact on the security of the Internet. 247 5. IANA Considerations 249 -- (Note to RFC-Editor:) 250 -- We request that you assign contiguous RFC numbers to the three GMPLS 251 -- MIB documents. 252 -- The first number to draft-ietf-ccamp-gmpls-tc-mib, the second to 253 -- draft-ietf-ccamp-gmpls-lsr-mib, and the third to 254 -- draft-ietf-ccamp-gmpls-te-mib. 255 -- (Please remove this note prior to publication.) 257 IANA is requested to root MIB objects in this MIB module under the 258 mplsStdMIB subtree by assigning an OID to gmplsTCStdMIB currently 259 indicated by { mplsStdMIB YYY }. 261 In the future, GMPLS related standards track MIB modules should be 262 rooted under the mplsStdMIB (sic) subtree. IANA has been requested to 263 manage that namespace in the SMI Numbers registry [RFC3811]. New 264 assignments can only be made via a Standards Action as specified in 265 [RFC2434]. 267 -- RFC Editor. Please replace YYY above with the OID assigned by IANA 268 -- and remove this note. 270 6. References 272 6.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirements Levels", BCP 14, RFC 2119, March 1997. 277 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 278 J., Rose, M., and S. Waldbusser, "Structure of 279 Management Information Version 2 (SMIv2)", STD 58, RFC 280 2578, April 1999. 282 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 283 J., Rose, M., and S. Waldbusser, "Textual Conventions 284 for SMIv2", STD 58, RFC 2579, April 1999. 286 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 287 J., Rose, M., and S. Waldbusser, "Conformance Statements 288 for SMIv2", STD 58, RFC 2580, April 1999. 290 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 291 (GMPLS) Signaling Functional Description", RFC 3471, 292 January 2003. 294 [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual 295 Conventions and for Multiprotocol Label Switching (MPLS) 296 Management", RFC 3811, June 2004. 298 [RFC3946] Mannie, E. and D. Papadimitriou, "Generalized Multi- 299 Protocol Label Switching (GMPLS) Extensions for 300 Synchronous Optical Network (SONET) and Synchronous 301 Digital Hierarchy (SDH) Control", RFC 3946, October 302 2004. 304 6.2. Informative References 306 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 307 "Introduction and Applicability Statements for 308 Internet-Standard Management Framework", RFC 3410, 309 December 2002. 311 [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label 312 Switching (GMPLS) Architecture", RFC 3945, October 2004. 314 7. Acknowledgements 316 This document is a product of the CCAMP Working Group. 318 Special thanks to Joan Cucchiara for her help with compilation 319 issues and her very thorough MIB Doctor review. Thanks also to 320 Bert Wijnen, David Harrington and Harrie Hazewinkel for their review 321 comments. 323 8. Contact Information 325 Thomas D. Nadeau 326 Cisco Systems, Inc. 327 1414 Massachusetts Ave. 328 Boxborough, MA 01719 329 Email: tnadeau@cisco.com 331 Adrian Farrel 332 Old Dog Consulting 333 Phone: +44 1978 860944 334 Email: adrian@olddog.co.uk 335 Cheenu Srinivasan 336 Bloomberg L.P. 337 731 Lexington Ave. 338 New York, NY 10022 339 Phone: +1-212-617-3682 340 Email: cheenu@bloomberg.net 342 Tim Hall 343 Data Connection Ltd. 344 100 Church Street 345 Enfield, Middlesex 346 EN2 6BQ, UK 347 Phone: +44 20 8366 1177 348 Email: tim.hall@dataconnection.com 350 Ed Harrison 351 Data Connection Ltd. 352 100 Church Street 353 Enfield, Middlesex 354 EN2 6BQ, UK 355 Phone: +44 20 8366 1177 356 Email: ed.harrison@dataconnection.com 358 9. Intellectual Property Considerations 360 The IETF takes no position regarding the validity or scope of any 361 Intellectual Property Rights or other rights that might be claimed to 362 pertain to the implementation or use of the technology described in 363 this document or the extent to which any license under such rights 364 might or might not be available; nor does it represent that it has 365 made any independent effort to identify any such rights. Information 366 on the procedures with respect to rights in RFC documents can be 367 found in BCP 78 and BCP 79. 369 Copies of IPR disclosures made to the IETF Secretariat and any 370 assurances of licenses to be made available, or the result of an 371 attempt made to obtain a general license or permission for the use of 372 such proprietary rights by implementers or users of this 373 specification can be obtained from the IETF on-line IPR repository at 374 http://www.ietf.org/ipr. 376 The IETF invites any interested party to bring to its attention any 377 copyrights, patents or patent applications, or other proprietary 378 rights that may cover technology that may be required to implement 379 this standard. Please address the information to the IETF at ietf- 380 ipr@ietf.org. 382 10. Full Copyright Statement 384 Copyright (C) The Internet Society (2005). This document is subject 385 to the rights, licenses and restrictions contained in BCP 78, and 386 except as set forth therein, the authors retain all their rights. 388 This document and the information contained herein are provided on an 389 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 390 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 391 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 392 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 393 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 394 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.