Skip to main content

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