Re: 24316 prefixes
David Conrad <davidc@keio.jp.apnic.net> Fri, 06 January 1995 21:40 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09940; 6 Jan 95 16:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09936; 6 Jan 95 16:40 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa04828; 6 Jan 95 16:40 EST
Received: from keio.jp.apnic.net (keio.jp.apnic.net [133.4.34.30]) by merit.edu (8.6.9/merit-2.0) with ESMTP id QAA25625 for <bgpd@merit.edu>; Fri, 6 Jan 1995 16:34:23 -0500
Received: from localhost (davidc@localhost) by keio.jp.apnic.net (8.6.9/8.6.9) with SMTP id GAA29656; Sat, 7 Jan 1995 06:31:56 +0900
Message-Id: <199501062131.GAA29656@keio.jp.apnic.net>
X-Authentication-Warning: keio.jp.apnic.net: Host localhost didn't use HELO protocol
To: yakov@watson.ibm.com
cc: bgpd@merit.edu
Subject: Re: 24316 prefixes
In-reply-to: Your message of "Fri, 06 Jan 1995 14:43:42 EST." <199501061943.OAA24183@merit.edu>
Date: Sat, 07 Jan 1995 06:31:56 +0900
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: David Conrad <davidc@keio.jp.apnic.net>
>Fully agree with this. However, the above implies that addresses are >assigned in such a way that the aggregation is possible. Let me suggest >that this group should pay MUCH MORE attention to the address assignment >procedures, or otherwise there will be not too much to aggregate. I, of course, strongly concur with Yakov's statement here. All the games and knobs you can play with won't help when addresses are allocated in ways that simply cannot be aggregated. I feel it is in the best interests of people who are watching their routers fall over to take a much more active interest in the policies involved in allocating address space. RFC 1466, RFC 1597, RFC 1627, the recent draft IANA statement posted to the IEPG list, and the Internet draft draft-iab-assignment-guidance-00.txt all have or may have direct relevance on how addresses are allocated. The last two in particular are likely to alter the current procedures used by the registries if they become official policies. To my mind there has been far too little discussion on these documents, considering some of their implications... Regards, -drc
- 24316 prefixes Peter Lothberg
- 24316 prefixes yakov
- Re: 24316 prefixes Curtis Villamizar
- Re: 24316 prefixes Curtis Villamizar
- 24316 prefixes yakov
- Re: 24316 prefixes Alan Barrett
- Re: 24316 prefixes Paul Traina
- Re: 24316 prefixes Andrew Partan
- Re: 24316 prefixes Paul Traina
- 24316 prefixes Tony Li
- Re: 24316 prefixes Andrew Partan
- Re: 24316 prefixes Alan Barrett
- 24316 prefixes Tony Li
- Re: 24316 prefixes Dave Morton
- Re: 24316 prefixes Alan Barrett
- 24316 prefixes Tony Li
- Re: 24316 prefixes Paul Traina
- Re: 24316 prefixes Sean Doran
- Re: 24316 prefixes Sean Doran
- Re: 24316 prefixes Sean Doran
- The AUP enforcement problem Alan Barrett
- 24316 prefixes yakov
- Re: 24316 prefixes Peter S. Ford
- NSFnet-approved nets inside non-approved aggregate Alan Barrett
- Re: 24316 prefixes Vadim Antonov
- 24316 prefixes yakov
- 24316 prefixes yakov
- Re: 24316 prefixes Peter S. Ford
- Re: 24316 prefixes Paul Traina
- Re: 24316 prefixes David Conrad
- Re: 24316 prefixes Paul Traina
- Re: 24316 prefixes Sean Doran
- Re: 24316 prefixes Sean Doran
- Re: 24316 prefixes Sean Doran
- Re: 24316 prefixes Vadim Antonov
- Re: 24316 prefixes Curtis Villamizar
- Re: 24316 prefixes Sean Doran
- Re: 24316 prefixes Curtis Villamizar
- 24316 prefixes Tony Li