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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 12 Oct 2010 14:17:12 +0200

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

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. 

T3. In 5.3 'This relation can be configurable' - same question as at T1.

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. 

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. 

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. 

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

  == Outdated reference: A later version (-01) exists of
     draft-ietf-ipfix-psamp-mib-00

  -- Obsolete informational reference (is this intentional?): RFC 3280
     (Obsoleted by RFC 5280)

  -- Obsolete informational reference (is this intentional?): RFC 4346
     (Obsoleted by RFC 5246)

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/ 

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/

E5. what does 'binning' mean in the context of this document? 

E6. Figure F: IPFIX Mediation Functional Block - should be either
'Blocks' or 'Block Diagram'

E7. in 5.3.2.3 s/describied/described/

---

From: Kobayashi Atsushi <[email-masked]>
Date: Sun, 24 Oct 2010 13:35:07 +0900

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

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

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

> I could not figure out what 'the appropriateness of the scope field

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.

> this as a non-blocking comment. 

I would like to follow the rule of IPFIX architecture, not use
capitalized keywords.

> follow the recommendations in T2 and T5. 

Ok, I will change them into "should".
>   Checking references for intended status: Informational
Ok.

>      draft-ietf-ipfix-psamp-mib-00
Ok.

>   -- Obsolete informational reference (is this intentional?): RFC 3280
Ok.

>   -- Obsolete informational reference (is this intentional?): RFC 4346
Ok.

> requirements with limited system resources, the IPFIX architecture needs

Ok.

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

> 'Blocks' or 'Block Diagram'
Ok.

> E7. in 5.3.2.3 s/describied/described/

Ok.

Thanks,
Atsushi Kobayashi

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 24 Oct 2010 12:44:30 +0200

Hi Atsushi,

Please see my comments in-line. 

Thanks and Regards,

Dan 

> -----Original Message-----
> From: Kobayashi Atsushi [mailto:[email-masked]] 
> 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,
> 

Please do. 

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

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

>       interpretations, respectively.  Activation of this function must

OK. 

> The purpose of the document  expands the functionality of 
> IPFIX Architecture, therefore the document follows the rule 
> of RFC5470.

OK. 

>       Intermediate Process(es).

OK. 

> outgoing sides in order to ensure the consistency of scope 
> field values of incoming and outgoing Data Records defined by 
> Options Templates.
> 
> 

OK. 

> I would like to follow the rule of IPFIX architecture, not use

OK

> >   == Outdated reference: 
> draft-ietf-ipfix-mediators-problem-statement
> > has

---

From: Kobayashi Atsushi <[email-masked]>
Date: Mon, 25 Oct 2010 17:55:46 +0900

Hi Dan,

Thank you for your reply.
During discussing with co-authors, my answer was a little bit changed.
Please see in-line.

On Sun, 24 Oct 2010 12:44:30 +0200

> >       parameters related to this function must be configurable.

According to IPFIX architecture document(rfc5470), it said that some
paramaters should be configurable. This framework follows it.
 
   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.  The
      parameters that represent the origin should be configurable.

      interpretations, respectively.  Activation of this function should
      be configurable.

> > field values of incoming and outgoing Data Records defined by 

I would like to add about the consistency of Template IDs of
Template Withdrawal Messages.

   o  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, and of Template IDs of incoming and outgoing IPFIX
      Template Withdrawal Messages.

Regards,
Atsushi
--- 
Atsushi KOBAYASHI  <[email-masked]>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 25 Oct 2010 16:14:00 +0200

Hi Atsushi,

The suggested changes and clarifications are OK with me. 

Thanks and Regards,

Dan

> Sent: Monday, October 25, 2010 10:56 AM
> To: Romascanu, Dan (Dan)
> Cc: IPFIX Working Group
> Subject: Re[2]: [IPFIX] AD Review of 
> draft-ipfix-mediators-framework-08
> 
> Hi Dan,
> 
> > > > The technical comments are marked Tx and the editorial comments 
> > > > are marked Ex.
> > > > 
> > > In section 5.2, some parameters must be configurable. 
> That implies 
> > > there is no parameter to be transmitted just like the 
> case of IPFIX 
> According to IPFIX architecture document(rfc5470), it said 
> that some paramaters should be configurable. This framework 
> follows it.
>  
> > >       Processes, PSAMP Metering Processes, and Exporting 
> Processes 
> > > from
> > >       an Original Exporter.  See section 4 of [RFC5101] 
> and section 
> > > 6 of
> > > > I could not figure out what 'the appropriateness of the scope 
> > > > field values' means.
> > > 
> > > Templates.