Subject: Re: [IPFIX] [Sender: [email-masked]] Re: draft-ietf-ipfix-ie-doctors-02 review

From: Andrew Feren <[email-masked]>
Date: Thu, 02 Aug 2012 09:56:07 -0400

Hi Paul,
 
 I'm not sure there was a consensus, but my personal conclusion currently is
that there should be a single bad state for IEs that should be avoided (call
it deprecated, obsolete, historical, whatever).  Ideally the description for
any deprecated IEs will point implementers in a more appropriate direction
(or explain why it is a bad idea and there is no alternative).  Exporter
implementers should favour the more appropriate choice.  Collector
implementers may choose to support or not deprecated IEs.
 
 -Andrew
 
 On 08/01/2012 07:19 AM, Paul Aitken wrote:

> Brian, Andrew, 
>  
>  What was the conclusion here?
>  
>  Please get some time to discuss this in the WG meeting.
>  
>  Thanks, 
>  P. 
>  
>  
>  On 19/07/12 15:45, Brian Trammell wrote:
>  
>> Hi, Andrew, 
>>  
>>  Essentially, if this is the argument (which I'm not saying I disagree with),
>> then we should drop obsolete as a status, and just stay with deprecated --
>> there's no point in distinguishing "don't use it" from "REALLY don't use it"
>> unless we specify that use of deprecated IEs is a warning and use of obsolete
>> IEs is an error.
>>  
>>  Especially since we'll never reclaim number or namespace anyway, why not
>> just collapse to one "dead" status?
>>  
>>  Cheers, 
>>  
>>  Brian 
>>  
>>  On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote:
>>  
>>  
>>> On 07/19/2012 05:01 AM, Brian Trammell wrote:
>>>  
>>>  [ snip ] 
>>>  
>>>>  
>>>>>  
>>>>>>     After a period of time determined in the eyes
>>>>>>      of the IE-DOCTORS experts to be reasonable in order to allow
>>>>>> deployed 
>>>>>>      Exporting Processes to be updated to account for the deprecation, a
>>>>>>      deprecated Information Element may be made obsolete.  Obsolete
>>>>>>      Information Elements MUST NOT be supported by either Exporting or
>>>>>>      Collecting Processes.  The receipt of obsolete Information Elements
>>>>>>  
>>>>>  ** ** Nope, not happening. I can't force my customers to upgrade just
>>>>> because some 3rd party says so.
>>>>>  
>>>>  "MUST NOT be supported by new implementations of either Exporting or
>>>> Collecting Processes"?
>>>>  
>>>>  The point here is that if we're going to support deprecation (which was
>>>> clearly the intent of the WG, given its inclusion in 5102), there may be a
>>>> mismatch between the deployed and specified environment WRT supported IEs.
>>>>  
>>>>  
>>>>  
>>>  I have to side with Paul on this one.  Saying that a collecting process
>>> MUST NOT support obsoleted IEs seems to me to violate the robustness
>>> principle.  An argument can be made that new exporters SHOULD / MUST NOT
>>> send deprecated IEs, but I think more than that is too much.
>>>  
>>>  To give a specific example of the shelf life of the obsolete. Wikipedia
>>> tells me that NetFlow v1 is obsolete (and it has been for years), but I
>>> still see NetFlow v1 exports on some customer networks.
>>>  
>>>  -Andrew 
>>>  _______________________________________________
>>>  IPFIX mailing list
>>>  [email-masked]
>>>  https://www.ietf.org/mailman/listinfo/ipfix
>>>  
>>  _______________________________________________
>>  IPFIX mailing list
>>  [email-masked] 
>>  https://www.ietf.org/mailman/listinfo/ipfix
>>  
>  
>  
>

---

From: Paul Aitken <[email-masked]>
Date: Thu, 02 Aug 2012 15:51:55 +0100

Andrew,

I mostly agree, except that collector implementers must support all the 
information elements that ever were, regardless of their current state, 
because you cannot know what an exporting process might send you.

Else you'll suddenly be unable to decode exports from all the un-updated 
devices in the field.

There are many reasons why exporting devices might not be updated.

P.

