A Summary of the X.500(96) User Schema for use with LDAPv3
RFC 2256
Document | Type |
RFC
- Proposed Standard
(December 1997)
Updated by RFC 3377
|
|
---|---|---|---|
Author | Mark Wahl | ||
Last updated | 2013-03-02 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
IESG | Responsible AD | (None) | |
Send notices to | (None) |
RFC 2256
Network Working Group INTERNET-DRAFT Sam Aldrin Intended Status: Standards Track Huawei Technologies Expires: June 29, 2014 M.Venkatesan Dell Inc. Kannan KV Sampath Redeem Software Thomas D. Nadeau December 26, 2013 BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks draft-ietf-bfd-mpls-mib-03 Abstract This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base BFD- STD-MIB and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 29, 2014. Aldrin, et al. Expires June 29, 2014 [Page 1] INTERNET DRAFT BFD Extensions for MPLS MIB December 26, 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Conventions used in this document . . . . . . . . . . . . . 3 3.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Brief description of MIB Objects . . . . . . . . . . . . . . . 4 5.1. Extensions to the BFD session table (bfdSessionTable) . . . 4 5.2. Example of BFD session configuration . . . . . . . . . . . 6 5.2.1 Example of BFD Session configuration for MPLS TE tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2.2 Example of BFD Session configuration for ME of MPLS-TP TE tunnel . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. BFD objects for session performance counters . . . . . . . 9 6. BFD-EXT-STD-MIB Module Definition . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 9.2 Informative References . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 Aldrin, et al. Expires June 29, 2014 [Page 2] INTERNET DRAFT BFD Extensions for MPLS MIB December 26, 2013 1 Introduction The current MIB for BFD as defined by BFD-STD-MIB is used for neighbor monitoring in IP networks. The BFD session association to the neighbors being monitored is done using the source and destination IP addresses of the neighbors configured using the respective MIB objects. To monitor MPLS/MPLS-TP paths like tunnels or Pseudowires, there is a necessity to identify or associate the BFD session to those paths. This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base BFD- STD-MIB and describes the managed objects to configure and/or monitor Bidirectional Forwarding Detection (BFD) protocol for MPLS [RFC5884] and MPLS-TP networks [RFC6428]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC2578, STD 58, RFC2579 and STD58, RFC2580. 3. Overview 3.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3.2 Terminology This document adopts the definitions, acronyms and mechanisms described in [BFD], [BFD-1HOP], [BFD-MH], [RFC5884], [RFC6428]. Unless otherwise stated, the mechanisms described therein will not be re-described here. Aldrin, et al. Expires June 29, 2014 [Page 3] #x27; ) No printable representation of values of the supportedAlgorithms attribute is defined in this document. Clients which wish to store and retrieve this attribute MUST use "supportedAlgorithms;binary", in which the value is transferred as a binary encoding. 7. Object Classes LDAP servers MUST recognize the object classes "top" and "subschema". LDAP servers SHOULD recognize all the other object classes listed here as values of the objectClass attribute. 7.1. top ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) Wahl Standards Track [Page 14] RFC 2256 LDAPv3 Schema December 1997 7.2. alias ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName ) 7.3. country ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ) ) 7.4. locality ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) ) 7.5. organization ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) 7.6. organizationalUnit ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL MUST ou MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) 7.7. person ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) 7.8. organizationalPerson ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ Wahl Standards Track [Page 15] RFC 2256 LDAPv3 Schema December 1997 facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) ) 7.9. organizationalRole ( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l $ description ) ) 7.10. groupOfNames ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( member $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) 7.11. residentialPerson ( 2.5.6.10 NAME 'residentialPerson' SUP person STRUCTURAL MUST l MAY ( businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l ) ) 7.12. applicationProcess ( 2.5.6.11 NAME 'applicationProcess' SUP top STRUCTURAL MUST cn MAY ( seeAlso $ ou $ l $ description ) ) 7.13. applicationEntity ( 2.5.6.12 NAME 'applicationEntity' SUP top STRUCTURAL MUST ( presentationAddress $ cn ) MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $ description ) ) 7.14. dSA ( 2.5.6.13 NAME 'dSA' SUP applicationEntity STRUCTURAL MAY knowledgeInformation ) Wahl Standards Track [Page 16] RFC 2256 LDAPv3 Schema December 1997 7.15. device ( 2.5.6.14 NAME 'device' SUP top STRUCTURAL MUST cn MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) ) 7.16. strongAuthenticationUser ( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top AUXILIARY MUST userCertificate ) 7.17. certificationAuthority ( 2.5.6.16 NAME 'certificationAuthority' SUP top AUXILIARY MUST ( authorityRevocationList $ certificateRevocationList $ cACertificate ) MAY crossCertificatePair ) 7.18. groupOfUniqueNames ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL MUST ( uniqueMember $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) 7.19. userSecurityInformation ( 2.5.6.18 NAME 'userSecurityInformation' SUP top AUXILIARY MAY ( supportedAlgorithms ) ) 7.20. certificationAuthority-V2 ( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP certificationAuthority AUXILIARY MAY ( deltaRevocationList ) ) 7.21. cRLDistributionPoint ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL MUST ( cn ) MAY ( certificateRevocationList $ authorityRevocationList $ deltaRevocationList ) ) 7.22. dmd ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST ( dmdName ) MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ Wahl Standards Track [Page 17] RFC 2256 LDAPv3 Schema December 1997 street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) 8. Matching Rules Servers MAY implement additional matching rules. 8.1. octetStringMatch Servers which implement the extensibleMatch filter SHOULD allow the matching rule listed in this section to be used in the extensibleMatch. In general these servers SHOULD allow matching rules to be used with all attribute types known to the server, when the assertion syntax of the matching rule is the same as the value syntax of the attribute. ( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 9. Security Considerations Attributes of directory entries are used to provide descriptive information about the real-world objects they represent, which can be people, organizations or devices. Most countries have privacy laws regarding the publication of information about people. Transfer of cleartext passwords are strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties. 10. Acknowledgements The definitions on which this document have been developed by committees for telecommunications and international standards. No new attribute definitions have been added. The syntax definitions are based on the ISODE "QUIPU" implementation of X.500. 11. Bibliography [1] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight X.500 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [2] The Directory: Models. ITU-T Recommendation X.501, 1996. [3] The Directory: Authentication Framework. ITU-T Recommendation X.509, 1996. Wahl Standards Track [Page 18] RFC 2256 LDAPv3 Schema December 1997 [4] The Directory: Selected Attribute Types. ITU-T Recommendation X.520, 1996. [5] The Directory: Selected Object Classes. ITU-T Recommendation X.521, 1996. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 12. Author's Address Mark Wahl Critical Angle Inc. 4815 West Braker Lane #502-385 Austin, TX 78759 USA Phone: +1 512 372 3160 EMail: M.Wahl@critical-angle.com Wahl Standards Track [Page 19] RFC 2256 LDAPv3 Schema December 1997 13. Full Copyright Statement Copyright (C) The Internet Society (1997). 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. Wahl Standards Track [Page 20]