Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information
draft-ietf-ipfix-protocol-rfc5101bis-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-09-12
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-08-29
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-08-09
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2013-08-06
|
10 | (System) | RFC Editor state changed to REF from AUTH |
2013-08-02
|
10 | (System) | RFC Editor state changed to AUTH from EDIT |
2013-07-19
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-07-19
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2013-07-19
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2013-07-18
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-07-17
|
10 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-07-16
|
10 | (System) | RFC Editor state changed to EDIT |
2013-07-16
|
10 | (System) | Announcement was received by RFC Editor |
2013-07-16
|
10 | (System) | IANA Action state changed to In Progress |
2013-07-16
|
10 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-07-16
|
10 | Amy Vezza | IESG has approved the document |
2013-07-16
|
10 | Amy Vezza | Closed "Approve" ballot |
2013-07-16
|
10 | Amy Vezza | Ballot approval text was generated |
2013-07-15
|
10 | Joel Jaeggli | I have reviewed. the changes and they satisfy the outstanding requests. |
2013-07-15
|
10 | Joel Jaeggli | State changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2013-07-11
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-07-11
|
10 | Brian Trammell | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-07-11
|
10 | Brian Trammell | New version available: draft-ietf-ipfix-protocol-rfc5101bis-10.txt |
2013-07-11
|
09 | Cindy Morgan | State changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2013-07-11
|
09 | Ted Lemon | [Ballot comment] I'm abstaining because I think the IANA registry thing is a bad idea, but nobody else does. In general I think the document … [Ballot comment] I'm abstaining because I think the IANA registry thing is a bad idea, but nobody else does. In general I think the document is a good idea, so don't take this too seriously... FORMER DISCUSS: I see a lot of cases of definitions for attributes of option templates where the text defining the attribute has been removed since RFC5101, and [IANA-IPFIX] is given as a reference where the definitions can be found. For example in section 4.3, the definitions for notSentFlowTotalCount, notSentPacketTotalCount and notSentOctetTotalCount. This seems really weird to me. If the text is identical in the document and in the registry, it's certainly fair to say that this is redundant. But the way I would be inclined to address the redundancy would be to keep the text in the IETF standard, and abbreviate the text in the registry, pointing the registry back at the document. The IANA registry is not a standard—it's a living document, which can change over time, so the explanatory text in it can likewise change over time. It probably _won't_, but I think relying on that is a bad idea. To clear this DISCUSS, you would need to give a satisfactory explanation as to why it makes sense to move normative text out of this document into the IANA registry, or you could restore the text to this document, or you could point out another IETF standard that also contains the definitions (and perhaps change the reference in this document to point to that one, rather than to the IANA registry). Or you could get the other ADs to gang up on me and tell me I'm making a fuss over nothing. :) The authors went with the last option above. :) COMMENTS: The document uses the term "treatment," I think as a term of art, but it results in some constructs that are hard to parse, like this one in section 2, Page 8, about halfway down: As sampling is a packet treatment, this definition includes packets selected by a sampling mechanism. It might help to add a terminology section on "packet treatment." However, this depends on the target readership, so I'm by no means demanding that such a section be added; simply suggesting it based on the fact that I stumbled over the term when reading the document. It seems unnecessary to repeat "network byte order (also known as big-endian byte order)" throughout the document. It might be better to just say "network byte order (also known as big-endian byte order)" the first time, and just "network byte order" subsequently. In 6.1.3 and 6.1.4, the floating point format is specified as IEEE 754 in network byte order. IEEE 754 doesn't specify a network byte ordering for floating point numbers. I think the encoding is fairly straightforward, but I am not convinced that a reader of this document who did not already know what IEEE 754 encoding in network byte order means would be able to figure it out. It would help to have a reference here to a document that defines what "network byte order" means here, or just a quick statement about how the bytes are arranged. In 8.2, there's a paragraph that's supposed to clarify the applicability of templates to data records that's got such a big parse stack it left my head spinning. I propose the following change: OLD: Put another way, a Template describes Data Records contained in IPFIX Messages with an Export Time between the Export Time of the IPFIX Message containing the Template Record and either the Export Time of the IPFIX Message containing the Template Withdrawal withdrawing it or the end of the Transport Session, inclusive. NEW: Put another way, a Template describes Data Records contained in IPFIX messages when the export time of such messages is between a specific start and end time. The start time is the Export Time of the IPFIX Message containing the Template record. The end time is one of two times. If the template is withdrawn during the session, then it is the Export Time of the IPFIX message containing the Template Withdrawal for the template. Otherwise, it is the end of the Transport Session. In the last paragraph of the first part of section 9, the text does not mention the handling of a malformed message in the case of TCP transport. I think in this case there is no way to resynchronize, because it's impossible to characterize the error that caused the malformed message. That being the case, doesn't the TCP connection have to be dropped when a malformed message is encountered? Shouldn't this be mentioned either in Section 9 or Section 10.4? Overall this update to RFC 5101 looks like a significant improvement. Thanks for doing it! |
2013-07-11
|
09 | Ted Lemon | Ballot comment text updated for Ted Lemon |
2013-07-11
|
09 | Cindy Morgan | [Ballot Position Update] Position for Ted Lemon has been changed to Abstain by Cindy Morgan |
2013-07-10
|
09 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-07-10
|
09 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-07-10
|
09 | Brian Trammell | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-07-10
|
09 | Brian Trammell | New version available: draft-ietf-ipfix-protocol-rfc5101bis-09.txt |
2013-07-09
|
08 | Ted Lemon | [Ballot discuss] I see a lot of cases of definitions for attributes of option templates where the text defining the attribute has been removed since … [Ballot discuss] I see a lot of cases of definitions for attributes of option templates where the text defining the attribute has been removed since RFC5101, and [IANA-IPFIX] is given as a reference where the definitions can be found. For example in section 4.3, the definitions for notSentFlowTotalCount, notSentPacketTotalCount and notSentOctetTotalCount. This seems really weird to me. If the text is identical in the document and in the registry, it's certainly fair to say that this is redundant. But the way I would be inclined to address the redundancy would be to keep the text in the IETF standard, and abbreviate the text in the registry, pointing the registry back at the document. The IANA registry is not a standard—it's a living document, which can change over time, so the explanatory text in it can likewise change over time. It probably _won't_, but I think relying on that is a bad idea. To clear this DISCUSS, you would need to give a satisfactory explanation as to why it makes sense to move normative text out of this document into the IANA registry, or you could restore the text to this document, or you could point out another IETF standard that also contains the definitions (and perhaps change the reference in this document to point to that one, rather than to the IANA registry). Or you could get the other ADs to gang up on me and tell me I'm making a fuss over nothing. :) |
2013-07-09
|
08 | Ted Lemon | Ballot discuss text updated for Ted Lemon |
2013-07-09
|
08 | Ted Lemon | [Ballot discuss] I see a lot of cases where definitions for attributes of option templates where the definitions of fields have been removed since RFC5101 … [Ballot discuss] I see a lot of cases where definitions for attributes of option templates where the definitions of fields have been removed since RFC5101, and [IANA-IPFIX] is given as a reference where the definitions can be found. For example in section 4.3, the definitions for notSentFlowTotalCount, notSentPacketTotalCount and notSentOctetTotalCount. This seems really weird to me. If the text is identical in the document and in the registry, it's certainly fair to say that this is redundant. But the way I would be inclined to address the redundancy would be to keep the text in the IETF standard, and abbreviate the text in the registry, pointing the registry back at the document. The IANA registry is not a standard—it's a living document, which can change over time, so the explanatory text in it can likewise change over time. It probably _won't_, but I think relying on that is a bad idea. To clear this DISCUSS, you would need to give a satisfactory explanation as to why it makes sense to move normative text out of this document into the IANA registry, or you could restore the text to this document, or you could point out another IETF standard that also contains the definitions (and perhaps change the reference in this document to point to that one, rather than to the IANA registry). Or you could get the other ADs to gang up on me and tell me I'm making a fuss over nothing. :) |
2013-07-09
|
08 | Ted Lemon | [Ballot comment] The document uses the term "treatment," I think as a term of art, but it results in some constructs that are hard to … [Ballot comment] The document uses the term "treatment," I think as a term of art, but it results in some constructs that are hard to parse, like this one in section 2, Page 8, about halfway down: As sampling is a packet treatment, this definition includes packets selected by a sampling mechanism. It might help to add a terminology section on "packet treatment." However, this depends on the target readership, so I'm by no means demanding that such a section be added; simply suggesting it based on the fact that I stumbled over the term when reading the document. It seems unnecessary to repeat "network byte order (also known as big-endian byte order)" throughout the document. It might be better to just say "network byte order (also known as big-endian byte order)" the first time, and just "network byte order" subsequently. In 6.1.3 and 6.1.4, the floating point format is specified as IEEE 754 in network byte order. IEEE 754 doesn't specify a network byte ordering for floating point numbers. I think the encoding is fairly straightforward, but I am not convinced that a reader of this document who did not already know what IEEE 754 encoding in network byte order means would be able to figure it out. It would help to have a reference here to a document that defines what "network byte order" means here, or just a quick statement about how the bytes are arranged. In 8.2, there's a paragraph that's supposed to clarify the applicability of templates to data records that's got such a big parse stack it left my head spinning. I propose the following change: OLD: Put another way, a Template describes Data Records contained in IPFIX Messages with an Export Time between the Export Time of the IPFIX Message containing the Template Record and either the Export Time of the IPFIX Message containing the Template Withdrawal withdrawing it or the end of the Transport Session, inclusive. NEW: Put another way, a Template describes Data Records contained in IPFIX messages when the export time of such messages is between a specific start and end time. The start time is the Export Time of the IPFIX Message containing the Template record. The end time is one of two times. If the template is withdrawn during the session, then it is the Export Time of the IPFIX message containing the Template Withdrawal for the template. Otherwise, it is the end of the Transport Session. In the last paragraph of the first part of section 9, the text does not mention the handling of a malformed message in the case of TCP transport. I think in this case there is no way to resynchronize, because it's impossible to characterize the error that caused the malformed message. That being the case, doesn't the TCP connection have to be dropped when a malformed message is encountered? Shouldn't this be mentioned either in Section 9 or Section 10.4? Overall this update to RFC 5101 looks like a significant improvement. Thanks for doing it! |
2013-07-09
|
08 | Ted Lemon | [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon |
2013-07-08
|
08 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-07-08
|
08 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-07-07
|
08 | Adrian Farrel | [Ballot comment] I hate the idea of tit-for-tat Discusses and will not raise one. However, having recently seen a number of Discusses entered on documents … [Ballot comment] I hate the idea of tit-for-tat Discusses and will not raise one. However, having recently seen a number of Discusses entered on documents saying that insufficient attention had been paid to RFC 5706 and the manageability issues and impacts for protcols, I must observe that this document is considerably lacking in that department. I looked for, but could not find an existing RFC providing a management framework for IPFIX although I do notice that a MIB module exists. Maybe RFC 5153 is supposed to cover this, but on a brief skim it does not seem to give much information about how IPFIX is managed. Please note that just because IPFIX is, itself, a management protocol does not mean that the impact that the impact on te network of its use should not be considered. Indeed, there are considerable concerns about how IPFIX could impact a live network. Furthermore, IPFIX needs to be managed, operated, and diagnosed in its own right, and that bears description. I leave it to the sponsoring AD and document editors to examine why they are comfortable to progress this document without this material. --- Section 8.4 Default settings for these values are deployment- and application-specific. I.e., there are no default settings? |
2013-07-07
|
08 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-07-05
|
08 | Joel Jaeggli | [Ballot comment] The opsdir review of the latest draft is extensive... Thanks sue for doing it Appendix A. Operations and Management Review Checklist Well written. … [Ballot comment] The opsdir review of the latest draft is extensive... Thanks sue for doing it Appendix A. Operations and Management Review Checklist Well written. Only a few technical questions/considerations: a) What happens when different observation points of an observation domain have different levels of timing (nano-second vs. second)? Does the second timing data get put in a different queue than nano-second data? b) Is there key rotation with DLTS using 2-way/3-way/ or 4-way handshake? c) What happens if the transports switch rapidly (UDP to TCP to STCP and rotate (UDP to TCP to UDP)? Are these denial of service attacks? Editorial: page 8 Flow key – could use an example. page 25 – 4.1 end of sentence change from: ; see (IPFIX-IANA] for their definitions” to: defined in [IPFIX-IANA]: p. 36 Section 8.0 last paragraph – could use an example. p. 50 section 11.1 – Last paragraph the offset by commas that starts “,i.e., a true and ends (and/or TCP), this” is confusing. Please reword p. 51 11.2 para. 1 “[RFC5246] and [5347],” to [RFC5246] and [5347]” otherwise sentence does not have strong sense of while.’ p. 52 section 11.4, para. 2 change “or scope information, a large amount” to “or scope information, or a large amount” p. 53 “section 11.4 para 5 change “a Collecting process; if provided, the” to “a Collecting process; and if provided, the” A.1. Operational Considerations 1. Has deployment been discussed: a. Does the document include a description of how this protocol or technology is going to be deployed and managed? Actual Deployments are not discussed in depth. Management and operational conditions for multiple transport, DOS, and scaling issues are discussed. b. Is the proposed specification deployable? If not, how could it be improved? This solution has description of scaling and management concerns. Any solution that monitors at per interface or more refined will run into issues with scaling. Improving the deployment would take another approach to the problem of store/forward or trigger updates. However, this document is about updating an existing process. For this approach, the authors have done a good job at working through possible refinements. If IETF wants c. Does the solution scale well from the operational and management perspective? Does the proposed approach have any scaling issues that could affect usability for large-scale operation? Most issues have been mentioned. A few things that should be considered: 1) fluctuations between times and queuing for different observation points or different data and 2) fluctuations if the transport failures cause the implementation to rate between transports. d. Are there any coexistence issues? Coexistence issues in transports or IDs are clearly stated. The document specifies it is interoperable with previous version of protocol [RFC101] 2. Has installation and initial setup been discussed? * Is the solution sufficiently configurable? Are configuration parameters clearly defined? Are configuration parameters normalized? Does the configuration have a reasonable default value? Solution appears to be configurable, defined, and normalized, with default values, but that configuration is dealt with elsewhere, and it is not the topic of this draft. o Configuration: RFC6615 (MIB), RFC627 (NETCONF), o Implementation guidelines [RFC5153], testing [RFC5471] * Will configuration be pushed to a device by a configuration manager, or pulled by a device from a configuration server? The MIB and NETCONF options allow either configuration manager to push the information. It is not clear if the IPFix device, exporter, collecting process or collector can pull global configuration. Since the TLVs in a sense self-configure, this is in a sense pulling the configuration. * How will the devices and managers find and authenticate each other? The devices and managers appear to find each other in an a priori manner via configuration. Group functions exist for observation point to observation domain, collecting processes to collecting hosts, and exporter processes to exporters. However, it does not appear that these grouping processes self-detect. The data within these monitoring flows self-detect but the identity does not appear to find each outside of configuration. If I have missed this, you might consider that I re-read RFC3917, RFC5470, RFC6615(MIB), RFC6728(netconf), RFC6727 (MIB), and RFC5102bis (MIB). RFC6728 indicates that the following trees/substrees contain sensitive information and write operations can have an impact: a) /ipfix/Observation b) ipfix/cache c) ipfix/exportingProcess d) ipfix/collectingProcess Due to these statements and section 11 that states an IPFIX collecting process (or processes) must prevent collection from an unauthorized Exporting Process or the export of data to an unauthorized collected process. This implies that the “discover” each method would need additional security mechanisms. 3. Has the migration path been discussed? Are there any backward compatibility issues? The document states the protocol is interoperable with RFC5101. The self-defining mechanism seems to provide this. 4. Have the Requirements on other protocols and functional components been discussed? In quick summary – Yes. The smorgasbord of options and parameters has been described, The impact of the ipfix process on the underlying carrying protocols (UDP, TCP, STCP), the device/node in the being sampled, the exporters impact, the collectors impact have been carefully specified. New protocol functions are either specified or reference by RFC. The NETCONF/YANG or MIB models are given as Management. 5. Has the impact on network operation been discussed? This document does discuss: o how ipfix increases traffic load and choice the network operator has in managing, o how ipfix will increase traffic load on existing networks and how to manage it, o how the protocol use impacts exporting processes and exporter, collecting processes and collector, o how the device impacts the behaviors of other protocols by sending traffic load and how to manage it, o how the device requires security. Since the IDs are self-defining, it does not appear that the DNS service has a critical impact on these. The DNS-ID is mutual authentication process which requires the DNS-ID as specified in section 6.4 of RFC6125. The security requires that the Common-Name (CN-IDs) not be placed in identifiers. 6. Have suggestions for verifying correct operation been discussed? The Testing operations exists RFC5471 and RFC5153. Since the protocols are interoperable only the differences need to be examine. The only differences that section 1.1 notes that impact implementation and testing are the timer encodings link to epochs or rollover, and template management relaxation. While section 5 and section 8 cover this information to one skilled in the art, it may be worthwhile to update both RFC5471 and RFC5153 with the appropriate information. 7. Has management interoperability been discusses? In short, yes. This protocol is a model protocol for information models, data models, and choices across platforms. 8. Are there fault or threshold conditions that should be reported This management information has timing implications and ties to a timing utility. The information is reporting on a constant stream. There does not appear to be any notifications defined in MIBs. This is not(!!) a polling application for event-drive. Overload alarms/notifications might be useful, except they might further provide a DOS attack. State saving, caching, template definition keeping are described carefully and thoroughly. 9. Is configuration discussed? See Section 3.4. * Are configuration defaults and default modes of operation considered? Defaults are described in MIB. Default process in this document. The discussion seems sufficient. * Is there discussion of what information should be preserved across reboots of the device or the management system? Can devices realistically preserve this information through hard reboots where physical configuration might change (e.g., cards might be swapped while a chassis is powered down)? Topics regarding reboot are not covered in this document. The word restart is only used regarding restarting the UDP. The word reboot is not used. A.2. Management Considerations Do you anticipate any manageability issues with the specification? 1. Is management interoperability discussed? The management may be centralized or distribution or a combination. The collector processes are considered to be remote from the exporting processes. However, the exportation/collection can be in the same virtual environment. No textual or graphical user interfaces are required. The format of the protocol utilizes TLVs. The internal data may be considered “sensitive” and may be encrypted due to its sensitivity whether it is textual or binary. 2. Is management information discussed? See Section 3.2. * What is the minimal set of management (configuration, faults, performance monitoring) objects that need to be instrumented in order to manage the new protocol? This is not discussed in this document. 3. Is fault management discussed? See Section 3.3. * Is Liveness Detection and Monitoring discussed? For the liveness indications for the transport protocols (STCP, UDP, TCP) and the exterior needs for liveness/monitoring neded when UDP is issued. * Does the solution have failure modes that are difficult to diagnose or correct? Faults and alarms are logged. However, if errors reoccur the mere keeping of the faults may overload. An overload mechanisms on exporting was discussed in 4.2 (Metering process)and 4.3 exporting process. 4. Is configuration management discussed? * Is protocol state information exposed to the user? MIBS and YANG/netconf model expose state and tables to user. * Significant failures of transport, stopping metering (4.2), stopping export (4.3) are discussed. 5. Is accounting management discussed? Only in terms of the link between performance data and accounting. 6. Is performance management discussed? See Section 3.6. * Protocol impacts performance of nodes (exporter load, collector load) and the network data passage (due to amount of data sent. This is discussed. * Protocol performance information is exposed when the information is dropped (metering 4.2, exporting, 4.3). The performance issues are discussed, but the performance metrics * Is protocol performance information exposed to the user? 7. Is security management discussed? Security features required to support IPFIX are discussed in section 11. This section discussed the security features the protocol requires, the applicability of TLS and DTLS, the usage of a unique secure channel, the mutual authentication, protection against DOS, and security issues with UDP only, requirement to log IPFIX attack, how to secure the collector, and the need to secure the data collected. A.3. Documentation * Is an operational considerations and/or manageability section part of the document? Security section is. The document weaves the operational considerations and management within the whole document since this is a protocol that impacts monitoring. The actual management and monitoring of the protocol doing the flow monitoring is part of this discussion. The configuration and data models are (thankfully) elsewhere described. * Does the proposed protocol have a significant operational impact on the Internet? Yes, yes, and yes! * Is there proof of implementation and/or operational experience? Significant lessons learned are causing the update. No specific implementation or operational experience is noted. |
2013-07-05
|
08 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2013-07-04
|
08 | Joel Jaeggli | back in iesg eval after successful last call |
2013-07-04
|
08 | Joel Jaeggli | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-06-28
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-06-27
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Brian Weis. |
2013-06-21
|
08 | Cindy Morgan | Note field has been cleared |
2013-06-21
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-06-21
|
08 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-ipfix-protocol-rfc5101bis-08. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-ipfix-protocol-rfc5101bis-08. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the IPFIX Information Element Registry in the IP Flow Information Export (IPFIX) Entities registry located at: http://www.iana.org/assignments/ipfix/ipfix.xml all reference to RFC5101 will be updated to [ RFC-to-be ]. In addition, at the IANA Matrix, the reference to Internet Draft draft-ietf-ipfix-information-model-rfc5102bis-10 for IPFIX Information Elements will be updated to [ RFC-to-be ]. IANA understands that this is the only action required 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. |
2013-06-20
|
08 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Withdrawn' |
2013-06-20
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
2013-06-20
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
2013-06-14
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2013-06-14
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2013-06-14
|
08 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Withdrawn' |
2013-06-14
|
08 | Jean Mahoney | Closed request for Telechat review by GENART with state 'Withdrawn' |
2013-06-14
|
08 | Jean Mahoney | Requested Last Call review by GENART |
2013-06-14
|
08 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Specification of the IP Flow … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information) to Internet Standard The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information' as Internet 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 2013-06-28. 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 the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1927/ |
2013-06-14
|
08 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-06-14
|
08 | Amy Vezza | Last call announcement was generated |
2013-06-14
|
08 | Joel Jaeggli | Placed on agenda for telechat - 2013-07-11 |
2013-06-14
|
08 | Joel Jaeggli | Last call was requested |
2013-06-14
|
08 | Joel Jaeggli | 08 Posted. AD Reviewed. |
2013-06-14
|
08 | Joel Jaeggli | State changed to Last Call Requested from AD Evaluation::AD Followup |
2013-06-13
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-06-13
|
08 | Brian Trammell | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-06-13
|
08 | Brian Trammell | New version available: draft-ietf-ipfix-protocol-rfc5101bis-08.txt |
2013-06-12
|
07 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-06-11
|
07 | Joel Jaeggli | Removed from agenda for telechat |
2013-06-11
|
07 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-06-11
|
07 | Spencer Dawkins | [Ballot comment] Brian provided explanations and text proposals (following), and these proposals address my DISCUSS (cleared) and all but one of my comments. On the … [Ballot comment] Brian provided explanations and text proposals (following), and these proposals address my DISCUSS (cleared) and all but one of my comments. On the #3 text proposal below ... we're talking about an Observation Domain using a single TCP connection, is that correct? If an OD sends a TCP stream that looks like this (each observation is transmitted as a separate IP packet) - Observation 1 - Observation 2 (assume this one gets lost in the network) - Observation 3 - Observation 4 - Observation 5 TCP guarantees in-order delivery, so the sending TCP will retransmit Observation 2 tenaciously, and the receiving TCP holds everything it receives after Observation 2 until it can deliver the retransmitted Observation 2. The Collecting Process won't see Observation 3 until after Observation 2 is successfully transmitted. If two Observation Domains, "a" and "b", are sharing a single TCP connection, and the interleaved TCP stream looks like this: - Observation a-1 - Observation a-2 (assume this one gets lost in the network) - Observation a-3 - Observation b-1 - Observation b-2 - Observation b-3 - Observation a-4 - Observation b-4 - Observation b-5 - Observation a-5 the in-order delivery guarantee spans Observation Domains, so not only does the receiving TCP hold everything for Observation Domain "a" until it receives Observation a-2, it holds everything for Observation Domain "b", because all of these observations are being blocked by the same head of line problem with the same TCP connection. So in this proposed text: Exporting Processes may choose IPFIX Message lengths lower than the maximum in order to avoid head-of-line blocking and/or to ensure timely export of Data Records. I think you can minimize head-of-line blocking, but I don't think you can avoid it. Maybe minimizing head-of-line blocking is OK (the Collecting Process is, after all, not a human, so I'm not sure why it would care about head-of-line blocking, as long as it sees reliable in-order delivery in the fullness of time), so I don't want to be difficult, but I did want to try to explain better what I was trying to say. -- From Brian: To summarize, I suggest the following changes to the document to address this DISCUSS and COMMENT: (1) NEW definition for Sequence Number in Section 3.1 (s/SHOULD/can/): Sequence Number Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process. Each SCTP Stream counts sequence numbers separately, while all messages in a TCP connection or UDP transport session are considered to be part of the same stream. This value can be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Options Template Records do not increase the Sequence Number. (2) NEW Section 10.2.5. Failover (in 10.2 SCTP) (clarify failure detect by lower-layer timeout): If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish an association, SCTP will automatically retry association establishment using exponential backoff. The Exporter MAY log an alarm if the underlying SCTP association establishment times out; this timeout should be configurable on the Exporter. The Exporting Process MAY open a backup SCTP association to a Collecting Process in advance, if it supports Collecting Process failover. (3) NEW Section 10.4.3. MTU paragraph 2 (remove confusing head of line blocking language): Exporting Processes may choose IPFIX Message lengths lower than the maximum in order to avoid head-of-line blocking and/or to ensure timely export of Data Records. (4) NEW Section 10.4.4. Connection Establishment and Shutdown first two paragraphs: The IPFIX Exporting Process initiates a TCP connection to the Collecting Process. An Exporting Process MAY support more than one active connection to different Collecting Processes (including the case of different Collecting Processes on the same host). An Exporting Process MAY support more than one active connection to the same Collecting Process to avoid head of line blocking across Observation Domains. The Exporter MAY log an alarm if the underlying TCP connection establishment times out; this timeout should be configurable on the Exporter. (5) NEW Section 10.4.5. Failover (in 10.4 TCP) (clarify failure detect by lower-layer timeout): If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish a connection, TCP will automatically retry connection establishment using exponential backoff. The Exporter MAY log an alarm if the underlying TCP connection establishment times out; this timeout should be configurable on the Exporter. The Exporting Process MAY open a backup TCP connection to a Collecting Process in advance, if it supports Collecting Process failover. |
2013-06-11
|
07 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to No Objection from Discuss |
2013-06-11
|
07 | Joel Jaeggli | requested by the authors for new rev. needs new ietf last call. |
2013-06-11
|
07 | Joel Jaeggli | State changed to AD Evaluation::Revised I-D Needed from IESG Evaluation |
2013-06-11
|
07 | Joel Jaeggli | currently requested status |
2013-06-11
|
07 | Joel Jaeggli | Intended Status changed to Internet Standard from Proposed Standard |
2013-06-11
|
07 | Martin Stiemerling | [Ballot comment] In support of Spencer's DISCUSS point |
2013-06-11
|
07 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-06-10
|
07 | Sean Turner | [Ballot comment] Should probably say something about the version of DTLS you want supported in s11.3 or is that covered in s11.1? Do you need … [Ballot comment] Should probably say something about the version of DTLS you want supported in s11.3 or is that covered in s11.1? Do you need to up the SHOULD in RFC 6347 about the cookie exchange to a MUST? |
2013-06-10
|
07 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-06-10
|
07 | Stephen Farrell | [Ballot comment] - I mostly used the diff to 5101 for this review. - In section 8, you have new text saying that the CP … [Ballot comment] - I mostly used the diff to 5101 for this review. - In section 8, you have new text saying that the CP MUST store all template record information for the duration of each transport section. I wondered if that creates any potential for a DoS? - Is all the naming stuff in 11.3 fully worked out and likely to be, or actually, implemented? E.g. it says that use of DNS-ID is a SHOULD be implementaton of CN based lists is a MUST - does that make sense really? - You say: SSL/TLS before TLS1.1 is a MUST NOT, TLS1.1 is a MUST and TLS1.2 is a SHOULD. Would it not be better to just say TLS1.2 is a MUST? Perhaps TLS1.2 support is (soon) more likely to be widely available for this kind of application - did you check recently? (I didn't, and [1] is a year old now.) [1] http://www.imperialviolet.org/2012/06/08/tlsversions.html - I wondered if its possible to analyse network timing to try to discover what kind of IPFIX collecting is going on, for example, via timing analysis. Since I don't know, I'm not asking that you add something to section 11, but I do wonder:-) |
2013-06-10
|
07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-06-09
|
07 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-06-06
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Kathleen Moriarty |
2013-06-06
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Kathleen Moriarty |
2013-06-03
|
07 | Spencer Dawkins | [Ballot discuss] This should be an easy one, especially if the resolution is to include some of the material from RFC 5101 that was taken … [Ballot discuss] This should be an easy one, especially if the resolution is to include some of the material from RFC 5101 that was taken out in this revision. In this text: 10.4.5. Failover If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish a connection, TCP will automatically retry connection establishment using exponential backoff. The Exporter MAY log an alarm if the time to establish the association exceeds a specified threshold, configurable on the Exporter. I'm somewhat confused about this description. I agree with the first sentence about TCP behavior, but is there any behavior at the IPFIX layer that you would like to specify, if the Exporting Process can't open a connection quickly enough? Does it matter whether TCP is still exponentially backing off on SYN retransmissions, or has finally given up and returned an error? I note that RFC 5101 talks about RESETing TCP connections, but I'm not seeing equivalent text in this draft. I think I have the same question about 10.2.5 Failover, for SCTP, but the question occurred to me while looking at 10.4.5. |
2013-06-03
|
07 | Spencer Dawkins | [Ballot comment] In this text: 3.1. Message Header Format Sequence Number Incremental sequence counter modulo 2^32 of all IPFIX Data Records … [Ballot comment] In this text: 3.1. Message Header Format Sequence Number Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process. Each SCTP Stream counts sequence numbers separately, while all messages in a TCP connection or UDP transport session are considered to be part of the same stream. This value SHOULD be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Options Template Records do not increase the Sequence Number. I wasn't clear on why this is an RFC 2119 SHOULD. Does it help with interoperability? In this text: 10.4.3. MTU However, if an Exporting Process exports data from multiple Observation Domains, it should be careful to choose IPFIX Message lengths appropriately to minimize head-of-line blocking between different Observation Domains. Multiple TCP connections MAY be used to avoid head-of-line blocking between different Observation Domains. I understand the point being made here. What I'm confused about, is that if head-of-line blocking between streams matters enough to affect the choice of IPFIX Message length, you can still experience head-of-line blocking between Observation Domains at any IPFIX Message length. Is this a real concern? If so, I wonder if better guidance might be to either recommend multiple TCP connections more strongly, or just say "if you care about head-of-line blocking between Observation Domains, SCTP with multiple streams might be the best choice of transport protocols". |
2013-06-03
|
07 | Spencer Dawkins | [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins |
2013-05-30
|
07 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Brian Weis. |
2013-05-30
|
07 | Stewart Bryant | [Ballot Position Update] New position, Recuse, has been recorded for Stewart Bryant |
2013-05-29
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-05-29
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-05-29
|
07 | Benoît Claise | [Ballot Position Update] New position, Recuse, has been recorded for Benoit Claise |
2013-05-28
|
07 | Joel Jaeggli | Placed on agenda for telechat - 2013-06-13 |
2013-05-28
|
07 | Joel Jaeggli | Ballot has been issued |
2013-05-28
|
07 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2013-05-28
|
07 | Joel Jaeggli | Created "Approve" ballot |
2013-05-28
|
07 | Joel Jaeggli | Ballot writeup was changed |
2013-05-28
|
07 | Joel Jaeggli | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-05-28
|
07 | Joel Jaeggli | Changed document writeup |
2013-05-27
|
07 | Benoît Claise | Changed document writeup |
2013-05-23
|
07 | Brian Trammell | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-05-23
|
07 | Brian Trammell | New version available: draft-ietf-ipfix-protocol-rfc5101bis-07.txt |
2013-05-01
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2013-05-01
|
06 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-ipfix-protocol-rfc5101bis-06. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-ipfix-protocol-rfc5101bis-06. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We understand that, upon approval of this document, there is a single action which we must complete. In the IP Flow Information Export (IPFIX) Entities registry located at: http://www.iana.org/assignments/ipfix/ipfix.xml the registry will be updated so that the references all point to [ RFC-to-be ] rather than RFC5102. References to RFC5102 will remain part of the historical record. We understand that this is the only action 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. |
2013-05-01
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-04-24
|
06 | Benoît Claise | Document shepherd changed to Juergen Quittek |
2013-04-18
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Kathleen Moriarty |
2013-04-18
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Kathleen Moriarty |
2013-04-18
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
2013-04-18
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
2013-04-17
|
06 | (System) | IANA Review state changed to IANA - Review Needed from IANA OK - Actions Needed |
2013-04-17
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-04-17
|
06 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Specification of the IP Flow Information … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information) to Proposed Standard The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information' 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 2013-05-01. 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 the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1927/ |
2013-04-17
|
06 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-04-17
|
06 | Joel Jaeggli | Last call was requested |
2013-04-17
|
06 | Joel Jaeggli | Last call announcement was generated |
2013-04-17
|
06 | Joel Jaeggli | Ballot approval text was generated |
2013-04-17
|
06 | Joel Jaeggli | Ballot writeup was generated |
2013-04-17
|
06 | Joel Jaeggli | State changed to Last Call Requested from AD Evaluation |
2013-04-17
|
06 | Joel Jaeggli | I reviewed this and provided feedback to the WG I belive it's ready for IETF last call. |
2013-04-17
|
06 | Joel Jaeggli | State changed to AD Evaluation from Publication Requested |
2013-04-09
|
06 | Benoît Claise | Shepherding AD changed to Joel Jaeggli |
2013-02-27
|
06 | Amy Vezza | ==================================================== Write-up for draft-ietf-ipfix-protocol-rfc5101bis-06 ==================================================== (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this … ==================================================== Write-up for draft-ietf-ipfix-protocol-rfc5101bis-06 ==================================================== (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Internet Standard. The header indicates: "Category: Standards Track". It is appropriate. The RFC obsoletes standards track RFC 5101. there3 are multiple experimental and commercial implementations of RFC5101. They have been tested at interop events. Errata's of RFC5101 have been solved without invalidating existing implementations. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. Working Group Summary: The documents obsoletes RFC 5101. It does not change the technical content of the RFC5101 protocol specification, but it add several clarifications. The WG jointly worked on improving RFC5101 based on implementations experience and document reviews. There is strong consensus on the document. Document Quality: This is an update of RFC 5101 based on a lot of practical experiences with implementing and operating the IPFIX protocol. Changes compared to RFC 5101 result from these experiences. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Juergen Quittek is the document shepherd. He has reviewed it personally and believes that this version is ready for forwarding to the IESG for publication. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed the draft and is fully convinced that it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document had multiple individual reviews from key WG members during WG last call. Several comments were made and have been addressed when updating the document after the reviews. The shepherd has no concern about the depth or breadth of the reviews. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no such issues. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure filed. It is known by the WG and has been discussed. It is not different from the IPR disclosures that had already been filed for RFC 5101. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG as a whole understands and agrees with it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet- Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are a few nits. - The reference to draft-claise-ipfix- information-model-rfc5102bis-01 is outdated and has a wrong author list. - The reference to draft-ietf-ipfix-mediation-protocol-03 is outdated. These can be fixed in an update after IETF last call. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No further formal review required except for a thorough review by IANA which will be conducted anyway. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? Yes, there is a references to draft-ietf-ipfix-information-model-rfc5102bis which is already in the RFC editor queue. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. RFC 5101 will be obsoleted by this document. This is explicitly mentioned in the abstract and introduction. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Most tet in the IANA considerations section repeats what has already been stated in RFC5101. The only new action for IANA is replacing references in IANA registries to RFC5101 with references to this document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no new IANA registries requested by this document. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None to be done. |
2013-02-27
|
06 | Amy Vezza | Note added 'Juergen Quittek (Quittek@neclab.eu) is the document shepherd.' |
2013-02-27
|
06 | Amy Vezza | Intended Status changed to Proposed Standard |
2013-02-27
|
06 | Amy Vezza | IESG process started in state Publication Requested |
2013-02-27
|
06 | (System) | Earlier history may be found in the Comment Log for draft-claise-ipfix-protocol-rfc5101bis |
2013-02-18
|
06 | Brian Trammell | New version available: draft-ietf-ipfix-protocol-rfc5101bis-06.txt |
2013-01-15
|
05 | Benoît Claise | Shepherding AD changed to Ronald Bonica |
2013-01-07
|
05 | Brian Trammell | New version available: draft-ietf-ipfix-protocol-rfc5101bis-05.txt |
2012-12-19
|
04 | Brian Trammell | New version available: draft-ietf-ipfix-protocol-rfc5101bis-04.txt |
2012-12-05
|
(System) | Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-ipfix-protocol-rfc5101bis-03 | |
2012-11-20
|
03 | Brian Trammell | New version available: draft-ietf-ipfix-protocol-rfc5101bis-03.txt |
2012-06-28
|
02 | Brian Trammell | New version available: draft-ietf-ipfix-protocol-rfc5101bis-02.txt |
2012-03-07
|
01 | Brian Trammell | New version available: draft-ietf-ipfix-protocol-rfc5101bis-01.txt |
2011-11-29
|
00 | (System) | New version available: draft-ietf-ipfix-protocol-rfc5101bis-00.txt |