Subject: FCFS policy unclear for "vanity" code points

From: "John G. Scudder" <[email-masked]>
Date: Tue, 30 Jun 2015 11:49:13 -0400

Hi Everybody,

We recently had an unusual situation with one of the BGP FCFS registries where someone requested a specific value rather than the usual behavior of asking for a code point and taking the next in-sequence number. Sue and I thought this seemed generally a bad idea, but it's not explicitly forbidden in the allocation policies, so in this case we've opted to ask the requester nicely if they can't just do the usual thing and take an in-sequence value, and we'll continue the discussion from there if they say no.

However, this raises the question of whether we should address this as a matter of policy. I strongly suspect it was not the intention of The Framers to encourage people to take whatever value they feel like, but given the extreme permissiveness of the FCFS policy it just never occurred to anyone it would be a thing. Here are a couple reasons why it might be seen as bad to allow this:

- The point of an FCFS registry is (in part) to discourage code point squatting by making the barrier to getting a code point trivially low. You ask for it, you get it, no questions asked. (Except in this case, it seems...) If there is no negative consequence for NOT doing this, it indirectly encourages people to squat on code points. And since most of them aren't going to squat on the output of /dev/random, but rather some human-obvious value (someone called this a "vanity code point"), the probability of collisions is going to be higher than random squatting would produce. But I shouldn't need to convince you code-point squatting is bad.

- For that matter, it potentially encourages dirty tricks -- you notice party A, whom you despise, has squatted on the unassigned code point 0x1234, so you say to yourself "ah ha!" and request IANA assign you 0x1234 for your competing proposal. I would like to think nobody would be so petty as to do this, but it is a possible consequence.

It may be that this from RFC 5226 is sufficient cover: "For numbers, the exact value is generally assigned by IANA". 

However, given the fact the issue has arisen, it appears the quoted text is insufficient or at least isn't obviously sufficient, more or less the same thing. In which case, perhaps this for RFC 5226bis?

OLD:
   For numbers, the exact
   value is generally assigned by IANA

NEW:
   For numbers, the exact
   value is generally assigned by IANA using the next in-sequence unallocated
   value, other values might be assigned at the discretion of <who exactly?> if an
   extenuating circumstance exists

By all means, please improve upon this, ideally by sending text.

Thanks,

--John

P.S.: Yes, that is really how FCFS works. Apparently this is not universally known. See https://tools.ietf.org/html/rfc5226#section-4.1

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Jun 2015 18:25:41 +0200

For established protocols and their internal numbers, much of what you
are writing makes sense to me.

However, the only thing common in the IETF is that everything is different.

Quite recently, we needed a port number for a new protocol.
We squatted on something, ran a lot of interops, and finally requested
that exact number we had been using all the time.  We got it, and a lot
of people did not have to flag-day their code.

Now, port numbers are harder to obtain than FCFS (in particular if you
need two of them).  Still, what happened there makes sense to me, too.

I happen to be designated expert for another protocol with less strict
allocation rules, and that is another space where I would prefer to be
able to heed requests for specific numbers.

In summary, I would be opposed to a hard and fast rule that suddenly is
applied for everything.  But I wouldn't oppose a default rule that can
be picked up explicitly by old registries after some deliberation, as
well as is picked up by default for new ones unless specified otherwise.

Grüße, Carsten

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 30 Jun 2015 09:27:04 -0700

John,

Just remove the word "generally": "For numbers, the exact value is assigned
by IANA."

That way, it's IANA's decision on which number to allocate, whether it's
the next in sequence or a specific requested number. If there is a request,
IANA is free to consult whoever they like, such as a relevant expert, WG
chair, etc., before making the allocation.

Cheers,
Andy

On Tue, Jun 30, 2015 at 8:49 AM, John G. Scudder <[email-masked]> wrote:

