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

[Kobayashi Atsushi <[e-mail]>]

Dear Dan and all,

Thank you for your review.
Sorry for late reply. Please see inline.

I will prepare next version until Nov.25.

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.

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.

> 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?

> 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).

> 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.


> 
> 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.

> 
> 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