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

 
 
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 protected]
>>>  https://www.ietf.org/mailman/listinfo/ipfix
>>>  
>>  _______________________________________________
>>  IPFIX mailing list
>>  [email protected] 
>>  https://www.ietf.org/mailman/listinfo/ipfix
>>  
>  
>  
>

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