idnits 2.17.1 draft-ietf-ops-vlanid-tc-mib-01.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 308. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-1Q.2003' == Outdated reference: A later version (-12) exists of draft-ietf-ipcdn-qos-mib-10 -- Obsolete informational reference (is this intentional?): RFC 2674 (Obsoleted by RFC 4363) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 none B. Wijnen 3 Internet-Draft Lucent Technologies 4 Expires: March 2, 2005 september 2004 6 Textual Conventions for Virtual Local Area Network Identifiers 7 (VLAN-ID) 8 draft-ietf-ops-vlanid-tc-mib-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 2, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This memo defines textual conventions to represent the commonly used 44 Virtual Local Area Network Identifier (VLAN-ID). The intent is that 45 these textual conventions (TCs) will be imported and used in MIB 46 modules that would otherwise define their own representations. 48 1. Introduction 50 Various Working Groups have defined standards-track MIB documents 51 (for example [RFC2613], [RFC2674] and [RFC3318]), that contain 52 objects and Textual Conventions to represent a Virtual Local Area 53 Network Identifier (VLAN-ID) [IEEE.802-1Q.2003]. New definitions are 54 showing up in various Internet-Drafts (for example 55 [I-D.ietf-ipcdn-qos-mib], [I-D.ietf-rmonmib-sspm-mib]). 56 Unfortunately the result is a set of different definitions for the 57 same piece of management information. This may lead to confusion and 58 unnecessary complexity. 60 This document defines a set of textual conventions (TCs) that can and 61 should be (re-)used in MIB modules, so that they all represent a 62 VLAN-ID in the same way. In fact, PIB modules can and should also 63 use these TCs when they need to represent a VLAN-ID. 65 2. The Internet-Standard Management Framework 67 For a detailed overview of the documents that describe the current 68 Internet-Standard Management Framework, please refer to section 7 of 69 RFC 3410 [RFC3410]. 71 Managed objects are accessed via a virtual information store, termed 72 the Management Information Base or MIB. MIB objects are generally 73 accessed through the Simple Network Management Protocol (SNMP). 74 Objects in the MIB are defined using the mechanisms defined in the 75 Structure of Management Information (SMI). This memo specifies a MIB 76 module that is compliant to the SMIv2, which is described in STD 58, 77 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 78 [RFC2580]. 80 3. Definitions 82 VLAN-ID-MIB DEFINITIONS ::= BEGIN 84 IMPORTS 86 MODULE-IDENTITY, mib-2, Integer32 FROM SNMPv2-SMI 87 TEXTUAL-CONVENTION FROM SNMPv2-TC; 89 vlanIdMIB MODULE-IDENTITY 91 LAST-UPDATED "200409270000Z" -- 27 September 2004 92 ORGANIZATION "IETF Operations and Management Area" 93 CONTACT-INFO "Bert Wijnen (Editor) 94 Lucent Technologies 95 Schagen 33 96 3461 GL Linschoten 97 Netherlands 99 Phone: +31 348-407-775 100 EMail: bwijnen@lucent.com 102 Send comments to . 103 " 104 DESCRIPTION "This MIB module provides commonly used textual 105 conventions for VLAN Identifiers. 107 Copyright (C) The Internet Society (2004). This 108 version of this MIB module is part of RFC XXXX, 109 see the RFC itself for full legal notices. 110 " 111 -- RFC-Editor: assign XXXX above 112 -- then remove this note 114 -- Revision History 116 REVISION "200409270000Z" -- 27 September 2004 117 DESCRIPTION "Initial version, published as RFC XXXX." 118 -- RFC-Editor: assign XXXX above, 119 -- then remove this note 121 ::= { mib-2 nnn } -- To be assigned by IANA 123 VlanIdentifier ::= TEXTUAL-CONVENTION 124 DISPLAY-HINT "d" 125 STATUS current 126 DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. It 127 is the 12-bit VLAN ID used in the VLAN Tag header. 128 The range is defined by the REFERENCEd specification. 129 " 130 REFERENCE "IEEE Std 802.1Q 2003 Edition, Virtual Bridged 131 Local Area Networks. 132 " 133 SYNTAX Integer32 (1..4094) 135 VlanIdentifierOrAny ::= TEXTUAL-CONVENTION 136 DISPLAY-HINT "d" 137 STATUS current 138 DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. 140 The special value of 4095 is used to indicate a 141 wildcard, i.e. any value. 142 " 143 SYNTAX Integer32 (1..4094 | 4095) 145 VlanIdentifierOrNone ::= TEXTUAL-CONVENTION 146 DISPLAY-HINT "d" 147 STATUS current 148 DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. 150 The special value of zero is used to indicate 151 that no VLAN ID is present or used. 152 " 153 SYNTAX Integer32 (0 | 1..4094) 155 VlanIdentifierOrAnyOrNone ::= TEXTUAL-CONVENTION 156 DISPLAY-HINT "d" 157 STATUS current 158 DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. 160 The special value of zero is used to indicate 161 that no VLAN ID is present or used. 163 The special value of 4095 is used to indicate a 164 wildcard, i.e. any value. 165 " 166 SYNTAX Integer32 (0 | 1..4094 | 4095) 168 END 170 4. Security Considerations 172 The MIB module contained in this memo does not define any management 173 objects. Instead, it defines a set of textual conventions which may 174 be used by other MIB modules to define management objects. 176 Meaningful security considerations can only be written for MIB 177 modules that define concrete management objects. This document has 178 therefore no impact on the security of the Internet. 180 5. IANA Considerations 182 IANA is requested to assign an OID under mib-2 to the MIB module in 183 section Section 3. 185 6. Acknowledgments 187 This document was produced as a result of a review of the use of 188 VLAN-ID in several MIB modules. Further investigation found that 189 VLAN-ID objects were defined in a few other MIB modules. The editor 190 would like to thank all who contributed to the discussion which 191 resulted in this document. Specifically Les Bell, Andrew Smith, Mike 192 Heard, Randy Presuhn, Dan Romascanu, Eduardo Cardona, Tom Petch, 193 Juergen Schoenwaelder, Richard Woundy, Tony Jeffree and William 194 Murwin. We also received input and feedback from IEEE confirming 195 that the values 0 and 4095 are not used for identifying a specific 196 VLAN-ID and so can be used to represent none or a wildcard (see 197 Appendix A). 199 7. References 201 7.1 Normative References 203 [IEEE.802-1Q.2003] 204 Institute of Electrical and Electronics Engineers, "IEEE 205 Std 802.1Q 2003 Edition, Virtual Bridged Local Area 206 Networks", IEEE Standard 802.1D, 2003 Edition, May 2003. 208 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 209 McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of 210 Management Information Version 2 (SMIv2)", STD 58, RFC 211 2578, April 1999. 213 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 214 McCloghrie, K., Rose, M. and S. Waldbusser, "Textual 215 Conventions for SMIv2", STD 58, RFC 2579, April 1999. 217 [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 218 "Conformance Statements for SMIv2", STD 58, RFC 2580, 219 April 1999. 221 7.2 Informative References 223 [I-D.ietf-ipcdn-qos-mib] 224 Patrick, M. and W. Murwin, "Data Over Cable System 225 Interface Specification Quality of Service Management 226 Information Base (DOCSIS-QOS MIB)", 227 draft-ietf-ipcdn-qos-mib-10 (work in progress), September 228 2004. 230 [I-D.ietf-rmonmib-sspm-mib] 231 Kalbfleisch, C., Cole, R. and D. Romascanu, "Definition of 232 Managed Objects for Synthetic Sources for Performance 233 Monitoring Algorithms.", draft-ietf-rmonmib-sspm-mib-12 234 (work in progress), June 2004. 236 [RFC2613] Waterman, R., Lahaye, B., Romascanu, D. and S. Waldbusser, 237 "Remote Network Monitoring MIB Extensions for Switched 238 Networks Version 1.0", RFC 2613, June 1999. 240 [RFC2674] Bell, L., Smith, A., Langille, P., Rijhsinghani, A. and K. 241 McCloghrie, "Definitions of Managed Objects for Bridges 242 with Traffic Classes, Multicast Filtering and Virtual LAN 243 Extensions", RFC 2674, August 1999. 245 [RFC3318] Sahita, R., Hahn, S., Chan, K. and K. McCloghrie, 246 "Framework Policy Information Base", RFC 3318, March 2003. 248 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 249 "Introduction and Applicability Statements for 250 Internet-Standard Management Framework", RFC 3410, 251 December 2002. 253 Author's Address 255 Bert Wijnen 256 Lucent Technologies 257 Schagen 33 258 3461 GL Linschoten 259 Netherlands 261 Phone: +31-348-407-775 262 EMail: bwijnen@lucent.com 264 Appendix A. Email from Tony Jeffrey from IEEE 266 -----Original Message----- 267 From: Tony Jeffree [mailto:tony@jeffree.co.uk] 268 Sent: Friday, 6th of June 2003 17:16 269 To: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 270 Subject: RE: VLAn ID 272 Bert et al - 274 We have concluded that the use of 4095 as a wildcard is acceptable 275 to 802.1, and we will make any necessary changes to 802.1Q in due 276 course to relax the current stated restriction. However, we need 277 to know whether that is all that needs to be done to 802.1Q - i.e., 278 is there any need to change our definitions of the managed objects 279 in the document (Clause 12) to reflect the interpretation of 4095 280 as a wildcard, or is this simply an issue for the SNMP machinery 281 to handle? 283 Regards, 284 Tony 286 Intellectual Property Statement 288 The IETF takes no position regarding the validity or scope of any 289 Intellectual Property Rights or other rights that might be claimed to 290 pertain to the implementation or use of the technology described in 291 this document or the extent to which any license under such rights 292 might or might not be available; nor does it represent that it has 293 made any independent effort to identify any such rights. Information 294 on the procedures with respect to rights in RFC documents can be 295 found in BCP 78 and BCP 79. 297 Copies of IPR disclosures made to the IETF Secretariat and any 298 assurances of licenses to be made available, or the result of an 299 attempt made to obtain a general license or permission for the use of 300 such proprietary rights by implementers or users of this 301 specification can be obtained from the IETF on-line IPR repository at 302 http://www.ietf.org/ipr. 304 The IETF invites any interested party to bring to its attention any 305 copyrights, patents or patent applications, or other proprietary 306 rights that may cover technology that may be required to implement 307 this standard. Please address the information to the IETF at 308 ietf-ipr@ietf.org. 310 Disclaimer of Validity 312 This document and the information contained herein are provided on an 313 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 314 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 315 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 316 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 317 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 318 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 320 Copyright Statement 322 Copyright (C) The Internet Society (2004). This document is subject 323 to the rights, licenses and restrictions contained in BCP 78, and 324 except as set forth therein, the authors retain all their rights. 326 Acknowledgment 328 Funding for the RFC Editor function is currently provided by the 329 Internet Society.