Re: [IPFIX] AD Review of draft-ipfix-mediators-framework-08

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi Atsushi,

Please see my comments in-line. 

Thanks and Regards,

Dan 

> -----Original Message-----
> From: Kobayashi Atsushi [mailto:[e-mail]] 
> Sent: Sunday, October 24, 2010 6:35 AM
> To: Romascanu, Dan (Dan)
> Cc: IPFIX Working Group
> Subject: Re: [IPFIX] AD Review of draft-ipfix-mediators-framework-08
> 
> Dear Dan and all,
> 
> Thank you for your review.
> Sorry for late reply. Please see inline.
> 
> I will prepare next version until Nov.25.

Please do. 

> 
> On Tue, 12 Oct 2010 14:17:12 +0200
> "Romascanu, Dan (Dan)" <[e-mail]> wrote:
> 
> > Please find below the AD review of
> > 
> > This document is in quite good shape. I would however 
> suggest to deal 
> > with the issues in this review before sending the document 
> to the IETF 
> > Last Call.
> > 
> > The technical comments are marked Tx and the editorial comments are 
> > marked Ex.
> > 
> > T1. Sections 5.2, 5.3: It is not clear what you mean when you say 
> > 'This function must be configurable' - does this mean that some 
> > parameters related to this function are configurable (which 
> ones?), or 
> > that 'Activation of this function must be configurable'?
> > 
> 
> In section 5.2, some parameters must be configurable. That 
> implies there is no parameter to be transmitted just like the 
> case of IPFIX proxy for original Exporter.
>  
> 5.2.  Exporting Process
> 
> snip
> 
>    o  Transmitting the origin (e.g., Observation Point, Observation
>       Domain ID, Original Exporter IP address, etc.) of the data in
>       additional Data Record fields or additional Data Records.  These
>       parameters related to this function must be configurable.
> 

OK - it is probably better  s/These parameters/The parameters/

> In section 5.3, Activation of this function must be configurable.
> 
> 5.3.  Intermediate Process
> 
> snip
> 
>    o  Reporting statistics and interpretations for IPFIX Metering
>       Processes, PSAMP Metering Processes, and Exporting 
> Processes from
>       an Original Exporter.  See section 4 of [RFC5101] and 
> section 6 of
>       [RFC5476] for relevant statistics data structures and
>       interpretations, respectively.  Activation of this function must
>       be configurable.

OK. 

> 
> > T2. Same sections and phrase. This seems to me a very clear 
> > architectural requirement where RFC 2119 capitalized MUST would fit.
> > Please consider this as a non-blocking comment. 
> > 
> 
> In RFC5470(IPFIX Architecture),  this does not use capitalized "MUST"
> as an informational document, although it uses a lot of 
> "must" or "may".
> 
> The purpose of the document  expands the functionality of 
> IPFIX Architecture, therefore the document follows the rule 
> of RFC5470.
> Capitalized letter will be used in later document like 
> Mediator protocol.
> 
> Is it OK?
> 

OK. 

> > T3. In 5.3 'This relation can be configurable' - same 
> question as at T1.
> > 
> > 
> 
> I would like to remove the sentence "This relation can be 
> configurable".
> The phrase already said that  it maintains configurable relation.
> 
> 5.3.  Intermediate Process
> 
> snip
> 
>    o  Maintaining the configurable relation between Collecting
>       Process(es)/Metering Process(es) and Exporting Process(es)/other
>       Intermediate Process(es).
> 

OK. 

> > T4. Section 5.3.2.1: 
> > 
> >       Maintaining the mapping information about Transport Sessions,
> >       Observation Domain IDs, and Template IDs on the incoming and
> >       outgoing sides to ensure the appropriateness of the 
> scope field
> >       values in Data Records defined by Options Templates 
> and of IPFIX
> >       Template Withdrawal Messages.
> > 
> > I could not figure out what 'the appropriateness of the scope field 
> > values' means.
> 
> I would like to improve the following.
> 
> Maintaining the mapping information about Transport Sessions, 
> Observation Domain IDs, and Template IDs on the incoming and 
> outgoing sides in order to ensure the consistency of scope 
> field values of incoming and outgoing Data Records defined by 
> Options Templates.
> 
> 

OK. 

> > 
> > T5. The 'must', 'should', 'may' in the Security 
> Considerations section
> > seem appropriate for RFC 2119 keywords capitalization. 
> Please consider
> > this as a non-blocking comment. 
> > 
> 
> I would like to follow the rule of IPFIX architecture, not use
> capitalized keywords.
> 

OK

> > 
> > E1. idnits complains about 
> > 
> > ** The document seems to lack a both a reference to RFC 2119 and the
> >      recommended RFC 2119 boilerplate, even if it appears to use RFC
> > 2119
> >      keywords. 
> > 
> >      RFC 2119, paragraph 2:
> >      "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> > NOT",
> >       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
> "OPTIONAL" in
> >       this document are to be interpreted as described in RFC 2119."
> > 
> > This is probably because of a SHOULD left capitalized in 
> the Security
> > Considerations section. Change it into a 'should' unless 
> you decide to
> > follow the recommendations in T2 and T5. 
> 
> Ok, I will change them into "should".
> > 
> > E2. idnits points to potential problems in references. 
> Please confirm if
> > this is what you intended, or updates are needed. 
> > 
> >   Checking references for intended status: Informational
> >  
> > 
> --------------------------------------------------------------
> ----------
> > ----
> > 
> >   == Outdated reference: 
> draft-ietf-ipfix-mediators-problem-statement
> > has
> >      been published as RFC 5982
> > 
> Ok.
> 
> >   == Outdated reference: A later version (-01) exists of
> >      draft-ietf-ipfix-psamp-mib-00
> > 
> Ok.
> 
> >   -- Obsolete informational reference (is this 
> intentional?): RFC 3280
> >      (Obsoleted by RFC 5280)
> > 
> Ok.
> 
> >   -- Obsolete informational reference (is this 
> intentional?): RFC 4346
> >      (Obsoleted by RFC 5246)
> > 
> Ok.
> 
> > E3. Section 1: 
> > 
> > s/To fulfill application requirements with limited system resources,
> > IPFIX architecture needs to introduce/To fulfill application
> > requirements with limited system resources, the IPFIX 
> architecture needs
> > to introduce/ 
> 
> Ok.
> 
> > 
> > E4. Section 2: 
> > 
> > s/The use of the terms "must", "should", and "may" in this 
> document are
> > informational only/The use of the terms "must", "should", 
> and "may" in
> > this document is informational only/
> 
> Ok.
> > 
> > E5. what does 'binning' mean in the context of this document? 
> > 
> 
> It means data binning.
> 
>    Intermediate Aggregation Process
> 
>       An Intermediate Aggregation Process is an Intermediate Process
>       that aggregates records based upon a set of Flow Keys 
> or functions
>       applied to fields from the record (e.g., data binning and subnet
>       aggregation).
> 
> 
> > E6. Figure F: IPFIX Mediation Functional Block - should be either
> > 'Blocks' or 'Block Diagram'
> > 
> Ok.
> 
> > E7. in 5.3.2.3 s/describied/described/
> > 
> 
> Ok.
> 
> Thanks,
> Atsushi Kobayashi
> 
>