Flow Selection Techniques
draft-ietf-ipfix-flow-selection-tech-18

[Ballot comment]
As discussed, it sounds like the correct text for 6.1 should be: "In order to be compliant with IPFIX, at least one of this document's flow filtering schemes MUST be implemented." I personally think it's wrong to have 2119 language for compliance statements, but since your responsible AD disagrees with me, I will just whinge here and be done with it. :-)

[Ballot comment]

Thanks for addressing my discuss points.

On the 2804 reference - I think it'd be even better to say
something like:

"the designated expert should consult with the community
if a request is received that runs counter to 2804"

That's implicit in what you have now, but I think that
being explicilt there would be better. However, I leave it
to you/your-AD to do that or not as you prefer.

[Ballot comment]
0) Full-on support Stephen's discusses.

1) s2: Missing a word (maybe "can be"):

  Hash-based Flow Filtering can already applied at packet level, in
  which case the Hash Domain MUST contain the Flow Key of the
  packet.
 
2) s7: 1st para 'bout info model should point to s8?

[Ballot comment]
Shouldn't Section 10 discuss the security implications of revealing to
an external party more detailed and finer grained information about
what is happening within a network?

This might be what Stephen is asking for in the second part of his Discuss.

[Ballot discuss]

(1) This is probably a discuss-discuss. Section 9.1.1 allows
addition of new flow selection algorithms via expert review.
Would/should a flow selection algorithm that was counter to
RFC 2804 and didn't have any e.g. network management
functionality be approved by the experts? I think the answer
ought be "no" so maybe that guidance to that effect could be
added to 9.1.1.

(2) section 10, I think you should add text (or a pointer to
text elsewhere) that recognizes that exported flows can be
sensitive for security or privacy reasons and need to be
protected. There's probably text in some other document but
if not, happy to help generate that.

[Ballot comment]

- I had similar questions to Pete about the write up and the
IPR situation. When I went to look in the wg list archive I
didn't see where this IPR declaration was annouced to the
list or discussed - can someone send a pointer? (I probably
missed it.)

- section 2: last 2 sentences of "hash-based flow filtering"
definition seem mangled

- 7.1 seems to say that propertly match filtering for all
entries in the [iana-ipfix-assignments] registry (which is
expert review) MUST be supported. Is that right? That seems
odd since the registry changes (with expert review) but the
code that'd be written for this spec won't necessarily
change. The IANA registry is also currently an informative
reference, so the "MUST be supported" interpretation above is
also a bit weird, but I've no idea which subset of the IANA
registered things need to be supported to get interop. Or
maybe I'm confused? (As usual:-) That would have been a
discuss but section 8 seems to fix the problem by listing the
IANA registered things that MUST be supported. Maybe add a
forward pointer from 7.1 to 8 to clarify?

- section 10, 3rd para: I suggest replacing "a user" with "an
adversary" since we're only concerned here about flows
involving an adversary and not with monitoring innocent
users, right?

- section 10, I'm not sure that a CBC IV is the right way to
say what you want - do you just want random numbers?  If so
then maybe NIST 800-90A is a better reference or even RFC
4086?

[Ballot discuss]
The shepherd writeup says:

  This draft raised IPR concerns, in the same manner as the PSAMP
  selection draft had done.  Nick Duffield (AT&T) commented that
  the AT&T IPR claim relates only to statistical sampling, and PSAMP
  handled this by saying "at least on of the sampling techniques
  must be implemented."
  In this draft, we have tightened that up a little by saying
  "a conforming implementation MUST implement at least the
  Property Match Filtering."

So you're saying that somehow the compliance requirement in section 6.1 helps with the IPR issue? I've got to say that even setting aside my general dislike of compliance requirements, it makes me very uneasy to have requirements for the purpose of addressing IPR issues. Can you explain a bit further?

[Ballot comment]
Section 2, "Hash-based Flow Filtering": I'm always a bit concerned to see protocol MUST requirements in a definitions section (as I am with IANA Considerations or Appendices). It's not clear to me that these requirements will be noticed. Is there nowhere else in the document these make sense to go? (6.1.2? Somewhere in section 7?)