On 02/08/12 14:56, Andrew Feren wrote:
> Hi Paul,
>
> I'm not sure there was a consensus, but my personal conclusion 
> currently is that there should be a single bad state for IEs that 
> should be avoided (call it deprecated, obsolete, historical, 
> whatever).  Ideally the description for any deprecated IEs will point 
> implementers in a more appropriate direction (or explain why it is a 
> bad idea and there is no alternative).  Exporter implementers should 
> favour the more appropriate choice.  Collector implementers may choose 
> to support or not deprecated IEs.
>
> -Andrew
>
>>> Essentially, if this is the argument (which I'm not saying I 
>>> disagree with), then we should drop obsolete as a status, and just 
>>> stay with deprecated -- there's no point in distinguishing "don't 
>>> use it" from "REALLY don't use it" unless we specify that use of 
>>> deprecated IEs is a warning and use of obsolete IEs is an error.
>>>
>>> Especially since we'll never reclaim number or namespace anyway, why 
>>> not just collapse to one "dead" status?
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>>>>> ** ** Nope, not happening. I can't force my customers to upgrade 
>>>>>> just because some 3rd party says so.
>>>>> "MUST NOT be supported by new implementations of either Exporting 
>>>>> or Collecting Processes"?
>>>>>
>>>>> The point here is that if we're going to support deprecation 
>>>>> (which was clearly the intent of the WG, given its inclusion in 
>>>>> 5102), there may be a mismatch between the deployed and specified 
>>>>> environment WRT supported IEs.
>>>>>
>>>>>
>>>> I have to side with Paul on this one.  Saying that a collecting 
>>>> process MUST NOT support obsoleted IEs seems to me to violate the 
>>>> robustness principle.  An argument can be made that new exporters 
>>>> SHOULD / MUST NOT send deprecated IEs, but I think more than that 
>>>> is too much.
>>>>
>>>> To give a specific example of the shelf life of the obsolete. 
>>>> Wikipedia tells me that NetFlow v1 is obsolete (and it has been for 
>>>> years), but I still see NetFlow v1 exports on some customer networks.
>>>>
>>>> -Andrew

---

From: Andrew Feren <[email-masked]>
Date: Thu, 02 Aug 2012 11:16:43 -0400

Hi Paul,

In theory I agree.  In practice I don't.

I said "may" because it may not be practical or desirable for a collector to
implement deprecated IEs.  You can say a collector MUST implement all IEs
there will be cases when they don't.  There are already cases when non
deprecated IEs are not supported (if the IE didn¹t exist when a collector
was last updated for example).  I don't see this being all that different.
I think saying collectors MUST support deprecated IE values is as pointless
as saying that deprecated IEs MUST NOT be supported by exporters.

-Andrew

From:  Paul Aitken <[email-masked]>
Date:  Thursday, August 2, 2012 10:51 AM
To:  Andrew Feren <[email-masked]>
Cc:  Brian Trammell <[email-masked]>, <[email-masked]>
Subject:  Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review

Andrew,

 
 
 P.

 On 02/08/12 14:56, Andrew Feren wrote:

> any deprecated IEs will point implementers in a more appropriate direction (or
> explain why it is a bad idea and there is no alternative).  Exporter
>>>  Essentially, if this is the argument (which I'm not saying I disagree
>>> with), then we should drop obsolete as a status, and just stay with
>>> deprecated -- there's no point in distinguishing "don't use it" from "REALLY
>>> don't use it" unless we specify that use of deprecated IEs is a warning and
>>> use of obsolete IEs is an error.
>>>

---

From: Paul Aitken <[email-masked]>
Date: Thu, 02 Aug 2012 17:01:36 +0100

Andrew, Steven,

Fair point. Obviously there are some limitations in which fields each EP 
and CP can support.

However that could lead to an interop failure where a 3rd party believes 
that IPFIX exporter X should work with IPFIX collector Y because they 
both claim IPFIX compliance. Yet this turns out not to be the case since 
X exports some too-new or too-old IEs which Y doesn't accept.

So our customers would be obliged to evaluate X against Y in their labs 
prior to deployment, and repeat for every new X' and Y'.

Or X and Y do the testing, and self-certify that version X interops 
correctly with version Y.

I have an idea. Let me unicast you.

P.

On 02/08/12 16:44, Steven Campbell wrote:
> I agree with Andrew's synopsis as stated below:
>>> whatever).  Ideally the description for any deprecated IEs will 
>>> point implementers in a more appropriate direction (or explain why 
>>> it is a bad idea and there is no alternative).  Exporter 
> We can look at a collector as simply a reporting device for IE's, but 
> in fact, many of the implementations do much more than simply 
> represent what they receive thus a collector may or may not derive 
> value from a deprecated IE thus might choose not to support it.
> Best regards,
> Steve
>
> On Aug 2, 2012, at 10:16 AM, Andrew Feren wrote:
>
>> Hi Paul,
>>
>> I said "may" because it may not be practical or desirable for a 
>> collector to implement deprecated IEs.  You can say a collector MUST 
>> implement all IEs there will be cases when they don't.  There are 
>> already cases when non deprecated IEs are not supported (if the IE 
>> didn’t exist when a collector was last updated for example).  I don't 
>> see this being all that different.  I think saying collectors MUST 
>> support deprecated IE values is as pointless as saying that 
>> deprecated IEs MUST NOT be supported by exporters.
>>
>> -Andrew
>>
>> From: Paul Aitken <[email-masked] <mailto:[email-masked]>>
>> To: Andrew Feren <[email-masked] <mailto:[email-masked]>>
>> Cc: Brian Trammell <[email-masked] 
>> <mailto:[email-masked]>>, <[email-masked] 
>> <mailto:[email-masked]>>
>> I mostly agree, except that collector implementers must support all 
>> the information elements that ever were, regardless of their current 
>> state, because you cannot know what an exporting process might send you.
>>
>> Else you'll suddenly be unable to decode exports from all the 
>> un-updated devices in the field.
>>
>>> whatever).  Ideally the description for any deprecated IEs will 
>>> point implementers in a more appropriate direction (or explain why 
>>> it is a bad idea and there is no alternative). Exporter implementers 
>>> should favour the more appropriate choice.  Collector implementers 
>>> may choose to support or not deprecated IEs.
>>>
>>> -Andrew
>>>
>>>>> Especially since we'll never reclaim number or namespace anyway, 
>>>>> why not just collapse to one "dead" status?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Brian
>>>>>
>>>>>>>>>     of the IE-DOCTORS experts to be reasonable in order to 
>>>>>>>>> allow deployed
>>>>>>>> ** ** Nope, not happening. I can't force my customers to 
>>>>>>>> upgrade just because some 3rd party says so.
>>>>>>> "MUST NOT be supported by new implementations of either 
>>>>>>> Exporting or Collecting Processes"?
>>>>>>>
>>>>>>> 5102), there may be a mismatch between the deployed and 
>>>>>>> specified environment WRT supported IEs.
>>>>>>>
>>>>>>>
>>>>>> Wikipedia tells me that NetFlow v1 is obsolete (and it has been 
>>>>>> for years), but I still see NetFlow v1 exports on some customer 
>>>>>> networks.
>>>>>>
>>>>>> -Andrew
>> [email-masked] <mailto:[email-masked]>

