Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
Bill, Bernard, Fascinating stories. My take is that we should take the document under consideration forward. Independently of that I want to look into the particular case and see if something can be done (e.g., the bsd folks asked to submit a description of their protocol; registries and collisions corrected). But I'll take that off this list. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
On 11/7/07, Bernard Aboba <[EMAIL PROTECTED]> wrote: > Here is a different take on what happened: ... There are all sorts of takes on what happened. What I was told at the time was that the CARP developers picked protocol 112 specifically to interfere with VRRP, to get back at the IETF for not accepting their anti-patent position and to show the IETF how irrelevant they were. My impression was always that the various other stories were fabricated to cover up that decision. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
Jari Arkko said: "> McBride never said so. He said you have to pay experts for the > reviews. Right, but that's not needed either. At least not if we are talking about a registry that has policy Expert Review. If an expert exists, he will be polled by IANA for an opinion. If an expert is not assigned for the particular registry, IANA will ask IESG to assign one." Here is a different take on what happened: >From http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol : "From OpenBSD.org: As a final note of course, when we petitioned IANA, the IETF body regulating "official" internet protocol numbers, to give us numbers for CARP and pfsync our request was denied. Apparently we had failed to go through an official standards organization. Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112. We also placed pfsync at an open and unused number. We informed IANA of these decisions, but they declined to reply. The reason for this is that no specification for CARP has ever been written. The closest thing to specifications is the implementation in OpenBSD. Note that VRRP also uses IP protocol 112, having been assigned it by IANA." See also: http://archives.devshed.com/forums/networking-100/carp-1500297.html ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
Stephane, >> IANA has never charged an applicant for their request for protocol >> parameters including port numbers. >> > > McBride never said so. He said you have to pay experts for the > reviews. > Right, but that's not needed either. At least not if we are talking about a registry that has policy Expert Review. If an expert exists, he will be polled by IANA for an opinion. If an expert is not assigned for the particular registry, IANA will ask IESG to assign one. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
On Tue, Nov 06, 2007 at 09:28:36AM -0800, Ted Hardie <[EMAIL PROTECTED]> 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
On Tue, Nov 06, 2007 at 11:04:46AM -0800, Michelle Cotton <[EMAIL PROTECTED]> wrote a message of 86 lines which said: > IANA has never charged an applicant for their request for protocol > parameters including port numbers. McBride never said so. He said you have to pay experts for the reviews. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
>For example, see: >http://kerneltrap.org/node/2873 That message appears to be based completely on conjecture - for example, their assertion based on looking at the list of assigned numbers ignores the fact that all of the numbers they based their supposition on were assigned before the rules were put in place. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
Keep in mind that the interview with Mr. McBride was back in April 2004. The response times back then may not have been great, but IANA has never charged an applicant for their request for protocol parameters including port numbers. IANA response times have greatly improved over the last few years. See: http://www.iana.org/reporting-and-stats/index.html (Performance Charts) In cases where experts are used, IANA has a reminder system in place as well as an escalation process to notify the IESG if an expert is not responding to IANA. With regards to the protocol numbers described in arkko-rfc2780-proto-upate, there are only approximately 115 that are unassigned in the registry. This is a scarce resource and care should taken in making assignments. This document does not change much in actual procedures with the IANA as a protocol number has not been assigned under NDA for at least 6 years if not longer. Hope this information is helpful. Michelle Cotton Manager, IETF Relations IANA -- From: Bernard Aboba <[EMAIL PROTECTED]> To: ietf@ietf.org Date: Tue, 6 Nov 2007 07:02:08 -0800 (PST) Subject: Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --- End of Forwarded Message ___ Ietf-iana mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-iana ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
Bernard, > I also agree that the change is appropriate. Good. > 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 > 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
At 7:02 AM -0800 11/6/07, Bernard Aboba wrote: >\ >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. 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 >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." 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
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 At 10:02 AM 11/6/2007, Bernard Aboba wrote: >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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
>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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
Brian, Frank, Thanks for your comments. A few additional notes below: > Red herring as far as this draft is concerned: I'd be interested > to know why we are still willing to allow non-disclosure for > port numbers (see RFC 2780 sections 8 and 9.1). Port numbers > are going fast. As was mentioned already, this is something that Lars and a few other folks are currently looking at. I'm presuming that there will be a draft about this later. But the port case might be different; that's why they are pursued separately, even if both share some practical problems associated with NDAs for volunteer experts etc. I view the protocol number rule change as a bug fix. >>> From -00 to Last Call in less than three hours, is that >> a "speedy publish" procedure I haven't heard of before ? > > I-D submission tool plus the sponsoring AD's special buttons in > the I-D tracker. Seems like eating our own dogfood to me. Its part of the IESG's effort to improve the speed of our process by moving to units of hours instead of months ;-) But seriously, this was merely the combination of a very short draft, a change that appears to be the right thing, sponsoring AD (Russ) being aware of the issue from past discussions with IANA, and the AD review getting done in fifteen minutes after I requested it. But the main effort and bulk of time for this draft is in the public discussion of what rules makes sense -- and we just started that in the last call. More generally, short drafts and bug fixes tend to go through relatively quickly. Individual submissions via sponsoring AD may sometimes go quicker than WG submissions, because there are less forums and their managers to go through. However, individual submissions may get less priority from the ADs if they have many WG submissions on their queue as well. And complex proposals need some forum for the discussion to happen in any case. Finally, drafts that do not need modification at LC or IESG review stage tend to go through about four times as fast as drafts that do need modification. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
On 2007-11-6, at 2:08, ext Brian E Carpenter wrote: Red herring as far as this draft is concerned: I'd be interested to know why we are still willing to allow non-disclosure for port numbers (see RFC 2780 sections 8 and 9.1). Port numbers are going fast. We've recently been discussing port number allocation procedures with IANA, and changes may be coming. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
On 2007-11-06 11:35, Frank Ellermann wrote: The IESG wrote: as a BCP +1, maybe s/to use of the/to use the limited/ 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. Red herring as far as this draft is concerned: I'd be interested to know why we are still willing to allow non-disclosure for port numbers (see RFC 2780 sections 8 and 9.1). Port numbers are going fast. From -00 to Last Call in less than three hours, is that a "speedy publish" procedure I haven't heard of before ? I-D submission tool plus the sponsoring AD's special buttons in the I-D tracker. Seems like eating our own dogfood to me. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
The IESG wrote: > as a BCP +1, maybe s/to use of the/to use the limited/ >From -00 to Last Call in less than three hours, is that a "speedy publish" procedure I haven't heard of before ? Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