[Ballot comment]
The terms "Intermediate Flow Selection Process" and "Intermediate Selection Process" are so similar that I had to read the glossary entry for the former several times in order to catch the difference. If possible, it would be better to use a different name to refer to this process. I realize this is a central bit of terminology in this draft, so the request may seem a bit extreme, but it looks like it's been newly introduced in this particular draft, so it's not too late to do something about it.  I'm not convinced that fixing it is worth the trouble, but I raise the issue because it tripped me up; it will probably trip up other new readers of the document.

In section 6.2.1, I assume that the flow key is substantially smaller than the flow cache entry, but this is a bit surprising. I'm assuming the flow cache entry is somehow a heavier-weight thing, but it's not obvious what that extra weight is. I went looking for a definition of "flow cache" and didn't find one in any of the referenced RFCs. It might be helpful to have a glossary entry that briefly describes the flow cache. Presumably it's just the set of all flow records; if so, the definition of flow record in 5101 doesn't give me a basis for thinking that it's much larger than a flow key. None of this is intended to imply that the text is wrong; just that it might help to have a bit more exposition on the topic.

6.2.2.1: what's a flow position?

Aside from these observations, which may or may not actually be helpful, the document looks good—thanks for doing the work!

The IETF last call has finished.
Can you please update your draft based on the feedback received.
Then I will progress it.

And don't forget to answer IANA's question.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ipfix-flow-selection-tech-14.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We have one comment about one of the actions requested in the IANA Considerations section of this document.

We understand that, upon approval of this document, there are three actions which we must complete.

First, in the existing IP Flow Information Export (IPFIX) Entities registry located at:

http://www.iana.org/assignments/ipfix/ipfix.xml

a new subregistry will be created called the "flowSelectorAlgorithm" registry.  This new subregistry is maintained via Expert Revew as defined in RFC 5226.  There are initial registrations in the new subregistry as follows:

+----+------------------------+--------------------------+
| ID |        Technique      |      Parameters          |
+----+------------------------+--------------------------+
| 1  | Systematic count-based | flowSamplingInterval    |
|    | Sampling              | flowSamplingSpacing      |
+----+------------------------+--------------------------+
| 2  | Systematic time-based  | flowSamplingTimeInterval |
|    | Sampling              | flowSamplingTimeSpacing  |
+----+------------------------+--------------------------+
| 3  | Random n-out-of-N      | samplingSize            |
|    | Sampling              | samplingPopulation      |
+----+------------------------+--------------------------+
| 4  | Uniform probabilistic  | samplingProbability      |
|    | Sampling              |                          |
+----+------------------------+--------------------------+
| 5  | Property Match        | Information Element      |
|    | Filtering              | Value Range              |
+----+------------------------+--------------------------+
|  Hash-based Filtering      | hashInitialiserValue    |
+----+------------------------+ hashFlowDomain          |
| 6  | using BOB              | hashSelectedRangeMin    |
+----+------------------------+ hashSelectedRangeMax    |
| 7  | using IPSX            | hashOutputRangeMin      |
+----+------------------------+ hashOutputRangeMax      |
| 8  | using CRC              |                          |
+----+------------------------+--------------------------+
| 9  | Flow-state Dependent  | No agreed Parameters    |
|    | Intermediate Flow      |                          |
|    | Selection Process      |                          |
+----+------------------------+--------------------------+

Second, eleven new IPFIX Information Elements will be added to the IPFIX Information Elements subregistry of the IP Flow Information Export (IPFIX) Entities registry located at:

http://www.iana.org/assignments/ipfix/ipfix.xml

