Subject: Re: [IPFIX] Shepherd review of draft-ietf-ipfix-flow-selection-tech

From: Nevil Brownlee <[email-masked]>
Date: Fri, 07 Jan 2011 10:31:56 +1300

Hi Lorenzo:

I haven't seen any response to my earlier emails (copied below).
Did you receive them?   Can you please make the changes I've detailed
and publish a new revision sometime soon?  I'd like to get the
shepherd document completed so that I can submit this draft to
IESG well before the Prague IETF meeting!

Cheers, Nevil

On 14/12/10 12:48 PM, Nevil Brownlee wrote:
>
> Hi Lorenzo et al:
>
> As part of writing a shepherd document I have to read your draft
> carefully, and check it for ID-nits.  I've done that, and I find
> quite a few things that need to be fixed, as follows:
>
> s7, p15:  List of new IEs
>     5102 clearly says that IE names start with a lower-case letter.
>          Also, none of the existing IEs use an underscore character.
>          How about using fsMeterUnmeasPacketCount, as per 5102?
>
> s7, p14
>      You say "Some elements have
>        been associated with a pair of timestamps, which are referred to as
>        Tfirst and Tlast (instead of element_nameTfirst, element_nameTlast).
>      Does that mean that you both the TFirst and Tlast timestamps are
>      also needed as IEs?    Or are they something that will only be used
>      inside a meter or mediator?  You need to explain this here!
>
> s7.1.1, p15
>      Refers to TsFirst and TsLast - you should change Tfirst and Tlast
> above (I think TsFirst is easier to read).
>
> s7.2.2  Why is ..PacketInDropped.. defined in terms of its two timestamps,
>      but ..ByteInDropped.. is not?
>      Similarly for other IEs in 7.2.x sections.
>
> s9, p22:  remove [RFC 2051] (as above)
>
> s9.1, p22:  In the table, don't use ID, that suggests its an ID for an
>      Informations Element.  I think you mean Value.
>
> Running ID-nits, using the [Nits] button at the top of
>     http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-03
>
> You should run this, and fix the little things it finds.
>
> In particular, I see that there's no Security Considerations section.
> Every RFC has to have such a section!  You need to add one, pointing
> out what possible security weaknesses could be introduced by using
> flow selection (or explaining that there aren't any obvious ones).
>
> Most of these are quite trivial, so they won't take much fixing.
> The ones that do need some real work are to explain how TsFirst/
> TsFirst are intended to be used in the FlowSelect Info Model, and
> to add a Security Considerations section.
>
> I look forward to seeing your next version.
>
> Cheers, Nevil

 > Lorenzo et al:
 >
 > One more thing, when your next revision is ready, I need to be able
 > to list two or three people as reviewers for it - perhaps you could
 > ask them directly and ask them to post their reviews on the IPFIX
 > list?
 >
 > Cheers again, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: [email-masked]
Date: Fri, 07 Jan 2011 15:20:41 +0100

Hi Nevil,

sorry for the very late answer. We are actively working on a new  
revision of the draft. We are going to publish the new revision  
tomorrow.

Cheers,
Lorenzo.