idnits 2.17.1 draft-ietf-adslmib-gshdslbis-00.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.5 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 486. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 454), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC3276]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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. == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (March 2004) is 7339 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) -- Looks like a reference, but probably isn't: '12' on line 367 == Unused Reference: 'RFC3411' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC3418' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC3415' is defined on line 415, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUXXXX' ** Obsolete normative reference: RFC 3276 (Obsoleted by RFC 4319) Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Sikes 2 Category: Internet Draft Paradyne 3 B. Ray 4 PESA Switching Systems 5 March 2004 7 Definitions of Managed Objects for G.SHDSL.BIS Lines 8 draft-ietf-adslmib-gshdslbis-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at: 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at: 29 http://www.ietf.org/shadow.htmlBIS.TXT. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document defines a portion of the Management Information Base 38 (MIB) module for use with network management protocols in the 39 Internet community. In particular, it introduces extensions to 40 several objects and textual conventions defined in the HDSL2-SHDSL 41 Line MIB (RFC 3276) [RFC3276] to manage a G.SHDSL.bis interface. 43 Table of Contents 45 1. The Internet-Standard Management Framework . . . . . . . . . . 2 46 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 47 2.1. Relationship of G.SHDSL.bis to RFC 3276 . . . . . . . . 2 48 2.2. Changes to RFC 3276 Textual Conventions. . . . . . . . . 3 49 2.3. Changes to RFC 3276 Objects . . . . . . . . . . . . . . 4 50 2.4. Changes to RFC 3276 Compliance Section . . . . . . . . . 6 51 2.5. Updated MIB Location . . . . . . . . . . . . . . . . . . 7 52 3. Implementation Analysis. . . . . . . . . . . . . . . . . . . . 7 53 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 8 54 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 56 5.2. Informative References . . . . . . . . . . . . . . . . . 9 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 58 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 59 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 61 1. The Internet-Standard Management Framework 63 For a detailed overview of the documents that describe the current 64 Internet-Standard Management Framework, please refer to section 7 of 65 RFC 3410 [RFC3410]. 67 Managed objects are accessed via a virtual information store, termed 68 the Management Information Base or MIB. MIB objects are generally 69 accessed through the Simple Network Management Protocol (SNMP). 70 Objects in the MIB are defined using the mechanisms defined in the 71 Structure of Management Information (SMI). This memo specifies a MIB 72 module that is compliant to the SMIv2, which is described in STD 58, 73 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 74 [RFC2580]. 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Overview 82 This document describes extensions to several objects and textual 83 conventions defined in the HDSL2-SHDSL Line MIB (RFC 3276) [RFC3276] 84 to support equivalent management of a G.SHDSL.bis interface. These 85 extensions are based upon the specifications for G.SHDSL.bis 86 as defined in the ITU documentation [ITUXXXX]. 88 2.1. Relationship of G.SHDSL.bis to G.SHDSL 90 As discussed in RFC3276, G.SHDSL supports up to two wire pairs in 91 a G.SHDSL line. With G.SHDSL.bis, the ITU has extended the 92 specification of G.SHDSL to support an additional two pairs of wires. 94 Thus, to support G.SHDSL.bis, several textual conventions and objects 95 must have their ranges and enumerations changed. 97 A modified version of Figure 2 from RFC3276, section 4.3.1, is below: 99 <-- Network Side Customer Side --> 101 || 103 <~~~> <~~~> HDSL2/SHDSL Segments <~~~> 105 +-------+ +-------+ +-------+ +-------+ +-------+ 106 + C=1=N C=1=N C=..1..=N C=1=N + 107 | xtuC | | xru1 | | xru2 | | xru8 | | xtuR | 108 + C=2=N C=2=N C=..2..=N C=2=N + 109 | | | | | | | | | | 110 + C=3=N C=3=N C=..3..=N C=3=N + 111 | | | | | | | | | | 112 + C=4=N C=4=N C=..4..=N C=4=N + 113 +-------+ +-------+ +-------+ +-------+ +-------+ 115 Key: HDSL2/SHDSL Span 116 <~~~~> HDSL2/SHDSL Segment 117 =1= HDSL2/SHDSL wire-pair-1 118 =2= SHDSL optional wire-pair-2 (Not applicable to HDSL2) 119 =3= G.SHDSL.bis optional wire-pair-3 (Not applicable to 120 HDSL2 or SHDSL) 121 =4= G.SHDSL.bis optional wire-pair-4 (Not applicable to 122 HDSL2 or SHDSL) 123 C Customer Side Segment Endpoint (modem) 124 N Network Side Segment Endpoint (modem) 126 Figure 1: General topology for an HDSL2/SHDSL/G.SHDSL.bis Line 128 2.2. Changes to RFC 3276 Textual Conventions 130 The textual convention, Hdsl2ShdslWirePair, is found in RFC3276: 132 Hdsl2ShdslWirePair ::= TEXTUAL-CONVENTION 133 STATUS current 134 DESCRIPTION 135 "This is the referenced pair of wires in a HDSL2/SHDSL Segment. 136 HDSL2 only supports a single pair (wirePair1), while SHDSL 137 supports an optional second pair (wirePair2)." 138 SYNTAX INTEGER 139 { 140 wirePair1(1), 141 wirePair2(2) 142 } 144 The introduction of two additional wire pairs on the line leads to 145 the following: 147 Hdsl2ShdslWirePair ::= TEXTUAL-CONVENTION 148 STATUS current 149 DESCRIPTION 150 "This is the referenced pair of wires in a HDSL2/SHDSL Segment. 151 HDSL2 only supports a single pair (wirePair1), while SHDSL 152 supports an optional second pair (wirePair2). G.SHDSL.bis 153 supports optional third and fourth wire pairs (wirePair3 154 and wirePair4)." 155 SYNTAX INTEGER 156 { 157 wirePair1(1), 158 wirePair2(2), 159 wirePair2(3), 160 wirePair2(4) 161 } 163 2.3. Changes to RFC 3276 Objects 165 The addition of two (optional) wire pairs leads to one direct 166 and several indirect changes. 168 2.3.1. Changes to hdsl2ShdslConfWireInterface 170 From RFC3276: 172 hdsl2ShdslSpanConfWireInterface OBJECT-TYPE 173 SYNTAX INTEGER 174 { 175 twoWire(1), 176 fourWire(2) 177 } 178 MAX-ACCESS read-create 179 STATUS current 180 DESCRIPTION 181 "This object configures the two-wire or optional four-wire 182 operation for SHDSL Lines." 183 DEFVAL { twoWire } 184 ::= { hdsl2ShdslSpanConfProfileEntry 2 } 186 Two additional enumerations are required to support G.SHDSL.bis. 188 hdsl2ShdslSpanConfWireInterface OBJECT-TYPE 189 SYNTAX INTEGER 190 { 191 twoWire(1), 192 fourWire(2), 193 sixWire(3), 194 eightWire(4) 195 } 196 MAX-ACCESS read-create 197 STATUS current 198 DESCRIPTION 199 "This object configures the number of wire pairs to be used 200 in the line. HDSL2 supports one pair (twoWire), SHDSL lines 201 support an optional, addition pair (fourWire), and 202 G.SHDSL.bis lines support up to four pairs (sixWire or 203 eightWire)." 204 DEFVAL { twoWire } 205 ::= { hdsl2ShdslSpanConfProfileEntry 2 } 207 2.3.2. Changes to Line Rate Objects 209 Four objects in the HDSL2/SHDSL Line MIB have rate limitations. 210 In each case, these objects have the syntax 212 SYNTAX Unsigned32(0..4112000) 214 Changes introduced in G.SHDSL.bis support an increased upper rate 215 of 5696 kbits/s, leading to the updated syntax 217 SYNTAX Unsigned32(0..5696000). 219 These objects with updated syntax are listed below: 221 hdsl2ShdslStatusMaxAttainableLineRate OBJECT-TYPE 222 SYNTAX Unsigned32(0..5696000) 223 UNITS "bps" 224 MAX-ACCESS read-only 225 STATUS current 226 DESCRIPTION 227 "Contains the maximum attainable line rate in this 228 HDSL2/SHDSL span. This object provides the maximum rate 229 the line is capable of achieving. This is based upon 230 measurements made during line probing." 231 ::= { hdsl2ShdslSpanStatusEntry 2 } 233 hdsl2ShdslStatusActualLineRate OBJECT-TYPE 234 SYNTAX Unsigned32(0..5696000) 235 UNITS "bps" 236 MAX-ACCESS read-only 237 STATUS current 238 DESCRIPTION 239 "Contains the actual line rate in this HDSL2/SHDSL span. 240 This should equal ifSpeed." 241 ::= { hdsl2ShdslSpanStatusEntry 3 } 243 hdsl2ShdslSpanConfMinLineRate OBJECT-TYPE 244 SYNTAX Unsigned32(0..5696000) 245 UNITS "bps" 246 MAX-ACCESS read-create 247 STATUS current 248 DESCRIPTION 249 "This object configures the minimum transmission rate for 250 the associated SHDSL Line in bits-per-second (bps). If 251 the minimum line rate equals the maximum line rate 252 (hdsl2ShdslSpanMaxLineRate), the line rate is considered 253 'fixed'. If the minimum line rate is less than the maximum 254 line rate, the line rate is considered 'rate-adaptive'." 255 DEFVAL { 1552000 } 256 ::= { hdsl2ShdslSpanConfProfileEntry 3 } 258 hdsl2ShdslSpanConfMaxLineRate OBJECT-TYPE 259 SYNTAX Unsigned32(0..5696000) 260 UNITS "bps" 261 MAX-ACCESS read-create 262 STATUS current 263 DESCRIPTION 264 "This object configures the maximum transmission rate for 265 the associated SHDSL Line in bits-per-second (bps). If 266 the minimum line rate equals the maximum line rate 267 (hdsl2ShdslSpanMaxLineRate), the line rate is considered 268 'fixed'. If the minimum line rate is less than the maximum 269 line rate, the line rate is considered 'rate-adaptive'." 270 DEFVAL { 1552000 } 271 ::= { hdsl2ShdslSpanConfProfileEntry 4 } 273 2.4. Changes to RFC 3276 Compliance Section 275 To maintain dual compliance with the existing HDSL2-SHDSL-LINE-MIB, 276 the compliance section must be extended. To accomplish this, 277 the objects identified above are restated with their original 278 ranges from RFC 3276. 280 OBJECT hdsl2ShdslSpanConfWireInterface 281 SYNTAX INTEGER 282 { 283 twoWire(1), 284 fourWire(2) 285 } 286 DESCRIPTION 287 "An implementation only has to support the range 288 as applicable for the original g.shdsl specification." 290 OBJECT hdsl2ShdslStatusMaxAttainableLineRate 291 SYNTAX Unsigned32(0..4112000) 292 DESCRIPTION 293 "An implementation only has to support the range 294 as applicable for the original g.shdsl specification." 296 OBJECT hdsl2ShdslStatusActualLineRate 297 SYNTAX Unsigned32(0..4112000) 298 DESCRIPTION 299 "An implementation only has to support the range 300 as applicable for the original g.shdsl specification." 302 OBJECT hdsl2ShdslSpanConfMinLineRate 303 SYNTAX Unsigned32(0..4112000) 304 DESCRIPTION 305 "An implementation only has to support the range 306 as applicable for the original g.shdsl specification." 308 OBJECT hdsl2ShdslSpanConfMaxLineRate 309 SYNTAX Unsigned32(0..4112000) 310 DESCRIPTION 311 "An implementation only has to support the range 312 as applicable for the original g.shdsl specification." 314 2.5. Updated MIB Location 316 A version of the MIB object definitions found in RFC3276 modified 317 to contain the above changes is available at: 319 www.ietf.org/internet-drafts/SHDSL-BIS-LINE-MIB.mib 321 3. Implementation Analysis 323 A management application which supports RFC3276 could mistakenly 324 flag a unit which responds with a rate or wire pair which exceeds 325 the ranges and/or enumerations specified in RFC3276. For example, 326 a G.SHDSL.bis line with four wire pairs would report statistics 327 for wire pairs that do not exist in RFC3276. That is, a GET-NEXT 328 request issued with the object identifier: 330 hdsl2ShdslEndpointCurrAtn.1.1.1.2 332 might return 334 hdsl2ShdslEndpointCurrAtn.1.1.1.3 = 0 336 with a G.SHDSL.bis unit and 338 hdsl2ShdslEndpointCurrSnrMgn.1.1.1.1 = 0 340 with an HDSL2 unit as these objects are indexed by 342 INDEX { ifIndex, hdsl2ShdslInvIndex, hdsl2ShdslEndpointSide, 343 hdsl2ShdslEndpointWirePair } 345 A management application which intends to manage G.SHDSL.bis 346 agents, should be modified to accept this sequence. 348 One should note that this same unmodified management application 349 is still capable of managing G.SHDLS.bis agents albiet to the 350 degree of G.SHDSL (non-bis) limitations. That is, it can create 351 and monitor configurations limited to two wire pairs with an 352 upper rate limit of 4112000 bits/second. 354 4. Security Considerations 356 In addition to the security considerations presented in RFC3276, 357 it is conceivable that a management application could be broken 358 by a G.SHDSL.bis agent which reports objects for additional 359 wire pairs (as noted in section 3). 361 For example, if a management application blindly loaded object 362 instances into an array until the an object changes (during 363 repeated GET-NEXT requests). It is anticipated that the 364 modifications to the management application code would be 365 straightforward. Perhaps, of the form: 367 if (name[12] > 2) reject(); 369 or 371 if (*val > 4112000) reject(); 373 5. References 375 5.1. Normative References 377 [ITUXXXX] ITU-T G.shdsl.bis, October 2003. 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 383 Rose, M. and S. Waldbusser, "Structure of Management 384 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 385 1999. 387 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 388 Rose, M. and S. Waldbusser, "Textual Conventions for 389 SMIv2", STD 58, RFC 2579, April 1999. 391 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 392 Rose, M. and S. Waldbusser, "Conformance Statements for 393 SMIv2", STD 58, RFC 2580, April 1999. 395 [RFC3276] Ray, B., and R. Abbi, "Definitions of Managed Objects 396 for High Bit-Rate DSL - 2nd generation (HDSL2) and 397 Single-Pair High-Speed Digital Subscriber Line (SHDSL) 398 Lines", RFC 3276, May 2002. 400 [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An 401 Architecture for Describing Simple Network Management 402 Protocol (SNMP) Management Frameworks", RFC 3411, 403 December 2002. 405 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 406 Simple Network Management Protocol (SNMP)", STD 62, RFC 407 3418, December 2002. 409 5.2. Informative References 411 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 412 "Introduction and Applicability Statements for Internet- 413 Standard Management Framework", RFC 3410, December 2002. 415 [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 416 Access Control Model (VACM) for the Simple Network 417 Management Protocol (SNMP)", STD 62, RFC 3415, December 418 2002. 420 6. Acknowledgements 422 Matt Beanland (Extel) 424 Steve Turner (IBEC) 426 Bert Wijnen (Lucent) 428 7. Authors' Addresses 430 Clay Sikes 431 Paradyne Corporation 432 8545 126th Ave. N. 433 Largo, FL 33773 434 USA 436 Phone: +1 727 530 8257 437 Fax: +1 727 532 5698 438 EMail: csikes@paradyne.com 440 Bob Ray 441 PESA Switching Systems, Inc. 442 330-A Wynn Drive 443 Huntsville, AL 35805 444 USA 446 Phone: +1 256 726 9200 ext. 142 447 Fax: +1 256 726 9271 448 EMail: rray@pesa.com 450 8. Full Copyright Statement 452 Copyright (C) The Internet Society (2004). This document is subject 453 to the rights, licenses and restrictions contained in BCP 78 and 454 except as set forth therein, the authors retain all their rights. 456 This document and the information contained herein are provided on an 457 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 458 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 459 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 460 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 461 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 462 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 464 Intellectual Property 466 The IETF takes no position regarding the validity or scope of any 467 Intellectual Property Rights or other rights that might be claimed to 468 pertain to the implementation or use of the technology described in 469 this document or the extent to which any license under such rights 470 might or might not be available; nor does it represent that it has 471 made any independent effort to identify any such rights. Information 472 on the procedures with respect to rights in RFC documents can be 473 found in BCP 78 and BCP 79. 475 Copies of IPR disclosures made to the IETF Secretariat and any 476 assurances of licenses to be made available, or the result of an 477 attempt made to obtain a general license or permission for the use of 478 such proprietary rights by implementers or users of this 479 specification can be obtained from the IETF on-line IPR repository at 480 http://www.ietf.org/ipr. 482 The IETF invites any interested party to bring to its attention any 483 copyrights, patents or patent applications, or other proprietary 484 rights that may cover technology that may be required to implement 485 this standard. Please address the information to the IETF at ietf- 486 ipr@ietf.org.