Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs

Brian,

Once more inline...

> Hi, Paul,
>
> thanks for the swift reply! inline per tradition:
>
> On Aug 21, 2012, at 5:18 PM, Paul Aitken wrote:
>
>> Brian,
>>
>>> Greetings, all,
>>>
>>> To close the discussion from Vancouver, we have two proposals under consideration for handling the transition of enterprise-specific IEs used for testing, research, or other pre-standardization purposes to IANA IEs:
>>>
>>> (1) The addition of an Enterprise-specific Reference column to the IANA registry, which would include PEN(s) and IE number(s) which have a description compatible with the IANA-registered IE; this is covered in the present revision of the IE-DOCTORS draft. The advantage of this is it provides a central registry; however, it presumes a model in which CPs are either frequently updated or periodically retrieve new registration information from IANA, and requires all users of ESIE codepoints replaced with an IANA codepoint to register that information with IANA.
>> NB "compatible description" isn't sufficient. The type, range, semantics, units, all have to be compatible too.
> indeed; I should have used a different word than "description" -- "IEs which are interoperable by definition"...

To be picky: eg, are TOS and DSCP interoperable?


>>> (2) The definition of an IE equivalence options template, which would define the equivalence of a set of IANA and enterprise-specific IEs. This would be sent by EPs which had updated an IE from an older enterprise-specific codepoint to a new IANA codepoint; this would be covered in a new draft which Paul Aitken has (I think) already started work on. This has the advantage that equivalence is not dependent on the IANA registry.
>> The draft was written over a year ago, and only needs some polishing before publication.
> Excellent.
>
>>> Benoit noted that this required the EP to (i) send additional information on session startup and (ii) to be updated both to use the new IANA codepoint as well as to send this additional information: a CP would not know an old ESIE was equivalent to a newer IANA IE if the EP it was receiving data from had not been updated.
>> So when updating an ESIE to IANA, I either notify IANA for method (1), or I add the mapping to my code for method (2). There's little difference in effort between them.
>>
>> Method (1) has some disadvantages: IANA must store enterprise-specific information, which seems contrary; and CP's must frequently refer to IANA for updates, which may not be possible or desirable in deployed systems.
>>
>> Method (2) ensures that a CP is always up to date for any EP which exports to it. It also has an additional advantage that a mapping can be sent from old-ESIE to new-ESIE, which isn't possible with method (1).
>>
>>
>>> As I see it, there are four possible ways forward:
>>>
>>> (a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a draft describing approach (2).
>> Providing two methods for the same thing is asking for trouble in future. eg, non-interoperable implementations, one using method (1), the other using method (2). Worse, how to handle inconsistencies between the information received by each method?
> A good point; however, the worst-case interoperability of a two-method solution is no worse than that of no solution.

Disagree. If there was no method, we'd work to create one as soon as the 
need was established. Whereas with two methods, we don't know who's 
doing what.


> Rules for conflict resolution would be a necessary part of any two-method solution.

Yep.


>>> (b) Support only the IANA method: leave approach (1) in IE-DOCTORS.
>>>
>>> (c) Support only the Options method: remove approach (1) from IE-DOCTORS, develop a draft describing approach (2).
>>>
>>> (d) Defer the question and leave ESIE promotion an open issue: remove approach (1) from IE-DOCTORS with no present decision on a draft about approach (2).
>>>
>>> I suppose I'm in favor of option (a), since each approach has its own use cases, as long as we're clear in both IE-DOCTORS and the equivalence options draft about the applicability of each approach.
>> Let me see if I can quickly polish up the draft so people can see what method (2) entails.
> Please do!

Ack!

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