Subject: Re: [IPFIX] IANA IPFIX request

From: Nevil Brownlee <[email-masked]>
Date: Fri, 13 Aug 2010 16:46:38 +1200

Hi Paul:

There are two things to consider here:

1) What number do we want for the new observationPointType IE?
    The next available number is 277, would that be OK?

2) Where we've specified an IE's values so far, we've done it
    by listing them in the IE Description field.  If people want
    to add new possible values, they should be able to do it by
    requesting IANA to change observationPointType's Description.
    That would be simpler than adding a new sub-registry.  Does
    it sound OK to you?
    If you really think a sub-registry is needed, I'll ask IANA
    about it - however, in that case we should discuss what the
    criteria are for doing so (so we're ready for the next time
    this issue crops up!).

Cheers, Nevil

Paul Aitken wrote:
> Nevil,
> 
> FYI I've requested a new IPFIX field from IANA:
> 
>> New field: observation point type ("observationPointType")
>>
>> Initial values:
>>
>> 1. Physical port
>> 2. Port channel
>> 3. Vlan.
> 
> These initial values are requested by another BU within cisco. Clearly 
> this list can be much more extensive. We don't propose to exhaustively 
> list all possibilities, but rather, allow people to extend the list as 
> and when they require - so a new extensible registry would be appropriate.
> 
> Thanks,
> P.

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Paul Aitken <[email-masked]>
Date: Fri, 13 Aug 2010 09:04:00 +0100

Nevil,

>    The next available number is 277, would that be OK?

Fine by me.

>    requesting IANA to change observationPointType's Description.

With the proviso that none of the existing values are changed. ie, the 
description can be added to but not otherwise modified.

>    That would be simpler than adding a new sub-registry.  Does

Fair enough.

>    criteria are for doing so (so we're ready for the next time

Potentially if the list of values for any IE is long enough then a 
sub-registry is the right way to go, because it separates the invariant 
semantics from the extensible value list.

Thanks,
P.

-- 
Paul Aitken
Cisco Systems, Edinburgh, Scotland.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 13 Aug 2010 12:16:30 +0200

Hi, Paul, Nevil, all,

Hate to throw a spanner into the works, but "appendable descriptions" seems like kind of a bad idea. They're a great deal easier to manage, to be sure, but could cause interoperability problems if we're not very careful about how appending is done.

I'd be in favor of a subregistry here; this from the IE name seems like a rather useful thing to have, depending on the description/intent of the IE (I'd have to see the description to be sure), I'd probably have a few to add to it in short order.

The real question is can we create a subregistry without an I-D? I would presume so, as most of the subregistries we have are bound to IEs, and all of the ones that don't require changes to the core protocol (the 5610 data types and semantics) are ER. As long as the subregistry doesn't have stricter requirements than the action that created it (i.e., a registry created via expert review that requires a standards action to modify), it shouldn't be a problem.

Hm... would it be possible to define now without a subregistry, but add a subregistry in the future if we find that we expand the meaning of the IE? 

These seem like IANA questions...

Cheers,

Brian

On Aug 13, 2010, at 10:04 AM, Paul Aitken wrote:

> With the proviso that none of the existing values are changed. ie, the description can be added to but not otherwise modified.
> 
> 
> Potentially if the list of values for any IE is long enough then a sub-registry is the right way to go, because it separates the invariant semantics from the extensible value list.
> 
> Thanks,
> P.
> 
> -- 
> Paul Aitken
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Nevil Brownlee <[email-masked]>
Date: Fri, 13 Aug 2010 23:45:37 -0700

Hi Brian:

Thanks for that - I'll ask IANA what's possible (and reasonable) for them.
The issue I'd seeen was "will we want to do this for other new IEs in
future; if so, what reasons would an IE have for needing it?"
After all, it doesn't seem reasonable to have a large number of potentially
open-ended sub-registries!

Cheers, Nevil

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 16 Aug 2010 14:35:48 +0200

I need to jump in :-) 

Would not creating sub-registries 'from now on' be actually an implicit
change in the protocol? If so, would not it be preferable to do it via
an RFC updating 5610? 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Nevil Brownlee
> Sent: Saturday, August 14, 2010 9:46 AM
> To: Brian Trammell
> Cc: IPFIX Working Group
> Subject: Re: [IPFIX] IANA IPFIX request
> 
> 
> Hi Brian:
> 
> The issue I'd seeen was "will we want to do this for other 
> new IEs in future; if so, what reasons would an IE have for 
> needing it?"
> After all, it doesn't seem reasonable to have a large number 
> of potentially open-ended sub-registries!
> 
> Cheers, Nevil
> 
> Brian Trammell wrote:
> > Hi, Paul, Nevil, all,
> > 
> > Hate to throw a spanner into the works, but "appendable 
> descriptions" seems like kind of a bad idea. They're a great 
> deal easier to manage, to be sure, but could cause 
> interoperability problems if we're not very careful about how 
> appending is done.
> > 
> > I'd be in favor of a subregistry here; this from the IE 
> name seems like a rather useful thing to have, depending on 
> the description/intent of the IE (I'd have to see the 
> description to be sure), I'd probably have a few to add to it 
> in short order.
> > 
> > The real question is can we create a subregistry without an 
> I-D? I would presume so, as most of the subregistries we have 
> are bound to IEs, and all of the ones that don't require 
> changes to the core protocol (the 5610 data types and 
> semantics) are ER. As long as the subregistry doesn't have 
> stricter requirements than the action that created it (i.e., 
> a registry created via expert review that requires a 
> standards action to modify), it shouldn't be a problem.
> > 
> > Hm... would it be possible to define now without a 
> subregistry, but add a subregistry in the future if we find 
> that we expand the meaning of the IE? 
> > 
> >> With the proviso that none of the existing values are 
> changed. ie, the description can be added to but not 
> otherwise modified.
> >>
> >>
> >> Potentially if the list of values for any IE is long 
> enough then a sub-registry is the right way to go, because it 
> separates the invariant semantics from the extensible value list.
> >>
> >> Thanks,
> >> P.
> >>
> >> --
> >> Paul Aitken

