• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: ipfix

Current state: WG Document

Viewing the last 20 entries. Show full log.

2013-05-16 10:19 Cindy Morgan

State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation

2013-05-16 04:55 Gonzalo Camarillo

[Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo

2013-05-15 23:45 Jari Arkko

[Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko

2013-05-15 15:21 Joel Jaeggli

[Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli

2013-05-15 13:08 Spencer Dawkins

[Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins

2013-05-15 08:22 Richard Barnes

[Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes

2013-05-14 11:14 Sean Turner

[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?

2013-05-14 11:14 Sean Turner

[Ballot Position Update] New position, No Objection, has been recorded for Sean Turner

2013-05-14 10:03 Adrian Farrel

[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.

2013-05-14 10:03 Adrian Farrel

[Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel

2013-05-14 07:49 Martin Stiemerling

[Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling

2013-05-14 06:11 Stephen Farrell

[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.

2013-05-14 06:11 Stephen Farrell

[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?

2013-05-14 06:11 Stephen Farrell

[Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell

2013-05-13 20:37 Pete Resnick

[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?

2013-05-13 20:37 Pete Resnick

[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?)

2013-05-13 20:37 Pete Resnick

[Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick

2013-05-13 12:39 Barry Leiba

[Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba

2013-05-13 08:43 Brian Haberman

[Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman

2013-05-12 09:17 Ted Lemon

[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!

Viewing the last 20 entries. Show full log.