Subject: Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Nov 2007 07:02:08 -0800 (PST)

>I also think this is an appropriate, even if significant,
>change of policy. I really don't see why we would give away
>a precious resource such as a protocol number for secret
>usage.

I also agree that the change is appropriate.  However, I am also aware of 
significant frustration being voiced with respect to the speed by which 
the expert review process moved -- and this change could slow it 
further.  It's worth keeping in mind that the IETF has no power to prevent
people from using unallocated protocol numbers.

For example, see:
http://kerneltrap.org/node/2873

Quoting from Ryan McBride:

"The IANA has a heavily bureaucratic process for getting official number 
assignments. There are essentially two options for getting a protocol 
number assigned: The first is to run your protocol through the IETF on a 
standards track. This avenue is closed to us - the IETF has become 
monopolized by large corporate interests, and they have no problem with 
using patented protocols. They're perfectly happy using VRRP, and they 
won't support another standard. The second path is their proprietary 
path; you pay for "experts" to review your protocol and if they agree 
that it requires the numbers you're asking for, you get it. If you look 
at the list of assigned protocol numbers, this method appears to be the 
favored one. Getting a number allocation has more to do with having 
money. Obviously, since we're not a large multinational corporation, we 
can't afford to take this path. Since they were unable to help us by 
providing a real alternative, our only option is to simply pick an unused 
number and go with that."

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 06 Nov 2007 12:19:28 -0500

Bernard:

The worst case latency comes from the expert review with 
non-disclosure agreements.

We really do believe that this will make the latency much more consistent.

Russ

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Nov 2007 09:28:36 -0800

At 7:02 AM -0800 11/6/07, Bernard Aboba wrote:
>\
>that it requires the numbers you're asking for, you get it.

Paying for expert review is certainly news to me.  I've cc'ed David Conrad, who is
GM of IANA, so he can comment. Looking at
 http://www.iana.org/cgi-bin/usr-port-number.pl and
http://www.iana.org/cgi-bin/sys-port-number.pl, though, I certainly don't
see a charge for expert review.

>If you look

The article goes on to say:

>JA: Are you concerned that at a future date the IANA might officially assign the port you've chosen to another protocol?
>Ryan McBride: Not extremely worried, no. Our hope is that they will accept it as an official assignment before that has to happen.

In other words, they are squatting.  They're certainly not the first, but it might
be useful if IANA put something in large letters about the fees or lack of fees
on the application page, to combat whatever other bad info is floating around
there. Not that I really expect blogs to fact check, but it would get anyone who
actually looked the right information.

				regards,
					Ted

---

From: Jari Arkko <[email-masked]>
Date: Tue, 06 Nov 2007 18:33:06 +0100

Bernard,

> I also agree that the change is appropriate.  

Good.

> However, I am also aware of 

I would like to separate three things: 1) this change which is for IPv4
and IPv6 protocol numbers, 2) expert review process speed, and 3)
the specific case that you pointed to in the above.

For 1), I do not think we can have a blanket IANA rule for everything.
What the numbers are for impacts what the policy should be. I believe
what we are suggesting for the proto numbers is the right thing,
given that we are dealing with this specific space. Since the new
policy is IESG Approval or Standards Approval, the IESG can grant
requests based on a judgment call. For what it is worth, if, e.g., some
open source developers approached me for an allocation I would
work to get it approved in a timely manner, assuming the request
was reasonably sane.

For 2), this is indeed a problem. The IESG and IANA have been
in discussions on how to track these cases, what deadlines
we should set for raising the issue to the IESG if the expert
does not respond, etc. I think there's definitely room for
improvement here.

In addition, as has been discussed before on this list, we need
to think about what policies make sense. A restrictive
Standards Action/Expert Review/IESG Approval does not
always make sense unless there are field size or
interoperability issues. The rest should be as open as
possible. In general, the IANA policies need monitoring
and updates; WGs should look at their current policies
and determine if they are correct in today's environment

This is part of the reason why I said that the port case
is being handled separately. I think people should be
able to request ports much more easily than protocol
numbers.

For 3), I respectfully disagree with Ryan's statements on
the web page. He said "... you pay for "experts" to review
your protocol and if they agree that it requires the numbers
you're asking for, you get it. If you look at the list of assigned
protocol numbers, this method appears to be the favored one.
Getting a number allocation has more to do with having money."
This is obviously completely incorrect. All you have to do to
get an expert looking at an allocation is ask. And experts
who are unresponsive -- they appear to be capable of stalling
requests even from the big business guys :-(

Jari

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 6 Nov 2007 22:32:43 +0100

On Tue, Nov 06, 2007 at 09:28:36AM -0800,
 Ted Hardie <[email-masked]> wrote 
 a message of 48 lines which said:

> ... to combat whatever other bad info is floating around there. Not
> that I really expect blogs to fact check, but it would get anyone
> who actually looked the right information.

I am not sure it is easy for a newcomer, who programs but is not
acquainted with IETF rules and habits, to know about these
processes. Those who are deeply involved in the IETF for many years
often forget how scary and surprising it can be for people coming from
the outside. RFC 3774, 2.6.6, 2.6.7, etc

In the hope of spreading the information, I've added pointers to the
IETF public archives to the Web page at kerneltrap.

Sorry for horribly mispelling your name, but I typed too fast and did
not find a way to fix my mistakes afterwards.