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

Stewart,
>
> Whilst I accept that IPFIX is pretty much complete in terms of
> addressing it's original goals as a network management
> protocol, I have some concerns about it's completeness
> as an  observation reporting protocol. I think these need
> to be addressed, before declaring completion of the work
> programme as a whole.
>
> (In my own time) I am looking at the definition of a protocol
> to observe and report the radio noise floor. The purpose
> is to map the rise in the radio noise floor due to RF pollution
> from domestic and industrial digital systems such as
> plasma televisions, and power line (digital) transmission
> systems. IPFIX is a good protocol for such mass observations,
> and has been used successfully in the radio propagation
> monitoring system pskreporter.
>
> In doing this I ran into two problems, firstly there are no
> experimental IE types, and thus I cannot prototype the
> application without either "camping" on a set of IEs, or
> waiting until I am allocated a PEN. 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 don't believe that allocating experimental IEs is a good idea.
First you need one per type. Unless you use RFC 5610, but if you do some 
experiments, then you most probably don't have RFC 5610. Then, as you 
said, you need multiple ones. How many? would 5 be enough, 10, 50, 100?

If you don't want to "waste" PEN for individual, which I understand, 
then why don't you request an experimental PEN.
Not an IPFIX experimental PEN, just an experimental PEN. This could be 
used for IPFIX, MIB, etc...
This would actually be better than individual PENs, somehow forcing 
people to go with a proper registration.

>
> 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.
It's true that IPFIX became a generic push mechanism.
We tried this in the past with the groups in 
http://tools.ietf.org/search/rfc5102#section-5
This was removed in RFC 7102.

Regards, Benoit
>
> - Stewart
>
>
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix
> .
>

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