Re: [IPFIX] Application of IPFIX to new application spaces.

On 4/01/2014 05:57, Paul Aitken wrote:
> Stewart, Brian,
>
>>> For reasons that will
>>> be clear from other work I have done in the IETF, I dislike
>>> the idea of "camping" on code-points. This makes it clear
>>> to me that we need a small, but not trivial set of
>>> experimental IEs that are intended for prototyping but
>>> explicitly excluded from use in production systems.
>>> This needs to be a reasonable number since a new application
>>> space might need a fair number of IEs to be practical.
>>> Thus I think that we need to either allocate some of the
>>> base protocol IEs to experimental, or to have IANA
>>> allocate a PEN specifically to experimental use which
>>> would allow experimentation in new applications spaces
>>> without the need to formally allocate IEs in either the
>>> base IE space, or the PEN space of the organization
>>> (or person) conducting the experiment.
>> I agree in principle that allocating a single "IPFIX Experimentation" PEN would be one solution to this problem, but it would have to be fairly tightly scoped (only for experimental use among EPs and CPs implemented and deployed by a single entity within the scope of a single experiment; MUST be logged as an error by CPs in production use). And I'd be very concerned that we were basically inviting people to camp on a whole new code space --- requiring experiments to use their own PEN space at least keeps experimental IEs that "leak" into production from colliding with each other, provided that the PEN owner manages their own space competently.
>
> +1
>
> I was about to say the same. While the "Experimentation PEN" idea 
> sounds good, there are practical dangers:
>
> With my netflow-police hat on, I allocate cisco's NFv9 and IPFIX 
> enterprise-specific IDs. I've had to reserve blocks of NFv9 IDs which 
> have been used by third parties (external to cisco) in released code 
> without telling us (a collector partner was good enough to inform us 
> about the potential clash). And in the past we've allocated our own 
> experimental IPFIX IDs which were meant to be replaced with IANA IDs 
> before release, but got overlooked.
>
> To avoid any issues, I'd rather see experiments done in private PEN space.
+1

Regards, B.
>
> P.
>
>
>>> The second problem that I see is the lack of a public registry
>>> for non-network managements applications. Specifically
>>> I am going to need "callsign", "maidenhead locator",
>>> "frequency", "noise power", maybe "field strength", "receiver type"
>>> etc. Now some of those may be of general use (frequency)
>>> but most of them would be cruft in the base protocol IE set
>>> which is set up for networking applications. On the other hand,
>>> I know of at least one PEN space that will have a number of the
>>> terms I need already defined, although these are by
>>> definition private. With the current IE registration structure
>>> the absence of a public registry inevitably means the
>>> redefinition of other than mainstream/network management
>>> terms across a number of private registries. I thus think
>>> it would be useful to introduce a PEN + registry for
>>> "other applications" or introduce the concept of a series
>>> of application specific registries with appropriate  PENs to
>>> identify the application space rather than  the private
>>> enterprise space.
>> This seems like a very good idea. I'll have to think about it some more.
>>
>> Thanks, cheers,
>>
>> Brian
>>
>>> __________________________________________
>>> 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

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