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

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

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