Re: I-D ACTION:draft-klensin-iana-reg-policy-00.txt
Brian E Carpenter <brc@zurich.ibm.com> Wed, 13 July 2005 14:58 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsigk-00012I-5u; Wed, 13 Jul 2005 10:58:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsigi-00012D-5T for ietf@megatron.ietf.org; Wed, 13 Jul 2005 10:58:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14638 for <ietf@ietf.org>; Wed, 13 Jul 2005 10:58:14 -0400 (EDT)
Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsj93-0003ur-77 for ietf@ietf.org; Wed, 13 Jul 2005 11:27:35 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j6DEw0Th165322 for <ietf@ietf.org>; Wed, 13 Jul 2005 14:58:00 GMT
Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6DEw0Rd149304 for <ietf@ietf.org>; Wed, 13 Jul 2005 16:58:00 +0200
Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j6DEvxfv007166 for <ietf@ietf.org>; Wed, 13 Jul 2005 16:58:00 +0200
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j6DEvxtP007157; Wed, 13 Jul 2005 16:57:59 +0200
Received: from zurich.ibm.com (sig-9-145-249-78.de.ibm.com [9.145.249.78]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA47820; Wed, 13 Jul 2005 16:57:57 +0200
Message-ID: <42D52BF6.50105@zurich.ibm.com>
Date: Wed, 13 Jul 2005 16:57:58 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: ietf@ietf.org
References: <E1DnM5q-00086s-8F@newodin.ietf.org>
In-Reply-To: <E1DnM5q-00086s-8F@newodin.ietf.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Content-Transfer-Encoding: 7bit
Cc: John Klensin <john-ietf@jck.com>, Scott Bradner <sob@harvard.edu>, Vint Cerf <vinton.g.cerf@mci.com>
Subject: Re: I-D ACTION:draft-klensin-iana-reg-policy-00.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
General AD hat on: I'm concerned that since rfc2434bis is in progress, any changes to RFC 2434 should be made in that draft, not by an additional document. Otherwise we will end up with a patchwork quilt of documents. So I'd encourage the authors of iana-reg-policy to figure out where their ideas would impact draft-narten-iana-considerations-rfc2434bis, and as the saying goes "send text." General AD hat off: 1. I agree with those who've said that we can't reasonably make blanket retroactive changes to the intent of previous IANA Considerations based on or citing RFC 2434. We can clearly change the intent of future IANA Considerations (see previous comment from the AD :-). But if existing, published documents need to change (2780 to take an example) I think they have to be changed explicitly. 2. It's easy to say that if a namespace is too small, we should make it bigger. But, to take a recently contentious example, there's a *reason* the IPv6 option field is only 3+5 bits long. It wasn't an idle choice. It was to keep the IPv6 header as short as possible and as nicely aligned as possible, for the benefit of hardware designers and wirless networks in particular. There was also a *reason* the diffserv code point was limited to 6 bits - as above, plus the fact that the ECN folk really needed the other two bits. So clearly, these small fields need prudent stewardship. As a matter of fact, I can make an argument for prudent stewardship in seemingly much larger fields. 32 bits seemed like a lot in 1980, no doubt; 128 bits seemed like a lot in 1995. But see draft-narten-iana-rir-ipv6-considerations-00.txt for why even a 128 bit field needs prudent stewardship. And even the rather large domain name space turns out to need prudent stewardship, as Vint knows only too well. So however large the namespace gets, it needs prudent stewardship. I can't disagree that namespaces should be as large as reasonably possible on engineering grounds. But actually extending a deployed namespace is a massive undertaking. A good example is the BGP4 AS number space - we've known for years that it is filling up, but the deployment effort involved in expanding it has prevented any action. So even if we can theoretically expand the namespace, it needs prudent stewardship in practice. 3. Thus I come to the key question - how high should the bar be for assignments in clearly constrained namespaces? This month's poster child is IPv6 option numbers, but at an even more basic level, we should probably be more worried about port numbers, where we seem pretty close to running out of well-known numbers, and moving along nicely through the registered port numbers. I'm on the side of fairly rigorous review in these constrained spaces. With the experience of the Larry Roberts request, I actually think RFC 2780 is too lax - it would be better if IETF Review (in rfc2434bis terminology) was required for option numbers. Contrary to what I understand the present draft to mean, I think that for some very critical namespaces, such as IP header fields, that may have fundamental impact on packet flows, a technical review of the proposed usage of the parameter is *always* required before an assignment, regardless of scarcity. Clarity of definition is *not* enough to justify a registration; we also need to agree as a community that the proposed usage will not be a cause of collateral damage to the Internet. There's every reason that the same standard should apply to specifications developed outside the IETF exactly as to IETF documents. For the more critical namespaces covered by 2780, I am quite sure this applies. There can be other namespaces where it certainly doesn't. I think we should concentrate on getting the definitions in 2434bis right. I also think an update of 2780 is needed in the light of experience. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: I-D ACTION:draft-klensin-iana-reg-policy-00.t… Brian E Carpenter
- RE: I-D ACTION:draft-klensin-iana-reg-policy-00.t… Nick Staff
- Re: I-D ACTION:draft-klensin-iana-reg-policy-00.t… Hans Kruse
- Re: I-D ACTION:draft-klensin-iana-reg-policy-00.t… John Leslie
- Re: I-D ACTION:draft-klensin-iana-reg-policy-00.t… John C Klensin
- Re: I-D ACTION:draft-klensin-iana-reg-policy-00.t… Brian E Carpenter
- Re: I-D ACTION:draft-klensin-iana-reg-policy-00.t… Brian E Carpenter
- Port numbers and IPv6 (was: I-D ACTION:draft-klen… David Hopwood
- Re: Port numbers and IPv6 (was: I-D ACTION:draft-… Steven M. Bellovin
- Re: Port numbers and IPv6 (was: I-D ACTION:draft-… Scott Bradner
- Re: I-D ACTION:draft-klensin-iana-reg-policy-00.t… Iljitsch van Beijnum
- Re: Port numbers and IPv6 (was: I-D ACTION:draft-… Jeroen Massar
- Re: I-D ACTION:draft-klensin-iana-reg-policy-00.t… JFC (Jefsey) Morfin
- Re: Port numbers and IPv6 (was: I-D ACTION:draft-… David Hopwood
- Re: Port numbers and IPv6 (was: I-D ACTION:draft-… Ned Freed
- Re: Port numbers and IPv6 (was: I-D ACTION:draft-… Iljitsch van Beijnum
- Re: Port numbers and IPv6 (was: I-D ACTION:draft-… John C Klensin
- Re: Port numbers and IPv6 (was: I-D ACTION:draft-… Ned Freed
- Re: Port numbers and IPv6 Iljitsch van Beijnum
- Re: Port numbers and IPv6 Ned Freed
- Re: Port numbers and IPv6 Ned Freed
- Re: Port numbers and IPv6 (was: I-D Bob Hinden
- Re: Port numbers and IPv6 Iljitsch van Beijnum
- Re: Port numbers and IPv6 Juergen Schoenwaelder
- Re: Port numbers and IPv6 (was: I-D John C Klensin
- Re: Port numbers and IPv6 (was: I-D John Day
- Re: Port numbers and IPv6 Ned Freed
- Re: Port numbers and IPv6 (was: I-D John C Klensin
- Re: Port numbers and IPv6 Michael Thomas
- Re: Port numbers and IPv6 Ned Freed
- Re: Port numbers and IPv6 Spencer Dawkins
- Re: Port numbers and IPv6 Steven M. Bellovin