Subject: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 2 Feb 2010 18:55:14 +0100

Please find below the AD review of draft-ietf-ipfix-mediators-framework.
The document is in pretty good shape, but I suggest that the editors
review my technical and editorial comments and address them before
deciding whether to revise the I-D or send the document directly to IETF
Last Call.

Thanks and Regards,

Dan

Technical: 

T1. I do not see the Data Retention use case mentioned in
draft-ietf-mediators-problem-statement addressed in any way in this
draft. Did I miss anything? 

T2. In Section 5.3: 

Maintaining additional information about output record streams,
      which includes information related to Original Exporter, and some
      configuration parameters related to each function.

I think here we need to add the observation domain and the admin domain
to the Original Exporter because of support for multiple exporters and
correlation between domains

T3. In section 7 - I cannot figure out how the collector knows what to
fill in the Observation Domain ID when this is different from the
incoming Observation Domain ID? Can you help by explaining how this
works? 

4. Data retention needs to be added to the security considerations - if
relevant - related to T1

Editorial: 

E1. running id-nits results in the following warnings: 

tmp/draft-ietf-ipfix-mediators-framework-04.txt:
tmp/draft-ietf-ipfix-mediators-framework-04.txt(405): Line has weird
spacing: '...ributor   one ...'
tmp/draft-ietf-ipfix-mediators-framework-04.txt(407): Line has weird
spacing: '...ntrator  one o...'
tmp/draft-ietf-ipfix-mediators-framework-04.txt(410): Line has weird
spacing: '...erading  one o...'
tmp/draft-ietf-ipfix-mediators-framework-04.txt(530): Line has weird
spacing: '...Reports  recor...'
tmp/draft-ietf-ipfix-mediators-framework-04.txt(547): Line has weird
spacing: '...rvation  into ...'

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
 
------------------------------------------------------------------------
----

  ** The document seems to lack a License Notice according IETF Trust
     Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep
2009
     Section 6.b -- however, there's a paragraph with a matching
beginning.
     Boilerplate error?

     IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i),
paragraph 3:
     "This document is subject to BCP 78 and the IETF Trust's Legal
