Subject: RE: [ipfix] IPFIX requirements - final changes

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 30 May 2003 11:43:12 -0700

Juergen,

  Your phrasing sounds good:

 "Many requirements in this document are not explicitly
  stated as IPFIX protocol requirements, but as requirements
  for the metering process, the exporting process, or for
  other traffic measurement components. However, every
  requirement that needs support from the IPFIX protocol
  MUST be covered by the IPFIX protocol specification
  independent of the significance of the requirement,
  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
  Note that the protocol specification itself also assigns
  significance attributes to its features, such that a
  protocol implementation does not necessarily need to
  implement all features."

  One change I would suggest is to recognize that the specification
contains both a protocol and an (extendable) information model.
E.g. anonymization can be addressed w/o any change to the
protocol.

  So I'd rather see one of the sentences modified as:

    However, every requirement that needs support from the 
  IPFIX protocol or information model MUST be covered by the 
  IPFIX protocol or information model specification
  independent of the significance of the requirement

Regards,

  Jeff Meyer

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]]
> Sent: Friday, May 30, 2003 5:50 AM
> To: Sebastian Zander
> Cc: [email-masked]
> Subject: Re: [ipfix] IPFIX requirements - final changes
> 
> 
> Sebastian,
> 
> -- Sebastian Zander wrote on 29 May 2003 03:29 +0200:
> 
> > Juergen,
> >
> > Juergen Quittek wrote:
> >> Sebastian,
> >>
> >> -- Sebastian Zander wrote on 28 May 2003 12:18 +0200:
> >>
> >>> Hi Juergen,
> >>>
> >>> i think your second paragraph is a very good idea. But i don't
> >>> understand the last 2 sentences. My understanding is that 
> the ipfix
> >>> requirement draft defines the ipfix protocol 
> requirements. So i don't
> >>> understand why the protocol specification must cover all 
> requirements.
> >>> E.g. when a requirementis optional why must it be covered 
> in the protocol
> >>> specification?
> >>
> >>
> >> If the requirement doc says "the exporter MAY anonymize", then the
> >> protocol specification MUST support anonymization in order to make
> >> sure, that anonymization is interoperable. For example the protocol
> >> spec MUST define how to inform a collecting process that 
> the data it
> >> receives is anonymized. Analogously, the protocol spec 
> should specify
> >> how to encrypt.
> >>
> >> In both cases, the protocol specification can state that a concrete
> >> implementation of the protocol MAY support features that serve
> >> anonymization. Then an implementor can choose whether or 
> not to implement
> >> this OPTIONAL feature of the protocol.
> >
> > You are right. The req draft contains protocol 
> specification requirements
> > (which is sometimes confusing and the reason why we get 
> those comments).
> > But i suggest to change the middle sentence saying that all protocol
> > specification requirements from the req draft must be taken 
> over into the
> > protocol draft *including their significance*. Otherwise 
> why do we spend a
> > long time discussing the significance of some reqs if it is 
> not used later
> > in the protocol draft? Furthermore some of the reqs may be 
> targeting the
> > information model or achitecture draft instead of the 
> protocol spec. So
> > the sentence should not only mention the protocol spec but *also the
> > information model etc*. (Jeff just gave an example that 
> anonymization may
> > influence the information model.)
> 
> I see your point, but I would suggest a different phrasing for the
> following reason:
>   - I do not expect that requirement items can be mapped 
> one-to-one onto
>     protocol features. Some individual protocol feature will 
> cover several
>     requirement items at once. So here you cannot map the significance
>     one-to-one, but need something like a minimum significance to be
>     considered.
>   - My experience from designing other protocols is that - 
> compared to the
>     requirements - you usually increase significance of some features
>     for technical or orther reasons. We must make sure that 
> the protocol
>     definition process has this level of freedom.
> 
> Therefore, I suggest to extend my initially suggested paragraph
> 
>  "Many requirements in this document are not explicitly
>   stated as IPFIX protocol requirements, but as requirements
>   for the metering process, the exporting process, or for
>   other traffic measurement components. However, every
>   requirement that needs support from the IPFIX protocol
>   MUST be covered by the IPFIX protocol specification
>   independent of the significance of the requirement,
>   which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>   Note that the protocol specification itself also assigns
>   significance attributes to its features, such that a
>   protocol implementation does not necessarily need to
>   implement all features."
> 
> by appending this sentence or a similar one:
> 
>  "However, the significance assigned to a protocol feature
>   MUST NOT be lower than the significance of the corresponding
>   requirements."
> 
> Cheers,
> 
>     Juergen
> 
> 
> > This statement must be put in the very beginning of the req draft.
> >
> > The last sentence is not necessary in my opinion because 
> its pretty obvious
> > that the protocol draft and the other drafts will use more (and more
> > detailed) reqs.
> >
> > Then there is no need to change the requirements to MUST.
> >
> > Cheers,
> >
> > Sebastian
> >
> >>> I agree to say its a MUST for the protocol but not all exporters
> >>> and collectors must support it.
> >>
> >>
> >> Agreed.
> >>
> >>> But i do *not* agree at all that in general anonymization and
> >>> confidentiality is not needed in a LAN. Anonymization can 
> be required
> >>> in a LAN and even in a LAN confidentiality may be needed because i
> >>> don't want everybody who has access to my LAN to have access to my
> >>> IPFIX data.
> >>
> >>
> >> Also agreed.
> >>
> >> Best wishes,
> >>
> >>    Juergen
> >>
> >>> Cheers,
> >>>
> >>> Sebastian
> >>>
> >>> Juergen Quittek wrote:
> >>>
> >>>> Tal, Reinaldo, and Benoit,
> >>>>
> >>>> Do we all have the following in mind?
> >>>>
> >>>>   Anonymization and confidentiality MUST be covered by the
> >>>>   protocol specification.  But the protocol specifiction
> >>>>   specification defines it as a MAY feature (anonymization)
> >>>>   or SHOULD feature (confidentiality) for IPFIX protocol
> >>>>   implementations.
> >>>>
> >>>> I guess this is what the IESG reviewers were referring to.
> >>>>
> >>>> What is probably missing in the requirements document is a
> >>>> statement like the following:
> >>>>
> >>>>   Many requirements in this document are not explicitly
> >>>>   stated as IPFIX protocol requirements, but as requirements
> >>>>   for the metering process, the exporting process, or for
> >>>>   other traffic measurement components. However, every
> >>>>   requirement that needs support from the IPFIX protocol
> >>>>   MUST be covered by the IPFIX protocol specification
> >>>>   independent of the significance of the requirement,
> >>>>   which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
> >>>>   Note that the protocol specification itself also assigns
> >>>>   significance attributes to its features, such that a
> >>>>   protocol implementation does not necessarily need to
> >>>>   implement all features.
> >>>>
> >>>> Any comment on this?
> >>>>
> >>>>    Juergen
> >>>>
> >>>>
> >>>> -- Tal Givoly wrote on 26 May 2003 09:42 -0700:
> >>>>
> >>>>> Juergen,
> >>>>>
> >>>>> I agree with Benoit - it doesn't make sense to make 
> confidentiality and
> >>>>> anonymization mandatory. In many deployments, there could be
> >>>>> physical and
> >>>>> other security measures that addresses these issues.
> >>>>>
> >>>>> Tal
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: majordomo listserver 
> [mailto:[email-masked]]On
> >>>>> Behalf
> >>>>> Of Benoit Claise
> >>>>> Sent: Monday, May 26, 2003 8:02 AM
> >>>>> To: Juergen Quittek
> >>>>> Cc: [email-masked]
> >>>>> Subject: Re: [ipfix] IPFIX requirements - final changes
> >>>>>
> >>>>>
> >>>>> Juergen,
> >>>>>
> >>>>>> 
> ==============================================================
> ==========
> >>>>>>
> >>>>>> 12. Confidentiality from SHOULD to MUST
> >>>>>> 
> ==============================================================
> ==========
> >>>>>>
> >>>>>> Problem Description:
> >>>>>> 
> --------------------------------------------------------------
> ----------
> >>>>>>
> >>>>>> Requirements on the ipfix implementation - the 
> document is long and I
> >>>>>> wonder if
> >>>>>> the working group really meant the protocol's 
> confidentiality and
> >>>>>> anonymization
> >>>>>> features to be so optional -  SHOULD confidentiality, MAY
> >>>>>> anonymization.
> >>>>>> Just for implementation.
> >>>>>> 
> ==============================================================
> ==========
> >>>>>>
> >>>>>> Suggested solution:
> >>>>>> 
> --------------------------------------------------------------
> ----------
> >>>>>>
> >>>>>>   change confidentiality requirement in section 6.3.3
> >>>>>>   from SHOULD to MUST
> >>>>>> 
> ==============================================================
> ==========
> >>>>>>
> >>>>>> Status: solution to be agreed on
> >>>>>> 
> ==============================================================
> ==========
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> I'm just wondering if a MUST is not a little bit extreme.
> >>>>> The draft would become:
> >>>>>    "Confidentiality of flow specific data transferred 
> from an exporting
> >>>>>    process to a collecting process MUST be ensured."
> >>>>> We all agree that over the Internet confidentiality is 
> compulsory but
> >>>>> this sentence would mean that even in a private LAN or 
> environment, we
> >>>>> must have confidentiality to be IPFIX compliant. And we 
> know that, with
> >>>>> the software based encryption, the throughput would be 
> lowered. Ok,
> >>>>> then
> >>>>> we should have an crypto engine in hardware on the 
> exporter to export
> >>>>> the numerous flow export packets but there is a price to it.
> >>>>> My point is that, as Confidentiality is not needed in 
> all cases, why
> >>>>> make it a MUST?
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 
> ==============================================================
> ==========
> >>>>>>
> >>>>>> 13. Anonymization from MAY to MUST
> >>>>>> 
> ==============================================================
> ==========
> >>>>>>
> >>>>>> Problem Description:
> >>>>>> 
> --------------------------------------------------------------
> ----------
> >>>>>>
> >>>>>> Requirements on the ipfix implementation - the 
> document is long and I
> >>>>>> wonder if
> >>>>>> the working group really meant the protocol's 
> confidentiality and
> >>>>>> anonymization
> >>>>>> features to be so optional -  SHOULD confidentiality, MAY
> >>>>>> anonymization.
> >>>>>> Just for implementation.
> >>>>>> 
> ==============================================================
> ==========
> >>>>>>
> >>>>>> Suggested solution:
> >>>>>> 
> --------------------------------------------------------------
> ----------
> >>>>>>
> >>>>>>   change anonymization requirement in section 6.7 from 
> MAY to MUST
> >>>>>> 
> ==============================================================
> ==========
> >>>>>>
> >>>>>> Status: solution to be agreed on
> >>>>>> 
> ==============================================================
> ==========
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Again, I have the same type of comments. Anonymization 
> is not required
> >>>>> in all cases. So why make it a MUST?
> >>>>>
> >>>>> Regards, Benoit.
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Help        mailto:[email-masked] and say "help" in
> >>>>> message
> >>>>> body
> >>>>> Unsubscribe mailto:[email-masked] and say
> >>>>> "unsubscribe ipfix" in message body
> >>>>> Archive     http://ipfix.doit.wisc.edu/archive/
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Help        mailto:[email-masked] and say 
> "help" in message
> >>>> body
> >>>> Unsubscribe mailto:[email-masked] and say
> >>>> "unsubscribe ipfix" in message body
> >>>> Archive     http://ipfix.doit.wisc.edu/archive/
> >>>>
> >>>
> >>>
> >>> --
> >>> Sebastian Zander                         E-mail:
> >>> [email-masked]
> >>> Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
> >>> Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
> >>> D-10589 Berlin, Germany
> >>> www.fokus.fraunhofer.de/usr/sebastian.zander
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> > --
> > Sebastian Zander                         E-mail: 
> [email-masked]
> > Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
> > Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
> > D-10589 Berlin, Germany                  
> www.fokus.fraunhofer.de/usr/sebastian.zander
> >
> >
> >
> >
> 
> 
> 
> --
> Help        mailto:[email-masked] and say "help" 
> in message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Juergen Quittek <[email-masked]>
Date: Sat, 31 May 2003 00:27:39 +0200

Jeff,

>   independent of the significance of the requirement

Agreed.
Maybe we should replace two times 'or' by 'and/or'.

    Juergen