> Hi Everybody,
>
> We recently had an unusual situation with one of the BGP FCFS registries
> where someone requested a specific value rather than the usual behavior of
> asking for a code point and taking the next in-sequence number. Sue and I
> thought this seemed generally a bad idea, but it's not explicitly forbidden
> in the allocation policies, so in this case we've opted to ask the
> requester nicely if they can't just do the usual thing and take an
> in-sequence value, and we'll continue the discussion from there if they say
> no.
>
> However, this raises the question of whether we should address this as a
> matter of policy. I strongly suspect it was not the intention of The
> Framers to encourage people to take whatever value they feel like, but
> given the extreme permissiveness of the FCFS policy it just never occurred
> to anyone it would be a thing. Here are a couple reasons why it might be
> seen as bad to allow this:
>
> - The point of an FCFS registry is (in part) to discourage code point
> squatting by making the barrier to getting a code point trivially low. You
> ask for it, you get it, no questions asked. (Except in this case, it
> seems...) If there is no negative consequence for NOT doing this, it
> indirectly encourages people to squat on code points. And since most of
> them aren't going to squat on the output of /dev/random, but rather some
> human-obvious value (someone called this a "vanity code point"), the
> probability of collisions is going to be higher than random squatting would
> produce. But I shouldn't need to convince you code-point squatting is bad.
>
> - For that matter, it potentially encourages dirty tricks -- you notice
> party A, whom you despise, has squatted on the unassigned code point
> 0x1234, so you say to yourself "ah ha!" and request IANA assign you 0x1234
> for your competing proposal. I would like to think nobody would be so petty
> as to do this, but it is a possible consequence.
>
> It may be that this from RFC 5226 is sufficient cover: "For numbers, the
> exact value is generally assigned by IANA".
>
> However, given the fact the issue has arisen, it appears the quoted text
> is insufficient or at least isn't obviously sufficient, more or less the
> same thing. In which case, perhaps this for RFC 5226bis?
>
> OLD:
>    For numbers, the exact
> P.S.: Yes, that is really how FCFS works. Apparently this is not
> universally known. See https://tools.ietf.org/html/rfc5226#section-4.1
>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 30 Jun 2015 12:27:28 -0400

This is a good point. In fact, if a protocol includes an unconstrained
parameter with unbounded length and people can pick a value, they can
encode arbitrary additional proprietary parameters into that field,
which might be undesireable. Lest you think this is purely
hypothetical, look at the X.509 Certificate Authorities that encode
all kinds of junk into the certificate "serial number" - but of course
that's not something assigned by IANA.

As to who should be able to authorize a non-sequential number, while a
particular Security Considerations could always specify something else
such as an Expert, I think that in the default it should be the IESG.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Jun 2015 13:03:10 -0400

> However, this raises the question of whether we should address this as a matter of policy. I strongly suspect it was not the intention of The Framers to encourage people to take whatever value they…

I think, as with everything, "it depends".

I had a draft a while back which asked the IANA to please assign a
certain number, if they didn't mind.

The registry looked something like:

1: something
2: something else
3 - 11: unallocated
12: draft-foo
13: unallocated
14: something else
15: also something else
16: yet another something else
17-255: unallocated

Codepoint 12 was preassigned for draft-foo, a very closely related
draft, which died on the vine. My draft was a respin of that, and I
(politely) asked for 13, if it pleased the IANA. Normally they would
have allocated 17, but ended up giving me 13. This was, IMO, useful
because it provided a debugging hint to people who knew about
draft-foo.
Was it earth shattering? No. Was it very useful? Nah. But, it makes
things a little easier for folk to remember, and it didn't fragment
the codespace at all -- if anything it removes some fragmentation.

So, I think, if the codespace already has some fragments, and asking
for a specific allocation helps group related things together, and,
most importantly, the IANA doesn't mind, it's acceptable...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Eliot Lear <[email-masked]>
Date: Tue, 30 Jun 2015 19:04:59 +0200

Hi John,

> We recently had an unusual situation with one of the BGP FCFS registries where someone requested a specific value rather than the usual behavior of asking for a code point and taking the next in-se…

The ports registry generally allows people to choose their ports,
although we reserve the right to change the number, particularly if we
know it's in use somewhere for some reason.  The reason for this is that
people will often pick a port to squat on, but they usually do so
judiciously, and then when the time comes to ask for the port, they do. 
Before we make them change their behavior, I'd like to understand
whether this really requires a broad solution at this point in time. 
That is- is there a serious squatting problem now, or is there a real
indication that this will become a problem?  Remember- most of these
codepoints are not particular user visible (especially in BGP land!!)
and even with TCP/UDP ports, I don't think port number selection isn't
what sells products.

Also...

> - For that matter, it potentially encourages dirty tricks -- you notice party A, whom you despise, has squatted on the unassigned code point 0x1234, so you say to yourself "ah ha!" and request IANA…

