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

From: Benoit Claise <[email-masked]>
Date: Mon, 02 Jun 2003 13:00:08 +0200

Juergen,

> 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 agree with Sebastian here to add *including their significance*

I see a potential with your proposed paragraph below:

    "However, the significance assigned to a protocol feature
     MUST NOT be lower than the significance of the corresponding
     requirements."

This paragraph is just comon sense; we spent sooo much time describing 
the requirements. We obviously don't want to rediscuss them
Now the possible trap is that: it MUST NOT lower, so it might be 
higher... we can start thinking...
And we start again on hot topic like adding extra reliability, changing 
MAY to SHOULD, SHOULD to MUST, etc... so rediscussing the requirements!

My vote goes to *including their significance*, as Sebastian proposed 
and removing your last paragraph.

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

And if, for whatever valid reasons (like a technical one), the WG 
consensus decides to increase the significance of a specific 
requirement, then we would still be OK with our requirement draft.

Regards, Benoit.

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

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 02 Jun 2003 13:47:12 +0200

Benoit,

-- Benoit Claise wrote on 02 June 2003 13:00 +0200:

> This paragraph is just comon sense; we spent sooo much time describing the requirements. We obviously don't want to rediscuss them
> Now the possible trap is that: it MUST NOT lower, so it might be higher... we can start thinking...
> And we start again on hot topic like adding extra reliability, changing MAY to SHOULD, SHOULD to MUST, etc... so rediscussing the requirements!
>
> My vote goes to *including their significance*, as Sebastian proposed and removing your last paragraph.
>
>>>
>>
> And if, for whatever valid reasons (like a technical one), the WG consensus decides to increase the significance of a specific requirement, then we would still be OK with our requirement draft.

I got yout point.  Fine with me.

Cheers,

    Juergen

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