---

From: Steven Campbell <[email-masked]>
Date: Thu, 2 Aug 2012 15:44:11 +0000

I agree with Andrew's synopsis as stated below:
I'm not sure there was a consensus, but my personal conclusion currently is that there should be a single bad state for IEs that should be avoided (call it deprecated, obsolete,         historical, whatever).  Ideally the description for any deprecated IEs will point implementers in a more appropriate direction (or explain why it is a bad idea and there is no alternative).  Exporter implementers should favour the more appropriate choice.  Collector implementers may choose to support or not deprecated IEs.

We can look at a collector as simply a reporting device for IE's, but in fact, many of the implementations do much more than simply represent what they receive thus a collector may or may not derive value from a deprecated IE thus might choose not to support it.
Best regards,
Steve

Hi Paul,

I said "may" because it may not be practical or desirable for a collector to implement deprecated IEs.  You can say a collector MUST implement all IEs there will be cases when they don't.  There are already cases when non deprecated IEs are not supported (if the IE didn’t exist when a collector was last updated for example).  I don't see this being all that different.  I think saying collectors MUST support deprecated IE values is as pointless as saying that deprecated IEs MUST NOT be supported by exporters.

-Andrew

From: Paul Aitken <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 2, 2012 10:51 AM
To: Andrew Feren <[email-masked]<mailto:[email-masked]>>
Cc: Brian Trammell <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review

Andrew,

I mostly agree, except that collector implementers must support all the information elements that ever were, regardless of their current state, because you cannot know what an exporting process might send you.

Else you'll suddenly be unable to decode exports from all the un-updated devices in the field.

P.

I'm not sure there was a consensus, but my personal conclusion currently is that there should be a single bad state for IEs that should be avoided (call it deprecated, obsolete, historical, whatever).  Ideally the description for any deprecated IEs will point implementers in a more appropriate direction (or explain why it is a bad idea and there is no alternative).  Exporter implementers should favour the more appropriate choice.  Collector implementers may choose to support or not deprecated IEs.

-Andrew

Thanks,
P.

Essentially, if this is the argument (which I'm not saying I disagree with), then we should drop obsolete as a status, and just stay with deprecated -- there's no point in distinguishing "don't use it" from "REALLY don't use it" unless we specify that use of deprecated IEs is a warning and use of obsolete IEs is an error.

Especially since we'll never reclaim number or namespace anyway, why not just collapse to one "dead" status?

Cheers,

Brian

[ snip ]
    After a period of time determined in the eyes
    of the IE-DOCTORS experts to be reasonable in order to allow deployed
    Exporting Processes to be updated to account for the deprecation, a
    deprecated Information Element may be made obsolete.  Obsolete
    Information Elements MUST NOT be supported by either Exporting or
    Collecting Processes.  The receipt of obsolete Information Elements
** ** Nope, not happening. I can't force my customers to upgrade just because some 3rd party says so.
"MUST NOT be supported by new implementations of either Exporting or Collecting Processes"?

The point here is that if we're going to support deprecation (which was clearly the intent of the WG, given its inclusion in 5102), there may be a mismatch between the deployed and specified environment WRT supported IEs.

I have to side with Paul on this one.  Saying that a collecting process MUST NOT support obsoleted IEs seems to me to violate the robustness principle.  An argument can be made that new exporters SHOULD / MUST NOT send deprecated IEs, but I think more than that is too much.

To give a specific example of the shelf life of the obsolete. Wikipedia tells me that NetFlow v1 is obsolete (and it has been for years), but I still see NetFlow v1 exports on some customer networks.

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

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