I could think of no better motivation to not squat ;-)  But seriously
folks, is this a problem that requires a real change of policy?

Eliot

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 30 Jun 2015 10:34:07 -0700

Just sell vanity numbers @ auction price. States do it with registration
plates and make a killing ;-)

::faceb00c:: should have gone for a couple bill @ least ;-)

-- tony

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2015 17:22:10 -0400

Tony: 

Sounds like a way to support IETF meetings …  for the good of the community. 

(smile – I couldn’t resist this one). 

Sue 

From: WGChairs [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Tuesday, June 30, 2015 1:34 PM
To: Eliot Lear
Cc: John G. Scudder; [email-masked]; IETF WG Chairs
Subject: Re: FCFS policy unclear for "vanity" code points

Just sell vanity numbers @ auction price. States do it with registration plates and make a killing ;-) 

-- tony 

Hi John,

Also...

Eliot

---

From: John Scudder <[email-masked]>
Date: Tue, 30 Jun 2015 17:39:31 -0400

To summarize my reading of the convo so far, it's a mix of some agreement and some mild disagreement of the form "yeah, that might be right for your registry John, but every case is different" (or maybe that's nitpicking and not disagreement, but for me to distinguish between the two would be more nitpicking). I don't think anyone has yet come out and said I'm completely in the weeds.

That said, nobody other than Andy has sent text (thanks, Andy!). Here was the text I proposed:

> On Jun 30, 2015, at 11:49 AM, John G. Scudder <[email-masked]> wrote:
> 
> OLD:
>   For numbers, the exact

Andy proposed the admirably minimal s/generally// solution instead. I don't think it fully solves the problem we had though, which was that the code point requester had no guidance to indicate to them it was not ok to cherry-pick a code point, and IANA felt they needed to ask the chairs for guidance. Andy's proposal does provide (probably) sufficient document cover to allow IANA to assign whatever code point they want, but because we are all nice people (aren't we?) the practical difference in this case would be nil, I bet. What is different in the text I suggested is it makes explicit the expectation you're generally going to get the next in-sequence value, absent a good reason to do otherwise.

I think my intent is fairly compatible with most of your comments (you can decide for yourself if my text is), in that it leaves the door wide open for requesting and receiving a selected value. It just makes the default expectation explicit, and implies you may be asked to justify your special value.

A few specifics:

Carsten and Eliot brought up port numbers. But, per Carsten, "port numbers are harder to obtain than FCFS" so I think although this is an interesting tangent, it's still a tangent. Unless there is a proposal to expand the "you get the next in-sequence value" default to other policies, that is. If my skim of 5226bis is accurate, all the other allocation policies are either no-ops (private, experimental) or have a gatekeeper in addition to IANA (designated expert or IESG) so I would be comfortable with not expanding beyond FCFS -- but feel free to make the case for it.

Eliot asked "But seriously folks, is this a problem that requires a real change of policy?"

No, I don't think there's a fire. But I also don't think I'm proposing a change of policy. I think I'm proposing a clarification by taking something we "all knew" and making it explicit, that is, you get the next in-sequence value unless you make a case for getting something else (as Warren described, for example). Let me turn the question around: 5226bis has not yet been finalized. The effort to make the change is low (see, I can say that because I'm not the author). What is gained by leaving the policy ambiguous? What is lost by making it clear?

Thanks,

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2015 17:55:09 -0400

John: 

I think your statement leaves the discretion up to IANA  who has a good
track record of being responsible.  I suggest we keep your text. 

Sue 

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Tuesday, June 30, 2015 5:40 PM
To: IETF WG Chairs
Cc: [email-masked]
Subject: Re: FCFS policy unclear for "vanity" code points

To summarize my reading of the convo so far, it's a mix of some agreement
and some mild disagreement of the form "yeah, that might be right for your
registry John, but every case is different" (or maybe that's nitpicking and
not disagreement, but for me to distinguish between the two would be more
nitpicking). I don't think anyone has yet come out and said I'm completely
in the weeds.

That said, nobody other than Andy has sent text (thanks, Andy!). Here was

>   extenuating circumstance exists

