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.

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