RFC Editor Model (Version 1)
RFC 5620
Document | Type | RFC - Informational (August 2009) | |
---|---|---|---|
Authors | IAB , Olaf Kolkman | ||
Last updated | 2013-03-02 | ||
RFC stream | Internet Architecture Board (IAB) | ||
Formats |
RFC 5620
SAVI C. An Internet-Draft J. Yang Intended status: Informational J. Wu Expires: December 20, 2012 J. Bi CERNET June 18, 2012 Definition of Managed Objects for SAVI Protocol draft-an-savi-mib-03 Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing SAVI (Source Address Validation Improvements) protocol instance. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 20, 2012. Copyright Notice Copyright (c) 2012 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 An, et al. Expires December 20, 2012 [Page 1] Internet-Draft SAVI-MIB June 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 4 5.1. The SAVI System Table . . . . . . . . . . . . . . . . . . 4 5.2. The SAVI Port Table . . . . . . . . . . . . . . . . . . . 5 5.3. The SAVI Binding Table . . . . . . . . . . . . . . . . . . 6 5.4. The SAVI Filtering Table . . . . . . . . . . . . . . . . . 7 6. Textual Conventions . . . . . . . . . . . . . . . . . . . . . 7 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 8 7.1. Relationship to the INET-ADDRESS-MIB . . . . . . . . . . . 8 7.2. Relationship to the IF-MIB . . . . . . . . . . . . . . . . 8 7.3. MIB modules required for IMPORTS . . . . . . . . . . . . . 8 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 12.3. URL References . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 24 An, et al. Expires December 20, 2012 [Page 2] Internet-Draft SAVI-MIB June 2012 1. Introduction The Source Address Validation Improvement protocol was developed to complement ingress filtering with finer-grained, standardized IP source address validation(refer to [I-D.ietf-savi-framework]).A SAVI protocol instance is located on the path of hosts' packets, enforcing the hosts' use of legitimate IP source addresses. SAVI protocol determines whether the IP address obtaining process is legitimate according to IP address assignment method. For links with Stateless Address Auto Configuration (SLAAC), Dynamic Host Configuration Protocol (DHCP), and Secure Neighbor Discovery (SEND), the process is defined in separate documents of SAVI Working Group (refer to [RFC6620], [I-D.ietf-savi-dhcp], [I-D.ietf-savi-send].) This document defines a MIB module that can be used to manage the SAVI protocol instance. It covers both configuration and status monitoring aspects of SAVI implementations. This document uses terminology from the SAVI Protocol specification. 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 RFC 3410 [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, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 1. Introduction ....................................................3 2. IAOC Implementation .............................................4 2.1. Expenses for the RFC Editor ................................4 3. RFC Editor Model ................................................5 3.1. RFC Series Editor ..........................................6 3.2. Independent Submission Editor ..............................8 3.3. RFC Production Center ......................................9 3.4. RFC Publisher .............................................11 4. Committees .....................................................11 4.1. RFC Series Advisory Group (RSAG) ..........................11 4.1.1. Charter ............................................11 4.1.2. Membership .........................................12 4.1.3. Disagreements among RFC Editor Entities ............13 4.2. Independent Submission Stream Editorial Board .............14 5. IANA Considerations ............................................14 6. Security Considerations ........................................14 7. Acknowledgments ................................................15 8. References .....................................................16 8.1. Normative References ......................................16 8.2. Informative References.....................................16 Appendix A. 2009 Selection Process ................................17 A.1. Ad Hoc Advisory Committee(s) ..............................17 A.2. The IAB Selection Process of an RFC Series Editor and/or an Independent Submission Editor ...................17 A.2.1. Nominations and Eligibility ........................17 A.2.2. Committees in 2009 .................................18 A.2.3. Selection ..........................................18 A.2.4. Care of Personal Information........................18 A.2.5. Term of Office and Selection Time Frame ............19 Kolkman & IAB Informational [Page 2] RFC 5620 RFC Editor Model (Version 1) August 2009 1. Introduction The IAB, on behalf of the Internet technical community, is concerned with ensuring the continuity of the RFC Series, orderly RFC Editor succession, maintaining RFC quality, and RFC document accessibility. The IAB is also sensitive to the concerns of the IETF Administrative Oversight Committee (IAOC) about providing the necessary services in a cost-effective and efficient manner. The definition of the RFC series is described in RFC 4844 [1]. Section 3.1 of RFC 4844 defines "RFC Editor": | 3.1. RFC Editor | | Originally, there was a single person acting as editor of the RFC | Series (the RFC Editor). The task has grown, and the work now | requires the organized activity of several experts, so there are RFC | Editors, or an RFC Editor organization. In time, there may be | multiple organizations working together to undertake the work | required by the RFC Series. For simplicity's sake, and without | attempting to predict how the role might be subdivided among them, | this document refers to this collection of experts and organizations | as the "RFC Editor". | | The RFC Editor is an expert technical editor and series editor, | acting to support the mission of the RFC Series. As such, the RFC | Editor is the implementer handling the editorial management of the | RFC Series, in accordance with the defined processes. In addition, | the RFC Editor is expected to be the expert and prime mover in | discussions about policies for editing, publishing, and archiving | RFCs. RFC 4844 makes no attempt to explore the internal organization of the RFC Editor. However, RFC 4844 envisions changes in the RFC Editor organizational structure. In discussion with the Internet community, the IAB considered changes that increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. The model set forth below is the result of those discussions, and examines the internal organization of the RFC Editor, while remaining consistent with RFC 4844. Kolkman & IAB Informational [Page 3] RFC 5620 RFC Editor Model (Version 1) August 2009 Note that RFC 4844 uses the term "RFC Editor function" or "RFC Editor" as the collective set of responsibilities for which this memo provides a model for internal organization. This memo introduces the term "RFC Series Editor" or "Series Editor" for one of the organizational components. While the IAB approved the initial version of this RFC Editor model on October 1, 2008, the model has received clarifications since. It should be noted that the publication of the document as an RFC does not cast the model in stone, as the primary purpose of this document, throughout the publication process, is to encourage normal community review in order to ascertain consensus to work to this model as a first step. The document, and the resulting structures, will be modified as needed through normal procedures. The IAB will continue to monitor discussions within the community about potential adjustments to the RFC Editor model and recognizes that the process described in this document may need to be adjusted to align with any changes that result from such discussions, hence the version number in the title. In particular, the document will be reviewed after the various transition periods and mechanisms specified in this version are completed. 2. IAOC Implementation The model is constructed in such a way that it allows for all these functions to be implemented jointly or under separate contractual arrangements. In fact, a bidder could put together a proposal that includes one or more subcontractors. The reporting structure will depend on the manner that the contracts are awarded, and they are subject to change over time. As a result, the model describes only responsibilities, procedures, and process. The exact implementation is a responsibility of the IAOC. 2.1. Expenses for the RFC Editor The expenses discussed in this document are not new expenses. They are part of the IASA budget. Today, these expenses are part of the RFC Editor contract with the University of Southern California's Information Sciences Institute. Kolkman & IAB Informational [Page 4] RFC 5620 RFC Editor Model (Version 1) August 2009 3. RFC Editor Model The RFC Editor model divides the responsibilities for the RFC Series into the following components: o RFC Series Editor ("RSE"). o Independent Submission Editor ("ISE"). o RFC Production Center. o RFC Publisher. The RFC Series production and process under this structure is schematically represented by the figure below. (The figure does not depict oversight and escalation relations.) ------ ----- ------ --------- Stream | | | | | | |Community| Pro- | IETF | | IAB | | IRTF | | at | ducers | | | | | | | Large | --^--- --^-- ---^-- ----^---- | | | | | | | | ------- | | | | | Indep.| --v--- ---v--- ---v-- ----v------ | Stream| Stream | | | | | | |Independent| | Edi- | Appro- | IESG | | IAB | | IRSG | |Submission |.....| torial| vers | | | | | | | Editor | | Board | ----^- ---^--- ----^--- ----^------ ------- | | | | | | | | ------- | | | | | RFC | ------ --v--------v----------v-----------v----- | Series| | | | | | Adv. | | IANA | <->| RFC Production Center <---. | Group | | | | | | ------- ------ -----------------^---------------------- | | | | | | ------v------- ------v--------- | | | | | RFC Series | | RFC Publisher |<------->| Editor | | | | | ---------------- -------------- Figure 1: Ordinary RFC Series production and process Kolkman & IAB Informational [Page 5] RFC 5620 RFC Editor Model (Version 1) August 2009 In this model, documents are produced and approved through multiple document streams. The four that now exist are described in [1]. Documents from these streams are edited and processed by the Production Center and published by the Publisher. The RFC Series Editor will exercise executive-level management over many of the activities of the RFC Publisher and the RFC Production Center (which can be seen as back-office functions) and will be the entity that: o Faces the community. o Works with the IAOC for contractual responsibilities. o In collaboration with the RFC Series Advisory Group (RSAG), identifies and leads community discussion of important issues and opportunities facing the RFC Series. while the IAB and IAOC maintain their chartered responsibility. More details about the collaboration with the RSAG and the IAB responsibilities can be found in Section 4.1. The RSE does not have the authority to hire or fire RFC Editor contractors or personnel (see Section 4.1.3). 3.1. RFC Series Editor The RFC Series Editor is an individual who may have assistants and who will regularly be provided support from an advisory group (see Section 4.1). The RSE is responsible for: 1. Identifying appropriate steps for RFC Series continuity; 2. Exercising executive-level management over the implementation of policies, processes, and procedures established to ensure the quality and consistency for the RFC Series. The RFC Series Editor will work with the RSAG, and, where appropriate, the IAB and IAOC to develop new policy and see that contractual agreements are met; 3. Taking proposed changes to the community, and working with the IAB so that the IAB can ensure that there is sufficient community review before significant policies or policy changes are adopted; 4. Coordinating with the IAB and/or IAOC and, together with the IAB and/or IAOC, participating in reviews of the RFC Publisher, RFC Production Center, and Independent Submission Editor functions to ensure the above-mentioned continuity; Kolkman & IAB Informational [Page 6] "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 4. Overview The SAVI Protocol MIB module (SAVI-MIB) is conformant to SAVI protocol, and is designed to: An, et al. Expires December 20, 2012 [Page 3] Internet-Draft SAVI-MIB June 2012 o Support centralized management and monitoring of SAVI protocol instance by standard SNMP protocol. o Support configuration and querying of SAVI protocol parameters. o Support configuration and querying of binding entries. Operators may insert and delete manual binding entries. o Support querying of filtering entries. Based on SAVI protocol, attributes and objects of a SAVI protocol instance can be classified into four categories: o System attributes. These attributes are corresponding to a SAVI protocol instance, such as IP Address Assignment Methods and some constants. o Anchor attributes. These attributes are corresponding to a SAVI anchor. Anchor is defined in [I-D.ietf-savi-framework]. o Binding Status Table. This table contains the state of binding between source address and binding anchor (refer to [RFC6620], [I-D.ietf-savi-dhcp], [I-D.ietf-savi-send]). o Filtering Table. This table contains the bindings between binding anchor and address, which is used to filter packets (refer to [RFC6620], [I-D.ietf-savi-dhcp], [I-D.ietf-savi-send]). A table is designed for each category of objects. 5. Structure of the MIB Module This section presents the structure of the SAVI-MIB module. The MIB objects are derived from the SAVI protocol specification. This MIB is composed of a series of tables meant to form the base for managing SAVI entities. The following subsections describe all tables in the SAVI MIB module. 5.1. The SAVI System Table The SAVI System Table (saviObjectsSystemTable) contains the objects which are corresponding to SAVI system-wide parameters. It supports the configuration and collection of SAVI system-wide parameters. There is an entry for each IP stack, IPv4 and IPv6. The table is indexed by: An, et al. Expires December 20, 2012 [Page 4] Internet-Draft SAVI-MIB June 2012 o saviObjectsSystemIPVersion - The IP Version. A textual convention InetVersion defined in RFC4001 is used to represent the different version of IP protocol. It contains the following objects: o saviObjectsSystemMode - Which IP address assignment method the link is running in (refer to [I-D.ietf-savi-framework]). o saviObjectsSystemMaxDhcpResponseTime - A constant defined in SAVI protocol (refer to [I-D.ietf-savi-dhcp]). o saviObjectsSystemBindRecoveryInterval - A constant defined in SAVI protocol (refer to [I-D.ietf-savi-dhcp]). o saviObjectsSystemMaxLeaseQueryDelay - A constant defined in SAVI protocol (refer to [I-D.ietf-savi-dhcp]). o saviObjectsSystemOffLinkDelay - A constant defined in SAVI protocol (refer to [I-D.ietf-savi-dhcp]). The MAX-ACCESS of thses objects is READ-WRITE. Network Operators may do configuration by setting these objects. 5.2. The SAVI Port Table The SAVI Port Table (saviObjectsPortTable) contains the objects which are corresponding to SAVI running parameters of each anchor. It supports the configuration and collection of SAVI parameters of each anchor. There is an entry for each IP stack, IPv4 and IPv6. The table is indexed by: o saviObjectsPortIPVersion - The IP Version. o saviObjectsPortIfIndex - The index value that uniquely identifies the interface to which this entry is applicable. It contains the following objects: o saviObjectsPortValidationAttr - The SAVI-Validation attribute of the port. o saviObjectsPortDhcpTrustAttr - The SAVI-DHCP-Trust attribute of the port. An, et al. Expires December 20, 2012 [Page 5] Internet-Draft SAVI-MIB June 2012 o saviObjectsPortSAVISAVIAttr - The SAVI-SAVI attribute of the port. o saviObjectsPortBindRecoveryAttr - The SAVI-BindRecovery Attribute of the port. o saviObjectsPortFilteringNum - The max filtering number of the Port. The MAX-ACCESS of thses objects is READ-WRITE. Network Operators may configure by setting these objects. 5.3. The SAVI Binding Table The SAVI Binding Table (saviObjectsBindingTable) contains the objects which are corresponding to Binding State Table (BST) defined in SAVI protocol. It contains the binding parameters and state of each binding entry. It supports the collection of binding entries. And an entry can be inserted or deleted if it is a manual binding entry. The table is indexed by: o saviObjectsBindingIpAddressType - IP address type. A textual convention InetAddressType defined in RFC4001 is used to represent the different kind of IP address. o saviObjectsBindingType - which IP address assignment method is used to create the binding entry - manual(1), slaac(2), dhcp(3), send(4). o saviObjectsBindingIfIndex - The index value that uniquely identifies the interface to which this entry is applicable. o saviObjectsBindingIpAddress - The binding source IP address. A textual convention InetAddress defined in RFC4001 is used to define this object. The SAVI Binding Table contains the following objects: o saviObjectsBindingMacAddr - The binding source mac address. o saviObjectsBindingState - The state of the binding entry. o saviObjectsBindingLifetime - The remaining lifetime of the entry. o saviObjectsBindingRowStatus - The status of this row, by which new entries may be created, or old entries be deleted from this table. As defined in RFC2579, the RowStatus textual convention is used to manage the creation and deletion of conceptual rows. For SAVI An, et al. Expires December 20, 2012 [Page 6] Internet-Draft SAVI-MIB June 2012 Binding Table, an entry can be created or deleted only when saviObjectsBindingType=manual. The MAX-ACCESS of thses objects is READ-CREATE. Network Operators may create or delete an entry by setting these objects. 5.4. The SAVI Filtering Table The SAVI Filtering Table (saviObjectsFilteringTable) contains the objects which are corresponding to Filtering Table (FT) defined in SAVI protocol. It supports the collection of filtering entries. The table is indexed by: o saviObjectsFilteringIpAddressType - IP address type. o saviObjectsFilteringIfIndex - The index value that uniquely identifies the interface to which this entry is applicable. o saviObjectsFilteringIpAddress - The source IP address. It contains the following objects: o saviObjectsFilteringMacAddr - The source mac address. The MAX-ACCESS of the object is READ-ONLY. 6. Textual Conventions The textual conventions used in the SAVI-MIB are as follows. The MODULE-COMPLIANCE,OBJECT-GROUP textual convention is imported from SNMPv2-CONF [RFC2580]. The MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, Unsigned32 textual convention is imported from SNMPv2- SMI [RFC2578]. The MacAddress,TimeInterval,RowStatus textual convention is imported from SNMPv2-TC [RFC2579]. The InetVersion,InetAddressType,InetAddress textual convention is imported from INET-ADDRESS-MIB [RFC4001]. The InterfaceIndex textual convention is imported from IF-MIB [RFC2863]. The ip textual convention is imported from IP-MIB [RFC4293]. An, et al. Expires December 20, 2012 [Page 7] Internet-Draft SAVI-MIB June 2012 7. Relationship to Other MIB Modules 7.1. Relationship to the INET-ADDRESS-MIB To support extensibility, IETF defined new textual conventions to represent different IP protocol and different IP address in a unified formation in RFC4001. To support different IP version, a textual convention InetVersion is defined to represent the different version of IP protocol. To support different IP address, a generic Internet address is defined. It consists of two objects: The first one has the syntax InetAddressType, and the second object have the syntax InetAddress. The value of the first object determines how the value of the second is encoded. Since SAVI running mode and parameter is independent of IPv4 and IPv6, so different OID instances should be defined for each protocol. In SAVI-MIB definition, when IP address is used as a part of binding table, it is defined using textual conventions described in INET- ADDRESS-MIB. 7.2. Relationship to the IF-MIB The Interfaces MIB [RFC2863] defines generic managed objects for managing interfaces. This document contains the interface-specific extensions for managing SAVI anchors that are modeled as interfaces. The IF-MIB module is required to be supported on the SAVI device. The interface MUST be modeled as an ifEntry, and ifEntry objects such as ifIndex are to be used as per [RFC2863]. An ifIndex [RFC2863] is used as a common index for interfaces in the SAVI-MIB modules. 7.3. MIB modules required for IMPORTS The SAVI MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579],SNMPv2-CONF [RFC2580], IF-MIB [RFC2863] and INET- ADDRESS-MIB [RFC4001] . 8. Definitions SAVI-MIB DEFINITIONS ::=BEGIN IMPORTS MODULE-COMPLIANCE,OBJECT-GROUP FROM SNMPv2-CONF --RFC2580 MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI --RFC2578 An, et al. Expires December 20, 2012 [Page 8] Internet-Draft SAVI-MIB June 2012 TEXTUAL-CONVENTION,MacAddress,TimeInterval,RowStatus FROM SNMPv2-TC --RFC2579 InterfaceIndex FROM IF-MIB --RFC2863 InetVersion,InetAddressType,InetAddress FROM INET-ADDRESS-MIB --RFC4001 ip FROM IP-MIB --RFC4293 ; saviMIB MODULE-IDENTITY LAST-UPDATED "201206170037Z" --June 17,2012 ORGANIZATION "IETF SAVI Working Group" CONTACT-INFO "WG charter: http://datatracker.ietf.org/wg/savi/charter/ Editor: Changqing An CERNET Postal: Network Research Center, Tsinghua University Beijing 100084 China Email: acq@cernet.edu.cn Jiahai Yang CERNET Postal: Network Research Center, Tsinghua University Beijing 100084 China Email: yang@cernet.edu.cn " DESCRIPTION "This MIB Module is designed to support configuration and monitoring of SAVI protocol. " REVISION "201206170037Z" DESCRIPTION "Initial version" ::= {ip xxx} saviObjects OBJECT IDENTIFIER ::= { saviMIB 1 } -- System parameters for SAVI protocol saviObjectsSystemTable OBJECT-TYPE An, et al. Expires December 20, 2012 [Page 9] Internet-Draft SAVI-MIB June 2012 SYNTAX SEQUENCE OF SaviObjectsSystemEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing savi system-wide parameters." ::= { saviObjects 1 } saviObjectsSystemEntry OBJECT-TYPE SYNTAX SaviObjectsSystemEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing savi system-wide parameters for a particular IP version. " INDEX { saviObjectsSystemIPVersion } ::= { saviObjectsSystemTable 1 } SaviObjectsSystemEntry ::= SEQUENCE { saviObjectsSystemIPVersion InetVersion, saviObjectsSystemMode INTEGER, saviObjectsSystemMaxDhcpResponseTime TimeInterval, saviObjectsSystemBindRecoveryInterval TimeInterval, saviObjectsSystemMaxLeaseQueryDelay TimeInterval, saviObjectsSystemOffLinkDelay TimeInterval } saviObjectsSystemIPVersion OBJECT-TYPE SYNTAX InetVersion MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP version " ::= { saviObjectsSystemEntry 1 } saviObjectsSystemMode OBJECT-TYPE SYNTAX INTEGER { savi-disable(1), savi-default(2), savi-dhcp-only(3), savi-slaac-only(4), savi-dhcp-slaac-mix(5), savi-send(6) } MAX-ACCESS read-write STATUS current DESCRIPTION An, et al. Expires December 20, 2012 [Page 10] Internet-Draft SAVI-MIB June 2012 "IP Address Assignment Methods. " ::= { saviObjectsSystemEntry 2 } saviObjectsSystemMaxDhcpResponseTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "A constant. TimeInterval is defined in RFC 2579, it's a period of time, measured in units of 0.01 seconds, and the value is (0..2147483647). " ::= { saviObjectsSystemEntry 3 } saviObjectsSystemBindRecoveryInterval OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "A constant. TimeInterval is defined in RFC 2579, it's a period of time, measured in units of 0.01 seconds, and the value is (0..2147483647). " ::= { saviObjectsSystemEntry 4 } saviObjectsSystemMaxLeaseQueryDelay OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "A constant. TimeInterval is defined in RFC 2579, it's a period of time, measured in units of 0.01 seconds, and the value is (0..2147483647). " ::= { saviObjectsSystemEntry 5 } saviObjectsSystemOffLinkDelay OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "A constant. TimeInterval is defined in RFC 2579, it's a period of time, An, et al. Expires December 20, 2012 [Page 11] Internet-Draft SAVI-MIB June 2012 measured in units of 0.01 seconds, and the value is (0..2147483647). " ::= { saviObjectsSystemEntry 6 } -- Port parameters for SAVI protocol saviObjectsPortTable OBJECT-TYPE SYNTAX SEQUENCE OF SaviObjectsPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing SAVI parameters of each anchor." ::= { saviObjects 2 } saviObjectsPortEntry OBJECT-TYPE SYNTAX SaviObjectsPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing SAVI running parameters of an anchor." INDEX { saviObjectsPortIPVersion, saviObjectsPortIfIndex } ::= { saviObjectsPortTable 1 } SaviObjectsPortEntry ::= SEQUENCE { saviObjectsPortIPVersion InetVersion, saviObjectsPortIfIndex InterfaceIndex, saviObjectsPortValidationAttr INTEGER, saviObjectsPortDhcpTrustAttr INTEGER, saviObjectsPortSAVISAVIAttr INTEGER, saviObjectsPortBindRecoveryAttr INTEGER, saviObjectsPortFilteringNum Unsigned32 } saviObjectsPortIPVersion OBJECT-TYPE SYNTAX InetVersion MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP version " ::= { saviObjectsPortEntry 1 } An, et al. Expires December 20, 2012 [Page 12]RFC 5620 RFC Editor Model (Version 1) August 2009 5. Developing, maintaining, and publishing the RFC Style Manual for use by authors, editors, the stream managers, the RFC Production Center, and the RFC Publisher; 6. Managing the RFC errata process; 7. Liaising with the IAB; 8. Overseeing consistency of RFCs with the RFC Series and RFC Style Manual. There are many potential issues with respect to RFC Series continuity. To name a few: look and feel of the series, indexing methodologies, accessibility of the publications, IPR and copyright issues, and formatting issues. After identifying the appropriate steps to address such issues, the implementation of those steps resides mostly with the RFC production and publishing functions. Since the IAOC maintains oversight of the implementation, the RFC Series Editor is expected to be invited and to participate in reviews of that implementation. The RFC Series Editor is a senior technology professional with the following qualifications: 1. Strong understanding of the IETF and RFC process. 2. Executive management experience suitable to managing the requirements outlined elsewhere in this document and the many aspects of this role, and to coordinating the overall RFC Editor process. 3. Good understanding of the English language and technical terminology related to the Internet. 4. Good communication skills. 5. Experience with editorial processes. 6. Independent worker. 7. Experience as an RFC author desired. There are alternative selection methods for selecting the individual to serve as the RFC Series Editor: The first alternative involves a Request for Proposal (RFP) process run by the IAOC. The IAOC would seek a person with the listed qualifications in a broadly distributed RFP. The winner would be Kolkman & IAB Informational [Page 7] RFC 5620 RFC Editor Model (Version 1) August 2009 selected by the IAOC in consultation with the IAB, and then, the IAOC would contract for the services. Contract terms, including length of contract, extensions, and renewals, shall be as provided in the RFP. The opportunity to bid shall be broadly available. Fees and expenses to support the administrative operation of the RFC Series Editor would be part of the awarded contract and be part of the IASA budget. The second alternative involves a nomination and confirmation process. Candidates are nominated, and then an individual with the listed qualifications is selected by the Internet community and confirmed by the IAB. An approach similar to the one used by the IAB to select an IAOC member every other year (as described in Appendix A) will be used. Once the selection is made, a contract will be negotiated between the person selected and the IAOC, following the general model above. Financial compensation and expenses to support the administrative operation of the RFC Series Editor selected in this manner would be part of the IASA budget. Based on an Request for Information (RFI) issued by the IAOC in December 2008, the IAOC recommended that the second alternative is chosen for the selection cycle to be completed in 2009. 3.2. Independent Submission Editor The Independent Submission Editor is an individual who may have assistants and who is responsible for: 1. Maintaining technical quality of the Independent Submission stream. 2. Reviewing, approving, and processing Independent Submissions. 3. Forwarding to the Production Center the Internet-Drafts that have been accepted for publication as RFCs in the Independent Submission Stream. 4. Reviewing and approving RFC errata in Independent Submissions. 5. Coordinating work and conforming to general RFC Series policies as specified by the IAB and RSE. 6. Providing statistics and documentation as requested by the RSE and/or IAOC. The Independent Submission Editor is a senior position for which the following qualifications are desired: Kolkman & IAB Informational [Page 8] RFC 5620 RFC Editor Model (Version 1) August 2009 1. Technical competence, i.e., broad technical experience and perspective across the whole range of Internet technologies and applications, and specifically, the ability to work effectively with portions of that spectrum in which no personal expertise exists. 2. Thorough familiarity with the RFC series. 3. An ability to define and constitute advisory and document review arrangements. If those arrangements include an Editorial Board similar to the current one or some equivalent arrangement, assess the technical competence of potential Editorial Board members. 4. Good standing in the technical community, in and beyond the IETF. 5. Demonstrated editorial skills, good command of the English language, and demonstrated history of being able to work effectively with technical documents and materials created by others. 6. The ability to work effectively in a multi-actor environment with divided authority and responsibility similar to that described in this document. The Independent Submission Editor may seek support from an advisory board (see Section 4.2) and may form a team to perform the activities needed to fulfill their responsibilities. The individual with the listed qualifications will be selected by the IAB after input is collected from the community. An approach similar to the one used by the IAB to select an IAOC member every other year (as described in Appendix A) should be used. While the ISE itself is considered a volunteer function, the IAB considers maintaining the Independent Submission stream within the RFC Series part of the IAB's supported activities, and will include the expenses made for the support of the ISE in its IASA-supported budget. 3.3. RFC Production Center RFC Production is performed by a paid contractor, and the contractor responsibilities include: 1. Editing inputs from all RFC streams to comply with the RFC Style Manual; 2. Creating records of edits performed on documents; Kolkman & IAB Informational [Page 9] RFC 5620 RFC Editor Model (Version 1) August 2009 3. Identifying where editorial changes might have technical impact and seeking necessary clarification; 4. Engaging in dialogue with authors, document shepherds, IANA, and/or stream-dependent contacts when clarification is needed; 5. Creating records of dialogue with document authors; 6. Requesting advice from the RFC Series Editor as needed; 7. Providing suggestions to the RFC Series Editor as needed; 8. Coordinating with IANA to perform protocol parameter registry actions; 9. Assigning RFC numbers; 10. Establishing publication readiness of each document through communication with the authors, document shepherds, IANA and/or stream-dependent contacts, and, if needed, with the RFC Series Editor; 11. Forwarding ready-to-publish documents to the RFC Publisher; 12. Forwarding records of edits and author dialogue to the RFC Publisher so these can be preserved; 13. Liaising with IESG and IAB. The RFC Production Center contractor is to be selected by the IAOC through an RFP process. The IAOC will seek a bidder who, among other things, is able to provide a professional, quality, timely, and cost- effective service against the established style and production guidelines. Contract terms, including length of contract, extensions and renewals, shall be as defined in an RFP. The opportunity to bid shall be broadly available. As described in Section 3.1, this model allows the IAOC to recommend the RSE position to be selected through an RFP process. In that case, the model also allows combining the RFC Production Center bid with the RSE bid. For 2009, the recommendation was made that the RSE is selected through an IAB-led selection process. Kolkman & IAB Informational [Page 10] RFC 5620 RFC Editor Model (Version 1) August 2009 3.4. RFC Publisher The RFC Publisher responsibilities include: 1. Announcing and providing on-line access to RFCs. 2. Providing on-line system to submit RFC Errata. 3. Providing on-line access to approved RFC Errata. 4. Providing backups. 5. Providing storage and preservation of records. 6. Authenticating RFCs for legal proceedings. All these activities will be done under general supervision of the RSE and need some level of coordination with various submission streams and the RSE. Implementation of the RFC Publisher function can be pursued in two different ways. The choice between these alternatives will be based on an RFI issued by the IAOC in January 2009. The first alternative is to modify the IETF Secretariat contract to include these services. Expenses to support these services would be part of the revised contract. The second alternative is a separate vendor selected by the IAOC through an RFP process, possibly as part of the same contract as the RFC Series Editor. Expenses to support these services would be part of the awarded contract. 4. Committees 4.1. RFC Series Advisory Group (RSAG) 4.1.1. Charter The purpose of the RSAG is to provide expert, informed guidance (chiefly, to the RSE) in matters affecting the RFC Series operation and development. Such matters include, but are not limited to, issues in operation of the RFC model components, and consideration of additional RFC streams, to give a sense of the range of topics covered. Kolkman & IAB Informational [Page 11] RFC 5620 RFC Editor Model (Version 1) August 2009 The RSAG is chartered by the IAB. As such, it operates independently of the IAB to fulfill that charter, and provides periodic reports to the IAB via the RSE. The group provides guidance to the RSE, who in turn addresses immediate operational issues or opportunities with the ISE, Production Center, or Publisher. In cases where these issues have contractual side-effects, the RSE provides guidance to the IETF Administrative Director (IAD). The RSAG also serves to provide advice to the RSE on longer-term, larger-scale developments for the RFC Series. This informs the proposals the RSE takes to the community for discussion, and the IAD/IAOC as proposals for implementation. The RSAG will assist the RSE in identifying and leading community discussion of important issues and opportunities facing the RFC Series. The IAB retains its oversight role and is responsible for ensuring that adequate community discussion has been held on any such significant topics. 4.1.2. Membership The RSAG full members are all at-large members, selected for their experience and interest in the RFC Series, to provide consistency and constancy of the RFC Series interpretation over time; the members do not represent a particular RFC stream or any organizations. In particular, there is no requirement or expectation that RSAG members will be IAB members. The RSAG members are proposed by the Series Editor in consultation with the sitting RSAG members, and then confirmed and formally appointed by the IAB. In addition to these full members, each RFC stream approver will appoint a liaison to the RSAG to provide context specific to their stream. The liaisons do not have to be members of the stream approval bodies. Initially, there will be no IAOC or IAB liaison for their oversight role; however, as experience is gained, the IAOC, IAB, or RSAG may request such liaisons. The RSAG does not select or appoint the RSE, or any other component of the RFC Editor model, although it acts as an important resource for informing any selection process. It is envisioned that the RSAG will be composed of appointed full members serving staggered 3 year terms, plus the RSE. The full members will serve at the pleasure of the IAB -- appointed by the IAB, and if necessary, removed by the IAB. Kolkman & IAB Informational [Page 12] RFC 5620 RFC Editor Model (Version 1) August 2009 In order to provide continuity and to assist with a smooth transition of the RFC Editor function, the members of the existing RFC Editor Editorial Board who are willing to do so are asked to serve as an interim RSAG, effective as of the time of approval of this document. Within one year from the time the RFC Editor function transitions to the new model and after consideration of the operation of the new model in practice, the interim RSAG and RSE will formulate recommendations to the IAB about this model, regarding the regular composition, size, and selection process for the permanent RSAG in particular. 4.1.3. Disagreements among RFC Editor Entities If during the execution of their activities, a disagreement arises over an implementation decision made by one of the entities in the model, any relevant party should first request a review and reconsideration of the decision. If that party still disagrees after the reconsideration, that party may ask the RSE to decide or, especially if the RSE is involved, that party may ask the IAB Chair (for a technical or procedural matter) or IAD (for an administrative or contractual one) to mediate or appoint a mediator to aid in the discussions, although neither is obligated to do so. All parties should work informally and in good faith to reach a mutually agreeable conclusion. If such a conclusion is not possible through those informal processes, then the matter must be registered with the RFC Series Advisory Group. The RSAG may choose to offer advice to the RSE or more general advice to the parties involved and may ask the RSE to defer a decision until it formulates its advice. However, if a timely decision cannot be reached through discussion, mediation, and mutual agreement, the Series Editor is expected to make whatever decisions are needed to ensure the smooth functioning of the RFC Editor function; those decisions are final. RSE decisions of this type are limited to the functioning of the process and evaluation of whether current policies are appropriately implemented in the decision or need adjustment. In particular, it should be noted that final decisions about the technical content of individual documents are the exclusive responsibility of the stream approvers for those documents, as shown in the illustration in Figure 1. If a disagreement or decision has immediate or future contractual consequences, the Series Editor must identify the issue to the IAOC and, if the RSAG has provided advice, forward that advice as well. Kolkman & IAB Informational [Page 13] RFC 5620 RFC Editor Model (Version 1) August 2009 After the IAOC has notified the IAB, the IAD as guided by the IAOC, with advice provided by the Series Editor, has the responsibility to resolve these contractual issues. If informal agreements cannot be reached and formal RSAG review and/or RSE or stream approver decisions are required, the RSE must identify the issues involved to the community and report them to the IAB in its oversight capacity. The RSE and IAB shall mutually develop a satisfactory mechanism for this type of reporting when and if it is necessary. IAB and community discussion of any patterns of disputes are expected to inform future changes to Series policies including possible updates to this document. 4.2. Independent Submission Stream Editorial Board Today the RFC Editor is supported by an Editorial Board for the review of Independent Submission stream documents. This board is expected to evolve in what we will call the Independent Submission Stream Editorial Board. This volunteer Editorial Board will exist at the pleasure of the ISE, and the members serve at the pleasure of the ISE. The existence of this board is simply noted within this model, and additional discussion of such is considered out of scope of this document. 5. IANA Considerations This document defines several functions within the overall RFC Editor structure, and it places the responsibility for coordination of registry value assignments with the RFC Production Center. The IAOC will facilitate the establishment of the relationship between the RFC Production Center and IANA. This document does not create a new registry nor does it register any values in existing registries, and no IANA action is required. 6. Security Considerations The same security considerations as those in RFC 4844 apply. The processes for the publication of documents must prevent the introduction of unapproved changes. Since the RFC Editor maintains the index of publications, sufficient security must be in place to prevent these published documents from being changed by external parties. The archive of RFC documents, any source documents needed to recreate the RFC documents, and any associated original documents Kolkman & IAB Informational [Page 14] RFC 5620 RFC Editor Model (Version 1) August 2009 (such as lists of errata, tools, and, for some early items, non- machine-readable originals) need to be secured against failure of the storage medium and other similar disasters. The IAOC should take these security considerations into account during the implementation of this RFC Editor model. 7. Acknowledgments The RFC Editor model was conceived and discussed in hallways and on mail lists. The first iteration of the text on which this document is based was drafted by Leslie Daigle, Russ Housley, and Ray Pelletier. In addition to the members of the IAOC and IAB in conjunction with those roles, major and minor contributions were made by (in alphabetical order): Bob Braden, Brian Carpenter, Sandy Ginoza, Alice Hagens, Joel M. Halpern, Alfred Hoenes, Paul Hoffman, John Klensin, Subramanian Moonesamy, and Jim Schaad. The IAOC members at the time the RFC Editor model was approved were (in alphabetical order): Fred Baker, Bob Hinden, Russ Housley, Ole Jacobsen, Ed Juskevicius, Olaf Kolkman, Ray Pelletier (non-voting), Lynn St. Amour, and Jonne Soininen. In addition, Marshall Eubanks was serving as the IAOC Scribe. The IAB members at the time the initial RFC Editor model was approved were (in alphabetical order): Loa Andersson, Gonzalo Camarillo, Stuart Cheshire, Russ Housley, Olaf Kolkman, Gregory Lebovitz, Barry Leiba, Kurtis Lindqvist, Andrew Malis, Danny McPherson, David Oran, Dave Thaler, and Lixia Zhang. In addition, the IAB included two ex- officio members: Dow Street, who was serving as the IAB Executive Director, and Aaron Falk, who was serving as the IRTF Chair. The IAB members at the time the this RFC was approved were (in alphabetical order): Marcelo Bagnulo, Gonzalo Camarillo, Stuart Cheshire, Vijay Gill, Russ Housley, John Klensin, Olaf Kolkman, Gregory Lebovitz, Andrew Malis, Danny McPherson, David Oran, Jon Peterson, and Dave Thaler. Kolkman & IAB Informational [Page 15] RFC 5620 RFC Editor Model (Version 1) August 2009 8. References 8.1. Normative References [1] Daigle, L. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007. 8.2. Informative References [2] Huston, G. and B. Wijnen, "The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process", BCP 113, RFC 4333, December 2005. Kolkman & IAB Informational [Page 16] RFC 5620 RFC Editor Model (Version 1) August 2009 Appendix A. 2009 Selection Process In 2009, the IAB is responsible for the selection of the RFC Series Editor and for the selection of the Independent Submission Editor. The IAOC selects the RFC Production Center and the RFC Publisher from vendors that choose to submit a proposal. The IAOC procurement process is not described in this document. The selection process for the ISE and RSE is taken from [2] but modified to allow for subject-matter experts to advise the IAB, to take into account that the community with interest in the RFC series extends beyond the IETF community. A.1. Ad Hoc Advisory Committee(s) It is expected that the IAB and IAOC will, during the various stages of the bidding process, establish one or more ad hoc advisory committees to assist them in the selection of the various functions. The names of the members of the committees, who do not need to be IAB members or IETF participants, will be made public through the IAB and IAOC minutes and possibly other mechanisms as well. Members of these committees are expected to have an understanding of the RFC series and related processes, and of procedures and interests of the various streams. Members of the subcommittees will be privy to confidential material and are expected to honor confidentiality. Because they are subject to confidential material, they are recused from bidding on any of the functions for which financial compensation is offered. The IAB and IAOC bear the responsibility for the selections of the candidates for defined functions. The committees provide advice and recommendations but are not expected to act as nomination or selection committees. A.2. The IAB Selection Process of an RFC Series Editor and/or an Independent Submission Editor A.2.1. Nominations and Eligibility The IAB will be making a broad public call for nominations. The public call will specify the manner by which nominations will be accepted and the means by which the list of nominees will be published. Self-nominations are permitted. Along with the name and contact information for each candidate, details about the candidate's background and qualifications for the position should be attached to the nomination. Kolkman & IAB Informational [Page 17] RFC 5620 RFC Editor Model (Version 1) August 2009 People that served on the ad-hoc advisory committee(s) mentioned above are not eligible. There are no further limitations. Specifically, nominees do not have to be actively contributing to the IETF and active participation as a working group chair, an IETF Nominating Committee member, or an IAB or IESG member is not a limitation. IAB members who accept a nomination for an IAB-selected position will recuse themselves from IAB selection discussions. A.2.2. Committees in 2009 During the 2009 selection process, a committee assisted the IAOC/IAB in creating the job descriptions and statements of work. This committee may also assist in assessing the bids made to the IAOC for the Production Center and the RFC Publisher. Another committee, the Ad Hoc Committee for Selection of Editorial Functions, assists the IAB in the assessment of the RFC Series Editor and the Independent Submission Editor candidates. A.2.3. Selection The IAB will publish the list of nominated persons prior to making a decision, allowing time for the community to pass any relevant comments to the IAB. When established, the advisory committee will be asked to provide a motivated shortlist. The IAB will review the nomination material, any submitted comments, the shortlist from the advisory committee, and make its selection. It is noted that the community mentioned above is the community with an interest in RFCs and the RFC Editor's functioning; the IETF community is only a part of that community. The main intent is to select the superior candidate, taking the continuity of the series into account. A.2.4. Care of Personal Information The following procedures will be used by the IAB in managing candidates' personal information: o The candidate's name will be published, with all other candidate names, at the close of the nominations period. o Except as noted above, all information provided to the IAB during this process will be kept as confidential to the IAB and, when established, the advisory committee. Kolkman & IAB Informational [Page 18] RFC 5620 RFC Editor Model (Version 1) August 2009 A.2.5. Term of Office and Selection Time Frame Subject to further negotiations and in the interest of providing stability, terms of office are expected to be five years with no restrictions on renewals and with provision for shorter actual contracts and intermediate reviews. In addition, an effort should be made so that terms of office for the RSE, ISE, and RFC Production Center do not terminate concurrently. The selection timeframe for 2009 is roughly: June - IAB calls for nominations for ISE and RSE positions; July - A Committee conducts interviews; Mid-August - Committee recommends individuals to IAB for ISE and RSE positions; Second half of September - IAB appoints ISE and RSE, subject to successful negotiations of agreement with IAOC; Mid-October - Memorandums of understanding (MOUs) executed with IAD, ISE for expenses, RSE for stipend and expenses; Mid-October - Transition begins; January 2010 - Contract begins. The timeline for future selections is subject to recommendation from the RSAG and review by the IAB. Authors' Addresses Internet-Draft SAVI-MIB June 2012 saviObjectsPortIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex. " ::= { saviObjectsPortEntry 2 } saviObjectsPortValidationAttr OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The SAVI-validation attribute of the port. enable(1), the attribute is set. disable(2), the attribute is not set. " ::= { saviObjectsPortEntry 3 } saviObjectsPortDhcpTrustAttr OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The DHCP trust attribute of the port. enable(1), the attribute is set. disable(2), the attribute is not set. " ::= { saviObjectsPortEntry 4 } saviObjectsPortSAVISAVIAttr OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION An, et al. Expires December 20, 2012 [Page 13] Internet-Draft SAVI-MIB June 2012 "The SAVI-SAVI attribute of the port. enable(1), the attribute is set. disable(2), the attribute is not set. " ::= { saviObjectsPortEntry 5 } saviObjectsPortBindRecoveryAttr OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The SAVI-BindRecovery attribute of the port. enable(1), the attribute is set. disable(2), the attribute is not set. " ::= { saviObjectsPortEntry 6 } saviObjectsPortFilteringNum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The max filtering number of the Port." ::= { saviObjectsPortEntry 7 } -- Binding Status Table for SAVI protocol saviObjectsBindingTable OBJECT-TYPE SYNTAX SEQUENCE OF SaviObjectsBindingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing the state of binding between source address and anchor. " ::= { saviObjects 3 } saviObjectsBindingEntry OBJECT-TYPE SYNTAX SaviObjectsBindingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing the state of binding between source An, et al. Expires December 20, 2012 [Page 14] Internet-Draft SAVI-MIB June 2012 address and anchor. Entries are keyed on the source IP address type, binding type, anchor, and source IP address. " INDEX { saviObjectsBindingIpAddressType, saviObjectsBindingType, saviObjectsBindingIfIndex, saviObjectsBindingIpAddress } ::= { saviObjectsBindingTable 1 } SaviObjectsBindingEntry ::= SEQUENCE { saviObjectsBindingIpAddressType InetAddressType, saviObjectsBindingType INTEGER, saviObjectsBindingIfIndex InterfaceIndex, saviObjectsBindingIpAddress InetAddress, saviObjectsBindingMacAddr MacAddress, saviObjectsBindingState INTEGER, saviObjectsBindingLifetime TimeInterval, saviObjectsBindingRowStatus RowStatus } saviObjectsBindingIpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "IP address type of the binding source IP." ::= { saviObjectsBindingEntry 1 } saviObjectsBindingType OBJECT-TYPE SYNTAX INTEGER { manual(1), slaac(2), dhcp(3), send(4) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "IP address assignment methods." ::= { saviObjectsBindingEntry 2 } saviObjectsBindingIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible An, et al. Expires December 20, 2012 [Page 15] Internet-Draft SAVI-MIB June 2012 STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex. " ::= { saviObjectsBindingEntry 3 } saviObjectsBindingIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The binding source IP address" ::= { saviObjectsBindingEntry 4 } saviObjectsBindingMacAddr OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The binding source mac address." ::= { saviObjectsBindingEntry 5 } saviObjectsBindingState OBJECT-TYPE SYNTAX INTEGER { NO_BIND(1), INIT_BIND_OR_TENTATIVE(2), BOUND_OR_VALID(3), TESTING_TP-LT(4), TESTING_VP(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The state of the binding entry. " ::= { saviObjectsBindingEntry 6 } saviObjectsBindingLifetime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-create STATUS current DESCRIPTION "The remaining lifetime of the entry. TimeInterval is defined in RFC 2579, it's a period of time, measured in units of 0.01 seconds, and the value is (0..2147483647). An, et al. Expires December 20, 2012 [Page 16] Internet-Draft SAVI-MIB June 2012 Olaf M. Kolkman (editor) EMail: olaf@nlnetlabs.nl Internet Architecture Board EMail: iab@iab.org Kolkman & IAB Informational [Page 19]