Skip to main content

Information Elements for Data Link Layer Traffic Measurement
draft-ietf-ipfix-data-link-layer-monitoring-08

Yes

(Benoît Claise)

No Objection

(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Ted Lemon)

Note: This ballot was opened for revision 07 and is now closed.

Yes (for -07) Unknown

                            
No Objection (2013-11-20 for -07) Unknown
The wording in the Acknowledgements is a little odd.
s/IPFIX members/IPFIX working group participants.

---

Section 7

Surely the more granular the data that can be reported, the greater the
risk of DoS attacks on a collection point. This document appears to
significantly increase the data that could be reported by node and so
increase the possiblitiy of congesting the collector through one 
(possibly accidental) configuration event. I think you should briefly 
mention this and highlight the mitigations.
No Objection (2013-11-17 for -07) Unknown
I've a few non-blocking comments that I'd like you to consider.  Feel free to chat with me about any of them if you want to.  This is all editorial.

-- Section 1 --

   While these innovations provide flexibility, scalability, and
   mobility to an existing network architecture, it increases the
   complexity of traffic measurement due to the existence of various
   Ethernet header formats.  To cope with this, a more sophisticated
   method is required.

"they increase" the complexity.  And a more sophisticated method of what?  Traffic measurement?  Please say that: "a more sophisticated method of [whatever] is required."

   layer, e.g., Ethernet header forms.  This document describes the
   Information Elements related to data link layers that enable a more
   sophisticated traffic measurement method.

Does this document only describe "the [existing] Information Elements"?  Or does it also define new IEs?

-- Section 2.2 --

   Also, the lack of
   management scalability and flexibility: increasing the number of VMs

Make it "Another is the lack of [...]".

-- Section 3.1.2 --

      *However, when the sectionOffset field corresponding to this
      Information Element does not exist, the octets MUST be from the
      start of the data link frame.*

Take this or leave it (also in the various subsections of Section 4): What you're really saying here is that the default for sectionOffset is 0, and I think it's actually clearer if you say it that way (and, in fact, you do, in Section 3.2.2):

NEW
      * If no corresponding sectionOffset is present, an offset of
      0 is used. *
END

-- Section 3.2.2 --

      If multiple sectionOffset IEs are specified within a single
      Template, then they apply to the packet section IEs in order. ie,
      the first sectionOffset applies to the first packet section, etc.

The combination of "IE" and "ie" (which should be "i.e." (note that throughout the document)) actually seems confusing, and isn't necessary.  May I suggest this?:

NEW
      If multiple sectionOffset IEs are specified within a single
      Template, then they apply to the packet section IEs in order:
      the first sectionOffset applies to the first packet section,
      the second to the second, and so on.
END

The "less" a couple of sentences later should be "fewer".

-- Section 8 --
I suggest that you add a note to the RFC Editor, reminding them to change all the "TBDnn" notations in the document, according to the IANA allocated values.  Less likely to fall through the cracks if there's an explicit reminder.
No Objection (for -07) Unknown

                            
No Objection (for -07) Unknown

                            
No Objection (for -07) Unknown

                            
No Objection (for -07) Unknown

                            
No Objection (for -07) Unknown

                            
No Objection (for -07) Unknown

                            
No Objection (for -07) Unknown

                            
No Objection (2013-11-21 for -07) Unknown
Strangely, I agree there are no new security or privacy
considerations here, even though I did expect there
would be;-)
No Objection (2013-11-21 for -07) Unknown
I have no objection to the publication of this document, or the technical description of each IE. However the purpose of this document is to update or populate the IANA registry which is now the definitive repository of IPFIX IEs. Therefore for each entry there needs to be a one to one mapping between the items in the definition and the headings in the IPFIX registry. This mapping has not been provided for all items.

Also where an entry is changed, an explanation needs to be provided for why the change was made together with text addressing any backwards compatibility issues, which hopefully is a note that there is no backwards compatibility issue.

I have discussed both of these issues with the authors and the responsible AD and I am happy that they will address these concerns.
No Objection (for -07) Unknown