ElementID: [ TBD-at-registration ]
Name: flowSelectorAlgorithm
Data Type: unsigned16
Data Type Semantics: identifier
Status: current
Description: This Information Element identifies the Intermediate Flow Selection Process technique(e.g., Filtering, Sampling) that is applied by the Intermediate Flow Selection Process.
Units:
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: flowSelectedOctetDeltaCount
Data Type: unsigned64
Data Type Semantics: 
Status: current
Description: This Information Element specifies the volume in octets of all Flows that are selected in the Intermediate Flow Selection Process since the previous report.
Units:Octets
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: flowSelectedPacketDeltaCount
Data Type: unsigned64
Data Type Semantics:
Status: current
Description: This Information Element specifies the volume in packets of all Flows that were selected in the Intermediate Flow Selection Process since the previous report.
Units: packets
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: flowSelectedFlowDeltaCount
Data Type: unsigned64
Data Type Semantics:
Status: current
Description: This Information Element specifies the number of Flows that were selected in the Intermediate Flow Selection Process since the last report.
Units: flows
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: selectorIDTotalFlowsObserved
Data Type: unsigned64
Data Type Semantics:
Status: current
Description: This Information Element specifies the total number of Flows observed by a Selector, for a specific value of SelectorId.  This Information Element should be used in an Options Template scoped to the observation to which it refers.
Units: flows
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: selectorIDTotalFlowsSelected
Data Type: unsigned64
Data Type Semantics:
Status: current
Description: This Information Element specifies the total number of Flows selected by a Selector, for a specific value of SelectorId.  This Information Element should be used in an Options Template scoped to the observation to which it refers.
Units: flows
Range:
References: [ RFC-to-be ], RFC5101

ElementID: [ TBD-at-registration ]
Name: samplingFlowInterval
Data Type: unsigned64
Data Type Semantics:
Status: current
Description: This Information Element specifies the number of Flows that are consecutively sampled.  A value of 100 means that 100 consecutive Flows are sampled.  For example, this Information Element may be used to describe the configuration of a systematic count-based Sampling Selector.
Units: flows
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: samplingFlowSpacing
Data Type: unsigned64
Data Type Semantics:
Status: current
Description:  This Information Element specifies the number of Flows between two "samplingFlowInterval"s.  A value of 100 means that the next interval starts 100 Flows (which are not sampled) after the current "samplingFlowInterval" is over.  For example, this Information Element may be used to describe the configuration of a systematic count-based Sampling Selector.
Units: flows
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: flowSamplingTimeInterval
Data Type: unsigned64
Data Type Semantics:
Status: current
Description: This Information Element specifies the time interval in microseconds during which all arriving Flows are sampled.  For example, this Information Element may be used to describe the configuration of a systematic time-based Sampling Selector.
Units: microseconds
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: flowSamplingTimeSpacing
Data Type: unsigned64
Data Type Semantics:
Status: current
Description: This Information Element specifies the time interval in microseconds between two "flowSamplingTimeInterval"s.  A value of 100 means that the next interval starts 100 microseconds (during which no Flows are sampled) after the current "flowsamplingTimeInterval" is over.  For example, this Information Element may used to describe the configuration of a systematic time-based Sampling Selector.
Units: microseconds
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: hashFlowDomain
Data Type:  unsigned16
Data Type Semantics: identifier
Status: current
Description: This Information Element specifies the Information Elements that are used by the Hash-based Flow Selector as the Hash Domain.
Units:
Range:
References: [ RFC-to-be ]


Third, in the IPFIX-SELECTOR-MIB Functions subregistry of the Network Management Parameters registry located at:

http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-20

a new OID will be registered as follows:

Decimal: [ TBD-at-registration ]
Name: flowSelectorAlgorithm
Description: This Object Identifier identifies the Intermediate Flow Selection Process technique (e.g., Filtering, Sampling) that is applied by the Intermediate Flow Selection Process
Reference: [ RFC-to-be ]

NOTE: Currently, the IPFIX-SELECTOR-MIB Functions subregistry is managed by Expert Review as defined in RFC 5226.  We will initiate a request and send this to the designated expert for review.

We understand that these three actions are the only one 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Flow Selection Techniques) to Proposed Standard


The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Flow Selection Techniques'
  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-04-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


  Intermediate Flow Selection Process is the process of selecting a
  subset of Flows from all observed Flows.  The Intermediate Flow
  Selection Process may be located at an IPFIX Exporter, Collector, or
  within an IPFIX Mediator.  It reduces the effort of post-processing
  Flow data and transferring Flow Records.  This document describes
  motivations for using the Intermediate Flow Selection process and
  presents Intermediate Flow Selection techniques.  It provides an
  information model for configuring Intermediate Flow Selection Process
  techniques and discusses what information about an Intermediate Flow
  Selection Process should be exported.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1540/

IESG:

IANA has reviewed draft-ietf-ipfix-flow-selection-tech-10.txt and has
the following comments:

IANA understands that at least one of the IANA actions in this document is
dependent upon approval of a different document and the IANA Actions contained
in that document.

