Subject: [IPFIX] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Nov 2013 15:17:03 -0600

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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:

None

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:

None

---

From: Benoit Claise <[email-masked]>
Date: Thu, 21 Nov 2013 12:45:39 +0100

Hi Ben,

Thanks for your review.
See in-line.
> 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.
Actually RFC 5477 uses an informative reference to RFC 2804.
> I apologize for bringing this up this late in the process--I missed it in my earlier review at last call.
>
The informative reference would be in line with RFC 5477. So yes.
Not sure if we need the reiteration.

Regards, Benoit

> None.

---

From: Paul Aitken <[email-masked]>
Date: Thu, 21 Nov 2013 14:21:18 +0000

Thanks Ben, we'll move 2804 to an informative reference.

P.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 21 Nov 2013 10:18:02 -0600

> Actually RFC 5477 uses an informative reference to RFC 2804.

Oops sorry, missed that. But it does cite 2804 in the same context (i.e. capture payload octets, subject to [RFC 2804]

> Not sure if we need the reiteration.

I think a sentence or two would save the reader from having to flip back and forth between docs. But it's not a big deal one way or ahother.

Thanks!

Ben.