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

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:
>>> 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
>
> On Aug 2, 2012, at 10:16 AM, Andrew Feren wrote:
>
>> 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] <mailto:[email protected]>>
>> Date: Thursday, August 2, 2012 10:51 AM
>> To: Andrew Feren <[email protected] <mailto:[email protected]>>
>> Cc: Brian Trammell <[email protected] 
>> <mailto:[email protected]>>, <[email protected] 
>> <mailto:[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] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/ipfix
>

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