Andy proposed the admirably minimal s/generally// solution instead. I don't
think it fully solves the problem we had though, which was that the code
point requester had no guidance to indicate to them it was not ok to
cherry-pick a code point, and IANA felt they needed to ask the chairs for
guidance. Andy's proposal does provide (probably) sufficient document cover
to allow IANA to assign whatever code point they want, but because we are
all nice people (aren't we?) the practical difference in this case would be
nil, I bet. What is different in the text I suggested is it makes explicit
the expectation you're generally going to get the next in-sequence value,
absent a good reason to do otherwise.

I think my intent is fairly compatible with most of your comments (you can
decide for yourself if my text is), in that it leaves the door wide open for
requesting and receiving a selected value. It just makes the default
expectation explicit, and implies you may be asked to justify your special
value.

A few specifics:

Carsten and Eliot brought up port numbers. But, per Carsten, "port numbers
are harder to obtain than FCFS" so I think although this is an interesting
tangent, it's still a tangent. Unless there is a proposal to expand the "you
get the next in-sequence value" default to other policies, that is. If my
skim of 5226bis is accurate, all the other allocation policies are either
no-ops (private, experimental) or have a gatekeeper in addition to IANA
(designated expert or IESG) so I would be comfortable with not expanding
beyond FCFS -- but feel free to make the case for it.

Eliot asked "But seriously folks, is this a problem that requires a real
change of policy?"

No, I don't think there's a fire. But I also don't think I'm proposing a
change of policy. I think I'm proposing a clarification by taking something
we "all knew" and making it explicit, that is, you get the next in-sequence
value unless you make a case for getting something else (as Warren
described, for example). Let me turn the question around: 5226bis has not
yet been finalized. The effort to make the change is low (see, I can say
that because I'm not the author). What is gained by leaving the policy
ambiguous? What is lost by making it clear?

Thanks,

--John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Jun 2015 18:25:23 -0400

I find it odd to have different rules for numeric and textual values. 
ISTM that "IANA picks" is a different policy from FCFS.

Ideally a new standard policy would be added to 5226 for "IANA picks". 
The problem with that is that it wouldn't apply retroactively to 
existing FCFS registries.

     Thanks,
     Paul

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 30 Jun 2015 15:32:14 -0700

John,

Thanks for your admiration of my minimalism, but I'm also OK with your
proposed text, although again in the spirit of minimalism, I suggest the
change s/at the discretion of <who exactly?>//.

This retains my original intent of leaving discretion with IANA.

Cheers,
Andy

On Tue, Jun 30, 2015 at 2:39 PM, John Scudder <[email-masked]> wrote:

> Andy proposed the admirably minimal s/generally// solution instead. I
> don't think it fully solves the problem we had though, which was that the
> code point requester had no guidance to indicate to them it was not ok to
> decide for yourself if my text is), in that it leaves the door wide open
> for requesting and receiving a selected value. It just makes the default
> tangent, it's still a tangent. Unless there is a proposal to expand the
> "you get the next in-sequence value" default to other policies, that is. If
> my skim of 5226bis is accurate, all the other allocation policies are
> either no-ops (private, experimental) or have a gatekeeper in addition to
> IANA (designated expert or IESG) so I would be comfortable with not
> expanding beyond FCFS -- but feel free to make the case for it.
>

---

From: John Scudder <[email-masked]>
Date: Tue, 30 Jun 2015 23:14:21 +0000

WFM.

--John

On Jun 30, 2015, at 6:32 PM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

John,

Thanks for your admiration of my minimalism, but I'm also OK with your proposed text, although again in the spirit of minimalism, I suggest the change s/at the discretion of <who exactly?>//.

Cheers,
Andy

On Tue, Jun 30, 2015 at 2:39 PM, John Scudder <[email-masked]<mailto:[email-masked]>> wrote:
To summarize my reading of the convo so far, it's a mix of some agreement and some mild disagreement of the form "yeah, that might be right for your registry John, but every case is different" (or maybe that's nitpicking and not disagreement, but for me to distinguish between the two would be more nitpicking). I don't think anyone has yet come out and said I'm completely in the weeds.

That said, nobody other than Andy has sent text (thanks, Andy!). Here was the text I proposed:

> On Jun 30, 2015, at 11:49 AM, John G. Scudder <[email-masked]<mailto:[email-masked]>> wrote:
>
> OLD:
>   For numbers, the exact

A few specifics:

Thanks,

--John