Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07

Request Review of draft-ietf-ipfix-data-link-layer-monitoring
Requested rev. no specific revision (document currently at 08)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-11-19
Requested 2013-11-06
Authors Shingo Kashima, Atsushi Kobayashi, Paul Aitken
Draft last updated 2014-05-22
Completed reviews Genart Last Call review of -06 by Ben Campbell (diff)
Genart Telechat review of -07 by Ben Campbell (diff)
Secdir Last Call review of -06 by Sam Hartman (diff)
Assignment Reviewer Ben Campbell 
State Completed
Review review-ietf-ipfix-data-link-layer-monitoring-07-genart-telechat-campbell-2014-05-22
Reviewed rev. 07 (document currently at 08)
Review result Ready with Issues
Review completed: 2014-05-22


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ipfix-data-link-layer-monitoring-07
Reviewer: Ben Campbell
Review Date: 2013-11-19
IESG Telechat date: 2013-11-21

Summary: This draft is essentially ready for publication as a standards track RFC. However, there is one issue that I unfortunately missed in my last call review of version 06 that should be considered prior to publication.

Major issues:


Minor issues:

There's a normative downref to RFC 2804, which is informational. That seems a really odd draft for a normative reference. There may be precedent, as I note that RFC 5477, referenced here for security considerations, does the same thing.  I apologize for bringing this up this late in the process--I missed it in my earlier review at last call.

As I understand it the context is that certain data elements can include payload octets. This is subject to the security considerations in 5477, which basically say don't include too much, because of guidance from 2804. But my reading of 2804 does not give specific guidance things like how much payload one can capture before it becomes too much.

I think the simplest solution would be to keep the reference to the 5477 security considerations, and reiterate that this model is not intended for gross capture of payloads, perhaps with an _informative_ reference to 2804.

Nits/editorial comments: