Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol
draft-ietf-ipfix-mib-variable-export-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-04-20
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-04-17
|
10 | (System) | RFC Editor state changed to AUTH48 from AUTH48-DONE |
2017-04-13
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-12-15
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-12-07
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2016-02-12
|
10 | (System) | RFC Editor state changed to AUTH from EDIT |
2016-01-21
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2016-01-21
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2016-01-21
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2016-01-20
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2016-01-20
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2015-12-13
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-11-30
|
10 | (System) | RFC Editor state changed to EDIT |
2015-11-30
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-11-30
|
10 | (System) | Announcement was received by RFC Editor |
2015-11-30
|
10 | (System) | IANA Action state changed to In Progress |
2015-11-30
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-11-30
|
10 | Amy Vezza | IESG has approved the document |
2015-11-30
|
10 | Amy Vezza | Closed "Approve" ballot |
2015-11-30
|
10 | Amy Vezza | Ballot approval text was generated |
2015-11-29
|
10 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2015-11-27
|
10 | Joel Jaeggli | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2015-11-23
|
10 | Stephen Farrell | [Ballot comment] Thanks for the speedy discuss resolution |
2015-11-23
|
10 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2015-11-20
|
10 | Colin McDowall | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2015-11-20
|
10 | Colin McDowall | New version available: draft-ietf-ipfix-mib-variable-export-10.txt |
2015-11-19
|
09 | Cindy Morgan | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2015-11-19
|
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Warren Kumari. |
2015-11-19
|
09 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-11-19
|
09 | Stephen Farrell | [Ballot discuss] I have what I think should be an easily fixed thing I'd like to discuss. Shouldn't there be some text about privacy considerations … [Ballot discuss] I have what I think should be an easily fixed thing I'd like to discuss. Shouldn't there be some text about privacy considerations here? If a MIB has some privacy sensitive value and that is now exported in push mode, that may produce unexpected results. I think implementers might at least need to have some ability to filter values for privacy reasons and that that is something that ought be called out here. One might also want to modify values, e.g. mask IP address bits or modify addresses in other ways, or to zero out values. Again, you probably should say something about that since the receiver of the data might not expect that they get filtered data instead of raw data. (So this could also touch on interop.) I think you could just say the above couple of things, say in section 10. |
2015-11-19
|
09 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2015-11-19
|
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-11-18
|
09 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-11-18
|
09 | Kathleen Moriarty | [Ballot comment] I agree with the SecDir reviewers comments https://mailarchive.ietf.org/arch/msg/secdir/Yeux55VEHEWOxCX5mV-qWfn7eBE and am following that discussion to see updated text that includes a reference for "existing … [Ballot comment] I agree with the SecDir reviewers comments https://mailarchive.ietf.org/arch/msg/secdir/Yeux55VEHEWOxCX5mV-qWfn7eBE and am following that discussion to see updated text that includes a reference for "existing SNMP rules" in the security considerations section: Current text: "However if the exporter is a client of an SNMP engine on the same device it MUST abide by existing SNMP security rules." or the suggested text in a response to that review: > > However, if the exporter is implemented as an SNMP manager > > accessing an SNMP agent, it MUST authenticate itself to the SNMP > > agent and the SNMP agent MUST enforce SNMP access control rules > > as it would for any other SNMP manager. But if the wording in the follow on email is used, is there a reference that can be added for the IPFIX exporter security options in b? a) The exporter acts as an SNMP manager retrieving data from an SNMP agent. In this case, the usual SNMP procedures concerning authentication and authorization apply b) The exporter is generating or capturing the field values itself. In this case the IPFIX approach applies that the IPFIX exporter defines what is exported to whom. |
2015-11-18
|
09 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2015-11-18
|
09 | Kathleen Moriarty | [Ballot comment] I agree with the SecDir reviewers comments and am following that discussion to see updated text that includes a reference for "existing SNMP … [Ballot comment] I agree with the SecDir reviewers comments and am following that discussion to see updated text that includes a reference for "existing SNMP rules" in the security considerations section: Current text: "However if the exporter is a client of an SNMP engine on the same device it MUST abide by existing SNMP security rules." or the suggested text in a response to that review: > > However, if the exporter is implemented as an SNMP manager > > accessing an SNMP agent, it MUST authenticate itself to the SNMP > > agent and the SNMP agent MUST enforce SNMP access control rules > > as it would for any other SNMP manager. But if the wording in the follow on email is used, is there a reference that can be added for the IPFIX exporter security options in b? a) The exporter acts as an SNMP manager retrieving data from an SNMP agent. In this case, the usual SNMP procedures concerning authentication and authorization apply b) The exporter is generating or capturing the field values itself. In this case the IPFIX approach applies that the IPFIX exporter defines what is exported to whom. |
2015-11-18
|
09 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-11-18
|
09 | Ben Campbell | [Ballot comment] I notice the heading says "IPFIX Working Group" even though this is an individual submission. I am agnostic as to whether that is … [Ballot comment] I notice the heading says "IPFIX Working Group" even though this is an individual submission. I am agnostic as to whether that is a problem, since I know this was in ipfix at one time. |
2015-11-18
|
09 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-11-18
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-11-18
|
09 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-11-18
|
09 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-11-17
|
09 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-11-17
|
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-11-17
|
09 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-11-16
|
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-11-14
|
09 | Elwyn Davies | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. |
2015-11-13
|
09 | Benoît Claise | [Ballot Position Update] New position, Recuse, has been recorded for Benoit Claise |
2015-11-12
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2015-11-12
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2015-11-12
|
09 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Withdrawn' |
2015-11-08
|
09 | Joel Jaeggli | Ballot has been issued |
2015-11-08
|
09 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2015-11-08
|
09 | Joel Jaeggli | Created "Approve" ballot |
2015-11-08
|
09 | Joel Jaeggli | Ballot writeup was changed |
2015-11-08
|
09 | Joel Jaeggli | IESG state changed to IESG Evaluation from Waiting for Writeup |
2015-11-08
|
09 | Joel Jaeggli | Write-up for: draft-ietf-ipfix-mib-variable-export-09 Exporting MIB Variables using the IPFIX Protocol === 1. Summary === Document shepherd: Nevil Brownlee Responsible Area Director: Joel Jaeggli … Write-up for: draft-ietf-ipfix-mib-variable-export-09 Exporting MIB Variables using the IPFIX Protocol === 1. Summary === Document shepherd: Nevil Brownlee Responsible Area Director: Joel Jaeggli This document specifies a way to complement IPFIX Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. An IPFIX Options Template and method are specified, which are used to export the extra information required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX. === 2. Review and Consensus === This draft was presented at IETF 85 in Atlanta, at that time it seemed the WG were near consensus. However, the draft's use of the IPFIX mechanisms seemed clumsy; the authors agreed to re-work it to use Extended Specifier Fields (EFS) instead. A revised version using EFS was presented at IETF 86, but it was clear that EFS was a significant extension to IPFIX. Paul Aitken - its lead author - agreed to re-work it again. The current version (-09) requires two new Options Templates and several new IPFIX Information Elements to describe SNMP objects properly; the IE Doctors are curently considering those. However, it does not need any extensions to the IPFIX protocol. Since the IPFIX WG closed down after IETF 88 there has been no discussion of the draft; at least that means that there have been no objections to it! Once the current IE Doctors discussion of it is complete, I believe we'll have something approaching consensus. === 3. Intellectual Property === This draft has Cisco IPR, i.e. "If technology in this document is included in a standard adopted by IETF and any claims of any Cisco patents are necessary for practicing the standard, any party will have the right to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the standard." === 4. Other Points === This document has no downward references. Its IANA Considerations clearly state what IANA is being asked to do, i.e. add some new IPFIX Information Elements to the IPFIX Information Element Registry. Note that one author is one of the IE-Doctors. The ID-nits checker has no complaints. Overall, I believe that this draft is ready for publication as an RFC. ============================== |
2015-11-08
|
09 | Joel Jaeggli | Notification list changed to "Nevil Brownlee" <n.brownlee@auckland.ac.nz> |
2015-11-08
|
09 | Joel Jaeggli | Document shepherd changed to Nevil Brownlee |
2015-11-08
|
09 | Joel Jaeggli | Changed consensus to Yes from Unknown |
2015-11-08
|
09 | Joel Jaeggli | Placed on agenda for telechat - 2015-11-19 |
2015-10-26
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-10-23
|
09 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2015-10-23
|
09 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of [draft-string]. If any part of this review is inaccurate, please let us know. Note: … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of [draft-string]. If any part of this review is inaccurate, please let us know. Note: the designated reviewers for the IPFIX Information Elements registry are currently discussing the registration proposals listed in Action 2. We will not be able to complete these registrations without their approval. IANA understands that upon approval of this document, there are two actions which IANA must complete. ACTION 1: The authors request that two new IPFIX semantics be allocated in IANA's IPFIX registry located at: http://www.iana.org/assignments/ipfix/ IANA understands that the following are to be registered in the IPFIX Structure Data Types Semantics Registry: Value: [ TBD-at-Registration ] Name: snmpCounter Description: An integral value reporting the value of a counter, identical to the Counter32 and Counter64 semantics in [RFC2578], as determined by the field length. Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Name: snmpGauge Description: An integral value identical to the Gauge32 semantic in [RFC2578], and the Gauge64 semantic in [RFC2856], as determined by the field length. Reference: [ RFC-to-be ] ACTION 2: In the IPFIX Information Elements subregistry of the IPFIX registry located at: http://www.iana.org/assignments/ipfix/ twenty-one new registrations are to be added as follows: ElementID: [ TBD-at-Registration ] Name: mibObjectValueInteger Data Type: signed64 Data Type Semantics: identifier Status: Current Description: An IPFIX Information Element which denotes that the integer value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of Integer32 and INTEGER with IPFIX Reduced Size Encoding used as required. The value is encoded as per the standard IPFIX Abstract Data Type of signed64. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectValueOctetString Data Type: octetArray Data Type Semantics: default Status: current Description: An IPFIX Information Element which denotes that an Octet String or Opaque value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of OCTET STRING and Opaque. The value is encoded as per the standard IPFIX Abstract Data Type of octetArray. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectValueOID Data Type: octetArray Data Type Semantics: Status: default Description: An IPFIX Information Element which denotes that an Object Identifier or OID value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of OBJECT IDENTIFIER. Note - In this case the "mibObjectIdentifier" will define which MIB object is being exported while the value contained in this Information Element will be an OID as a value. The mibObjectValueOID Information Element is encoded as ASN.1/BER [BER] in an octetArray. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectValueBits Data Type: octetArray Data Type Semantics: flags Status: current Description: An IPFIX Information Element which denotes that a set of Enumerated flags or bits from a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of BITS. The flags or bits are encoded as per the standard IPFIX Abstract Data Type of octetArray, with sufficient length to accomodate the required number of bits. If the number of bits is not an integer multiple of octets then the most significant bits at end of the octetArray MUST be set to zero. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectValueIPAddress Data Type: ipv4Address Data Type Semantics: default Status: current Description: An IPFIX Information Element which denotes that the IPv4 Address of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of IPaddress. The value is encoded as per the standard IPFIX Abstract Data Type of ipv4Address. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectValueCounter Data Type: unsigned64 Data Type Semantics: snmpCounter Status: current Description: An IPFIX Information Element which denotes that the counter value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of Counter32 or Counter64 with IPFIX Reduced Size Encoding used as required. The value is encoded as per the standard IPFIX Abstract Data Type of unsigned64. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectValueGauge Data Type: unsigned32 Data Type Semantics: snmpGauge Status: current Description: An IPFIX Information Element which denotes that the Gauge value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of Gauge32. The value is encoded as per the standard IPFIX Abstract Data Type of unsigned64. This value will represent a non-negative integer, which may increase or decrease, but shall never exceed a maximum value, nor fall below a minimum value. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectValueTimeTicks Data Type: unsigned32 Data Type Semantics: default Status: current Description: An IPFIX Information Element which denotes that the TimeTicks value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of TimeTicks. The value is encoded as per the standard IPFIX Abstract Data Type of unsigned32. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectValueUnsigned Data Type: unsigned64 Data Type Semantics: identifier Status: current Description: An IPFIX Information Element which denotes that an unsigned integer value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the Base Syntax of unsigned64 with IPFIX Reduced Size Encoding used as required. The value is encoded as per the standard IPFIX Abstract Data Type of unsigned64. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectValueTable Data Type: basicList Data Type Semantics: list Status: current Description: An IPFIX Information Element which denotes that a complete conceptual table will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with a SYNTAX of SEQUENCE OF. This is encoded as a basicList of "mibObjectValueRow"s. The Field ID for the basicList MUST be the same as the ElementID for mibObjectValueRow (below). The mibObjectValueRow MUST be of the same type/OID as specified in this MIB object's syntax. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectValueRow Data Type: subTemplateList Data Type Semantics: list Status: current Description: An IPFIX Information Element which denotes that a row of a conceptual table will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with a SYNTAX of SEQUENCE. This is encoded as a subTemplateList of mibObjectValue Information Elements. The template specified in the subTemplateList MUST be an Options Template and MUST include all the Objects listed in the INDEX clause as Scope Fields. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectIdentifier Data Type: octetArray Data Type Semantics: default Status: current Description: An IPFIX Information Element which denotes that a MIB Object Identifier (MIB OID) is exported in the (Options) Template Record. The mibObjectIdentifier Information Element contains the OID assigned to the MIB Object Type Definition encoded as ASN.1/BER. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibSubIdentifier Data Type: unsigned32 Data Type Semantics: identifier Status: current Description: A non-negative sub-identifier of an Object Identifier (OID). Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibIndexIndicator Data Type: unsigned64 Data Type Semantics: flags Status: current Description: This set of bit fields is used for marking the Information Elements of a Data Record that serve as INDEX MIB objects for an indexed Columnar MIB object. Each bit represents an Information Element in the Data Record with the n-th bit representing the n-th Information Element. A bit set to value 1 indicates that the corresponding Information Element is an index of the Columnar Object represented by the mibFieldValue. A bit set to value 0 indicates that this is not the case. If the Data Record contains more than 64 Information Elements, the corresponding Template SHOULD be designed such that all INDEX Fields are among the first 64 Information Elements, because the mibIndexIndicator only contains 64 bits. If the Data Record contains less than 64 Information Elements, then the extra bits in the mibIndexIndicator for which no corresponding Information Element exists MUST have the value 0, and must be disregarded by the Collector. This Information Element may be exported with IPFIX Reduced Size Encoding. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibCaptureTimeSemantics Data Type: unsigned8 Data Type Semantics: identifier Status: current Description: Indicates when in the lifetime of the flow the MIB value was retrieved from the MIB for a mibObjectIdentifier. This is used to indicate if the value exported was collected from the MIB closer to flow creation or flow export time and will refer to the Timestamp fields included in the same record. This field SHOULD be used when exporting a mibObjectValue that specifies counters or statistics. If the MIB value was sampled by SNMP prior to the IPFIX Metering Process or Exporting Process retrieving the value (i.e. the data is already stale) and it's important to know the exact sampling time, then an additional observationTime* element should be paired with the OID using structured data. Similarly, if different mibCaptureTimeSemantics apply to different mibObject elements within the Data Record, then individual mibCaptureTimeSemantics should be paired with each OID using structured data. Values: 0. undefined 1. begin - The value for the MIB object is captured from the MIB when the Flow is first observed 2. end - The value for the MIB object is captured from the MIB when the Flow ends 3. export - The value for the MIB object is captured from the MIB at export time 4. average - The value for the MIB object is an average of multiple captures from the MIB over the observed life of the Flow Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibContextEngineID Data Type: octetArray Data Type Semantics: default Status: current Description: A mibContextEngineID that specifies the SNMP engine ID for a MIB field being exported over IPFIX. Definition as per [RFC3411] section 3.3 Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibContextName Data Type: string Data Type Semantics: default Status: current Description: This Information Element denotes that a MIB Context Name is specified for a MIB field being exported over IPFIX. Reference [RFC3411] section 3.3 Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectName Data Type: string Data Type Semantics: default Status: current Description: The name (called a descriptor in [RFC2578]) of an object type definition. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectDescription Data Type: string Data Type Semantics: default Status: current Description: The value of the DESCRIPTION clause of an MIB object type definition. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibObjectSyntax Data Type: string Data Type Semantics: default Status: current Description: The value of the SYNTAX clause of an MIB object type definition, which may include a Textual Convention or Subtyping. See [RFC2578]. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] ElementID: [ TBD-at-Registration ] Name: mibModuleName Data Type: string Data Type Semantics: default Status: current Description: The textual name of the MIB module that defines a MIB Object. Units: Range: References: [ RFC-to-be ] Requester: [ RFC-to-be ] Revision: 0 Date: [ TBD-at-Registration ] IANA understands that these two actions are the only ones required to be completed upon approval of this document Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2015-10-14
|
09 | (System) | Notify list changed from draft-ietf-ipfix-mib-variable-export.ad@ietf.org, cmcdowal@brocade.com, draft-ietf-ipfix-mib-variable-export.shepherd@ietf.org, j.schoenwaelder@jacobs-university.de, paitken@brocade.com, bclaise@cisco.com, draft-ietf-ipfix-mib-variable-export@ietf.org to (None) |
2015-10-09
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Niclas Comstedt |
2015-10-09
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Niclas Comstedt |
2015-10-01
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2015-10-01
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2015-10-01
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Warren Kumari |
2015-10-01
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Warren Kumari |
2015-09-28
|
09 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-09-28
|
09 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Exporting MIB Variables using the IPFIX … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Exporting MIB Variables using the IPFIX Protocol) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Exporting MIB Variables using the IPFIX Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-10-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a way to complement IPFIX Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. An IPFIX Options Template and method are specified, which are used to export the extra information required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2146/ https://datatracker.ietf.org/ipr/1436/ |
2015-09-28
|
09 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-09-28
|
09 | Amy Vezza | Last call announcement was changed |
2015-09-27
|
09 | Joel Jaeggli | Last call was requested |
2015-09-27
|
09 | Joel Jaeggli | Last call announcement was generated |
2015-09-27
|
09 | Joel Jaeggli | Ballot approval text was generated |
2015-09-27
|
09 | Joel Jaeggli | Ballot writeup was generated |
2015-09-27
|
09 | Joel Jaeggli | IESG state changed to Last Call Requested from AD Evaluation |
2015-09-07
|
09 | Joel Jaeggli | IESG state changed to AD Evaluation from Publication Requested |
2015-09-04
|
09 | Joel Jaeggli | Assigned to Operations and Management Area |
2015-09-04
|
09 | Joel Jaeggli | Intended Status changed to Proposed Standard |
2015-09-04
|
09 | Joel Jaeggli | IESG process started in state Publication Requested |
2015-09-04
|
09 | (System) | Earlier history may be found in the Comment Log for /doc/draft-johnson-ipfix-mib-variable-export/ |
2015-07-01
|
09 | Paul Aitken | New version available: draft-ietf-ipfix-mib-variable-export-09.txt |
2015-03-16
|
08 | Cindy Morgan | Changed field(s): group,abstract |
2015-01-04
|
08 | Paul Aitken | New version available: draft-ietf-ipfix-mib-variable-export-08.txt |
2014-10-26
|
07 | Paul Aitken | New version available: draft-ietf-ipfix-mib-variable-export-07.txt |
2014-07-04
|
06 | Paul Aitken | New version available: draft-ietf-ipfix-mib-variable-export-06.txt |
2014-03-04
|
05 | Paul Aitken | New version available: draft-ietf-ipfix-mib-variable-export-05.txt |
2014-02-14
|
04 | Colin McDowall | New version available: draft-ietf-ipfix-mib-variable-export-04.txt |
2013-10-21
|
03 | Paul Aitken | New version available: draft-ietf-ipfix-mib-variable-export-03.txt |
2013-07-25
|
(System) | Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-ipfix-mib-variable-export-02 | |
2013-02-25
|
02 | Paul Aitken | New version available: draft-ietf-ipfix-mib-variable-export-02.txt |
2012-10-22
|
01 | Paul Aitken | New version available: draft-ietf-ipfix-mib-variable-export-01.txt |
2012-07-06
|
00 | Paul Aitken | New version available: draft-ietf-ipfix-mib-variable-export-00.txt |