IANA understands that, upon approval of this document, there are two IANA
Actions which must be completed.

First, in the IPFIX Information Elements subregistry in the IP Flow Information
Export (IPFIX) Entities registry located at:

http://www.iana.org/assignments/ipfix/ipfix.xml

eleven new Information Elements will be registered as follows:

Element ID: [ tbd at time of registration ]
Name: flowSelectorAlgorithm
Data Type: unsigned16
Data Type Semantics: idintifier
Status: Proposed
Description: This Information Element identifies the flow selection method (e.g.
Filtering, Sampling) that is applied by the Flow Selection Process
Units:
Range:
References: [ RFC-to-be ]

Element ID: [ tbd at time of registration ]
Name: flowSelectedOctetDeltaCount
Data Type: unsigned64
Data Type Semantics: Octets
Status: Proposed
Description: This Information Element specifies the volume in octets of all
flows that are selected during the Flow Selection Process since the previous
report.
Units:
Range:
References: [ RFC-to-be ]

Element ID: [ tbd at time of registration ]
Name: flow SelectedPacketDeltaCount
Data Type: unsigned64
Data Type Semantics: Packets
Status: Proposed
Description: This Information Element specifies the volume in packets of all
flows that were selected during the Flow Selection Process since the previous
report.
Units:
Range:
References: [ RFC-to-be ]

Element ID: [ tbd at time of registration ]
Name: flow SelectedFlowDeltaCount
Data Type: unsigned64
Data Type Semantics: Flows
Status: Proposed
Description: This Information Element specifies the number of Flows that were
selected during the Flow Selection Process since the last report.
Units:
Range:
References: [ RFC-to-be ]

Element ID: [ tbd at time of registration ]
Name: selectorIDTotalFlowsObserved
Data Type: unsigned64
Data Type Semantics: Flows
Status: Proposed
Description: This Information Element specifies the total number of flows
observed by a Selector, for a specific value of SelectorId. This Information
Element should be used in an Options Template scoped to the observation to which
it refers. See Section 3.4.2.1 of the IPFIX protocol document [RFC5101].
Units:
Range:
References: [ RFC-to-be ]

Element ID: [ tbd at time of registration ]
Name: selectorIDTotalFlowsSelected
Data Type: unsigned64
Data Type Semantics: Flows
Status: Proposed
Description: This Information Element specifies the total number of flows
selected by a Selector, for a specific value of SelectorId. This Information
Element should be used in an Options Template scoped to the observation to which
it refers. See Section 3.4.2.1 of the IPFIX protocol document [RFC5101].
Units:
Range:
References: [ RFC-to-be ]

Element ID: [ tbd at time of registration ]
Name: samplingFlowInterval
Data Type: unsigned64
Data Type Semantics: Flows
Status:
Description: This Information Element specifies the number of flows that are
consecutively sampled. A value of 100 means that 100 consecutive flows are
sampled. For example, this Information Element may be used to describe the
configuration of a systematic count-based Sampling Selector.
Units:
Range:
References: [ RFC-to-be ]

Element ID: [ tbd at time of registration ]
Name: samplingFlowSpace
Data Type: unsigned64
Data Type Semantics: Flows
Status:
Description: This Information Element specifies the number of flows between two
"samplingFlowInterval"s. A value of 100 means that the next interval starts 100
flows (which are not sampled) after the current "samplingFlowInterval" is over.
For example, this Information Element may be used to describe the configuration
of a systematic count-based Sampling Selector.
Units:
Range:
References: [ RFC-to-be ]

Element ID: [ tbd at time of registration ]
Name: flowSamplingTimeInterval
Data Type: unsigned 64
Data Type Semantics: microseconds
Status: Proposed
Description: This Information Element specifies the time interval in
microseconds during which all arriving flows are sampled. For example, this
Information Element may be used to describe the configuration of a systematic
time-based Sampling Selector.
Units:
Range:
References: [ RFC-to-be ]

Element ID: [ tbd at time of registration ]
Name: flowSamplingTimeSpace
Data Type: unsigned64
Data Type Semantics: microseconds
Status: Proposed
Description: This Information Element specifies the time interval in
microseconds between two "flowSamplingTimeInterval"s. A value of 100 means that
the next interval starts 100 microseconds (during which no flows are sampled)
after the current "flowSamplingTimeInterval" is over. For example, this
Information Element may be used to describe the configuration of a systematic
time-based Sampling Selector.
Units:
Range:
References: [ RFC-to-be ]

