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

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 protected]>
Date:  Thursday, August 2, 2012 10:51 AM
To:  Andrew Feren <[email protected]>
Cc:  Brian Trammell <[email protected]>, <[email protected]>
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.
 
 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