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

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.

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. :-)

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?

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.

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!