Element ID: [ tbd at time of registration ]
Name: hashFlowDomain
Data Type: unsigned16
Data Type Semantics: identifier
Status: Proposed
Description: This Information Element specifies the Information Elements that
are used by the Hash-based flow Selection Selector as the Hash Domain.
Units:
Range:
References: [ RFC-to-be ]

Second, in the subregistry created upon approval by the Internet Draft
dkcm-ipfix-rfc5815bis a new value will be registered as follows:

Decimal: 1
Name: flowSelectorAlgorithm
Description: This Object Identifier identifies the flow selection method (e.g.
Filtering, Sampling) that is applied by the Flow Selection Process.

IANA understands that these are the only actions required to be completed by
IANA upon approval 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.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (Flow Selection Techniques) to Proposed Standard





The IESG has received a request from the IP Flow Information Export WG

(ipfix) to consider the following document:

- 'Flow Selection Techniques'

  as a 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 2012-04-11. 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





  Flow selection is the process of selecting a subset of flows from all

  observed flows.  The Flow Selection Process may be located at an

  observation point, or on an IPFIX Mediator.  Flow selection reduces

  the effort of post-processing flow data and transferring Flow

  Records.  This document describes motivations for flow selection and

  presents flow selection techniques.  It provides an information model

  for configuring flow selection techniques and discusses what

  information about a flow selection process should be exported.











The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/





The following IPR Declarations may be related to this I-D:



  http://datatracker.ietf.org/ipr/1540/

Shepherd write-up by Nevil Brownlee:

As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding,
this is the current template for the Document Shepherd Write-Up.
Changes are expected over time.  This version is dated February 1, 2007.


    (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

  Nevil Brownlee.  I have reviewed this draft, I believe it's ready
  for publication.

    (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

  Yes.  This draft had a WGLC in August 2011, which raised important
  issues, mostly concerning its relationship to the PSAMP selection
  RFC.  It was revised to address those issues, and had a second
  WGLC in February 2012.  That raised a few further issues; these have
  been addressed in the current version.

    (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

  No.

    (1.d)  Does the Document Shepherd have any specific concerns or
          issues 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.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

  This draft raised IPR concerns, in the same manner as the PSAMP
  selection draft had done.  Nick Duffield (AT&T) commented that
  the AT&T IPR claim relates only to statistical sampling, and PSAMP
  handled this by saying "at least on of the sampling techniques
  must be implemented."
  In this draft, we have tightened that up a little by saying
  "a conforming implementation MUST implement at least the
  Property Match Filtering."

    (1.e)  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 has reached full consensus on this draft.

    (1.f)  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
          entered into the ID Tracker.)

  No.

    (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

  The ID nits checker finds six nots concerned with references.
  In my opinion these are all Editorial, and - since the IETF-83
  drafts deadline is very close now - can be fixed later on,
  say after IETF Last Call.

    (1.h)  Has the document split its references into normative and
          informative?  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
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

  Yes.  There no references to non-existing documents.
  The only issue here are the ID nits mentioned above.

    (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

  Yes.  No new IANA registries are required.

    (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

  There are no sections in a formal language.

    (1.k)  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
    Flow selection is the process of selecting a subset of flows from all
    observed flows.  The Flow Selection Process may be located at an
    observation point, or on an IPFIX Mediator.  Flow selection reduces
    the effort of post-processing flow data and transferring Flow
    Records.  This document describes motivations for flow selection and
    presents flow selection techniques.  It provides an information model
    for configuring flow selection techniques and discusses what
    information about a flow selection process should be exported.

          Working Group Summary
    This document has been extensively reviewed by the WG, and has
    had two WGLCs.  I believe that all the issues raised have been
    resolved; we now have clear WG consensus.

          Document Quality
    I'm not aware of any implementations of IPFIX flow selection.
    Brian Trammell provided reviews that were particularly useful
    to the draft's authors.

          Personnel
  Shepherd: Nevil Brownlee
  AD: Dan Romascanu / Benoit Claise
  IANA Expert:  Nevil Brownlee / Juergen Quittek