Subject: [core] Comments on option numbers

From: Cullen Jennings <[email-masked]>
Date: Fri, 3 Aug 2012 11:57:47 -0700

This with my individual contributor hat on 

I think we should split up the space into roughly three categories. I think they should be  

1) Standards Track 
- this is for very low numbers that very desirable and to make sure that other stuff does not use up all the super prime realestate that future revisions of the key RFC may need. This should be very small. 

2) IETF Review 
This is pretty easy and lots of stuff would fall in here. Note that many IETF standards Track RFC might choose to use a code point out of this space if they do not need the optimization of space 1. 

3) Expert Review with Specification Required 
This is "almost" first come first serve. But I think we want to try and avoid completely duplicated of code points that mean that do the same thing. We also need to check that things like the interactions with proxies was correctly considered. To do this, the lightest weight thing we can do is have expert review. And the expert needs to have something to review. This can be just a company web page, and internet draft, or pretty much anything. 

4) Unallocated
Future RFCs can define how these will be used but this just reserves some space that we can decide later how to allocate it. If we find out we ran out too quickly of one of the above spaces, we pull more out of this block. 

I don't know how large each block should be but as a very rough straw man, how about 

1) is 1 to 50 with well spaced items so that many requests can get past 64 without long jump

2) is 100 to to 500

3) is 1000 to 5000

4) is the rest of the space so 51 to 99, 501 to 999, and 5001 to 2^16-1 

I really have not put much thought into if theses numbers look good or not but you get the basic idea of how we might slice it up. The storage increment means it might be better to make the unallocated space something like all the even numbers. 

I can imagine a future with several hundred headers registered, and the average messages using say 4 or them other than the very basic stuff. It seems likely that all 4 of the non basic ones may end of need a long jump. In a future like that, I'd love to see how much saving we got from this differential coding scheme.

---

From: Bert Greevenbosch <[email-masked]>
Date: Wed, 8 Aug 2012 02:24:29 +0000

Hi Cullen,

Interesting option numbering scheme. I think that reserving option numbers for future use (i.e. category 4 below) certainly makes sense.

I have a question about the proposed gaps 51-99 and 501-999:

If at some point in time we want to expand category 1, we will likely use gap 51-99, whereas if we want to expand category 2 we will likely prefer gap 501-999 over 51-99 (as using 51-99 for category 2 would reduce the expansion space for category 1). But then why not allocate 51-99 to category 1 now?

Do you think there may be a future Category 5 that would benefit from low option numbers?

Since 51-99 can be considered as "valuable option numbers", maybe it is better to reserve higher option numbers for future use?

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: 04 August 2012 02:58
To: core WG
Subject: [core] Comments on option numbers

1) Standards Track 

2) IETF Review 

4) Unallocated

2) is 100 to to 500

3) is 1000 to 5000

 

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core