idnits 2.17.1 draft-ietf-ccamp-gmpls-tc-mib-08.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 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 381. ** 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 6739 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 266, 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-08.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 "200505200001Z" -- 20 May 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 "200505200001Z" -- 20 May 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 ::= { mib-2 YYY } 148 ::= { mplsStdMIB YYY } 150 -- RFC Editor. Please replace XXX above with the correct RFC number and 151 -- remove this note. 153 -- RFC Editor. Please replace YYY above with the OID assigned by IANA 154 -- and remove this note 156 GmplsFreeformLabel ::= TEXTUAL-CONVENTION 157 STATUS current 158 DESCRIPTION 159 "This Textual Convention can be used as the syntax of an object 160 that contains any GMPLS label. Objects with this syntax can be 161 used to represent labels that have label types that are not 162 defined in any RFCs. The freeform GMPLS Label may also be used 163 by systems that do not wish to represent labels that have 164 label types defined in RFCs using type-specific syntaxes." 165 REFERENCE 166 "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling 167 Functional Description, RFC 3471, section 3.2." 168 SYNTAX OCTET STRING (SIZE (0..64)) 170 GmplsLabelType ::= TEXTUAL-CONVENTION 171 STATUS current 172 DESCRIPTION 173 "Determines the interpretation that should be applied to an 174 object that encodes a label. The possible types are: 176 gmplsMplsLabel(1) - The label is an MPLS packet, cell, 177 or frame label and is encoded as 178 described for the Textual 179 Convention MplsLabel defined in 180 RFC 3811. 182 gmplsPortWavelengthLabel(2) - The label is a port or wavelength 183 label as defined in RFC 3471. 185 gmplsFreeformLabel(3) - The label is any form of label 186 encoded as an OCTET STRING using 187 the Textual Convention 188 GmplsFreeformLabel. 190 gmplsSonetLabel(4) - The label is a SONET label as 191 defined in RFC 3946. 193 gmplsSdhLabel(5) - The label is an SDH label as 194 defined in RFC 3946. 196 gmplsWavebandLabel(6) - The label is a waveband label as 197 defined in RFC 3471." 198 REFERENCE 199 "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling 200 Functional Description, RFC 3471, section 3. 201 2. Definition of Textual Conventions and for Multiprotocol Label 202 Switching (MPLS) Management, RFC 3811, section 3. 203 3. Generalized Multi-Protocol Label Switching (GMPLS) Extensions 204 for Synchronous Optical Network (SONET) and Synchronous 205 Digital Hierarchy (SDH) Control, RFC 3946, section 3." 206 SYNTAX INTEGER { 207 gmplsMplsLabel(1), 208 gmplsPortWavelengthLabel(2), 209 gmplsFreeformGeneralizedLabel(3), 210 gmplsSonetLabel(4), 211 gmplsSdhLabel(5), 212 gmplsWavebandLabel(6) 213 } 215 GmplsSegmentDirection ::= TEXTUAL-CONVENTION 216 STATUS current 217 DESCRIPTION 218 "The direction of data flow on an LSP segment with respect to the 219 head of the LSP. 221 Where an LSP is signaled using a conventional signaling 222 protocol, the 'head' of the LSP is the source of the signaling 223 (also known as the ingress) and the 'tail' is the destination 224 (also known as the egress). For unidirectional LSPs, this 225 usually matches the direction of flow of data. 227 For manually configured unidirectional LSPs the direction of the 228 LSP segment matches the direction of flow of data. For manually 229 configured bidirecitonal LSPs, an arbitrary decision must be 230 made about which LER is the 'head'." 231 SYNTAX INTEGER { 232 forward(1), -- data flows from head-end of LSP toward tail-end 233 reverse(2) -- data flows from tail-end of LSP toward head-end 234 } 236 END 238 4. Security Considerations 240 This module does not define any management objects. Instead, it 241 defines a set of textual conventions which may be used by other GMPLS 242 MIB modules to define management objects. 244 Meaningful security considerations can only be written in the MIB 245 modules that define management objects. Therefore, this document has 246 no impact on the security of the Internet. 248 5. IANA Considerations 250 -- (Note to RFC-Editor:) 251 -- We request that you assign contiguous RFC numbers to the three GMPLS 252 -- MIB documents. 253 -- The first number to draft-ietf-ccamp-gmpls-tc-mib, the second to 254 -- draft-ietf-ccamp-gmpls-lsr-mib, and the third to 255 -- draft-ietf-ccamp-gmpls-te-mib. 256 -- (Please remove this note prior to publication.) 258 IANA is requested to root MIB objects in this MIB module under the 259 mplsStdMIB subtree by assigning an OID to gmplsTCStdMIB currently 260 indicated by { mplsStdMIB YYY }. 262 In the future, GMPLS related standards track MIB modules should be 263 rooted under the mplsStdMIB (sic) subtree. IANA has been requested to 264 manage that namespace in the SMI Numbers registry [RFC3811]. New 265 assignments can only be made via a Standards Action as specified in 266 [RFC2434]. 268 -- RFC Editor. Please replace YYY above with the OID assigned by IANA 269 -- and remove this note. 271 6. References 273 6.1. Normative References 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirements Levels", BCP 14, RFC 2119, March 1997. 278 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 279 J., Rose, M., and S. Waldbusser, "Structure of 280 Management Information Version 2 (SMIv2)", STD 58, RFC 281 2578, April 1999. 283 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 284 J., Rose, M., and S. Waldbusser, "Textual Conventions 285 for SMIv2", STD 58, RFC 2579, April 1999. 287 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 288 J., Rose, M., and S. Waldbusser, "Conformance Statements 289 for SMIv2", STD 58, RFC 2580, April 1999. 291 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 292 (GMPLS) Signaling Functional Description", RFC 3471, 293 January 2003. 295 [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual 296 Conventions and for Multiprotocol Label Switching (MPLS) 297 Management", RFC 3811, June 2004. 299 [RFC3946] Mannie, E. and D. Papadimitriou, "Generalized Multi- 300 Protocol Label Switching (GMPLS) Extensions for 301 Synchronous Optical Network (SONET) and Synchronous 302 Digital Hierarchy (SDH) Control", RFC 3946, October 303 2004. 305 6.2. Informative References 307 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 308 "Introduction and Applicability Statements for 309 Internet-Standard Management Framework", RFC 3410, 310 December 2002. 312 [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label 313 Switching (GMPLS) Architecture", RFC 3945, October 2004. 315 7. Acknowledgements 317 This document is a product of the CCAMP Working Group. 319 Special thanks to Joan Cucchiara for her help with compilation 320 issues and her very thorough MIB Doctor review. Thanks also to 321 Bert Wijnen, David Harrington and Harrie Hazewinkel for their review 322 comments. 324 8. Contact Information 326 Thomas D. Nadeau 327 Cisco Systems, Inc. 328 1414 Massachusetts Ave. 329 Boxborough, MA 01719 330 Email: tnadeau@cisco.com 332 Adrian Farrel 333 Old Dog Consulting 334 Phone: +44 1978 860944 335 Email: adrian@olddog.co.uk 336 Cheenu Srinivasan 337 Bloomberg L.P. 338 731 Lexington Ave. 339 New York, NY 10022 340 Phone: +1-212-617-3682 341 Email: cheenu@bloomberg.net 343 Tim Hall 344 Data Connection Ltd. 345 100 Church Street 346 Enfield, Middlesex 347 EN2 6BQ, UK 348 Phone: +44 20 8366 1177 349 Email: tim.hall@dataconnection.com 351 Ed Harrison 352 Data Connection Ltd. 353 100 Church Street 354 Enfield, Middlesex 355 EN2 6BQ, UK 356 Phone: +44 20 8366 1177 357 Email: ed.harrison@dataconnection.com 359 9. Intellectual Property Considerations 361 The IETF takes no position regarding the validity or scope of any 362 Intellectual Property Rights or other rights that might be claimed to 363 pertain to the implementation or use of the technology described in 364 this document or the extent to which any license under such rights 365 might or might not be available; nor does it represent that it has 366 made any independent effort to identify any such rights. Information 367 on the procedures with respect to rights in RFC documents can be 368 found in BCP 78 and BCP 79. 370 Copies of IPR disclosures made to the IETF Secretariat and any 371 assurances of licenses to be made available, or the result of an 372 attempt made to obtain a general license or permission for the use of 373 such proprietary rights by implementers or users of this 374 specification can be obtained from the IETF on-line IPR repository at 375 http://www.ietf.org/ipr. 377 The IETF invites any interested party to bring to its attention any 378 copyrights, patents or patent applications, or other proprietary 379 rights that may cover technology that may be required to implement 380 this standard. Please address the information to the IETF at ietf- 381 ipr@ietf.org. 383 10. Full Copyright Statement 385 Copyright (C) The Internet Society (2005). This document is subject 386 to the rights, licenses and restrictions contained in BCP 78, and 387 except as set forth therein, the authors retain all their rights. 389 This document and the information contained herein are provided on an 390 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 391 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 392 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 393 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 394 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 395 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.