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

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Sun, 1 Jun 2003 21:44:41 -0700

Juergen,

  "and/or" or "or" either way works for me.

-- Jeff

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: Friday, May 30, 2003 3:28 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1); Sebastian Zander
Cc: [email-masked]
Subject: RE: [ipfix] IPFIX requirements - final changes

Jeff,

-- MEYER,JEFFREY D (HP-Cupertino,ex1) wrote on 30 May 2003 11:43 -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

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

    Juergen

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

--
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: Benoit Claise <[email-masked]>
Date: Mon, 02 Jun 2003 12:43:39 +0200

Jeff,

>  independent of the significance of the requirement
You have a good point.
Now, I'm thinking loud here.
Aren't they any requirements that influence the architecture draft?
So should we have this sentence more generic? And as a consequence 
include a pointer to the architecture draft?
I think this is worth mentioning.

So this paragraph would become (at least regarding the meaning):

    However, every requirement that needs support from one or multiple drafts (IPFIX architecture, I PFIX protocol, information model) MUST be covered by the respective specification
    independent of the significance of the requirement

Regards, Benoit.

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Mon, 2 Jun 2003 11:39:54 -0700

Benoit,
 
  Makes sense to me.  Since we are decomposing the problem into
architecture, info model and protocol, it may be that any of these address
this.
 
-- Jeff

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]]
Sent: Monday, June 02, 2003 3:44 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Juergen Quittek'; Sebastian Zander; [email-masked]
Subject: Re: [ipfix] IPFIX requirements - final changes

Jeff,

  implement all features."

protocol.

You have a good point.
Now, I'm thinking loud here.
Aren't they any requirements that influence the architecture draft?
So should we have this sentence more generic? And as a consequence include a
pointer to the architecture draft?
I think this is worth mentioning.

    However, every requirement that needs support from one or multiple
drafts (IPFIX architecture, I PFIX protocol, information model) MUST be
covered by the respective specification

Regards,

  Jeff Meyer

-----Original Message-----

From: Juergen Quittek [ mailto:[email-masked]
<mailto:[email-masked]> ]

To: Sebastian Zander

Cc:  [email-masked] <mailto:[email-masked]> 

Sebastian,

    

Juergen,

Juergen Quittek wrote:

Sebastian,

        

Hi Juergen,

the ipfix

requirements. So i don't

requirements.

in the protocol

specification?

the data it

should specify

how to encrypt.

not to implement

those comments).

over into the

why do we spend a

not used later

targeting the

protocol spec. So

anonymization may

following reason:

one-to-one onto

cover several

    considered.

compared to the

the protocol

  implement all features. " <byappendingthissentenceorasimilarone:> 

  requirements."

Cheers,

    Juergen

its pretty obvious

detailed) reqs.

Cheers,

Sebastian

Agreed.

be required

IPFIX data.

Also agreed.

Best wishes,

   Juergen

Cheers,

Sebastian

Juergen Quittek wrote:

  implementations.

  implement all features.

Any comment on this?

   Juergen

            

Juergen,

confidentiality and

physical and

Tal

-----Original Message-----

[ mailto:[email-masked] <mailto:[email-masked]>
]On

Behalf

Of Benoit Claise

To: Juergen Quittek

Cc:  [email-masked] <mailto:[email-masked]> 

Juergen,

==========

                

==========

Problem Description:

----------

document is long and I

wonder if

confidentiality and

anonymization

anonymization.

Just for implementation.

==========

Suggested solution:

----------

  from SHOULD to MUST

==========

                

==========

The draft would become:

from an exporting

compulsory but

environment, we

know that, with

lowered. Ok,

then

exporter to export

all cases, why

make it a MUST?

                

==========

                

==========

Problem Description:

----------

document is long and I

wonder if

confidentiality and

anonymization

anonymization.

Just for implementation.

==========

Suggested solution:

----------

MAY to MUST

==========

                

==========

is not required

Regards, Benoit.

--

Help         mailto:[email-masked]
<mailto:[email-masked]>  and say "help " in
<inmessagebodyUnsubscribemailto:[email-masked]> 

message

body

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/> 

--

Help         mailto:[email-masked]
<mailto:[email-masked]>  and say 

"help" in message

body

Unsubscribe  mailto:[email-masked]
<mailto:[email-masked]>  and say

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/> 

--

Sebastian Zander                         E-mail:

[email-masked] <mailto:[email-masked]> 

D-10589 Berlin, Germany

www.fokus.fraunhofer.de/usr/sebastian.zander
<http://www.fokus.fraunhofer.de/usr/sebastian.zander> 

        

--

Sebastian Zander                         E-mail: 

[email-masked] <mailto:[email-masked]> 

D-10589 Berlin, Germany                  

www.fokus.fraunhofer.de/usr/sebastian.zander
<http://www.fokus.fraunhofer.de/usr/sebastian.zander> 

--

Help         mailto:[email-masked]
<mailto:[email-masked]>  and say "help "
<inmessagebodyUnsubscribemailto:[email-masked]> 

in message body

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/> 

--

Help         mailto:[email-masked]
<mailto:[email-masked]>  and say "help " in message body
<inmessagebodyUnsubscribemailto:[email-masked]> 

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/>