---

From: Brian Trammell <[email-masked]>
Date: Mon, 16 Aug 2010 16:34:13 +0200

Hi, Dan, all

There's no implicit change to the protocol here, as for now whether we create a subregistry or not is the prerogative of the people involved in the adding the entry into the IE registry; that is, IANA and the IPFIX experts (who are IIRC Nevil and Juergen). By my reading, this discussion happening on the list is more or less exactly what should happen according to 5102.

However, as we start to see more one-off IEs that _may_ need a little more thought to their creation than a name and a description, as well as the expansion of IPFIX into new application areas, it's probably a good idea to do some policy work, to systematize best practices for the orderly application of IPFIX, much like what's been done for MIBs. 

We're planning on submitting something shortly (well in advance of Beijing) that would form the basis of such a document; this is the future work alluded to in our discussion of "what do we do with iespec?" in Maastricht. 

Best regards,

Brian

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 16 Aug 2010 16:51:53 +0200

I am looking forward to your document. 

I would note by now that there is a difference between saying 'this is
how a specific entry or a small and finite group of entries in the IE
registry are structured' and 'this is how entries in the IE registry
SHOULD (or even MUST) be structured from now on'. 

Dan

> From: Brian Trammell [mailto:[email-masked]] 
> Sent: Monday, August 16, 2010 5:34 PM
> To: Romascanu, Dan (Dan)
> Cc: Nevil Brownlee; IPFIX Working Group
> There's no implicit change to the protocol here, as for now 
> whether we create a subregistry or not is the prerogative of 
> the people involved in the adding the entry into the IE 
> registry; that is, IANA and the IPFIX experts (who are IIRC 
> Nevil and Juergen). By my reading, this discussion happening 
> on the list is more or less exactly what should happen 
> according to 5102.
> 
> However, as we start to see more one-off IEs that _may_ need 
> a little more thought to their creation than a name and a 
> description, as well as the expansion of IPFIX into new 
> application areas, it's probably a good idea to do some 
> policy work, to systematize best practices for the orderly 
> application of IPFIX, much like what's been done for MIBs. 
> 
> We're planning on submitting something shortly (well in 
> advance of Beijing) that would form the basis of such a 
> document; this is the future work alluded to in our 
> discussion of "what do we do with iespec?" in Maastricht. 
> 
> Best regards,
> 
> Brian
> 
> > Would not creating sub-registries 'from now on' be actually an 
> > implicit change in the protocol? If so, would not it be 
> preferable to 
> > do it via an RFC updating 5610?
> > 
> > Dan
> > 
> > 
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Nevil Brownlee
> new IEs in 
> >> After all, it doesn't seem reasonable to have a large number of 
> >> potentially open-ended sub-registries!
> >> 
> >> Cheers, Nevil
> >> 
> >> Brian Trammell wrote:
> >>> Hi, Paul, Nevil, all,
> >>> 
> >> descriptions" seems like kind of a bad idea. They're a great deal 
> >> easier to manage, to be sure, but could cause interoperability 
> >> problems if we're not very careful about how appending is done.
> >>> 
> >> name seems like a rather useful thing to have, depending on the 
> >> description/intent of the IE (I'd have to see the 
> description to be 
> >> sure), I'd probably have a few to add to it in short order.
> >>> 
> >> I-D? I would presume so, as most of the subregistries we have are 
> >> bound to IEs, and all of the ones that don't require 
> changes to the 
> stricter 
> >> requirements than the action that created it (i.e., a registry 
> >> created via expert review that requires a standards action to 
> >> modify), it shouldn't be a problem.
> >>> 
> >> subregistry, but add a subregistry in the future if we 
> find that we 
> >> expand the meaning of the IE?
> >>> 
> >>>>> 2) Where we've specified an IE's values so far, we've 
> done it  by 
> >>>>> listing them in the IE Description field.  If people 
> want  to add 
> >>>>> new possible values, they should be able to do it by  
> requesting 
> >>>>> IANA to change observationPointType's Description.
> >> changed. ie, the description can be added to but not otherwise 
> >> modified.
> >>>> 
> >>>> 
> >>>>>  That would be simpler than adding a new sub-registry.  
> Does  it 
> >>>>> sound OK to you?
> >>>> Fair enough.
> >>>> 
> >>>> 
> >>>>> criteria are for doing so (so we're ready for the next 
> time  this 
> >>>>> issue crops up!).