Re: [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-00 - New Version draft-ietf-bmwg-ipflow-meth-02.txt

["Jan Novak (janovak)" <[e-mail]>]

Paul,

I would like to thank you for a very detailed review including
the language and mainly for improving/introducing the use of 
correct terminology - I think it made the doc much better !!!

I have worked on the text since you first provided the review back
in May so I hope it reflects and satisfies all your comments.

I have agreed with the very most of changes you wanted but these
below which I consider substantial to mention separately. Otherwise
see some answers to your questions/concerns through the review
in the attached text file.

1) Maximum Flow Monitoring Throughput

>PJ: The actual, average or effective "Flow Monitoring Throughput" 
>may be much lower, so you should clearly name this quantity as
> a *maximum*.

There is no such a quantity as actual/average/effective Flow Monitoring
Throughput - there is simply no definition anywhere for those. Flow
Monitoring Throughput is a "MAximum" by definition - please see section
3.1 of the reviewed document. 
This is in an exact analogy with the section 3.17 of RFC1242 defining 
the packet forwarding throughput. 
One could look at your suggestion as just a change
of the name for the defined quantity but the "Maximum" here would be an
adjective to something else and you would have to define what is the
 rest behind the adjective ...

2) Export of options and templates

>Also, I didn't yet read anything about allowing for export templates
>and/or options. Should these be included or excluded from the 
>measurements?

I would like to strongly disagree here. We had extensive discussions 
about it already with one of the previous reviewers and I always
pointed to the definition of Control Information by RFC5470
 (and I think also other IPFIX documents) section 2 which in
my opinion covers for the export of options and templates but I never
got
any answer regarding that - neither from you yet.
The reviewed document has explicit statements about export of this
information
in several places unless my understanding of the RFC5470 definition is
wrong.
I hope not though since I wouldn't like to dive into the definitions of
what those are in IPFIX. I hope you can comfirm that.

3) Packet Sampling 

>PJ: I'd like to see a greater discussion of the relevance of sampling, 
>throughout this document. I've already indicated a few places where
sampling 
>would impact the test.

Packet sampling is out of the scope of this document. If you prefer I
will
replace section 4.5 of the reviewed document with an explicit statement
saying just that instead. It is a separate I would say research subject
which can be undertaken by a future work/document.

Regards, Jan

The climate of Edinburgh is such that the weak succumb young .... 
and the strong envy them.
                                 Dr. Johnson



-----Original Message-----
From: Paul Aitken (paitken) 
Sent: 20 June 2011 10:18
To: Jan Novak (janovak); Al Morton
Cc: [e-mail]
Subject: Re: WGLC: draft-ietf-bmwg-ipflow-meth-00

Jan,

In reviewing this draft, I objected to numerous places where you 
discussed the cache as holding Flow Records.

eg, "the cache doesn't hold flow records, because the cache is a 
function of the metering process while flow records are a product of the

exporting process."

While RFC 5101 (IPFIX) doesn't specifically mention caches, it does say:

       The Metering Process generates Flow Records.


And

       The Metering Process consists of a set of functions that includes
       packet header capturing, timestamping, sampling, classifying, and
       maintaining Flow Records.


"maintaining Flow Records" could be interpreted as cache maintenance.

So I'll relax my objection because this isn't clearly defined in IPFIX.

Thanks,
P.


On 13/06/11 14:02, Paul Aitken wrote:
> Al, Jan,
>
> I've attached a version of draft-ietf-bmwg-ipflow-meth-01 with 
> numerous comments inline (look for "PJ:").
>
> I've made numerous small changes directly to the text. Hopefully you 
> can see those with in the change history (see "track changes").
>
> I anticipate an updated document and a further WGLC.
>
> Cheers,
> P.