OBJECTS {
adslConfProfileLineType
}
STATUS current
DESCRIPTION
"A collection of objects providing profile
control for the ADSL system."
::= { adslExtGroups 4 }
adslExtLineAlarmConfProfileGroup OBJECT-GROUP
OBJECTS {
adslAtucThreshold15MinFailedFastR,
adslAtucThreshold15MinSesL,
adslAtucThreshold15MinUasL,
adslAturThreshold15MinSesL,
adslAturThreshold15MinUasL
}
STATUS current
DESCRIPTION
"A collection of objects providing alarm profile
control for the ADSL system."
::= { adslExtGroups 5 }
adslExtNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
adslAtucFailedFastRThreshTrap,
adslAtucSesLThreshTrap,
adslAtucUasLThreshTrap,
adslAturSesLThreshTrap,
adslAturUasLThreshTrap
}
STATUS current
DESCRIPTION
"The collection of ADSL extension notifications."
::= { adslExtGroups 6 }
END
7. Acknowledgments
This document is a product of the ADSL MIB Working Group.
8. References
8.1 Normative References
[ANSI T1.413] American National Standards Institute, ANSI
T1.413, Issue 2, "Standards Project for Interfaces
Relating to Carrier to Customer Connection of ADSL
Equipment", 1998.
[ETSI DTS/TM06006] European Telecommunications Standards Institute
"ADSL European Specific Requirements", November
2000.
[ITU G.992.1] ITU-T Telecommunication Standardization Sector,
"Asymmetric digital subscriber line (ADSL)
transceivers", June 1999.
[ITU G.992.2] ITU-T Telecommunication Standardization Sector,
"Splitterless asymmetric digital subscriber line
(ADSL) transceivers", June 1999.
[ITU G.997.1] ITU-T Telecommunication Standardization Sector,
"Physical Layer Management of Digital Subscriber
Transceivers", June 1999.
[RFC2026] Bradner S., "The Internet Standards Process -
Revision 3", BCP 9, RFC2026, October 1996.
[RFC2028] Hovey R. and S. Bradner, "The Organizations
Involved in the IETF Standards Process", BCP 11,
RFC2028, October 1996.
[RFC2493] Tesink, K., "Textual Conventions for MIB Modules
Using Performance History Based on 15 Minute
Intervals" RFC2493, January 1999.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Case, J., Rose, M. and S. Waldbusser, "Structure
of Management Information Version 2 (SMIv2)", STD
58, RFC2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Case, J., Rose, M. and S. Waldbusser, "Textual
Conventions for SMIv2", STD 58, RFC2579, April
1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Case, J., Rose, M. and S. Waldbusser, "Conformance
Statements for SMIv2", STD 58, RFC2580, April
1999.
[RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed
Objects for the ADSL Lines", RFC2662, May 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces
Group MIB", RFC2863, June 2000.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security
Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3)", STD 62, RFC3414,
December 2002.
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-
based Access Control Model (VACM) for the Simple
Network Management Protocol (SNMP)", STD 62, RFC
3415, December 2002.
8.2 Informative References
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC3410,
December 2002.
9. Security Considerations
The following security matters should be considered when implementing
this MIB.
1) Blocking unauthorized access to the ADSL MIB via the element
management system is outside the scope of this document. It
should be noted that access to the MIB permits the unauthorized
entity to modify the profiles (section 6.4) such that both
subscriber service and network operations can be interfered with.
Subscriber service can be altered by modifying any of a number of
service characteristics such as rate partitioning and maximum
transmission rates. Network operations can be impacted by
modifying notification thresholds such as Signal-to-Noise Ratio
(SNR) margins.
2) SNMPv1 by itself is such an insecure environment. Even if the
network itself is secure (for example by using IPSec), there is no
control over who on the secure network is allowed to access and
GET (read) the objects in this MIB. It is recommended that the
implementors consider the security features as provided by the
SNMPv3 framework. Specifically, the use of the User-based
Security Model STD 62, RFC3414 [RFC3414] and the View-based
Access Control Model STD 62, RFC3415 [RFC3415] is recommended.
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to only those objects, and to those
principals (users) that have legitimate rights to access them.
3) The profile mechanism presented in this document requires specific
attention. The implementor of this MIB has a choice of
implementing either 'static' or 'dynamic' profiles. This decision
must be consistent with the implementation of RFC2662.
In the case of 'static' profiles, the elements of the profile are
read-write, as opposed to read-create when 'dynamic' profiles are
implemented:
- adslConfProfileLineType,
- adslAtucThreshold15MinFailedFastR,
- adslAtucThreshold15MinSesL,
- adslAtucThreshold15MinUasL,
- adslAturThreshold15MinSesL, and
- adslAturThreshold15MinUasL.
This decision also impacts the mechanics of the index,
adslLineConfProfileDualLite. When 'static' profiles are
implemented, its value is algorithmically set by the system and
its value is based on the ifIndex. Hence it is not guaranteed
across system reboots. Similar to the handling of
adslLineConfProfile [RFC2662], the implementor of this MIB must
ensure that the profile object values associated with these
indices are maintained across system reboots.
In the case of dynamic profiles, this object is set by the SNMP
manager. The implementor of this MIB may want to provide a view
of the profile on a customer-by-customer standpoint, but should be
cautious of the dynamic nature of these objects.
4) ADSL layer connectivity from the ATU-R will permit the
subscriber to manipulate both the ADSL link directly and the ADSL
overhead control channel(AOC)/embedded operations channel (EOC)
for their own loop. For example, unchecked or unfiltered
fluctuations initiated by the subscriber could generate sufficient
notifications to potentially overwhelm either the management
interface to the network or the element manager. Other attacks
affecting the ATU-R portions of the MIB may also be possible.
10. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11 [RFC2028].
Copies of claims of rights made available for publication 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 implementors or users of this
specification can be obtained from the IETF Secretariat.
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 practice
this standard. Please address the information to the IETF Executive
Director.
11. Authors' Addresses
Faye Ly
Pedestal Networks
6503 Dumbarton Circle,
Fremont, CA 94555
Phone: +1 510-578-0158
Fax: +1 510-744-5152
EMail: faye@pedestalnetworks.com
Gregory Bathrick
Nokia Networks
2235 Mercury Way,
Santa Rosa, CA 95405
Phone: +1 707-362-1125
Fax: +1 707-535-7300
EMail: greg.bathrick@nokia.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.