Provisions
      Relating to IETF Documents (http://trustee.ietf.org/license-info)
      in effect on the date of publication of this document.  Please
      review these documents carefully, as they describe your rights and
      restrictions with respect to this document.  Code Components
      extracted from this document must include Simplified BSD License
      text as described in Section 4.e of the Trust Legal Provisions and
      are provided without warranty as described in the Simplified BSD
      License."     

     ... text found in draft:
     "This document is subject to BCP 78 and the IETF Trust's Legal
Provisions
      Relating to IETF Documents in effect on the date of publication of
.................................^
      this document (http://trustee.ietf.org/license-info). Please
review
      these documents carefully, as they describe your rights and
      restrictions with respect to this document."

     (You're using the IETF Trust Provisions' Section 6.b License Notice
from
     12 Feb 2009 rather than one of the newer Notices.  See
     http://trustee.ietf.org/license-info/.)

E2. Section 1. 

To acihive application requirements with limited system resources,
   IPFIX architecture needs to introduce an intermediate device between
   Exporters and Collectors. 

s/acihive/achieve/

Also 'device' has too much a hardware connotation, while mediators need
not be necessarily hardware 'devices'. Probably 'component' or 'entity'
is more appropriate. 

E3. Part of the definitions in section 2 duplicate definitions in
draft-ietf-mediators-problem-statement. Better avoid the duplication and
just refer draft-ietf-mediators-problem-statement. 

 E4. Section 7 - 

 The IPFIX Message Header [RFC5101] includes Export Time, Sequence
   Number, and Observation Domain ID fields.  This section describes
   some consideration points for the IPFIX Message Header encoding.

Need to add 'in the context of IPFIX Mediation'.

E5. Should not [IPFIX-MD-PS] be a Normative Reference?

---

From: Atsushi Kobayashi <[email-masked]>
Date: Wed, 10 Feb 2010 00:24:37 +0900

Hi Dan, and all,

Thank you for your comments. Sorry for my late reply.
Please see in-line.

On Tue, 2 Feb 2010 18:55:14 +0100

> draft. Did I miss anything? 

Problem statement draft raised the following requirements about data
retentions.

- Reliable exporting
In this case, an IPFIX Mediator beside an Original Exporter can enhance
the export reliability by converting from UDP to SCP. This has relevance
to section 5.3.2.1. "Intermediate Conversion Process".

- Huge storage for data records
In this case, an IPFIX Mediator re-exports data records stored to a
Collector on demand. This has relevance to section 6.3. "IPFIX File
Writer/Reader".

I will improve the section 5.3.2.1. and section 6.3 as follows.

5.3.2.1.  Intermediate Conversion Process

[snip]

[Old]
In the case of IPFIX transport protocol conversion, the Intermediate
Conversion Process covers the following functions.

[New]
In the case of IPFIX transport protocol conversion to enhance the export
reliability, commonly used in data retention and accounting, the
Intermediate Conversion Process covers the following functions.

6.3.  IPFIX File Writer/Reader

[snip]

   .-------------.  .---------------.  .---------------.  .-----------.
   | IPFIX       |  | Intermediate  |  | Intermediate  |  | Exporting |
   |   File      |  | Anonymization |  |   Correlation |  |   Process |
   |      Reader +->|       Process +->|       Process +->|           |
   '-------------'  '---------------'  '---------------'  '-----------'

   Figure J: IPFIX Mediation Example with IPFIX File Reader.

[New]
When distributed IPFIX Mediators export Data Records stored on demand as
like figure, it allows us to build the collecting infrastructure with
huge storage for data retention.

> correlation between domains

I will replace it as follows.

[New]
Maintaining additional information about output record streams, which
includes information related to Original Exporter, Observation Domain, and
administrative domain and some configuration parameters related to each
function.

> incoming Observation Domain ID? Can you help by explaining how this

Could you please see last sentense in section 7. But, it seems sketchy.
I will replace it as follows.

[Old]
In that case, the IPFIX Concentrator can add a new field to the Flow
Record instead of the Observation Domain ID.  The field indicates the
largest set of Observation Points for an aggregated Flow Record.

[New]
When an IPFIX Mediator needs to give the Observation Domain ID value
exported from an Original Exporter to Collector, an IPFIX Mediator can
insert this value as new fields into Flow Record, or Data Records
defined by Options Templates.  In the case of Flow Records aggregation
in an IPFIX Mediator, this new
field indicates the largest set of Observation Points for an aggregated
Flow Record.

I think this method will be described in detail in standard mediation
protocol document at next stage.

> 4. Data retention needs to be added to the security considerations - if

I put the feedback from problem statement draft, and will enhance them.

>   http://trustee.ietf.org/license-info):

This document was submitted in October, 2009. Thus, it could not catch
up with latest License Notice. I will take care in next version.

>       Relating to IETF Documents in effect on the date of publication of

Thank you. 

> Need to add 'in the context of IPFIX Mediation'.
Ok.

> E5. Should not [IPFIX-MD-PS] be a Normative Reference? 

[IPFIX-MD-PS] describes the concept of mediation as informative
reference, does not describe the normative standard.
Thus, I think it is a informative reference.

Regards,
Atsushi

> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Feb 2010 13:10:21 +0100

Hi Atsushi,

Your proposed edits are fine. I am expecting for a revised version to be
published before sending the document to IETF Last Call. 

Thanks and Regards,

Dan 

> -----Original Message-----
> From: Atsushi Kobayashi [mailto:[email-masked]] 
> Sent: Tuesday, February 09, 2010 5:25 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework
> 
> 
> Hi Dan, and all,
> 
> > deciding whether to revise the I-D or send the document directly to 
> > IETF Last Call.
> > 
> > Thanks and Regards,
> > 
> > Dan
> > 
> > 
> > Technical: 
> > 
> Problem statement draft raised the following requirements 
> about data retentions.
> 
> - Reliable exporting
> In this case, an IPFIX Mediator beside an Original Exporter 
> can enhance the export reliability by converting from UDP to 
> SCP. This has relevance to section 5.3.2.1. "Intermediate 
> Conversion Process".
> 
> In this case, an IPFIX Mediator re-exports data records 
> stored to a Collector on demand. This has relevance to 
> section 6.3. "IPFIX File Writer/Reader".
> 
> In the case of IPFIX transport protocol conversion, the 
> In the case of IPFIX transport protocol conversion to enhance 
> the export reliability, commonly used in data retention and 
> accounting, the Intermediate Conversion Process covers the 
> following functions.
> 
> When distributed IPFIX Mediators export Data Records stored 
> on demand as like figure, it allows us to build the 
> collecting infrastructure with huge storage for data retention.
> 
> 
> > T2. In Section 5.3: 
> > 
> > I think here we need to add the observation domain and the admin 
> > domain to the Original Exporter because of support for multiple 
> > exporters and correlation between domains
> 
> Maintaining additional information about output record 
> streams, which includes information related to Original 
> Exporter, Observation Domain, and administrative domain and 
> some configuration parameters related to each function.
> 
> > 
> In that case, the IPFIX Concentrator can add a new field to 
> the Flow Record instead of the Observation Domain ID.  The 
> field indicates the largest set of Observation Points for an 
> aggregated Flow Record.
> 
> [New]
> When an IPFIX Mediator needs to give the Observation Domain 
> ID value exported from an Original Exporter to Collector, an 
> IPFIX Mediator can insert this value as new fields into Flow 
> Record, or Data Records defined by Options Templates.  In the 
> case of Flow Records aggregation in an IPFIX Mediator, this 
> new field indicates the largest set of Observation Points for 
> an aggregated Flow Record.
> 
> I think this method will be described in detail in standard 
> mediation protocol document at next stage.
> 
> > 
> > 4. Data retention needs to be added to the security 
> considerations - 
> > if relevant - related to T1
> 
> This document was submitted in October, 2009. Thus, it could 
> not catch up with latest License Notice. I will take care in 
> next version.
> 
> 
> >       Relating to IETF Documents in effect on the date of 
> publication 
> > of .................................^
> >      (You're using the IETF Trust Provisions' Section 6.b License 
> > Notice from
> > Also 'device' has too much a hardware connotation, while mediators 
> > need not be necessarily hardware 'devices'. Probably 
> 'component' or 'entity'
> > is more appropriate. 
> 
> Thank you. 
> 
> > 
> > draft-ietf-mediators-problem-statement. Better avoid the 
> duplication 
> > and just refer draft-ietf-mediators-problem-statement.
> > 
> >  E4. Section 7 -
> > 
> [IPFIX-MD-PS] describes the concept of mediation as 
> informative reference, does not describe the normative standard.

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 15 Feb 2010 13:18:37 +0100

Hi Dan, Atsushi,

I'm confused. Has there already been a WG LC for this document?

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Informatics
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Feb 2010 15:05:43 +0100

Hmmmm ... This is a question for the chairs actually. The tracker says it was submitted to the IESG on 1/19 together with draft-ipfix-mediators-problem-statement, but maybe the track is wrong as I cannot find a PROTO write-up  for it - the one in the tracker is for problem-statement. I am freezing this one until I get a clarification from Juergen and Nevil. If you are correct I will wait for the WG to complete the consensus process. No bad things happened, anyway - you just got an early AD review :-) 

Dan

> From: Gerhard Muenz [mailto:[email-masked]] 
> Sent: Monday, February 15, 2010 2:19 PM
> To: Romascanu, Dan (Dan)
> Cc: Atsushi Kobayashi; [email-masked]
> > Your proposed edits are fine. I am expecting for a revised 
> version to 
> > be published before sending the document to IETF Last Call.
> > 
> > Thanks and Regards,
> > 
> > Dan
> > 
> about data 
> >> In this case, an IPFIX Mediator beside an Original Exporter can 
> >> enhance the export reliability by converting from UDP to SCP. This 
> >> has relevance to section 5.3.2.1. "Intermediate Conversion 
> Process".
> >>
> stored to a 
> Intermediate 
> >> In the case of IPFIX transport protocol conversion to enhance the 
> >> export reliability, commonly used in data retention and 
> accounting, 
> >> the Intermediate Conversion Process covers the following functions.
> >>
> >> When distributed IPFIX Mediators export Data Records 
> stored on demand 
> >> as like figure, it allows us to build the collecting 
> infrastructure 
> >> with huge storage for data retention.
> >>
> >>
> >>> T2. In Section 5.3: 
> >>>
> streams, which 
> >> includes information related to Original Exporter, Observation 
> >> Domain, and administrative domain and some configuration 
> parameters 
> >> related to each function.
> >>
> >> exported from an Original Exporter to Collector, an IPFIX Mediator 
> >> can insert this value as new fields into Flow Record, or 
> Data Records 
> >> defined by Options Templates.  In the case of Flow Records 
> >> aggregation in an IPFIX Mediator, this new field indicates the 
> ---------------------------------------------------------------------
> >> -
> >>> --
> >>> ----
> >>>
> >> This document was submitted in October, 2009. Thus, it could not 
> >> catch up with latest License Notice. I will take care in next 
> >> version.
> >>
> >>
> >>>       this document 
> (http://trustee.ietf.org/license-info). Please 
> >>> review
> Chair for Network Architectures and Services (I8) Technische 
> Universität München - Department of Informatics Boltzmannstr. 
> 3, 85748 Garching bei München, Germany

---

From: Atsushi Kobayashi <[email-masked]>
Date: Tue, 16 Feb 2010 01:13:01 +0900

Hi Dan, Gerhard,

I am also asking chairs what happened to this document. It seems mistake.
All I can say is that Dan review is worthwhile at even this phase. Thank
you.

Regards,
Atsushi

On Mon, 15 Feb 2010 15:05:43 +0100

---

From: "Juergen Quittek" <[email-masked]>
Date: Tue, 16 Feb 2010 18:13:47 +0100

Dear Dan and all,

This is a mistake in the tracker.

On Jan 19 I submitted the write-up for
draft-ipfix-mediators-problem-statement,
but not for draft-ietf-ipfix-mediators-framework.

The framework still needs to undergo a WG last call
Which will probably happen soon.

    Juergen

On 15.02.10 15:05  "Dan Romascanu" <[email-masked]> wrote:

> Hmmmm ... This is a question for the chairs actually. The tracker says it was
> submitted to the IESG on 1/19 together with
> draft-ipfix-mediators-problem-statement, but maybe the track is wrong as I
> cannot find a PROTO write-up  for it - the one in the tracker is for
> problem-statement. I am freezing this one until I get a clarification from
> Juergen and Nevil. If you are correct I will wait for the WG to complete the
> consensus process. No bad things happened, anyway - you just got an early AD
> review :-) 
> 
> Dan
> 
>