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

Brian Trammell <[email protected]> Fri, 3 Jan 2014 18:54:39 +0100
Newsgroups	gmane.ietf.ipfix
Message-ID	<[email protected]>
On 03 Jan 2014, at 13:06, Stewart Bryant <[email protected]> wrote:

> I brought up the concept of ownership of PENs by individuals 
> in a couple of IESG discussions on IPFIX, and the opinion that
> I get (as I recall from the APPs ADs) is that PENs were never 
> intended to be assigned to individuals together with surprise
> that any had been allocated to individuals. Hence my initial 
> reluctance. I know that there are some other owned by individuals, 
> and I  have requested one for the purpose of trying out this 
> application of the protocol. However I think the concern is 
> that it would not scale if every individual experimenter 
> requested their own, much less one per experiment.

It’s probably well outside the scope of IANA’s competence to rule on the differences between individuals, sole proprietorships, single member LLCs/GmbHs, C/S corporations, AGs/ABs/SAs, unorganized collectives of software developers, and so on. Without that competence, it’s pretty difficult to give them guidelines as to what to allow and what to deny in terms of individual registrations. So FCFS to anyone who can control an email address it is.

If you’re doing experiments with IPFIX (or, indeed, SNMP) as an individual or academic at an organization without a PEN or where it’s difficult to get “official” IPFIX IE number space within that PEN, getting your own is the only way to go.

Of course, I’m probably the worst abuser of this property, having requested the first PEN (29305) for an RFC (5103) for the single-record biflow hack. 
>> I could see this being a problem if one were trying to run many experiments within the same very large organization with undefined or draconian processes for reserving an enterprise-specific IE. But PEN space is 2^32-1 large and we haven;t even exhausted the first block of 2^16, so “get a new PEN and label it useful for a given experiment” is probably an acceptable way out of this quandary.
> I think the question is one of whether or not that is best practice.
> Sure the space is large, but so was the IPv4 Address space when it
> was created :)

I share your concern in theory. But practically I cannot imagine a world in which the number of IPFIX experiments (plus normal SMI “enterprises”) is anywhere near on the order of addressable locations in the IPv4 number space. We’re talking tens of PENs, hundreds if we are successful in expanding the IPFIX information model to be the One True Way the Internet of Things talks about itself.

I realize I’ve just made a “nobody needs more than 64k autonomous systems” statement. And I completely agree that this is somewhat outside the original intention of the PEN registry at its creation time, but compare this to the difference between the domain name space as it was conceived and as it’s (ab)used today, and I think what I’m proposing is a relatively minor violation, and is indeed not really all that different from the PENs-for-application-areas proposal (which I quite like as well).
>>> 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.
> Text of the following format needs to be associated with the
> space:
> Code points in the experimental range MUST be used according to the
> guidelines of RFC 3692 [RFC3692].
Yep, that’s good and unambiguous, but it still does not address the issue of what happens after the termination of the experiment.
>>> 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. 
s/private/not necessarily public/ — there is nothing keeping an operator of a PEN registry from publishing that registry. Indeed, the intention of RFC 5610 was to allow such operators to publish such registries _inline_ to allow polymorphic collectors / file readers to load such registries at runtime.
>>> 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.

As I noted above, there’s already precedent for this: PEN 29305 for RFC 5103.

We could certainly define a few “extended application” areas, assign them PENs, and allocate them via IANA; we’d just need to add a PEN column to the registry, and update 7102. Deciding on an initial list might take a while though.

Cheers,

Brian

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
signature.asc (application/pgp-signature, 496 B)