Re: [IPFIX] Ted Lemon's No Objection on draft-ietf-ipfix-flow-selection-tech-16: (with COMMENT)

Hi Ted,
> Ted Lemon has entered the following ballot position for
> draft-ietf-ipfix-flow-selection-tech-16: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
>
> ----------------------------------------------------------------------
> 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.
Just replying to this COMMENT above.

Here is a little bit of history.
RFC 6183, IP Flow Information Export (IPFIX) Mediation: Framework, 
specified a couple of terms. Those terms (and  "Intermediate Selection 
Process" was one of them) were generic terms to be used by the different 
RFCs: RFC 6235,
draft-ietf-ipfix-a9n-08, 
<http://datatracker.ietf.org/doc/draft-ietf-ipfix-a9n/>draft-ietf-ipfix-flow-selection-tech-16 
<http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/>, 
draft-ietf-ipfix-mediation-protocol-04 
<http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol/>
However, when developing draft-ietf-ipfix-flow-selection-tech-16, 
<http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/>the 
authors realized that the "Intermediate Selection Process" definition 
[RFC6183] was not suitable. Hence the redefinition into "Intermediate 
Flow Selection Process".

This was discussed recently on the IPFIX mailing list, and the 
conclusion was to add the section 4 "Difference between Intermediate 
Flow Selection Process and Intermediate Selection Process"

While the situation is not ideal, my advice would be to leave the 
situation as it is.

I let the authors respond to the rest.
Note: maybe you meant 6.1.2 in your next comment.

Regards, Benoit
>
> 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!
>
>
>
>

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix