From weiler at tislabs.com Sun Oct 1 15:11:35 2006 From: weiler at tislabs.com (Sam Weiler) Date: Sun, 1 Oct 2006 21:11:35 +0200 (CEST) Subject: [ppml] Consensus and voting: a proposal Message-ID: I'm concerned that the reliance on straw polls during ARIN's public policy meetings significantly impedes progress towards consensus. Accordingly, I'd like to see ARIN eliminate or seriously revamp the use of straw polls (voting) in the public policy meeting. In my understanding, consensus requires consideration of the concerns of all parties, including those opposed to a particular proposal. A prerequisite to such consideration is having all parties voice their concerns in enough detail to allow for meaningful dialog. In my experience at ARIN meetings, the up-or-down straw polls on policy proposals often don't provide enough information about the nature of the opposition to permit a meaningful attempt to find a compromise or resolve the disagreement. In many of these cases, the AC has used the results of those straws poll to justify a finding that there's not consensus, but without giving us a path toward consensus -- we often don't know why there's opposition to a proposal. By way of comparison, the IETF (at least the working groups I'm active in) asks for opposition to described in some detail, which gives those tasked with judging consensus a rich set of data to work with. It also gives the participants in the discussion a chance to dialong about the objections to a proposal and attempt to reach consensus. In order to keep us from deadlocking for want of understanding, I'd like to see the AC make a point of considering opposition to a proposal only when that opposition is voiced in enough detail for the AC to clearly understand the opposition (and, by implication, in enough detail to allow a dialog on the substance). To that end, I propose the following changes: -- In the public policy meeting, solicit straw polls only reluctantly and only when the AC thinks that taking one will significantly help in reaching or judging consensus. In particular, -- In the absence of voiced opposition to a proposal (and, presumably, the presence of any voiced support), don't do any straw poll at all. -- In the presence of voiced opposition, allow the AC, at its own discretion, to poll for 1) support for a proposal and 2) objection on specific grounds, with each separate reason for opposition being polled separately. I suggest that the AC delegate the authority to ask for this poll to particular individuals (perhaps the shepherds for each proposal, or the AC members on stage during the presentation). It might further help to have the AC, prior to the public policy meeting, specifically contemplate 1) what opposition it expects to hear on a particular proposal and 2) whether a straw poll about that particular item will help the community reach consensus. That group discussion can then guide the AC members tasked with deciding, in real time, whether to do a straw poll during the meeting. -- Sam Weiler From sleibrand at internap.com Sun Oct 1 21:32:43 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sun, 01 Oct 2006 21:32:43 -0400 Subject: [ppml] Consensus and voting: a proposal In-Reply-To: References: Message-ID: <45206C3B.9050208@internap.com> Overall I like Sam's proposal. Would it be possible to do a procedural experiment at the upcoming ARIN meeting? Specifically, if the person running the straw polls thinks it would be helpful, could they try asking for straw polls on specific points of objection (raised in discussion or on PPML) if the first straw poll shows enough objection to indicate a lack of consensus? -Scott Sam Weiler wrote: > I'm concerned that the reliance on straw polls during ARIN's public > policy meetings significantly impedes progress towards consensus. > Accordingly, I'd like to see ARIN eliminate or seriously revamp the > use of straw polls (voting) in the public policy meeting. > > In my understanding, consensus requires consideration of the concerns > of all parties, including those opposed to a particular proposal. A > prerequisite to such consideration is having all parties voice their > concerns in enough detail to allow for meaningful dialog. > > In my experience at ARIN meetings, the up-or-down straw polls on > policy proposals often don't provide enough information about the > nature of the opposition to permit a meaningful attempt to find a > compromise or resolve the disagreement. In many of these cases, the > AC has used the results of those straws poll to justify a finding that > there's not consensus, but without giving us a path toward consensus > -- we often don't know why there's opposition to a proposal. > > By way of comparison, the IETF (at least the working groups I'm active > in) asks for opposition to described in some detail, which gives those > tasked with judging consensus a rich set of data to work with. It > also gives the participants in the discussion a chance to dialong > about the objections to a proposal and attempt to reach consensus. > > In order to keep us from deadlocking for want of understanding, I'd > like to see the AC make a point of considering opposition to a > proposal only when that opposition is voiced in enough detail for the > AC to clearly understand the opposition (and, by implication, in > enough detail to allow a dialog on the substance). To that end, I > propose the following changes: > > -- In the public policy meeting, solicit straw polls only reluctantly > and only when the AC thinks that taking one will significantly help > in reaching or judging consensus. In particular, > > -- In the absence of voiced opposition to a proposal (and, > presumably, the presence of any voiced support), don't do any > straw poll at all. > > -- In the presence of voiced opposition, allow the AC, at its own > discretion, to poll for 1) support for a proposal and 2) > objection on specific grounds, with each separate reason for > opposition being polled separately. I suggest that the AC > delegate the authority to ask for this poll to particular > individuals (perhaps the shepherds for each proposal, or the AC > members on stage during the presentation). > > It might further help to have the AC, prior to the public policy > meeting, specifically contemplate 1) what opposition it expects to > hear on a particular proposal and 2) whether a straw poll about that > particular item will help the community reach consensus. That group > discussion can then guide the AC members tasked with deciding, in real > time, whether to do a straw poll during the meeting. > > -- Sam Weiler > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Sun Oct 1 21:44:03 2006 From: randy at psg.com (Randy Bush) Date: Sun, 01 Oct 2006 15:44:03 -1000 Subject: [ppml] Consensus and voting: a proposal In-Reply-To: <45206C3B.9050208@internap.com> References: <45206C3B.9050208@internap.com> Message-ID: <45206EE3.7080606@psg.com> Scott Leibrand wrote: > Overall I like Sam's proposal. Would it be possible to do a procedural > experiment at the upcoming ARIN meeting? Specifically, if the person > running the straw polls thinks it would be helpful, could they try > asking for straw polls on specific points of objection (raised in > discussion or on PPML) if the first straw poll shows enough objection to > indicate a lack of consensus? what abou tthose supporting also having to justify their support? goos and gander and all that? randy From sleibrand at internap.com Sun Oct 1 22:01:46 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sun, 01 Oct 2006 22:01:46 -0400 Subject: [ppml] Consensus and voting: a proposal In-Reply-To: <45206EE3.7080606@psg.com> References: <45206C3B.9050208@internap.com> <45206EE3.7080606@psg.com> Message-ID: <4520730A.60509@internap.com> Randy Bush wrote: > Scott Leibrand wrote: >> Overall I like Sam's proposal. Would it be possible to do a >> procedural experiment at the upcoming ARIN meeting? Specifically, if >> the person running the straw polls thinks it would be helpful, could >> they try asking for straw polls on specific points of objection >> (raised in discussion or on PPML) if the first straw poll shows >> enough objection to indicate a lack of consensus? > > what about those supporting also having to justify their support? > goose and gander and all that? > > Often the justification for support will be "I agree with what's in the justification section of the policy proposal". If we could get similarly detailed justification for opposition (which we usually do, in the form of a PPML post), and then could see how many people oppose the policy for each different reason (Sam's proposal) we'd be in a better position to know which direction to take the policy proposal in order to achieve consensus. So I see a few different (possibly somewhat overlapping) categories: * I support the policy proposal, for the reasons outlined in its justification section. * I largely support the policy proposal, but for reason X (where X has already been presented to PPML or to the mic). * I oppose the policy proposal, for reason Y (where Y has already been presented to PPML or to the mic). * I oppose the policy proposal, for reason Z (where Z has already been presented to PPML or to the mic)... This seems to me very much like the way the Supreme Court comes to decisions. They have someone writing for the majority, sometimes have justices voting with the majority but with their own justifications (and writing their own opinion), and one or more minority opinions written by and voted for by those opposing the majority's view. But all in all, we don't need something quite so complicated. :) If we could simply get different straw polls to gauge *why* people oppose a policy proposal, that would definitely help move the policy proposal toward consensus. -Scott -Scott From owen at delong.com Mon Oct 2 00:55:44 2006 From: owen at delong.com (Owen DeLong) Date: Sun, 1 Oct 2006 21:55:44 -0700 Subject: [ppml] Consensus and voting: a proposal In-Reply-To: References: Message-ID: <00889A91-18EB-4357-81F2-6ABE546764B3@delong.com> On Oct 1, 2006, at 12:11 PM, Sam Weiler wrote: > I'm concerned that the reliance on straw polls during ARIN's public > policy meetings significantly impedes progress towards consensus. > Accordingly, I'd like to see ARIN eliminate or seriously revamp the > use of straw polls (voting) in the public policy meeting. > I'm not convinced of this. I think the debate before the straw polls tends to provide the kind of qualitative information you claim to be looking for. I think the straw polls are useful in guaging the qunatitative properties of support and opposition. I would also point out that in a number of cases, the straw poll has been conducted in a manner other than a straight yes/no vote. For example, 2005-1 was able to achieve consensus only because we were able to provide alternative options to several critical chunks of the policy, allowing for fine tuning of the policy in the straw poll process. > In my understanding, consensus requires consideration of the concerns > of all parties, including those opposed to a particular proposal. A > prerequisite to such consideration is having all parties voice their > concerns in enough detail to allow for meaningful dialog. > > In my experience at ARIN meetings, the up-or-down straw polls on > policy proposals often don't provide enough information about the > nature of the opposition to permit a meaningful attempt to find a > compromise or resolve the disagreement. In many of these cases, the > AC has used the results of those straws poll to justify a finding that > there's not consensus, but without giving us a path toward consensus > -- we often don't know why there's opposition to a proposal. > If it were just the straw polls by themselves, I would agree with you. However, the straw polls are conducted at the end of debate on the topic. Often after significant debate. As such, I think they provide a useful metric to understand what percentage of those present are in support or opposition of the proposal. If there is opposition to the proposal, but, none of the opponents stepped up to the mic. to explain said opposition, I don't think that means the opposition should be disregarded. > In order to keep us from deadlocking for want of understanding, I'd > like to see the AC make a point of considering opposition to a > proposal only when that opposition is voiced in enough detail for the > AC to clearly understand the opposition (and, by implication, in > enough detail to allow a dialog on the substance). To that end, I > propose the following changes: > > -- In the public policy meeting, solicit straw polls only reluctantly > and only when the AC thinks that taking one will significantly > help > in reaching or judging consensus. In particular, > There's no real provision for gauging the AC's desire on this in time to call the question if they want it called. This would essentially require a 15-person side-vote on each item to determine whether or not to call a straw poll. > -- In the absence of voiced opposition to a proposal (and, > presumably, the presence of any voiced support), don't do any > straw poll at all. > I completely disagree here. The opposition not wanting to approach the microphone should not eliminate their voting rights. This would disenfranchise a number of ARIN constituents for no other reason that they are microphone-shy. > -- In the presence of voiced opposition, allow the AC, at its own > discretion, to poll for 1) support for a proposal and 2) > objection on specific grounds, with each separate reason for > opposition being polled separately. I suggest that the AC > delegate the authority to ask for this poll to particular > individuals (perhaps the shepherds for each proposal, or the AC > members on stage during the presentation). > This is such an important aspect of the consensus gauging process that I am not comfortable with a fuzzy-logic set of rules for how it is to be conducted. If you can come up with an exact procedure for such delegation, I would recommend submitting it for consideration as a modification to the IRPEP. > It might further help to have the AC, prior to the public policy > meeting, specifically contemplate 1) what opposition it expects to > hear on a particular proposal and 2) whether a straw poll about that > particular item will help the community reach consensus. That group > discussion can then guide the AC members tasked with deciding, in real > time, whether to do a straw poll during the meeting. > I'm pretty sure the AC (or at least the AC members) already contemplate all the proposals prior to the meeting, including what support, what opposition, and what questions are observed and expected. In my opinion, the debate prior to the calling of the question provides the qualitative information desired in most cases. I have not observed a distinct lack of opposition speaking in the debates, so perhaps your observation is different from mine. The straw polls add a quantitative perspective on the magnitude of opposition, support, and, in many cases, apathy. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From BillD at cait.wustl.edu Mon Oct 2 06:52:45 2006 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 2 Oct 2006 05:52:45 -0500 Subject: [ppml] Consensus and voting: a proposal References: <00889A91-18EB-4357-81F2-6ABE546764B3@delong.com> Message-ID: I believe that Owen is correct in his observations. The straw polls at meetings are a means to provide tangible evidence of consensus, and are useful in that. But, only after there has been debate on the ppml long before the meeting and a presentation and opportunity for discussion in the meeting prior to and often complicated series of poll questions posed in such a way as to 'tease' out the subtleties of support. I might add that there are Board members and AC as well as some who attend meeting regularly who are 'contrarian' and offer the 'devil's advocate' position for consideration. Also, in meeting assessing consensus, individual AC members will often bring up opposing points of view that might be in there experience, but were unexposed by others on the ppml or in the meeting. Many of the AC, perhaps all, are not happy with the polling process, not because it is not valuable, but because it represents only those in the meetings...and most often, only a portion of those. As such, the AC uses the polls judiciously looking skeptically at results that are no wholely lopsided and large in number relative to those in attendance. Even so, it is only one aspect of the consensus judgement. All externalities of ppml, side conversations, pleas from individuals, other mailing lists, personal experience and observations, all are brought to the table. Welcome to all suggestions on how to improve the involvement others in the process and to improve the breadth, transparancy and objectivity of the consensus building and judgement process. The AC will make a concensus judgement given what they have to work with, but I can assure you we are quite conservative in our assessments. Even then, when the AC is convinced that consensus exists for a decision on a policy proposal, the proposal is exposed once again on the ppml for rebuttal or support as those involved/interested may choose. Bill Darte ARIN AC -----Original Message----- From: ppml-bounces at arin.net on behalf of Owen DeLong Sent: Sun 10/1/2006 11:55 PM To: Sam Weiler Cc: ppml at arin.net Subject: Re: [ppml] Consensus and voting: a proposal On Oct 1, 2006, at 12:11 PM, Sam Weiler wrote: > I'm concerned that the reliance on straw polls during ARIN's public > policy meetings significantly impedes progress towards consensus. > Accordingly, I'd like to see ARIN eliminate or seriously revamp the > use of straw polls (voting) in the public policy meeting. > I'm not convinced of this. I think the debate before the straw polls tends to provide the kind of qualitative information you claim to be looking for. I think the straw polls are useful in guaging the qunatitative properties of support and opposition. I would also point out that in a number of cases, the straw poll has been conducted in a manner other than a straight yes/no vote. For example, 2005-1 was able to achieve consensus only because we were able to provide alternative options to several critical chunks of the policy, allowing for fine tuning of the policy in the straw poll process. > In my understanding, consensus requires consideration of the concerns > of all parties, including those opposed to a particular proposal. A > prerequisite to such consideration is having all parties voice their > concerns in enough detail to allow for meaningful dialog. > > In my experience at ARIN meetings, the up-or-down straw polls on > policy proposals often don't provide enough information about the > nature of the opposition to permit a meaningful attempt to find a > compromise or resolve the disagreement. In many of these cases, the > AC has used the results of those straws poll to justify a finding that > there's not consensus, but without giving us a path toward consensus > -- we often don't know why there's opposition to a proposal. > If it were just the straw polls by themselves, I would agree with you. However, the straw polls are conducted at the end of debate on the topic. Often after significant debate. As such, I think they provide a useful metric to understand what percentage of those present are in support or opposition of the proposal. If there is opposition to the proposal, but, none of the opponents stepped up to the mic. to explain said opposition, I don't think that means the opposition should be disregarded. > In order to keep us from deadlocking for want of understanding, I'd > like to see the AC make a point of considering opposition to a > proposal only when that opposition is voiced in enough detail for the > AC to clearly understand the opposition (and, by implication, in > enough detail to allow a dialog on the substance). To that end, I > propose the following changes: > > -- In the public policy meeting, solicit straw polls only reluctantly > and only when the AC thinks that taking one will significantly > help > in reaching or judging consensus. In particular, > There's no real provision for gauging the AC's desire on this in time to call the question if they want it called. This would essentially require a 15-person side-vote on each item to determine whether or not to call a straw poll. > -- In the absence of voiced opposition to a proposal (and, > presumably, the presence of any voiced support), don't do any > straw poll at all. > I completely disagree here. The opposition not wanting to approach the microphone should not eliminate their voting rights. This would disenfranchise a number of ARIN constituents for no other reason that they are microphone-shy. > -- In the presence of voiced opposition, allow the AC, at its own > discretion, to poll for 1) support for a proposal and 2) > objection on specific grounds, with each separate reason for > opposition being polled separately. I suggest that the AC > delegate the authority to ask for this poll to particular > individuals (perhaps the shepherds for each proposal, or the AC > members on stage during the presentation). > This is such an important aspect of the consensus gauging process that I am not comfortable with a fuzzy-logic set of rules for how it is to be conducted. If you can come up with an exact procedure for such delegation, I would recommend submitting it for consideration as a modification to the IRPEP. > It might further help to have the AC, prior to the public policy > meeting, specifically contemplate 1) what opposition it expects to > hear on a particular proposal and 2) whether a straw poll about that > particular item will help the community reach consensus. That group > discussion can then guide the AC members tasked with deciding, in real > time, whether to do a straw poll during the meeting. > I'm pretty sure the AC (or at least the AC members) already contemplate all the proposals prior to the meeting, including what support, what opposition, and what questions are observed and expected. In my opinion, the debate prior to the calling of the question provides the qualitative information desired in most cases. I have not observed a distinct lack of opposition speaking in the debates, so perhaps your observation is different from mine. The straw polls add a quantitative perspective on the magnitude of opposition, support, and, in many cases, apathy. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ed.Lewis at neustar.biz Mon Oct 2 09:19:22 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 2 Oct 2006 15:19:22 +0200 Subject: [ppml] Consensus and voting: a proposal In-Reply-To: References: <00889A91-18EB-4357-81F2-6ABE546764B3@delong.com> Message-ID: At 5:52 -0500 10/2/06, Bill Darte wrote: > I believe that Owen is correct in his observations. Me too. > The straw polls at meetings are a means to provide tangible > evidence of consensus, and are useful in that. But, only I think Bill meant this (supported by a later statement): s/consensus/consensus of those who bothered to show up and bothered to raise a hand/ (If not: Bill I apologize.) > after there has been debate on the ppml long before the > meeting and a presentation and opportunity for discussion in > the meeting prior to and often complicated series of poll > questions posed in such a way as to 'tease' out the > subtleties of support. That is an important point. The reason policies have to be in the process well before the public policy meeting is to provide opportunity for discussion before the meeting is held. By the time we get to the straw polls, they are the tail of the discussion "dog." > I might add that there are Board members and AC as well as > some who attend meeting regularly who are 'contrarian' and > offer the 'devil's advocate' position for consideration. > Also, in meeting assessing consensus, individual AC members > will often bring up opposing points of view that might be in > there experience, but were unexposed by others on the ppml > or in the meeting. The BoT and AC are not volunteers but rather elected (albeit uncompensated) representatives of the membership responsible for the appropriate due diligence in approving a policy change. I.e., they do (and are expected to do) more than what a volunteer is expected to do. AC and BoT members have to do things or they face the wrath of the membership (not get re-elected). > Many of the AC, perhaps all, are not happy with the polling > process, not because it is not valuable, but because it > represents only those in the meetings...and most often, only a This revelation affirms my faith in the elected AC - the straw poll (note how John Curran introduces them) is just an indication of what folks in the room think and is used as input to the AC. It is not, not, not a vote. (Another clue - the audience is the open policy meeting, not the membership.) Setting aside any assessment of the way the IETF works, the IETF is hardly an appropriate model for the running of ARIN. The problems sets are different even if there is a large cross-over attendance. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From dlw+arin at tellme.com Mon Oct 2 10:09:11 2006 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 2 Oct 2006 07:09:11 -0700 Subject: [ppml] Consensus and voting: a proposal In-Reply-To: <00889A91-18EB-4357-81F2-6ABE546764B3@delong.com> References: <00889A91-18EB-4357-81F2-6ABE546764B3@delong.com> Message-ID: <20061002140911.GJ26506@shell01.corp.tellme.com> On Sun, Oct 01, 2006 at 09:55:44PM -0700, Owen DeLong wrote: > If there is opposition to the proposal, but, none of the opponents > stepped up > to the mic. to explain said opposition, I don't think that means the > opposition > should be disregarded. While I agree with Owen (and others who responded to his message), I do think that something constructive could be done after a straw poll that reveals unexpected opposition. If there's been little debate, but a large fraction of the room votes against a proposal, perhaps some promprting of an explanation would be helpful. Mysterious and gratuitous opposition seems like a difficult stance to understand. On the other hand, this seems to be fairly unusual. I suspect there's no need for any change in actual procedures. -David From schiller at uu.net Mon Oct 2 15:25:19 2006 From: schiller at uu.net (Jason Schiller) Date: Mon, 02 Oct 2006 15:25:19 -0400 (EDT) Subject: [ppml] Opposition to 2006-2 v6 internal microallocation In-Reply-To: Message-ID: I haven't heard a lot of opposition to 2006-2 v6 internal microallocation, so I would like to invite people to offer any opposing thoughts for debate. Please voice are any new concerns that have not yet been addressed so that these thoughts can be discussed, and possibly folded into the policy. Thanks, ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. From pesherb at yahoo.com Tue Oct 3 00:06:04 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Mon, 2 Oct 2006 21:06:04 -0700 (PDT) Subject: [ppml] ARIN member in good standing? In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40365ED0A@CL-S-EX-1.stanleyassociates.com> Message-ID: <20061003040604.3620.qmail@web54707.mail.yahoo.com> > Can you describe the data capture mechanism? I mentioned the > billing system that would be required. Even if you discard > payload and only keep source and destination addresses and packet > size, you're talking about increasing network load by a > significant amount (30%?). Billing data for an OC3 could be > 16TB per month. Multiply hundreds of circuits times a five-year > record-retention policy, and I get a 97PB database. Assumption: need to count sent volumes only. A sending network or a node (SN) is identified by its source address (SA). SN is connected to provider's distribution router (DR). DR counts the length of all packets sent from SA and reports the total number of bits to a database server. Database server maintains SA table with a cumulative sent volume per each SA per month. Monthly volume is archived on a server. Additional traffic needed is between DR and a server where DR only reports SA and one number representing SA's sent volume e.g. every 1 hr. Billing system collects the total volume per each SA from the database server once a month. > I don't understand "unpaid volumes." You bill your customers. In some cases volume based billing is announced but it may not necessarily be enforced. Billing works OK for burstable circuits. A regular T1 would be provisioned to accommodate e.g. about 0.5Mbps at a busy hour. Three T1s on a single DR may have different usage patterns. E.g. one transmits at 1.2Mbps during 3hrs in the morning. Second sends at 1.1Mbps at night for 6hrs. The third sends at 0.3Mbps 24hrs daily with occasional bursts up to 1.5Mbps. Each pays $1,200 but over the month #1 have sent 49GB, #2 = 89GB, #3 = 110GB. Sometimes providers would go after "abusers" who exceed average usage tens or hundreds times. "Abusers" can be looked at as an opportunity assuming they have a need to move data and are willing to pay for it. > You keep saying "proper," as if to say that there is an established > right way to do things. "Proper" means following the basic logic of a process. E.g. in a world of a regular mail or cargo shipments a sender pays for moving a certain number of molecules over distance. Energy wise how does moving electrons fundamentally differ from moving molecules? If electrons are too many to count let's define a countable network unit representing a fair amount of electrons. > I am not familiar with telecommunications licensing, but I do not > have the impression that licenses are available to anyone. My > impression is that the "certain criteria" are high. Does each > coffee shop and private interconnect have to get a license? The process is straightforward, as long as you meet all "high" criteria you will get the license. If network services are defined and regulated then anyone who falls under that definition is a subject to a license. > So does this mean a new kind of governmental licensing agency, > which works closely with the government tax collection agency, > and the two agencies direct ARIN? It is a matter of coordination between already established agencies, e.g. Tax and FCC. Agencies feed ARIN with the number of subscribers by provider as well as suggested fees. ARIN autonomously performs address allocation practice. ARIN collects fees from all holders of licenses for network services. > I'm unclear on the taxpayer-node relationship. Each taxpaying > individual with a tax ID gets an allocation? What size? Taxpayers are not homogeneous and need segmentation. How many addresses is enough for a single individual? Assuming that at some point we will start fixing genes and that human DNA consists of about 3 billion base pairs will /96 be enough? For the start we may want to reserve more space and start experimenting with less. > Each taxpaying organization with a tax ID get an allocation? > What size? Depending on what they can justify. Current ARIN approach works well here. > Not to be pedantic, but are tax-exempt organizations eligible? All tax-exempt organizations must be on the record as such with a tax agency, which turns a tax agency into a single tracker of all economically active units, both individuals and establishments. > I was talking about IP address allocation. Say my company has > offices in 14 states and two provinces, with leased lines between > them, and three Internet connections. Do I get three assignments > from my carriers, or 14? Or since I have leased lines, do I get a > telecom license? You will get your PI assignment directly from ARIN in the amount you can justify. Whichever provider(s) serve your Internet connection(s) they will report it to ARIN. You will get a telecom license if you meet all of the criteria for it in your region and if you want to be engaged in a telecom business and if a contract with your provider permits you to sub-lease lines. > I pay taxes, so I'm entitled to a direct allocation from ARIN. > But I don't know how much until I go to my ISP and buy service. ARIN will tell you how many addresses you get as an individual taxpayer. From your ISP you only buy an Internet connection. > They tell their licensing agency how many subscribers they have, > the licensing agency tells ARIN how many address to provide and > how much to allocate. ISP reports to ARIN the number of their Internet subscribers. ARIN solely decides how many addresses to provide to whom. Licensing agency establishes a fee amount and makes sure that paying the fee to ARIN is a requirement for an ISP license. > When do I get mine? As an individual taxpayer you are entitled to ARIN-determined address space. > Do I pay ARIN or the ISP? You pay to the ISP for the use of the service. ISP pays to ARIN a fee based on the number of subscribers they have. > How much do I pay? Can I use those addresses with any carrier? You pay what your ISP charges you for the amount of traffic you send. Addresses are allocated to you directly. When you change providers addresses remain with you. You may be connected to several networks and send your traffic through whoever offers the best rate. > My wife pays taxes too. Does she get a separate allocation? Yes, as an individual taxpayer. > She's a programmer for an office-less company. Her company buys > an Internet connection to our house. Does her work PC get an IP > address based on her company's tax ID number, or hers? She has a choice to use her own or her company based on whichever considerations. > What's a top level licensee? E.g. FCC in the US or CRTC in Canada. > > In a case where two individuals have invested in a wire connecting their PCs > > across the street they will not be a subject to ARIN fee as long as their > > private network has no access to the Internet. > > What if one of them sets up community wireless? If he is a philanthropist it benefits the community as long as this private network serves its purpose. If he sells his services he either complies with or violates the license regime, which is a matter of a local licensing office. Thanks, Peter --- "Howard, W. Lee" wrote: > I'm going to defend the topicality of this subject insofar as it > discusses allocation practice. Interconnect charges are not > directly on topic, but may be an important part of why a model will > or will not work. > > > -----Original Message----- > > From: Peter Sherbin [mailto:pesherb at yahoo.com] > > Sent: Friday, September 29, 2006 9:48 AM > > To: Howard, W. Lee; ppml at arin.net > > Subject: RE: [ppml] ARIN member in good standing? > > > > > You would bill the packet originator, not the destination? > > > > Yes, the originator of the packet pays to a transport provider > > > > >you would bill the peer network who sent the packet to you > > > > Peers cut the settlement based on volumes of packets they > > exchange. A bit is a > > single common cost driver on the internet. Any HW or network > > design starts with > > calculating bit volumes. Same should be extended to the > > internet financials. > > Can you describe the data capture mechanism? I mentioned the > billing system that would be required. Even if you discard > payload and only keep source and destination addresses and packet > size, you're talking about increasing network load by a > significant amount (30%?). Billing data for an OC3 could be > 16TB per month. Multiply hundreds of circuits times a five-year > record-retention policy, and I get a 97PB database. > > > > How is your model better than what we have now? > > > > As a provider I support the infrastracture carrying unpaid > > volumes while I am > > challenged with capturing that revenue. We have what we have. > > I guess this is a > > constant search for doing things the proper way. > > I don't understand "unpaid volumes." You bill your customers. > > You keep saying "proper," as if to say that there is an established > right way to do things. > > > > > I don't understand whether you mean every organization should get a > > > provider-independent address block and a telecommunications > > license, or > > > if you mean that only telcos should get PI address space, > > and everybody > > > else must accept assignments from telcos. > > > > Every taxpayer (entity or individual) within RIR area is > > entitled to a certain > > amount of IP (IPv6) address space. I assume a > > telecommunication license is available > > to anyone who wants it and meets certain criteria. Assignment > > of the address space > > goes directly from RIR to a taxpayer. > > I am not familiar with telecommunications licensing, but I do not > have the impression that licenses are available to anyone. My > impression is that the "certain criteria" are high. Does each > coffee shop and private interconnect have to get a license? > > So does this mean a new kind of governmental licensing agency, > which works closely with the government tax collection agency, > and the two agencies direct ARIN? > > I'm unclear on the taxpayer-node relationship. Each taxpaying > individual with a tax ID gets an allocation? What size? > Each taxpaying organization with a tax ID get an allocation? > What size? > Not to be pedantic, but are tax-exempt organizations eligible? > > > > I'm not sure where you put large enterprise networks. Distributed > > > offices, multi-homed networks, multi-national presences... > > > > The entity always carries the cost of the transport network > > wether its own or leased from whichever provider. > > I was talking about IP address allocation. Say my company has > offices in 14 states and two provinces, with leased lines between > them, and three Internet connections. Do I get three assignments > from my carriers, or 14? Or since I have leased lines, do I get a > telecom license? > > > > So only telcos would get IP addresses from ARIN? > > > > Not only telcos but all taxpayers (individuals and entities) > > > > > In the U.S., would the regional licenser be the state PUC > > or the FCC? > > > > Licensers at all levels in all countries within ARIN region > > would need to provide to > > ARIN subscriber counts from their licensees. > > This is all new, so forgive me while I try to put this together. > > I pay taxes, so I'm entitled to a direct allocation from ARIN. > But I don't know how much until I go to my ISP and buy service. > They tell their licensing agency how many subscribers they have, > the licensing agency tells ARIN how many address to provide and > how much to allocate. When do I get mine? Do I pay ARIN or > the ISP? How much do I pay? Can I use those addresses with any > carrier? > > My wife pays taxes too. Does she get a separate allocation? > She's a programmer for an office-less company. Her company buys > an Internet connection to our house. Does her work PC get an IP > address based on her company's tax ID number, or hers? > > > > > In your model, that agency would annually count the number > > of Internet users > > (people, households, businesses, or hosts?) the telco has, > > multiply by some fee, and > > tell ARIN how much to invoice. > > > > That is correct. Providers who routinely report on their > > Internet subscribers > > (connection users) will provide those numbers to ARIN. The > > exact fee amount in a > > particular country is up to the local top level licensee. > > What's a top level licensee? > > > In a case where two > > individuals have invested in a wire connecting their PCs > > accross the street they > > will not be a subject to ARIN fee as long as their private > > network has no access to > > the Internet (that assumes that IP addresses per se are not a > > sellable commodity, they are a common resourse). > > What if one of them sets up community wireless? > > Keep going, I want to understand where this road leads. > > Lee > > > > > Thanks, > > > > Peter > > > > > > --- "Howard, W. Lee" wrote: > > > > > > > > Peter Sherbin > > > > > > > > > The Internet is an electronic version of a global postal > > > > service. As such it should > > > > move to a proper financial model where each delivery is paid > > > > for according to its volume and destination. > > > > > > That would be an exciting billing system! Every packet > > would have to be > > > logged with source address, destination address, and size. Another > > > table > > > to link IP address to billing address. You would bill the packet > > > originator, not the destination? If the originator is not > > a customer, I > > > > > > assume you would bill the peer network who sent the packet > > to you. This > > > implies some significant changes to many network peering > > relationships, > > > and you pretty quickly answer the question of which way > > payment goes. > > > > > > You imply that the current model is improper, but I only > > see analogy to > > > support that implication. How is your model better than > > what we have > > > now? > > > > > > > Here is a proposed model: > > > > PI addresses > > > > > > I don't understand whether you mean every organization should get a > > > provider-independent address block and a telecommunications > > license, or > > > if you mean that only telcos should get PI address space, > > and everybody > > > else must accept assignments from telcos. > > > > > > > RIR invoices every entity with telecommunications licence in > > > > the region a per sibscriber fee to cover admin expenses > > > > Regional issuer of telecom licenses determines the fee amount > > > > as well as makes such > > > > fee a condition of the license (don't mean to regulate the > > > > Internet but please share your comments) > > > > > > I'm not sure where you put large enterprise networks. Distributed > > > offices, > > > multi-homed networks, multi-national presences. I don't know which > > > telco > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From ipgoddess at gmail.com Tue Oct 3 05:58:53 2006 From: ipgoddess at gmail.com (Stacy Taylor) Date: Tue, 3 Oct 2006 02:58:53 -0700 Subject: [ppml] Opposition to 2006-2 v6 internal microallocation In-Reply-To: References: Message-ID: <1c16a4870610030258s61205693rdcd20bb8e7eed944@mail.gmail.com> Hi All, I support this proposal. I believe this is an excellent technical reason for a microallocation that does no harm and only good for our networks and customers. Thanks, Stacy On 10/2/06, Jason Schiller wrote: > I haven't heard a lot of opposition to 2006-2 v6 internal microallocation, > so I would like to invite people to offer any opposing thoughts for > debate. > > Please voice are any new concerns that have not yet been addressed so that > these thoughts can be discussed, and possibly folded into the policy. > > > Thanks, > > ___Jason > > ========================================================================== > Jason Schiller (703)886.6648 > Senior Internet Network Engineer fax:(703)886.0512 > Public IP Global Network Engineering schiller at uu.net > UUNET / Verizon jason.schiller at verizonbusiness.com > > The good news about having an email address that is twice as long is that > it increases traffic on the Internet. > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -- :):) /S From weiler at tislabs.com Tue Oct 3 07:37:19 2006 From: weiler at tislabs.com (Sam Weiler) Date: Tue, 3 Oct 2006 13:37:19 +0200 (CEST) Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <20061003031931.W42164@fledge.watson.org> References: <20061003031931.W42164@fledge.watson.org> Message-ID: J Bacher writes in response to Owen: >> A residential customer should, in all cases, have the option of >> publishing their information as any other >> internet user. The option of hiding residential address is not >> unreasonable, however, at the least, >> city, state, and non-specific postal code should be preserved (5- >> digit ZIP (US), first 3 characters > > This is not reasonable for those in low population dense areas. I concur completely. >> Realistically, more information than this is a matter of public >> record if the customer has registered to vote. I'm not sure why that's relevent. Even if we assume that there's a public record of the names and addresses of everyone in ARIN's service region, that doesn't mean that we have a mapping from IP address to individual or address. We could even assume that everyone's credit report files and medical records were public, yet we wouldn't have the IP address to person (or address) mappings. -- Sam From dsd at servervault.com Tue Oct 3 09:09:47 2006 From: dsd at servervault.com (Divins, David) Date: Tue, 3 Oct 2006 09:09:47 -0400 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: Message-ID: Residential Privacy is great. Now we should extend it to all and have private whois for non-residential customers. -dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Sam Weiler Sent: Tuesday, October 03, 2006 7:37 AM To: J Bacher Cc: PPML Subject: Re: [ppml] Policy Proposal 2006-1: Residential Customer Privacy J Bacher writes in response to Owen: >> A residential customer should, in all cases, have the option of >> publishing their information as any other internet user. The option >> of hiding residential address is not unreasonable, however, at the >> least, city, state, and non-specific postal code should be preserved >> (5- digit ZIP (US), first 3 characters > > This is not reasonable for those in low population dense areas. I concur completely. >> Realistically, more information than this is a matter of public >> record if the customer has registered to vote. I'm not sure why that's relevent. Even if we assume that there's a public record of the names and addresses of everyone in ARIN's service region, that doesn't mean that we have a mapping from IP address to individual or address. We could even assume that everyone's credit report files and medical records were public, yet we wouldn't have the IP address to person (or address) mappings. -- Sam _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From weiler at tislabs.com Tue Oct 3 09:19:59 2006 From: weiler at tislabs.com (Sam Weiler) Date: Tue, 3 Oct 2006 15:19:59 +0200 (CEST) Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: References: <445B9208.9060700@arin.net> Message-ID: I've been rereading the responses to my question: "[is it] appropriate [for the AC] to reject a policy proposal merely because there's a 'better' path for resolving the matter"? First, I appreciate so many of the AC candidates (eight out of ten) responding to my query during this election season. I also appreciate the reminders of the existence of the petition process, which can quickly make the AC's initial rejection of a policy proposal irrelevent. On the other hand, I'm a bit disappointed that it was hard to find a clear and direct answer to the exact question asked in some of the responses. As background, it's been my experience that many items that are (at least arguably) in-scope for the public policy process could also be appropriate to deal with informally (or through the new ACSP). I agree with most of the candidates that, in most cases, the public policy process is clearly a slower, kludgier, and less desirable way of dealing with these issues than the informal processes. On the other hand, the informal routes may not provide the result the community desires. Accordingly, I'd like the see the option of using the public policy process remain available for anything that could possibly be in-scope for that process, even when an informal alternative exists. In the interest of facilitating further discussion, I've included the text of the AC candidates' responses below. -- Sam Owen DeLong It depends in part on how much better said path is, and, on the nature of the path. If there is a more appropriate open public process for a proposal, then, I would have no problem rejecting the proposal with a recommendation that it be submitted, instead, to that process. If the "better" process is not similarly open, I would be unlikely to reject the proposal on that basis alone. Mark Kosters There are proposals that have come in recently that can be argued that are not policy but more focused on new services or process for ARIN operational matters. I've argued that there has been no other way to go forward except through the policy process for things that are member matters (hence my objection that is recorded in section 6 of the Arin AC meeting of May 4): http://www.arin.net/meetings/minutes/ac/ac2006_0504.html I'm very encouraged that there is now an emerging set of processes for non policy matters that the members can bring to ARIN that is a more logical path forward than using the policy process. As far as the the existing process has been defined, I personally like to see the process to be setup more like the policy process with reasonable overrides if there is resistance by leadership within ARIN but wanted by its members.* Michael Lambert I like your use of the term 'metric' in the subject. Assuming that the metric for all the options is in the range [0,1]: If we're talking about 0.92 versus 0.94, I see no reason for the AC to circumvent the public policy process. However, if the options are 0.3 vs 0.8 it's a different matter. BUT, in the latter case, I would hope it is reasonably apparent to the entire community that the full public policy process is not appropriate. It's the middle ground where the AC needs to make thoughtful recommendations. Leo Bicknell I think a large component of the AC's job is community education. It's helping those who are not familiar with the process navigate through it when necessary. If the AC can help the proposer find a better path to resolution I think that makes everyone happy. I'll also point out that we have a petition process, documented in http://www.arin.net/policy/irpep.html. I hope the AC would always be able to provide a path forward that satisfies the author, but if not there is a mechanism to allow the author to move a proposal forward. Andrew Dul The AC is chartered to make the decisions based upon the input from all stakeholder sources. A good example of something that is best addressed outside the public policy process would be issues that are clearly operational in nature. In the past, some issues have been referred to ARIN staff so they can address the issue. In many cases, I believe these issues have been adaquately addressed by ARIN staff. I see no need to overburden the public policy or the Number Resource Policy Manual (NRPM) with operational issues that can best be addressed by the ARIN staff. If ARIN staff has been unresponsive to an issue and a community member feels that the issue still needs to be addressed, the issue could be addressed through the open policy process; in that case the rationale should clearly state the reason why the issue is being submitted to the public policy process. The public policy process does allow a "fallback" option through the petition process. Any AC action can be overridden by the petition process. Stacy Taylor If the AC deems an issue better handled by another path or process, it is its responsibility to forward it on. Robert E.Seastrom I agree with both Stacy and Andrew. Micromanagement of operational issues via the public policy process is not a desirable outcome; unnecessarily constrains ARIN staff and if done too often will result in the NRPM becoming huge and unwieldy. The AC finding that something "can best be addressed by the ARIN Board of Trustees" is completely neutral on the proposal's merits, it's just a suggestion that it is more operational than policy oriented. The ACSP is a new thing, which should eliminate much of the need to use the public policy process to get the attention of ARIN's ops side. I think this represents a step towards goodness and applaud the efforts of ARIN staffers to bring it to fruition. As much as I'd like to put in a suggestion that at least one future ARIN meeting per year ought to take place in an ARIN region country other than the US and Canada, I suppose I'll restrain myself... Aaron Dudek It depends on what it proposal is and whether there is a precidence to follow. Issues on operational policies should be discussed during the membership meeting. If the policy falls into the public domain then I think that the AC should make a recommedation instead of rejecting it. From ipgoddess at gmail.com Tue Oct 3 09:23:15 2006 From: ipgoddess at gmail.com (Stacy Taylor) Date: Tue, 3 Oct 2006 06:23:15 -0700 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: References: <20061003031931.W42164@fledge.watson.org> Message-ID: <1c16a4870610030623g539c8f83j68e7a88a7af17c4a@mail.gmail.com> Hi Sam, If you concur completely, why was this change, that was suggested at the meeting in Montreal, not incorporated into the policy for this policy cycle? The community is at risk of running further cycles on this policy than necessary. Would you be amenable to change policy proposal 2006-1 to incorporate "at the least, city, state, and non-specific postal code should be preserved (5- digit ZIP (US), first 3 characters [I assume a reference to Canada would be here]" Or do I misunderstand with what you are concurring? Stacy On 10/3/06, Sam Weiler wrote: > J Bacher writes in response to Owen: > > >> A residential customer should, in all cases, have the option of > >> publishing their information as any other > >> internet user. The option of hiding residential address is not > >> unreasonable, however, at the least, > >> city, state, and non-specific postal code should be preserved (5- > >> digit ZIP (US), first 3 characters > > > > This is not reasonable for those in low population dense areas. > > I concur completely. > > >> Realistically, more information than this is a matter of public > >> record if the customer has registered to vote. > > I'm not sure why that's relevent. Even if we assume that there's a > public record of the names and addresses of everyone in ARIN's service > region, that doesn't mean that we have a mapping from IP address to > individual or address. We could even assume that everyone's credit > report files and medical records were public, yet we wouldn't have the > IP address to person (or address) mappings. > > -- Sam > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -- :):) /S From ipgoddess at gmail.com Tue Oct 3 09:27:53 2006 From: ipgoddess at gmail.com (Stacy Taylor) Date: Tue, 3 Oct 2006 06:27:53 -0700 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: References: <445B9208.9060700@arin.net> Message-ID: <1c16a4870610030627r7d16e775kd6bf5503b903356f@mail.gmail.com> In case my response was not clear: Yes, it is absolutely appropriate for the AC to forward an issue to the correct path for action. I will also reiterate my objection to the use of the word reject, which I believe is wholly inappropriate to describe the actions the AC took in these specific instances. Stacy On 10/3/06, Sam Weiler wrote: > I've been rereading the responses to my question: "[is it] appropriate > [for the AC] to reject a policy proposal merely because there's a > 'better' path for resolving the matter"? > > First, I appreciate so many of the AC candidates (eight out of ten) > responding to my query during this election season. I also appreciate > the reminders of the existence of the petition process, which can > quickly make the AC's initial rejection of a policy proposal > irrelevent. On the other hand, I'm a bit disappointed that it was > hard to find a clear and direct answer to the exact question asked in > some of the responses. > > As background, it's been my experience that many items that are (at > least arguably) in-scope for the public policy process could also be > appropriate to deal with informally (or through the new ACSP). > > I agree with most of the candidates that, in most cases, the public > policy process is clearly a slower, kludgier, and less desirable way > of dealing with these issues than the informal processes. On the > other hand, the informal routes may not provide the result the > community desires. Accordingly, I'd like the see the option of using > the public policy process remain available for anything that could > possibly be in-scope for that process, even when an informal > alternative exists. > > In the interest of facilitating further discussion, I've included the > text of the AC candidates' responses below. > > -- Sam > > > Owen DeLong > > It depends in part on how much better said path is, and, on the nature > of the path. If there is a more appropriate open public process for a > proposal, then, I would have no problem rejecting the proposal with a > recommendation that it be submitted, instead, to that process. If the > "better" process is not similarly open, I would be unlikely to reject > the proposal on that basis alone. > > Mark Kosters > > There are proposals that have come in recently that can be argued > that are not policy but more focused on new services or process > for ARIN operational matters. I've argued that there has been no > other way to go forward except through the policy process for things > that are member matters (hence my objection that is recorded > in section 6 of the Arin AC meeting of May 4): > http://www.arin.net/meetings/minutes/ac/ac2006_0504.html > > I'm very encouraged that there is now an emerging set of processes for > non policy matters that the members can bring to ARIN that is a more > logical path forward than using the policy process. As far as the the > existing process has been defined, I personally like to see the > process to be setup more like the policy process with reasonable > overrides if there is resistance by leadership within ARIN but wanted > by its members.* > > Michael Lambert > > I like your use of the term 'metric' in the subject. Assuming that > the metric for all the options is in the range [0,1]: If we're talking > about 0.92 versus 0.94, I see no reason for the AC to circumvent the > public policy process. However, if the options are 0.3 vs 0.8 it's a > different matter. BUT, in the latter case, I would hope it is > reasonably apparent to the entire community that the full public > policy process is not appropriate. It's the middle ground where the > AC needs to make thoughtful recommendations. > > Leo Bicknell > > I think a large component of the AC's job is community education. It's > helping those who are not familiar with the process navigate through > it when necessary. If the AC can help the proposer find a better path > to resolution I think that makes everyone happy. > > I'll also point out that we have a petition process, documented in > http://www.arin.net/policy/irpep.html. I hope the AC would always be > able to provide a path forward that satisfies the author, but if not > there is a mechanism to allow the author to move a proposal forward. > > Andrew Dul > > The AC is chartered to make the decisions based upon the input from > all stakeholder sources. A good example of something that is best > addressed outside the public policy process would be issues that are > clearly operational in nature. In the past, some issues have been > referred to ARIN staff so they can address the issue. In many cases, > I believe these issues have been adaquately addressed by ARIN staff. > > I see no need to overburden the public policy or the Number Resource > Policy Manual (NRPM) with operational issues that can best be > addressed by the ARIN staff. If ARIN staff has been unresponsive to > an issue and a community member feels that the issue still needs to be > addressed, the issue could be addressed through the open policy > process; in that case the rationale should clearly state the reason > why the issue is being submitted to the public policy process. > > The public policy process does allow a "fallback" option through the > petition process. Any AC action can be overridden by the petition > process. > > Stacy Taylor > > If the AC deems an issue better handled by another path or process, it > is its responsibility to forward it on. > > Robert E.Seastrom > > I agree with both Stacy and Andrew. Micromanagement of operational > issues via the public policy process is not a desirable outcome; > unnecessarily constrains ARIN staff and if done too often will result > in the NRPM becoming huge and unwieldy. The AC finding that something > "can best be addressed by the ARIN Board of Trustees" is completely > neutral on the proposal's merits, it's just a suggestion that it is > more operational than policy oriented. > > The ACSP is a new thing, which should eliminate much of the need to > use the public policy process to get the attention of ARIN's ops side. > I think this represents a step towards goodness and applaud the > efforts of ARIN staffers to bring it to fruition. > > As much as I'd like to put in a suggestion that at least one future > ARIN meeting per year ought to take place in an ARIN region country > other than the US and Canada, I suppose I'll restrain myself... > > Aaron Dudek > > It depends on what it proposal is and whether there is a precidence to > follow. Issues on operational policies should be discussed during the > membership meeting. If the policy falls into the public domain then I > think that the AC should make a recommedation instead of rejecting it. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -- :):) /S From weiler at tislabs.com Tue Oct 3 09:28:34 2006 From: weiler at tislabs.com (Sam Weiler) Date: Tue, 3 Oct 2006 15:28:34 +0200 (CEST) Subject: [ppml] 2006-1 Residential Privacy Policy In-Reply-To: <20061003031947.S42164@fledge.watson.org> References: <20061003031947.S42164@fledge.watson.org> Message-ID: Martin Hannigan writes: >> - Current Status: Not revised; the author did not desire to change the >> text of the proposal > > Ok. I'll bite. Why not? This seems obtuse considering > all of the feedback provided and the subsequent discussion. As I wrote in April: "...it seems that the main point of contention in 2006-1 (Residential Customer Privacy) is about whether ARIN will continue to get city, state (or province), and postal code or not (or perhaps the objection was merely that the text I proposed is unclear on that question)."[1] Since then, I think we've clarified the meaning of the text (this text doesn't constrain what ARIN could ask for under NDA, it just gives ISPs permission to suppress data from the WHOIS [2]). I also asked ARIN staff to clarify their need for city/state/zip[1]. ARIN's CEO responded: "I will not go into a discussion of how often or under which circumstances it is specifically used, but will say that it is necessary information needed by staff to perform their work."[3] Absent more detail from the staff, I continue to believe that this policy won't cause ARIN any operational problems that can't be easily worked around (perhaps with an NDA'd disclosure). So I think we've made progress on the main point of contention, and that progress doesn't suggest to me that the text needs to change. Accordingly, I left the text untouched. -- Sam [1] http://lists.arin.net/pipermail/ppml/2006-April/005330.html [2] http://lists.arin.net/pipermail/ppml/2006-April/005340.html [3] http://lists.arin.net/pipermail/ppml/2006-April/005331.html From weiler at tislabs.com Tue Oct 3 09:32:37 2006 From: weiler at tislabs.com (Sam Weiler) Date: Tue, 3 Oct 2006 15:32:37 +0200 (CEST) Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: <1c16a4870610030623g539c8f83j68e7a88a7af17c4a@mail.gmail.com> References: <20061003031931.W42164@fledge.watson.org> <1c16a4870610030623g539c8f83j68e7a88a7af17c4a@mail.gmail.com> Message-ID: On Tue, 3 Oct 2006, Stacy Taylor wrote: > If you concur completely, why was this change, that was suggested at > the meeting in Montreal, not incorporated into the policy for this > policy cycle? The community is at risk of running further cycles on > this policy than necessary. > > Would you be amenable to change policy proposal 2006-1 to incorporate > "at the least, city, state, and non-specific postal code should be > preserved (5- digit ZIP (US), first 3 characters [I assume a reference > to Canada would be here]" No. > Or do I misunderstand with what you are concurring? I think you misunderstood -- I concur with J. Backer that publishing city/state/postal code does not offer a reasonable level of privacy protection for those in small areas, which tend to be areas of low population density. My perception was that most (certainly not all, but most) of the opposition to 2006-1 voiced in Montreal was about ARIN's operational needs not being met -- I think we had a rough consensus that doing some partial-postal-code thing was not such a good idea. My previous post talks about bit more about the operational concerns raised by ARIN staff. -- Sam From Ed.Lewis at neustar.biz Tue Oct 3 12:02:59 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 3 Oct 2006 18:02:59 +0200 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: References: <445B9208.9060700@arin.net> Message-ID: At 15:19 +0200 10/3/06, Sam Weiler wrote: >I agree with most of the candidates that, in most cases, the public >policy process is clearly a slower, kludgier, and less desirable way >of dealing with these issues than the informal processes. On the >other hand, the informal routes may not provide the result the >community desires. Accordingly, I'd like the see the option of using >the public policy process remain available for anything that could >possibly be in-scope for that process, even when an informal >alternative exists. The public policy process referred to above is not the real name of the process, the formal name is "Internet Resource Policy Evaluation Process (IRPEP)." The Advisory Council (AC) plays a role in that process. If a change to the Number Resource Policy Manual (NRPM) is required, the IRPEP is what is to be followed. Kludgy and slow is in the eye of the beholder - due diligence may require that. Less desirable implies that there is another process - and there isn't. There is no informal route towards a change to the NRPM. If there were, ARIN would be in trouble with people with different expertise than I. I suspect that this thread begun over the Registration Services Agreement complaint. The RSA is not an Internet resource, hence modifications to it is not subject to the IRPEP. The AC was correct in, for lack of a better term, "bouncing" any proposal to alter the RSA. Over the past few years there has been a call to allow comments from the public and membership on ARIN's performance of its duties. The ARIN Consultation and Suggestion Process (ACSP) is the current vehicle for that. "Current" as this is a new process and has yet to prove itself over time. There is no choice to be made. Changes to the NRPM undergo the IRPEP, which may involve the AC. ("May" refers to the exceptions for emergency changes.) Changes to the way ARIN (and it's staff) carry out the duties of ARIN now go through the ACSP. To drop back into history a moment...at the ARIN meeting in October, 2004, in Reston, BoT member Scott Bradner scolded us for talking about "IPs" and not "Internet Addresses." Although the comment seemed rather pedantic at the moment, the use of colloquialisms is quite possibly the root cause of why these misunderstandings arise. When I began to prepare this message I wondered if there was a clear delineation of what issues went to the AC. Having been on staff (but separate from the IRPEP) and now a member representing an organization, it wasn't until I "dug" up the formal names for the processes and now I see clearly that there is a delineation. Perhaps we need to be ever more formal as more and more newcomers arrive at the meetings so we don't fall into these kinds of diversions. In short, Scott is right. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From sandy at tislabs.com Tue Oct 3 13:03:32 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Tue, 3 Oct 2006 13:03:32 -0400 (EDT) Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: Message-ID: <20061003170332.11B043F425@pecan.tislabs.com> >If a change to the Number Resource Policy Manual (NRPM) is required, >the IRPEP is what is to be followed. True. But is the converse true as well? That is, is the IRPEP restricted to considering ONLY changes to the NRPM? I see text that says: Policies are documented community decisions that determine the rules by which Internet numbering resources are managed and administered by ARIN. It is important that policies be distinctly separated from activities that are considered to be general practices and procedures of ARIN. This does not specifically say that only changes to the NRPM are policies. And there was ample opportunity for those who crafted this language to say exactly that. I presume that means that those who crafted this language did not mean to limit policies to changes to the NRPM. I would say that "you must sign this RSA" is a rule by which ARIN manages and administers number resources, i.e., a policy that the membership could change in the IRPEP, rather than an activity considered to be general practice and procedure. You may interpret this differently. But is there anywhere that specifically says that *only* NPRM changes are subject to the IRPEP? --Sandy From Ed.Lewis at neustar.biz Wed Oct 4 03:21:07 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 4 Oct 2006 09:21:07 +0200 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: <20061003170332.11B043F425@pecan.tislabs.com> References: <20061003170332.11B043F425@pecan.tislabs.com> Message-ID: At 13:03 -0400 10/3/06, Sandy Murphy wrote: >>If a change to the Number Resource Policy Manual (NRPM) is required, >>the IRPEP is what is to be followed. > >True. But is the converse true as well? That is, is the IRPEP restricted >to considering ONLY changes to the NRPM? > >I see text that says: > >Policies are documented community decisions that determine the rules >by which Internet numbering resources are managed and administered by ARIN. >It is important that policies be distinctly separated from activities that >are considered to be general practices and procedures of ARIN. Keep in mind that I'm not an expert in this area. Being an engineer, I'm not trained in the kind of logic best used for such questions. >This does not specifically say that only changes to the NRPM are policies. >And there was ample opportunity for those who crafted this language to >say exactly that. I presume that means that those who crafted this >language did not mean to limit policies to changes to the NRPM. Part of my gut reaction is that English is not C - English is not as precise. Another is that the people that crafted this (I assume) were more attuned to engineering than law. The maintainers certainly are. Finally, "policies" aren't the subject for what is handed to the AC, it's "Internet resource policies." You'd get a better answer from a BoT member or the legal council for ARIN. I just sit in the back of the room at meetings twice a year. (And snipe on the list.) >I would say that "you must sign this RSA" is a rule by which ARIN >manages and administers number resources, i.e., a policy that the membership >could change in the IRPEP, rather than an activity considered to be >general practice and procedure. The RSA is a billing matter, a membership matter. You may recall an earlier thread in which Sam protested the RSA, I replied that the RSA is under control of the membership proxied by the BoT. A BoT member replied I was wrong about that. It turns out that the BoT member was wrong. I learned this by addressing questions directly to the staff for clarification. One thing to keep in mind - the "Open Policy Meeting" is where policies are discussed and is part of the IRPEP. Anyone can attend. The "Members Meeting" follows the next day and is where other matters are discussed, including the budget, staff activity, and the update on the IRPEP. The same happens in the other RIRs I attend. >You may interpret this differently. But is there anywhere that specifically >says that *only* NPRM changes are subject to the IRPEP? Not that I know of. But maybe that question ought to be asked of ARIN. Sam's inference that there is an informal process that is an alternative to the formally defined and documented process is definitely wrong (even if that is just what he concluded from the answers from the AC). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From weiler at tislabs.com Wed Oct 4 03:43:54 2006 From: weiler at tislabs.com (Sam Weiler) Date: Wed, 4 Oct 2006 09:43:54 +0200 (CEST) Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: References: <445B9208.9060700@arin.net> Message-ID: On Tue, 3 Oct 2006, Edward Lewis wrote: > There is no choice to be made. Changes to the NRPM undergo the > IRPEP, which may involve the AC. ("May" refers to the exceptions for > emergency changes.) Changes to the way ARIN (and it's staff) carry > out the duties of ARIN now go through the ACSP. Ed, I admire your ability to see things in such black and white terms. I don't. When the NRPM already deals with a particular matter, yes, the IRPEP is needed to change it. When it doesn't, the path is less clear. Here are some particular examples of changes that I think could (arguably, at least) be handled through either the IRPEP or outside it: -- 2006-6. This has already been addressed outside of the IRPEP. -- 2006-3. It appears that staff can modify the templates to do this even without specific direction from the IRPEP. -- 2006-1. Had there been broad agreement with my interpretation of 2003-3, staff could have made that clarification without needing the proposal -- arguably, we don't even need to change the NRPM. -- The RSA Modification procedure and Requirement for Reasonable Contract Terms proposals: the proponents thought these were appropriate for the IRPEP, but they were addressed (in some fashion), by the staff/board. I continue to believe that significant hurdles to getting resources are within scope for the IRPEP, and the RSA certainly counts as such a hurdle. -- 2003-7. The policy proposal was abandoned, but ARIN seems to be doing this now. So, again, while I agree that the IRPEP is needed to change the NRPM, remember that the NRPM "... is only a reformatting of existing policy statements,"[1] and it is often ambiguous as to whether a change in a process that isn't already mandated in the NRPM needs to be adopted through such a policy or could be adopted by the board/staff on its own initiative. -- Sam [1] http://www.arin.net/meetings/minutes/bot/bot2004_0929.html From Michael.Dillon at btradianz.com Wed Oct 4 07:41:01 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 4 Oct 2006 12:41:01 +0100 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy In-Reply-To: Message-ID: > My perception was that most (certainly not all, but most) of the > opposition to 2006-1 voiced in Montreal was about ARIN's operational > needs not being met -- I think we had a rough consensus that doing > some partial-postal-code thing was not such a good idea. My previous > post talks about bit more about the operational concerns raised by > ARIN staff. This is the bit that confuses me. Why is a policy proposal messing around with ARIN's operational model? Clearly, ARIN has a need for detailled address utilization information in order to perform its basic functions. And ARIN is ready and willing to sign an NDA with any applicant who has concerns about the sensitivity of the data that they submit. They even operate a Chinese wall internally so that, for instance, managers do not have access to this data. Applicants regularly submit detailed network diagrams and maps, purchase orders, client lists, inventory records, spreadsheets, databases and all manner of information to show that they are indeed building out a network of the magnitude that will justify the number of addresses they are requesting. Or to show that they really did use up the addresses that they got. This policy suggests changing a section of policy that applies only to ISPs. It obfuscates this behind the NPRM section number 4.2.3.7.6 which refers to IPV4, Allocations to ISPs, Reassigning Address Space to Customers, Reassignment Information, Residential Customer Privacy. If you examine the NPRM you will notice that there is another section entitled Directory Services that deals with some aspects of whois data. Then, going to 4.2.3.7 you will see that it *MIXES TOGETHER* references to the data needed by ARIN operationaly and the data published by Directory Services using whois and rwhois protocol. To begin with, this is bad, bad policy. It is confusing to read, mixes up internal operational issues with external public policy issues, and it does not have any published rationale for its existence. Secondly, picking nits with bad policy, such as is done in proposal 2006-1, is not the way to fix this thing. It only adds to the confusion because different sets of edits to this confusing section are made based on different basic premises. http://www.arin.net/policy/proposals/2006_1.html Nevertheless, I would vote in support of this policy change because it does allow the entire address to be suppressed and that is a good thing. I would hope that any ARIN members assigning to residential sites already suppress the address anyway regardless of the flawed policy. But, we need to go much further than this. To start with, any ARIN operational needs must be separated from Directory Services. Then, we need to define a clear scope for Directory Services. It is widely known that the whole model is broken and has been broken since the advent of the commercial Internet over 10 years ago. We need an up to date definition for the scope and purpose of ARIN's whois directory service. It needs to specifically meet the needs of network operations people and nothing more. In particular, ARIN is not obliged to support vigilante groups, private investigators, stalkers, or even law enforcement in its published whois directory. If law enforcement needs data, they can always get it under subpoena wherever it may be whether in ARIN's hands or an ISP's. If we go back to network operational realities, the main requirement for a whois directory is so that when network problems occur, for whatever reason, a netops person can contact a responsible person in another organization's network operations department. To that end, it makes sense to only publish information for those people who voluntarily request it with one exception, that any organization receiving an ARIN allocation MUST publish at least one working contact point. --Michael Dillon From sandy at tislabs.com Wed Oct 4 09:33:05 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Wed, 4 Oct 2006 09:33:05 -0400 (EDT) Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: Message-ID: <20061004133305.6E3EE3F507@pecan.tislabs.com> Ed Lewis said: >Part of my gut reaction is that English is not C - English is not as >precise. But your email suggested that strict adherence to terminology is a good thing. So I'm strictly adhering. --Sandy From info at arin.net Wed Oct 4 17:34:58 2006 From: info at arin.net (Member Services) Date: Wed, 04 Oct 2006 17:34:58 -0400 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-1 Message-ID: <45242902.4000409@arin.net> These are the ARIN staff comments regarding Policy Proposal 2006-1: Residential Customer Privacy. These comments include those of the ARIN General Counsel and ARIN staff, and contain analysis of legal, procedural, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of this proposal may necessitate further analysis by Counsel and staff. Policy Proposal 2006-1 restated below and available at: http://www.arin.net/policy/proposals/2006_1.html. This policy calls for the suppression of certain items of information regarding customers of organizations that receive allocations of Internet number resources from ARIN. The ARIN General Counsel sees no liability risk for ARIN but has some concerns. Counsel states: "However, this type of policy may have a series of impacts in different portions of the Internet community. Let me give a single example: Law enforcement authorities have a desire for real time ability to obtain information of the type that will now be masked. This may increase the burden on ISP's who must be correspondingly contacted more often to obtain such information. The government's might wish a different policy. Issues of customer privacy and how ARIN's policies impact such issues remains an area of ongoing legal concern and attention." ARIN staff concerns relate to whether or not this policy is interpreted to mean suppression of information that is collected as opposed to suppression of information that is available to the general public. ARIN has a stringent non disclosure policy concerning the protecting of information. Such non disclosure can be applied to any information that is to be suppressed from access by the general public. Staff calls to the attention of the community the effect of the suppression of information from the general public that is currently used by those who use this data in research. This data would have a diminished value as the use of a term such as "private residence" or "private customer" may not necessarily reflect the accurate distribution of the address space by the customers of ARIN. The community may want to consider further definition of these terms to provide clarity to the research community. If on the other hand this policy would permit the suppression of information being presented to ARIN, staff has additional concerns to those described above. These concerns relate to the ability of ARIN to verify the validity of the information as it is reported by the customers of ARIN as required by current policy. It would be easier for less than scrupulous organizations when reporting utilization information of the address space entrusted to them to hide or otherwise provide false information such as substituting "private residence" when in fact the information relates to a business. This impacts ARIN's ability to exercise the stewardship role that has been entrusted to it by the community. If adopted this policy replaces policy text in sections 4.2.3.7.6 and 6.5.5.1 as well as remove the words "that includes displaying only the city, state, zip code, and country" from section 3.2. The resource impact of implementing this policy is viewed as moderate. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Changes to the current software suite - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-1: Residential Customer Privacy Policy statement Proposal type: modify (NRPM sections 4.2.3.7.6 and 6.5.5.1) Policy Term: permanent An organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private customer - XYZ Network', and the customer's entire address may be replaced with 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. NRPM Section 3.2 on Distributed Information Server Use Requirements (from policy proposal 2003-5) is also updated by striking the words "that includes displaying only the city, state, zip code, and country". Policy Rationale This policy allows for a residential customer's entire physical address to be suppressed, not just the street name and number. It also removes the US-centric phrases "state" and "zip code" from the NRPM, reflecting ARIN's broader service area. In many cases, a postal code or even a city name can identify few enough individuals, particularly considering the set of those likely to have their own IP assignments, that the intent of policy proposal 2003-3 is constructively defeated. Timetable for implementation: Immediately upon approval. From info at arin.net Wed Oct 4 17:35:17 2006 From: info at arin.net (Member Services) Date: Wed, 04 Oct 2006 17:35:17 -0400 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-2 Message-ID: <45242915.403@arin.net> These are ARIN staff comments regarding Policy Proposal 2006-2: Micro-allocations for Internal infrastructure. These comments include those of the ARIN General Counsel and ARIN staff, and contain analysis of legal, procedural, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of this proposal may necessitate further analysis by Counsel and staff. Policy Proposal 2006-2 restated below and available at: http://www.arin.net/policy/proposals/2006_2.html. This policy provides for organizations using only a single aggregate requiring additional noncontiguous IP space for their internal infrastructure not to be routed in the global Internet routine table. The ARIN General Counsel sees no liability risk for ARIN. ARIN staff believes the policy is not entirely clear. Specifically, the term 'justification' is broad and requires further definition. ARIN cannot verify the blocks allocated under this policy are not routed. In the event that these blocks are routed, staff proposes revoking the number resources. This policy appears to be directed towards allocations, the community may want to consider further definition of this policy regarding end user assignments to provide clarity on this point. If adopted this policy statement will be inserted into a new section numbered 6.10.2. The existing policy text under 6.10 will be renumbered to 6.10.1. The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure Policy statement Proposal type: modify Policy term: permanent Policy statement: 6.10.1 Micro-allocations for Internal Infrastructure Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide technical justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations must be allocated from specific blocks reserved only for this purpose. Policy Rationale Organizations that have only a single aggregate may require additional noncontiguous IP space for their internal infrastructure. This space should not be routed in the global Internet routing table. This will provide for the protection of internal infrastructure and support for applications that are sensitive to long convergence times like VoIP. It is important to note that the additional prefix allocation will not negatively impact the global routing table size as the additional prefix should not be routed. BGP Re-Convergence ISPs use BGP to originate their aggregate from multiple nodes within their infrastructure. They do this by routing their aggregate to discard on multiple devices. This ensures the Internet can reach the aggregate even when one or more nodes fail. If the next hop for a route is reachable via an aggregate that is in the routing table, then failures affecting the reachability of the next hop are subject to BGP hold timers, which can cause traffic to be dropped for the length of the bgp hold time (typically 3 minutes) The BGP re-convergence problem results when a multi-homed customer is announcing the same route to two different edge routers. When the edge router sourcing the primary path fails, the local address which is acting as the next hop, is removed from the IGP. If the next hop is still reachable through an aggregate or covering route, then the route will not be immediately invalidated in bgp. Until the bgp session with the failed device times out, traffic will be drawn to the device originating the aggregate, which is routed to discard and traffic will be dropped. After the bgp session with the failed device times out, the route will be removed and the next best route will be used. To minimize route failover time, you must ensure that the local addresses of the infrastructure, that act as next-hops for Internet routes, are NOT numbered with addresses that are a more specific than the aggregate. A detailed description of the problem space follows in the next three paragraphs. Having BGP next-hops that are not aggregated can cause faster convergence for customers who have multiple links to multiple routers of a single upstream AS. Take the case where a customer has two connections, link1 to edge-router1 and link2 to edge-router2, to a single upstream AS. The customer has an eBGP session with the loopback 2001:DB8::1/128 on edge-router1 and with loopback 2001:DB8::2/128 on edge-router2. The customer advertises a single prefix 2001:DB8:1000::/48 to both edge-router1 and edge-router2. The edge routers set next-hop self. The upstream ISP will have two paths to the prefix 2001:DB8:1000::/48, one with a protocol next-hop of 2001:DB8::1 and one with a protocol next-hop of 2001:DB8::2. Assume the upstream ISP's entire network prefers the path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 due to lower BGP MED value. Also assume that all of the address space owned by the upstream ISP is 2001:DB8::/32, and the loopbacks of both edge routers are a more specific of the aggregate /32. The upstream ISP has a pull-up route for 2001:DB8::/32 in the core of the network. This allows for the aggregation of all the more specific routes of 2001:DB8::/32. It insures the stability of the 2001:DB8::/32 announcement, while preventing an isolated edge router from advertising reachability to the network. If edge-router1 fails then 2001:DB8::1/128 will be immediately removed from the IGP. The preferred prefix for 2001:DB8:1000::/48 with a next-hop of 2001:DB8::1 will remain a valid bgp route and will continue to be the best path because 2001:DB8::1 is reachable through the pull-up route 2001:DB8::/32. Traffic will get blackholed for up to three minutes (BGP default hold time) until the BGP prefix 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 times out. Only then will traffic get forwarded to the next best path for 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::2. If instead the loopbacks of the edge routers (or any BGP protocol next-hop addresses) are not part of the 2001:DB8::/32 aggregate, and there is no aggregate that covers the edge router loopbacks, then convergence will be much quicker. Assume that edge-router1 is using 2001:408::1 and edge-router2 is using 2001:408::2, and the only pull-up route is 2001:DB8::/32. In this case once edge-router1 fails, the IGP will detect it and remove 2001:408::1/128 from the IGP. This will invalidate the preferred path to 201:DB8:1000::/48 with a protocol next-hop of 2001:408:1 as there will be no route to the next hop (or even a less specific of this address). Once the path is invalidated, then the next best path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:408::2 will be declared best. Convergence times will be on the order of magnitude of the IGP failure detection and path re-calculation, typically less than one second. --------------- | Core Router |static route | |2001:DB8::/32 discard ----+------+--- | | / \ /-------------/ \--------\ / \ / /----------------------------\ \ | | | | ------+---+-- --+---+------ |Core Router|static route |Core Router|static route | |2001:DB8::/32 discard | |2001:DB8::/32 discard ---------+--- ---------+--- | | ---------+--------- ---------+--------- | edge-router1 | | edge-router2 | | 2001:DB8::1/128 | | 2001:DB8::2/128 | ---------+--------- ---------+--------- | | \ link1 link2 / \------------\ /---------/ \ / | | ----+---------+---- | CPE | | | ---------+--------- | LAN 2001:DB8:1000::/48 Internal Infrastructure Security Considerations Internal infrastructure could be numbered out of space that is not routed or reachable by the public Internet. This could be used to secure internal only services in a multi-layered approach by filtering direct network connections in the forwarding plane, and not routing the network in the global Internet routing table. Internal services which could take advantage of these layers of protection include: SNMP services, iBGP mesh, Out-of-Band management network(s), remote access to the network devices that make up the network in question. A layered security approach will help to prevent breaches in security via singular config management problems. Additionally, having all of the services out of an aggregate block will simplify the configuration management situation. In essence, this allows for a two tier approach of protecting infrastructure, both in the control plane by not routing the network, and in the forwarding plane by utilizing packet filters which are easily constructed and managed due to the uniqueness of the internal infrastructure block. Private Address Considerations Private addresses are not appropriate for a number of reasons. A public Internet network using private addresses internally may create confusion if trace routes contain private addresses. Additional problems may result due to wide spread filtering of private address space. ICMP messages may get dropped due to such a policy. This can lead to perceived odd behavior and make troubleshooting difficult. Additionally, the consequences of accidentally routing private ip space that is not globally unique, are potentially worse than if you accidentally announced globally unique space. DNS for private address space is today provided by blackhole-1.iana.org. and blackhole-2.iana.org. A provider who wants to maintain forward and reverse DNS sanity has to hijack those ip addresses to provide consistent DNS resolution. This will cause any users who's traffic transits that provider's network to also get 'inconsistent' answers with respect to the private address space in question. For management and troubleshooting purposes, it is important that infrastructure which provides Internet route reachability be numbered with addresses that resolve through DNS. Also, global uniqueness of addressing is important in minimizing renumbering efforts as organizations (and their networks) merge. RFC 4193 provides for neither of these needs. Timetable for implementation: Immediate From info at arin.net Wed Oct 4 17:35:29 2006 From: info at arin.net (Member Services) Date: Wed, 04 Oct 2006 17:35:29 -0400 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 Message-ID: <45242921.7020106@arin.net> These are the ARIN staff comments regarding Policy Proposal 2006-3: Capturing Originations in Templates. These comments include those of the ARIN General Counsel and ARIN staff, and contain analysis of legal, procedural, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of this proposal may necessitate further analysis by Counsel and staff. Policy Proposal 2006-3 restated below and available at: http://www.arin.net/policy/proposals/2006_3.html. This policy provides for capture and publicly available mapping of authorized prefix originations by ASNs. The ARIN General Counsel sees no liability risk for ARIN. ARIN staff believes the policy is not entirely clear. Specifically the term "user" could apply to both direct registrants as well as reassignments and needs further definition. The policy duplicates capabilities of the routing registry and could be addressed by enhancing this existing functionality. If adopted the policy statement will be inserted into a new section numbered 3.5. The resource impact of implementing this policy is significant. Barring any unforeseen resource requirements, this policy could be implemented within 3-6 months from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Template change - Revision to Registration Software - Revision to Directory Services - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-3: Capturing Originations in Templates Policy statement Proposal type: new Policy term: permanent Policy statement: ARIN will collect an optional field in all IPv4 and IPv6 address block transactions (allocation and assignment requests, reallocation and reassignment actions, transfer and experimental requests). This additional field will be used to record a list of the ASes that the user permits to originate address prefixes within the address block. ARIN will produce a collection of the mappings from address blocks to ASes permitted to originate that address block, The collection will consist of a list where each entry will consist, at a minimum, of an address block, a list of AS numbers, and a tag indicating the type of delegation of the address block. This collection will be produced at least daily. ARIN will make the collected mappings from address blocks to AS numbers available for bulk transfer in one or more formats chosen at its own discretion, informed by the community's current needs. This data will not be subject to any redistribution restrictions -- it may be republished or repackaged it any form. Should ARIN choose to use WHOIS bulk transfer as the bulk form of data access required by this paragraph, the address block to AS mappings will not be subject to any redistribution restrictions, but the remainder of the WHOIS data will remain subject to the terms of the then-current AUP regarding bulk access to WHOIS data. ARIN may also make the collected or individual mappings from address blocks to AS numbers available in other forms, possibly query services, chosen at its own discretion, informed by the community's current needs. ARIN may require agreement to an acceptable use policy for access to the data in these forms. Policy Rationale Origination of prefixes by ASes that have no authority for the origination is a recurring problem in the Internet routing system. A list of authorized prefix originations would be beneficial to operators in * constructing routing filter lists to counter bogus originations, * interacting with customers requesting routing of a prefix, and * diagnosing routing problems. A list of authorized prefix originations is also the necessary first step for any known solution for securing the routing system. Prefix originations can be stored in routing registry RPSL route objects. However, the authority for addresses and for ASes belongs to the RIRs. There is presently no mechanism to translate ARIN's authority for number resources to an IRR. Furthermore, operators have been less than diligent in creating and maintaining route objects. Capturing the prefix origination authorization in number resource registrations with ARIN has two main goals: * benefit from the scrutiny with which ARIN verifies initial requests and authenticates subsequent transactions, and * inherit the operators' self-discipline in completing resource requests and transactions. As an additional benefit, this could take a step toward populating the IRR with data known to be accurate. The intended use of this data means that both query for individual entries and bulk access to a list of the collected entries, without restriction on redistribution, is required. This policy requires that the additional data be provided through the usual whois query service and some bulk access service that has no restrictions. It permits ARIN to provide the bulk access through the existing bulk whois service if the new additional data is not subject to the bulk whois AUP restrictions. The policy does not limit ARIN to providing only those two services (whois query and unrestricted bulk access); other additional services may be developed at ARIN's discretion. It is expected that entries in the list of collected entries will include at a minimum the present NetRange and NetType attributes, with a new attribute, perhaps named OriginatingASList, for the list of permitted originating ASes. This policy will presumably be incorporated into NRPM section 3.4. Timetable for implementation: Within sixty (60) days of approval. From william at elan.net Wed Oct 4 18:21:04 2006 From: william at elan.net (william(at)elan.net) Date: Wed, 4 Oct 2006 15:21:04 -0700 (PDT) Subject: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) Message-ID: I'd like to make additional comment regarding 2006-1 and potentially offering a way to a solution that solves the issues but does not cause as many problems and changes with ARIN system. As a reminder a primary justification for introducing this seems to be that full ZIP codes (6 code in Canada or full 9 digit code in US) and city is in some cases are too specific and is almost the same as offering full street address. The primary concerns seems to be about those living in rural areas where the the density is very low. Regarding zip/postal codes - a solution was proposed to only require partial (minimum 3-letter) code rather then full zip/postal code. I think many others have already shown that this would solve any potential privacy concerns as 3-letter codes are not specific enough (in fact for US even 5 letter code is not specific - zip codes follow density as well so rural territories have very large areas covered by same zipcode). Regarding city this is indeed an issue for rural areas where city may include only a dozen households (in many states they would not even allow to incorporate in this case). I agree that this needs to be addressed and there is actually a very simple solution by allowing County name to be entered in case this is unincorporated area (which is in fact exactly what is being done right now) as well as if the city itself is smaller then say 1000 residents - we can even do it by just renaming "city" field to "city/locality" and leaving it to the discretion of the ISP if the are entering actual city name there or name of local territorial unit (township, borrough, county, etc) if user has privacy concerns. I also would like to note a concern that privacy issues effecting very few users in rural areas (<0.1%) are considered for changes that would cause data not be available for the reminder 99.9%. As you know if you make something optional many just not do it at all even if its not a problem for their case. The solution for this really should be the one that addresses specific issues with those 0.1% where current privacy policy would not be enough. In short this issue needs to be looked at further by the AC but the current proposal should be rejected. -- William Leibzon Elan Networks william at elan.net From Ed.Lewis at neustar.biz Thu Oct 5 04:32:49 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 5 Oct 2006 10:32:49 +0200 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: <20061004133305.6E3EE3F507@pecan.tislabs.com> References: <20061004133305.6E3EE3F507@pecan.tislabs.com> Message-ID: At 9:33 -0400 10/4/06, Sandy Murphy wrote: >Ed Lewis said: > >>Part of my gut reaction is that English is not C - English is not as >>precise. > >But your email suggested that strict adherence to terminology is a good >thing. So I'm strictly adhering. The processes surrounding the Internet are evolving. As the Internet has moved from being an experiment to a utility the focus has changed. Words written (say) 10 years ago assumed more context than is needed now. 10 years ago, there was a lot more homogeneity in the community, we "spoke the same language." And that language was C.) Nowadays, the chance that the latest member speaks the same language is lower (not just Python, but business, legal, etc.). This is why I emphasized Scott Bradner's point of two years ago ("no IPs, Internet Addresses!") as important to us now. Those of us who have been around a long time need to be mindful that we need to step up our use of formal terms so as to not confuse the newcomers. This isn't unique to ARIN. I see it in where I've done more work - the IETF. The original specifications for DNS (RFC 1034, 1035) were good enough then to start the system but today wouldn't be good enough for a draft. More recent RFCs on DNS have increasingly formal language. It's all part of the evolution of the Internet. It's an evolution that isn't taught in engineering school. The lack of formality in the past has opened the system up for abuse. Abuse is never good. We can either accept it or defend against it by modifying the words and processes. That is what happens in the real world, it needs to happen here. But is needs to happen appropriately. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From iljitsch at muada.com Thu Oct 5 06:14:50 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 5 Oct 2006 12:14:50 +0200 Subject: [ppml] Fwd: Keeping in reserve References: Message-ID: Hi, I understand that ARIN wants to give out /48s for PI but reserve a / 44. That's a bad idea, see the message below about this that I sent to the RIPE address policy list. Begin forwarded message: > History, both in IPv4 and IPv6, has shown that keeping space in > reserve to accommodate future request doesn't work very well: > people often end up announcing several blocks anyway. So let's not > waste the space and make filtering harder by doing this. Also, > since a /48 is an incredible amount of space to begin with, coming > back for more should be rare in IPv6. > The advantage of only giving out /48s with no unused space between > them is that if, for instance, 12000 /48s are given out, that will > be from a single /34 and allowing /48s from a /34 allows 16384 > routes, while allowing /48s from a /20 (because for every /48 of > 12000 a /32 is kept in reserve) allows 268 million routes, more > than enough to overload any reasonable routing system in an attack. From Michael.Dillon at btradianz.com Thu Oct 5 07:05:49 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 5 Oct 2006 12:05:49 +0100 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-1 In-Reply-To: <45242902.4000409@arin.net> Message-ID: > Staff calls to > the attention of the community the effect of the suppression of > information from the general public that is currently used by those who > use this data in research. This data would have a diminished value as > the use of a term such as "private residence" or "private customer" may > not necessarily reflect the accurate distribution of the address space > by the customers of ARIN. The community may want to consider further > definition of these terms to provide clarity to the research community. Clarification is good. In my opinion, there is no legitimate and justifiable requirement to provide any data whatsoever to the research community that is not also provided to the general public. This goes back to the fact that ARIN publishes a whois directory simply because it is "traditional" to do so. The tradition arose out of the need of ARPANET administrators to record users of the ARPANET in order to justify the expenditure of funds. I would welcome a clear definition that describes the purpose and scope of the whois directory. Potentially such a definition of scope could include some of the needs of researchers. Two years ago I made an attempt at such a definition with this policy proposal: http://www.arin.net/policy/proposals/2004_4.html If you read sentence 7 and item (i) in the rationale on that page then that shows how the whois directory could contain information to support research while still maintaining privacy. > If on the other hand this policy would permit the suppression of > information being presented to ARIN, staff has additional concerns to > those described above. Good example of the ambiguity of current policy. This needs to be fixed so that the operational need for information is handled entirely separately from the definition of which information is collected for the express purpose of publishing it. I suggest that the staff and trustees should think about how to define which bits of the current policy could be removed because they really belong in some definiton of ARIN services and practices. Now that there is this new process http://www.arin.net/about_us/corp_docs/acsp.html to drive needed changes in ARIN services and practices, there is no need for ARIN policy to contain these grey areas. --Michael Dillon From Michael.Dillon at btradianz.com Thu Oct 5 07:10:26 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 5 Oct 2006 12:10:26 +0100 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <45242921.7020106@arin.net> Message-ID: > The policy duplicates > capabilities of the routing registry and could be addressed by enhancing > this existing functionality. This is a very important observation. I would rather see a policy that defines the purpose and scope of ARIN's routing registry. That policy could include text like the following: > ARIN will collect an optional field in all IPv4 and IPv6 address block > transactions (allocation and assignment requests, reallocation and > reassignment actions, transfer and experimental requests). This > additional field will be used to record a list of the ASes that the user > permits to originate address prefixes within the address block. --Michael Dillon From Ed.Lewis at neustar.biz Thu Oct 5 08:15:32 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 5 Oct 2006 14:15:32 +0200 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: References: Message-ID: At 12:10 +0100 10/5/06, Michael.Dillon at btradianz.com wrote: >> The policy duplicates >> capabilities of the routing registry and could be addressed by enhancing >> this existing functionality. > >This is a very important observation. I would rather I certainly agree with that. "The" routing registry or "a" routing registry? >see a policy that defines the purpose and scope of >ARIN's routing registry. That policy could include >text like the following: > >> ARIN will collect an optional field in all IPv4 and IPv6 address block >> transactions (allocation and assignment requests, reallocation and >> reassignment actions, transfer and experimental requests). This >> additional field will be used to record a list of the ASes that the user >> permits to originate address prefixes within the address block. Will ARIN need to process (more/new) templates to permit updates to the information? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From Ed.Lewis at neustar.biz Thu Oct 5 08:16:46 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 5 Oct 2006 14:16:46 +0200 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-1 In-Reply-To: References: Message-ID: At 12:05 +0100 10/5/06, Michael.Dillon at btradianz.com wrote: >I would welcome a clear definition that describes >the purpose and scope of the whois directory. Potentially Me too. I applaud Leo's attempt over the past few years, even if he eventually pulled the work from the table. We need it, and/but it's a lot of work. >> If on the other hand this policy would permit the suppression of >> information being presented to ARIN, staff has additional concerns to >> those described above. > >Good example of the ambiguity of current policy. >This needs to be fixed so that the operational need >for information is handled entirely separately from >the definition of which information is collected for >the express purpose of publishing it. Until seeing this clarification from the staff, I hadn't thought deeply enough about the issue. The data ought to go in, regardless. But the current proposed change does not address this. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From sandy at tislabs.com Thu Oct 5 08:41:21 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 08:41:21 -0400 (EDT) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: Message-ID: <20061005124121.2A8E83F49E@pecan.tislabs.com> >Will ARIN need to process (more/new) templates to permit updates to >the information? There are already templates that one uses if one wishes to modify information. The language "all IPv4 and IPv6 address block transactions (allocation and assignment requests, " was intended to capture those as well. At one point, there was a list of templates here, but it was suggested that a list could become stale and was better left to staff. --Sandy From sandy at tislabs.com Thu Oct 5 08:38:11 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 08:38:11 -0400 (EDT) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: Message-ID: <20061005123811.258C13F49A@pecan.tislabs.com> >> The policy duplicates >> capabilities of the routing registry and could be addressed by enhancing >> this existing functionality. The policy as stated is deliberately agnostic as to where the collected data could be stored. It could be stored in the routing registry, for example. In early discussions of this AS collection, there was an opinion expressed that any data collected in whois templates needed to be kept in the whois database. But that's probably a staff concern. --Sandy From sandy at tislabs.com Thu Oct 5 08:41:46 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 08:41:46 -0400 (EDT) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: Message-ID: <20061005124146.723DD3F4A0@pecan.tislabs.com> >Will ARIN need to process (more/new) templates to permit updates to >the information? There are already templates that one uses if one wishes to modify information. The language "all IPv4 and IPv6 address block transactions (allocation and assignment requests, " was intended to capture those as well. At one point, there was a list of templates here, but it was suggested that a list could become stale and was better left to staff. --Sandy From sandy at tislabs.com Thu Oct 5 09:22:20 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 09:22:20 -0400 (EDT) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: Message-ID: <20061005132220.641023F49A@pecan.tislabs.com> The April ARIN meeting saw the first presentation of policy 2006-3 ("Capturing Originations in Templates"), which suggested that AS origination authorization be collected in a new optional field in address resource templates. The intent was to permit the publication of an authenticated list of authorized prefix originations. The AC decided that this policy proposal should be revised in order to make it more acceptable to the membership. However, the AC and I found it difficult to decide just what revisions were needed. The decision was to broaden the proposal to suit the goal of the suggested collection, rather than state the collection mechanism itself. So the proposal in summary would state that ARIN will support and facilitate the collection and publication of an authenticated list of authorized prefix originations (for prefixes assigned to ARIN) and cooperate with other RIRs in any similar efforts. The April meeting also saw a panel presentation about a resource certificate PKI and route origination attestations based on that PKI. The goal underlying both the panel topic and the proposal 2006-3 is to produce an authenticated list of authorized prefix originations. (The resource certificate PKI could be used in other ways as well, as a means of judging the validity of requests for route origination from new customers, as a resource to use when diagnosing routing difficulties, ) Commentary at the mike during the resource PKI and route origination attestation panel was predominantly positive. The comments at the mike regarding policy proposal 2006-3 were not as predominately positive :-). However, none of the comments about the policy proposal disagreed with the policy proposal's goal. Would the membership accept the broadened statement of proposal 2006-3? Such a proposal would indicate the membership's support for the goals of the resource certificate PKI, and (happily) would also support the goal behind policy proposal 2006-3. --Sandy From markk at verisignlabs.com Thu Oct 5 09:39:13 2006 From: markk at verisignlabs.com (Mark Kosters) Date: Thu, 5 Oct 2006 09:39:13 -0400 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <20061005132220.641023F49A@pecan.tislabs.com> References: <20061005132220.641023F49A@pecan.tislabs.com> Message-ID: <20061005133913.GC3058@verisignlabs.com> On Thu, Oct 05, 2006 at 09:22:20AM -0400, Sandy Murphy wrote: > The April meeting also saw a panel presentation about a resource certificate > PKI and route origination attestations based on that PKI. > > The goal underlying both the panel topic and the proposal 2006-3 is to > produce an authenticated list of authorized prefix originations. (The > resource certificate PKI could be used in other ways as well, as a means of > judging the validity of requests for route origination from new customers, > as a resource to use when diagnosing routing difficulties, ) > > Commentary at the mike during the resource PKI and route origination > attestation panel was predominantly positive. The comments at the mike > regarding policy proposal 2006-3 were not as predominately positive :-). > However, none of the comments about the policy proposal disagreed with the > policy proposal's goal. > > Would the membership accept the broadened statement of proposal 2006-3? > Such a proposal would indicate the membership's support for the goals of the > resource certificate PKI, and (happily) would also support the goal behind policy > proposal 2006-3. I personally support the goal behind 2006-3 and see it as an intermediate measure to improve state of routing security. The PKI effort is quite impressive and allows for strong security. However, there much work to be done here and the end result may be complex. Having an authenticated list of authorized prefix originations will probably be simpler and faster measure for ARIN to implement. Once the PKI stuff is done and 2006-3 in some form is approved, ISPs then could have three choices use the PKI facility use the route origination list do nothing Thus, this all allows isps a choice of what type of validation they wish to perform on their networks. What do others think? Mark -- Mark Kosters markk at verisignlabs.com VeriSign From Ed.Lewis at neustar.biz Thu Oct 5 09:48:53 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 5 Oct 2006 15:48:53 +0200 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <20061005132220.641023F49A@pecan.tislabs.com> References: <20061005132220.641023F49A@pecan.tislabs.com> Message-ID: At 9:22 -0400 10/5/06, Sandy Murphy wrote: >The April ARIN meeting saw the first presentation of policy 2006-3 ("Capturing >Originations in Templates"), which suggested that AS origination authorization >be collected in a new optional field in address resource templates. >The intent >was to permit the publication of an authenticated list of authorized prefix >originations. > >The AC decided that this policy proposal should be revised in order to make >it more acceptable to the membership. However, the AC and I found >it difficult >to decide just what revisions were needed. The decision was to broaden >the proposal to suit the goal of the suggested collection, rather than state >the collection mechanism itself. So the proposal in summary would state that >ARIN will support and facilitate the collection and publication of an >authenticated list of authorized prefix originations (for prefixes assigned >to ARIN) and cooperate with other RIRs in any similar efforts. Having spent some time getting more familiar with the IRPEP, I would (now) concur that the proposed policy (change) deal with both semantics of collection and publication (or redistribution) of the data, if not syntax. >The April meeting also saw a panel presentation about a resource certificate >PKI and route origination attestations based on that PKI. A presentation on this was given (again) at RIPE 53 this week. Geoff Huston began it with an observation that he has covered this topic quite often in the past year or so, and he has come to the realization that the approach being taken in presentations probably ought to be modified. If I caught this right - he said it was like talking about driving a car and he had been boring us with the details of the internal combustion engine and not spending time on the techniques and tools of driving well. I say this because maybe the discussion on 2006-3 is suffering from the cart and horse misplacement problem. Perhaps 2006-3 is trying to put functionality in place to enable certificates for routing before there is broad understanding of the problem. (Not that the experts don't have an understanding, it's the broadness of understanding.) >The goal underlying both the panel topic and the proposal 2006-3 is to >produce an authenticated list of authorized prefix originations. (The >resource certificate PKI could be used in other ways as well, as a means of >judging the validity of requests for route origination from new customers, >as a resource to use when diagnosing routing difficulties, ) > >Commentary at the mike during the resource PKI and route origination >attestation panel was predominantly positive. The comments at the mike >regarding policy proposal 2006-3 were not as predominately positive :-). >However, none of the comments about the policy proposal disagreed with the >policy proposal's goal. > >Would the membership accept the broadened statement of proposal 2006-3? >Such a proposal would indicate the membership's support for the goals of the >resource certificate PKI, and (happily) would also support the goal behind >policy proposal 2006-3. I think the policy proposal ought to talk about the data collected, how it is redistributed. I think that the proposal needs to be understood in the context of the routing certificate goop. The proposal also needs to be understood in terms of any unintended consequences too (as usual), meaning the role the data plays outside of the PKI goop. I don't know if this collection ought to be tied to a/the routing registry. As much as it would be bad to have this data be stored in two places (because the two may become inconsistent), I am not sure which routing registry ARIN should insert this learned data. Will another routing registry recognize ARIN as the authority to do so? (I guess I am assuming that there are multiple routing registries still in play.) Maybe the larger issue is that although it is acceptable to me that ARIN bind a resource to a registrant, ARIN has traditionally stayed out of operations, so creating a binding between any two "Internet resources" seems like "something new" or maybe "mission creep." A question I have is whether this collected information is intended to stay in the ARIN database, and/or whether this information ought to stay in the ARIN database. Is it reasonable for an address range to change its originating autonomous system number? If so - the policy should also cover modifying the origination information for an already allocated/assigned address range. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From Michael.Dillon at btradianz.com Thu Oct 5 10:27:06 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 5 Oct 2006 15:27:06 +0100 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <20061005123811.258C13F49A@pecan.tislabs.com> Message-ID: > >> The policy duplicates > >> capabilities of the routing registry and could be addressed by enhancing > >> this existing functionality. > > The policy as stated is deliberately agnostic as to where the collected > data could be stored. It could be stored in the routing registry, for > example. In early discussions of this AS collection, there was an > opinion expressed that any data collected in whois templates needed > to be kept in the whois database. But that's probably a staff concern. This discussion isn't about data storage. As you point out, that is something that the staff (and the trustees) can deal with. The discussion is about what data will be published and how it will be published. A secondary issue is the collection of data. Secondary, because it is obvious that in order to publish data, the data must first be in ARIN's hands. I believe it is reasonable for ARIN to publish the allowed originating ASes for each IPv4 and IPv6 address block that it issues. Further, I believe that it is reasonable for block holders to publish allowed originating ASes for each block that they assign or sub-allocate. It goes without saying, that if ARIN is going to be publishing the INTENTIONS OF THIRD PARTIES, in the form of a list of allowed originating ASes, then it will collect that information from those 3rd parties in some form. However, I don't see any reason why this needs to be mentioned in ARIN policy unless we wish to make it MANDATORY to submit such information to ARIN. The fact that ARIN also publishes ISP information by proxy via the SWIP-to-whois-directory mechanism or the RRtemplate-to-routing-registry mechanism are irrelevant to this. If they will be used for the publishing of the information, then staff will update whatever template mechanisms are necessary. Why are policy writers so concerned with the minutiae of what ARIN must do? We are supposed to be writing ARIN policies, not writing ARIN's process manual. The gist of this policy seems to be: For each address range which ARIN has issued, ARIN will publish the list of allowed originating ASes as supplied by the authorized user for each netblock within that range. ARIN will form a public working group to produce a document specifying the requirements, and implementation details at the end of 6 months after this policy is ratified by the board of trustees. What more needs to be said in the NPRM? The technical details can be hashed out on a WG mailing list. Whatever reaches consensus within 6 months goes into the document and the WG dissolves. Then staff implement it. If anything in that document needs a policy change to make it so, then you can bet that it WILL be brought to our attention. The Trustees can be trusted to see to that. --Michael Dillon From Michael.Dillon at btradianz.com Thu Oct 5 10:38:35 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 5 Oct 2006 15:38:35 +0100 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <20061005133913.GC3058@verisignlabs.com> Message-ID: > The PKI effort is quite > impressive and allows for strong security. However, there much work > to be done here and the end result may be complex. This is what frightens me. Complex means expensive and fraught with error. To see how bad PKI really is read this: http://www.civics.com/PKI/ > Having an authenticated > list of authorized prefix originations will probably be simpler and > faster measure for ARIN to implement. Yes, and that is what I would like to see ARIN get involved with. No grand scheme, just some solid straighforward implementation work. --Michael Dillon From Ed.Lewis at neustar.biz Thu Oct 5 10:44:47 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 5 Oct 2006 16:44:47 +0200 Subject: [ppml] Policy Proposal writing In-Reply-To: References: Message-ID: At 15:27 +0100 10/5/06, Michael.Dillon at btradianz.com wrote: >Why are policy writers so concerned with the minutiae >of what ARIN must do? We are supposed to be writing >ARIN policies, not writing ARIN's process manual. (Maybe) Because proposals keep getting bounced at open meetings for not being specific enough. >The gist of this policy seems to be: > > For each address range which ARIN has issued, > ARIN will publish the list of allowed originating > ASes as supplied by the authorized user for each > netblock within that range. ARIN will form a public > working group to produce a document specifying the > requirements, and implementation details at the end > of 6 months after this policy is ratified by the board > of trustees. > >What more needs to be said in the NPRM? I think that if you gave that as a "mission statement" to a WG, the result might not be what is intended. I believe the intention is to prepare certificates with all this stuff, the above makes it seem that entries in WhoIs could be the end goal. >The technical details can be hashed out on a WG mailing >list. Whatever reaches consensus within 6 months goes >into the document and the WG dissolves. Then staff >implement it. If anything in that document needs a >policy change to make it so, then you can bet that it >WILL be brought to our attention. The Trustees can be >trusted to see to that. Of course, I am assuming the WG is not carrying any other context other than the statement above. The WG can be carefully selected to bring in the needed context though, but then we get towards "subjective" selection which might cause heartburn. The above suggestion is pretty close to what I suggested at the open mic a year ago (the first "an attendee"): http://arin.net/meetings/minutes/ARIN_XVI/mem_minutes.html#anchor_9 I suppose it's a matter of "do we set up coarse proposals that get refined later" or "do we refine proposals and pass the final text?" -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From Michael.Dillon at btradianz.com Thu Oct 5 10:57:11 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 5 Oct 2006 15:57:11 +0100 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: Message-ID: > >The April meeting also saw a panel presentation about a resource certificate > >PKI and route origination attestations based on that PKI. > > A presentation on this was given (again) at RIPE 53 this week. Geoff > Huston began it with an observation that he has covered this topic > quite often in the past year or so, and he has come to the > realization that the approach being taken in presentations probably > ought to be modified. If I caught this right - he said it was like > talking about driving a car and he had been boring us with the > details of the internal combustion engine and not spending time on > the techniques and tools of driving well. I sat through Geoff's presentation and was horrified at the complexity of it all so I did a fair bit of research after the meeting. X.509 is a lot like that machine gun with the replay feature in Fifth Element. It seems to have ever type of portable weapon known to man all built into a nice compact portable package. It even has a little red button that makes it blow up in your face. It's far worse than a square peg in a round hole. X.509 is trying to sell us a big fancy weapon when all we need is a simple key. We are facing a simple administrative problem that can be solved with some simple administrative techniques. No bleeding edge technology is needed. --Michael Dillon From weiler at tislabs.com Thu Oct 5 11:30:01 2006 From: weiler at tislabs.com (Sam Weiler) Date: Thu, 5 Oct 2006 17:30:01 +0200 (CEST) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 Message-ID: On Thu, 5 Oct 2006, Michael.Dillon at btradianz.com wrote: > The gist of this policy seems to be: > > For each address range which ARIN has issued, > ARIN will publish the list of allowed originating > ASes as supplied by the authorized user for each > netblock within that range. ARIN will form a public > working group to produce a document specifying the > requirements, and implementation details at the end > of 6 months after this policy is ratified by the board > of trustees. With the caveat that I collaborated closely with Sandy in the writing of 2006-3... Comparing the text above to 2006-3 as written, they are remarkably similar except that: - 2006-3 explicitly makes providing an AS list to ARIN optional - 2006-3 limits the redistributiuon restrictions ARIN can put on the publiched list - 2006-3 gives ARIN almost complete discretion to choose the publication mechanism without setting a timelime nor requiring a particular methodology - 2006-3 clearly gives ARIN the option of adding additional forms of publication in the furture (an IRR, a certificate system, etc.) - 2006-3 requires ARIN to (proactively) provide an opportunity to update the AS list every time any other maintenance is done on the address block > What more needs to be said in the NPRM? At the very least, that providing an AS list is optional and that ARIN may not restrict distribution of the aggregated data. I think the instruction to ARIN to invite registrants to provide an AS list at particular times is pretty important, too. To be clear, I have doubts about the accuracy of the staff statement: "The policy duplicates capabilities of the routing registry and could be addressed by enhancing this existing functionality." First, this policy gives ARIN the option of using an IRR as the publication mechanism for these mappings. Two key parts of this proposal, the regular invitations to update the AS lists and the implicit authentication provided by the template system, might be hard to incorporate into ARIN's existing IRR. There's also the question of how to handle the existing, poorly authenticated, data present in the IRR. On the whole, the proponents of this proposal were concerned that trying to "enhance" the existing IRR would be intractable. Accordingly, this proposal gives ARIN the leeway to publish the data in an IRR or elsewhere, including in a certificate system, as it deems feasible. Assuming that we like the idea of ARIN collecting and publishing address block to ASN mappings, this proposal gives ARIN a great deal of flexibility to do something that's 1) easy for them and 2) meets the community's needs, even as those needs change over time. -- Sam From Suzanne_Woolf at isc.org Thu Oct 5 11:51:09 2006 From: Suzanne_Woolf at isc.org (Suzanne Woolf) Date: Thu, 5 Oct 2006 15:51:09 +0000 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: References: <20061005133913.GC3058@verisignlabs.com> Message-ID: <20061005155109.GA28310@farside.isc.org> On Thu, Oct 05, 2006 at 03:38:35PM +0100, Michael.Dillon at btradianz.com wrote: > > Having an authenticated > > list of authorized prefix originations will probably be simpler and > > faster measure for ARIN to implement. > > Yes, and that is what I would like to see ARIN > get involved with. No grand scheme, just some solid > straighforward implementation work. Getting back to the policy for a moment.... The policy directs ARIN to make it easy for people to associate their route and AS data through ARIN if they want to. That association is input for a lot of possible mechanisms that could be used for the larger goal of authenticating route originations. The discussion of what mechanism, if any, ARIN itself should support in the operational context-- the certification system currently under development/discussion among multiple RIRs, or something else-- is interesting and extremely important. However, Policy Proposal 2006-3 doesn't constrain that discussion; it seems to be compatible with promoting any of the mechanisms contemplated. When the proposal was first discussed at the previous Public Policy meeting, it had limited support as written. But when the room was polled on the related question of whether ARIN should be supporting activity to promote route certification, there seemed to be a strong consensus that it should. That input to the AC was the difference between abandoning the proposal and deciding to keep it in the process and work with it further. Support for this policy proposal makes it easier for ARIN to promote the association of routes and AS numbers in a form that can be published by ARIN or republished by others as part of a system for greater security in Internet routing. It allows people to replace outdated or missing information in ARIN's and other IRRs or other data repositories in a way that will be better authenticated to start with and, we hope, better maintained. Regardless of what publication mechanism and operational infrastructure you like for using the data, this seems like a Good Thing(tm) to me. The question for the Public Policy meeting is whether it's enough of a Good Thing(tm) to justify the effort, as described in the staff analysis. Suzanne Woolf ARIN AC (personal opinions) From Michael.Dillon at btradianz.com Thu Oct 5 12:04:01 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 5 Oct 2006 17:04:01 +0100 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: Message-ID: > Comparing the text above to 2006-3 as written, they are remarkably > similar except that: > - 2006-3 explicitly makes providing an AS list to ARIN optional No policy currently makes it mandatory. Why specify that it is optional? > - 2006-3 limits the redistributiuon restrictions ARIN can put on > the publiched list The whois directory and the routing registry are already published by ARIN and already have redistribution guidelines. Why should this data be treated differently? If it goes in the whois directory, it inherits the whois rules, if it goes in the registry, it inherits the registry rules. In any case, it is published, i.e. made public, so any restrictions on redistribution are virtually impossible to apply. The only thing that stops me from redistributing this data with my own AS added to the list, is that nobody would accept my copy of the data. Why try to fix a theoretical problem that does not exist in the real world. > - 2006-3 gives ARIN almost complete discretion to choose the > publication mechanism without setting a timelime nor requiring > a particular methodology And that is a bit too vague, IMHO. My wording adds a fairly light touch but it does set a deadline so that something actually gets done. > - 2006-3 clearly gives ARIN the option of adding additional forms > of publication in the furture (an IRR, a certificate system, etc.) And my wording regards the form of publication to be outside the scope of the policy and inside the scope of the working group. Since it is not in the policy, ARIN is automatically free to change it at any time. > - 2006-3 requires ARIN to (proactively) provide an opportunity to > update the AS list every time any other maintenance is done on the > address block Seems to me exactly what the staff would do if left to their own devices. On the other hand, if you believe that the staff are dumb, it is better to give them some rope and let them hang themselves with it. That way, the trustees can get better staff. In any case, best dealt with outside the policy. > At the very least, that providing an AS list is optional and that ARIN > may not restrict distribution of the aggregated data. I think the > instruction to ARIN to invite registrants to provide an AS list at > particular times is pretty important, too. I think you are picking nits. Even though my wording is concise and leaves out irrelevant process details, it still sucks. It fails to define the scope of this whole thing. It fails to specify ARIN's role and responsibilities within that scope. ARIN is the authority at the top of the DELEGATION TREE for IP address ranges. ARIN delegates ranges to organizations. In turn, these organizations may delegate sub ranges and so on for an unspecified, though small, number of levels. A policy could give ARIN the responsibility to maintain an publish authoritative delegation data for this hierarchy in a form which can be used within the Internet routing system. If ARIN would provide a mechanism for delegees of a range to publish the list of allowed originating ASes for that range, then it would support a more secure Internet routing system. The policy really should start with something on this level and leave the details to either the staff, or an implementation working group. > To be clear, I have doubts about the accuracy of the staff statement: > "The policy duplicates capabilities of the routing registry and could > be addressed by enhancing this existing functionality." I think they mean that ARIN already runs a routing registry so that organizations can publish information about delegated address ranges and SUBNETS OF DELEGATED RANGES. Of course the IRR is targeted at AS holders, but could easily be extended to support address range holders as well and could easily support additional attributes. > Two key parts of this proposal, the > regular invitations to update the AS lists and the implicit > authentication provided by the template system, might be hard to > incorporate into ARIN's existing IRR. That is precisely the reason I suggested a working group with a deadline. It might be hard or it might be easy. Rather than hang the whole policy on some "might be"'s, I think it works better to hash this out in the open, after the policy has been approved and ratified by the BoT. The WG may decide that even if it is hard, it is still beneficial and the best way to proceed. Or not. > There's also the question of > how to handle the existing, poorly authenticated, data present in the > IRR. On the whole, the proponents of this proposal were concerned > that trying to "enhance" the existing IRR would be intractable. Sounds like another good reason for a WG. > Accordingly, this proposal gives ARIN the leeway to publish the data > in an IRR or elsewhere, including in a certificate system, as it deems > feasible. As you know, I prefer that they just set up an LDAP server and be done with it. ;-) --Michael Dillon From drc at virtualized.org Thu Oct 5 12:17:34 2006 From: drc at virtualized.org (David Conrad) Date: Thu, 5 Oct 2006 09:17:34 -0700 Subject: [ppml] Fwd: Keeping in reserve In-Reply-To: References: Message-ID: <9991A4A8-7922-4338-8AEC-DBF635DAD7AB@virtualized.org> Is there any reason PI /48s shouldn't be allocated with the bisection method, thus removing the need to reserve space? Thanks, -drc On Oct 5, 2006, at 3:14 AM, Iljitsch van Beijnum wrote: > Hi, > > I understand that ARIN wants to give out /48s for PI but reserve a / > 44. That's a bad idea, see the message below about this that I sent > to the RIPE address policy list. > > Begin forwarded message: > >> History, both in IPv4 and IPv6, has shown that keeping space in >> reserve to accommodate future request doesn't work very well: >> people often end up announcing several blocks anyway. So let's not >> waste the space and make filtering harder by doing this. Also, >> since a /48 is an incredible amount of space to begin with, coming >> back for more should be rare in IPv6. > >> The advantage of only giving out /48s with no unused space between >> them is that if, for instance, 12000 /48s are given out, that will >> be from a single /34 and allowing /48s from a /34 allows 16384 >> routes, while allowing /48s from a /20 (because for every /48 of >> 12000 a /32 is kept in reserve) allows 268 million routes, more >> than enough to overload any reasonable routing system in an attack. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > From sandy at tislabs.com Thu Oct 5 12:17:15 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 12:17:15 -0400 (EDT) Subject: [ppml] Policy Proposal writing In-Reply-To: Message-ID: <20061005161715.290543F49A@pecan.tislabs.com> >I think that if you gave that as a "mission statement" to a >WG, the result might not be what is intended. I believe >the intention is to prepare certificates with all this stuff, >the above makes it seem that entries in WhoIs could be the >end goal. The original proposal's intent was to collect/publish the authenticated list of authorized prefix originations (herein after referred to as ALAPO) in the ordinary ARIN templates. The new goal-oriented proposal would support collection of prefix originations by any means, templates or PKI or whatnot. I think it would be really nifty if there was an EASY button for converting database entries into PKI certificates. (From what I understand of Geoff Huston's presentations, APNIC is doing that.) If there were, a database that contained this new info would convert to what Steve Kent calls a ROA - a Route Origination Attestation. But the proposal just says that ARIN will collect the info (means at their choice) and publish the info (means at their choice, with some caveats about bulk publication and use restrictions in the original proposal). --Sandy From sandy at tislabs.com Thu Oct 5 12:29:28 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 12:29:28 -0400 (EDT) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <45242921.7020106@arin.net> Message-ID: <20061005162928.94C173F497@pecan.tislabs.com> >The policy duplicates >capabilities of the routing registry and could be addressed by enhancing >this existing functionality. It is true that RPSL route objects convey much the same origination information as is proposed to be collected in templates. However, the current ARIN IRR, according to recent messages on the ppml list, contains information that is pulled in from other IRR sources. The authenticity of this data can not be verified by ARIN. For route objects stored in the ARIN IRR, according to information I was told early this year, ARIN does not presently verify the person registering the object against POC info in the resource database as is done for address and AS objects. So ARIN could, but does not, authenticate this information. Because ARIN does authenticate that templates are received from the proper contact, the info collected in templates has higher assurance. (OK, not much higher assurance, given the common use of MAIL_FROM, but still the concept is there.) Perhaps existing functionality could be enhanced to provide these features. OTOH, existing functionality could be enhanced to add a comment to templates, also. --Sandy From sandy at tislabs.com Thu Oct 5 12:45:01 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 12:45:01 -0400 (EDT) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: Message-ID: <20061005164501.D2AAB3F4AC@pecan.tislabs.com> >I sat through Geoff's presentation and was horrified >at the complexity of it all so I did a fair bit of >research after the meeting. I'm pretty sure that you use https, which might be complex if the details were all subject to your configuration. If the interactions with the resource certificates were as little needing of configuration, would you be as alarmed? --Sandy From owen at delong.com Thu Oct 5 13:14:17 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Oct 2006 10:14:17 -0700 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <20061005123811.258C13F49A@pecan.tislabs.com> References: <20061005123811.258C13F49A@pecan.tislabs.com> Message-ID: <2ADF5C7F-96FE-4E36-B655-408D58A9DA89@delong.com> On Oct 5, 2006, at 5:38 AM, Sandy Murphy wrote: >>> The policy duplicates >>> capabilities of the routing registry and could be addressed by >>> enhancing >>> this existing functionality. > > The policy as stated is deliberately agnostic as to where the > collected > data could be stored. It could be stored in the routing registry, for > example. In early discussions of this AS collection, there was an > opinion expressed that any data collected in whois templates needed > to be kept in the whois database. But that's probably a staff > concern. As was discussed at the Montreal meeting, I just don't see the gain to adding this to the template. If a recipient wants to provide this information, there is a process for providing it in a much more meaningful and useful form using RPSL in ARIN's (or any of several other) routing registries. The effort being expended on this, in my opinion, would be better spent making it easier for people to use an IRR than mucking with the existing assignment/allocation/reassignment templates. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From owen at delong.com Thu Oct 5 13:26:16 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Oct 2006 10:26:16 -0700 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: References: <20061005132220.641023F49A@pecan.tislabs.com> Message-ID: <33951CF7-2790-4A09-A0C3-6379F882AA0C@delong.com> > I don't know if this collection ought to be tied to a/the routing > registry. As much as it would be bad to have this data be stored in > two places (because the two may become inconsistent), I am not sure > which routing registry ARIN should insert this learned data. Will > another routing registry recognize ARIN as the authority to do so? Presumably ARIN would insert it into the ARIN routing registry and all of the main IRRs I am aware of do recognize the ARIN IRR as a legitimate IRR from/to which they do share/synchronize data. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From owen at delong.com Thu Oct 5 13:54:59 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Oct 2006 10:54:59 -0700 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <20061005162928.94C173F497@pecan.tislabs.com> References: <20061005162928.94C173F497@pecan.tislabs.com> Message-ID: <7E75DA3C-2FD8-442F-B856-B3FB1B13F228@delong.com> On Oct 5, 2006, at 9:29 AM, Sandy Murphy wrote: >> The policy duplicates >> capabilities of the routing registry and could be addressed by >> enhancing >> this existing functionality. > > It is true that RPSL route objects convey much the same origination > information as is proposed to be collected in templates. > > However, the current ARIN IRR, according to recent messages on the > ppml > list, contains information that is pulled in from other IRR sources. > The authenticity of this data can not be verified by ARIN. > As I understand it, the IRR does not "contain" this data, but, does contain references to this data. Also, all of the records contain a Source: field which indicates which IRR the data came from. A such, you can, if you want to be certain, examine that field and if it isn't an RIRs IRR, you can discard the data. The bigger problem, as I see it, is that the maintainer in the IRR is tied to the ASN, not the Prefix. > For route objects stored in the ARIN IRR, according to information I > was told early this year, ARIN does not presently verify the person > registering the object against POC info in the resource database as > is done for address and AS objects. So ARIN could, but does not, > authenticate this information. Hence my belief that the effort being expended on putting this proposal through the policy process would be better spent on improving the IRR process and accessibility. However, such belongs in the Comment/Feedback process recently announced more than in the policy arena at this time, as, it is not related to Internet Resource Policy, but, Route Authentication. I'm not saying the goal is bad, just that you're using the wrong hammer to pound the screw into the sheet metal. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From sandy at tislabs.com Thu Oct 5 14:02:43 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 14:02:43 -0400 (EDT) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <20061005155109.GA28310@farside.isc.org> Message-ID: <20061005180243.3164D3F49F@pecan.tislabs.com> >The question for the Public Policy meeting is whether >it's enough of a Good Thing(tm) to justify the effort, as described in >the staff analysis. Which reminds me: >The resource impact of implementing this policy is significant. >Barring any unforeseen resource requirements, this policy could be >implemented within 3-6 months from the date of the ratification of the >policy by the ARIN Board of Trustees. Implementation would not require >the acquisition of staff personnel or equipment. It will require the >following: > >- Template change >- Revision to Registration Software >- Revision to Directory Services >- Revisions to registration guidelines >- Staff Training Could estimates of impact give measures of impact? Is the impact judged to be significant because of the number of effected components or because of the level of effort required? You say "implemented within 3-6 months from the date of the ratification", which doesn't sound like a large effort, unless you mean 3-6 months with the entire ARIN staff devoted to nothing else. :-) --Sandy From sandy at tislabs.com Thu Oct 5 14:10:40 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 14:10:40 -0400 (EDT) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <20061005180243.3164D3F49F@pecan.tislabs.com> Message-ID: <20061005181040.F1B083F4A1@pecan.tislabs.com> >Could estimates of impact give measures of impact? Sorry to the list, I did not mean that to go to the whole list as it was not a comment on the proposals. --Sandy From weiler at tislabs.com Thu Oct 5 12:02:48 2006 From: weiler at tislabs.com (Sam Weiler) Date: Thu, 5 Oct 2006 18:02:48 +0200 (CEST) Subject: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) In-Reply-To: References: Message-ID: On Wed, 4 Oct 2006, william(at)elan.net wrote: > I'd like to make additional comment regarding 2006-1 and potentially > offering a way to a solution that solves the issues but does not cause > as many problems and changes with ARIN system. > > As a reminder a primary justification for introducing this seems to > be that full ZIP codes (6 code in Canada or full 9 digit code in US) > and city is in some cases are too specific and is almost the same as > offering full street address. As I said in April[1] and repeated earlier this week[2], my impression from Montreal was that MOST of the objections to 2006-1 were fueled by the staff's concerns about not having access to data they need, not a desire to have city/state/postal codes published for all to see. I don't think we'd heard from many folks who want to use that data about their desire for it, particularly absent a name, street name, and number. If there are such folks out there, I'd really like to hear more about their need, and why it can't be satisfied in some other way. Then we, as a community, can desire whether their need for the data outweighs the individual users' rights to some privacy. Absent such voices, let's deal with the other objections and move along. -- Sam [1] http://lists.arin.net/pipermail/ppml/2006-April/005330.html [2] http://lists.arin.net/pipermail/ppml/2006-October/005712.html From owen at delong.com Thu Oct 5 14:21:01 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Oct 2006 11:21:01 -0700 Subject: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) In-Reply-To: References: Message-ID: On Oct 5, 2006, at 9:02 AM, Sam Weiler wrote: > On Wed, 4 Oct 2006, william(at)elan.net wrote: > >> I'd like to make additional comment regarding 2006-1 and potentially >> offering a way to a solution that solves the issues but does not >> cause >> as many problems and changes with ARIN system. >> >> As a reminder a primary justification for introducing this seems to >> be that full ZIP codes (6 code in Canada or full 9 digit code in US) >> and city is in some cases are too specific and is almost the same as >> offering full street address. > > As I said in April[1] and repeated earlier this week[2], my impression > from Montreal was that MOST of the objections to 2006-1 were fueled by > the staff's concerns about not having access to data they need, not a > desire to have city/state/postal codes published for all to see. > My impression and certainly my objections were over multiple issues. I believe that the research and other value of having the non-specific location data are beneficial to the community and should be preserved. As such, while I accept the idea of not publishing complete address information, I still think that it is a bad idea to stop publishing City and non-specific postal code information. > I don't think we'd heard from many folks who want to use that data > about their desire for it, particularly absent a name, street name, > and number. If there are such folks out there, I'd really like to > hear more about their need, and why it can't be satisfied in some > other way. Then we, as a community, can desire whether their need for > the data outweighs the individual users' rights to some privacy. > I remember a number of people coming to the microphone and talking about their uses of the data. I don't remember CAIDA being at the meeting, but, I think they use this data on a regular basis. I know Martin Hannigan outlined several legitimate uses of the data. > Absent such voices, let's deal with the other objections and move > along. > Since such voices are/were not absent, lets accept that these objections still exist and preserve the city, state/province, and non-specific postal code. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From iljitsch at muada.com Thu Oct 5 14:36:48 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 5 Oct 2006 20:36:48 +0200 Subject: [ppml] Fwd: Keeping in reserve In-Reply-To: <9991A4A8-7922-4338-8AEC-DBF635DAD7AB@virtualized.org> References: <9991A4A8-7922-4338-8AEC-DBF635DAD7AB@virtualized.org> Message-ID: [Originally to ppml, CC to address-policy at ripe, prune as necessary] On 5-okt-2006, at 18:17, David Conrad wrote: > Is there any reason PI /48s shouldn't be allocated with the > bisection method, thus removing the need to reserve space? The goal of filtering in BGP is either to keep out accidentally injected prefixes, or keep out both accidentially and maliciously injected prefixes. This means that a reasonable filter, i.e., one that can be configured on a router with a relatively limited number of filter rules, must allow through all prefixes that match legitimate allocations, and reject as much of everything else as possible. This means that ideally, from a certain block of address space, prefixes of one size are allocated sequentially with no unused space between them. For instance: 192.0.0.0/24 -> /28s: 192.0.0.0/28 192.0.0.16/28 ... 192.0.0.192/28 192.0.0.208/28 In this example, only blocks above 192.0.0.208/28 can be successfully used to get around the filter, either for the purpose of hijacking unused address space for purposes like spamming, or to overload routers by injecting large numbers of bogus prefixes. If we now reserve a /26 for every user of a /28, we'd have: 192.0.0.0/28 192.0.0.64/28 ... 192.0.2.0/28 192.0.2.64/28 So a filter would have to allow 192.0.0.0/22 -> /26 - /28. This gives an attacker the opportunity to inject three malicious /28 prefixes between any two legitimate /28s. Worse, when someone grows out of a / 28 and gets a /27, such as 192.0.0.64/27, an attacker can inject 192.0.0.64/28 + 192.0.0.80/28, which cover the same address space but the longest match first rule makes packets flow toward the attacker rather than the real holder of the addresses. For this reason and because of temporary instability when moving from a smaller to a larger prefix, or maybe because of simple laziness or cluelessness, the real holder of the address space may choose to inject both 192.0.0.64/28 and 192.0.0.80/28 and maybe also 192.0.0.64/27. This negates the purpose of keeping some extra space in reserve between allocations. In IPv4 we have to be careful not to give too much space away, but in IPv6 there is absolutely no reason to skimp when people come back for seconds. So if a /48 isn't enough, don't grow to a /47 or even a /44, just give a /40 and then a /32. The number of extra prefixes in the routing table that this results in is minimal because even a /48 is more than enough for the majority of organizations, and it allows for much stricter filters. And it avoids fragmenting the address space. With the bisection method, you'd have to use even more liberal filters and allow between /25 and /28 in this example. All in all, it would be best if for every block of address space, only a fixed size allocations are given out. From narten at us.ibm.com Thu Oct 5 15:46:39 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 05 Oct 2006 15:46:39 -0400 Subject: [ppml] Fwd: Keeping in reserve In-Reply-To: <9991A4A8-7922-4338-8AEC-DBF635DAD7AB@virtualized.org> References: <9991A4A8-7922-4338-8AEC-DBF635DAD7AB@virtualized.org> Message-ID: <200610051946.k95Jkdwp013327@cichlid.raleigh.ibm.com> > Is there any reason PI /48s shouldn't be allocated with the bisection > method, thus removing the need to reserve space? I too, have the same question. I think it is short-sighted to assume that every end site will find a /48 to be enough space. Maybe most will. But there is no reason to lock that in today if not really necessary. So, better to allocate using sparse allocation. Keep our options open. We have lots of address space in IPv6. Let's continue to give the need to preserve aggregation adequate weight and consideration. Thomas From Ed.Lewis at neustar.biz Thu Oct 5 16:00:49 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 5 Oct 2006 22:00:49 +0200 Subject: [ppml] Policy Proposal writing In-Reply-To: <20061005161715.290543F49A@pecan.tislabs.com> References: <20061005161715.290543F49A@pecan.tislabs.com> Message-ID: At 12:17 -0400 10/5/06, Sandy Murphy wrote: >I think it would be really nifty if there was an EASY button for >converting database entries into PKI certificates. (From what I >understand of Geoff Huston's presentations, APNIC is doing that.) >If there were, a database that contained this new info would convert >to what Steve Kent calls a ROA - a Route Origination Attestation. One thing I'll mention just as a caution against overly great expectations - from my recollection the ARIN database is designed differently from the APNIC database. What may be easily fit into one database may not as easily be built into another. This is coming from someone who did work for ARIN, but is as familiar with databases as I am with the Windows operating system. Which is to say "not much." My statement is also not a relative comparison between the two designs. The approaches taken came from different requirements. I won't go further as my opinions in this regard are based on a 11-year old's comprehension of how databases are built and work. I don't mean to slight 11 year olds - they are wonderful people who generally later become 12 year olds. If someone wants to set the record straight and feels it is appropriate to get into such a detailed discussion on an open list, I'll leave it to someone else. But, yes, it would be nifty, but I wouldn't count on it. More seriously, the reason there are different RIRs is that there are going to be regional differences. There is one here. It would be good to have the ability to provide these certificates out of the ARIN region just as in the APNIC region but what it would take to accomplish the same service will be different. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From Ed.Lewis at neustar.biz Thu Oct 5 16:17:21 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 5 Oct 2006 22:17:21 +0200 Subject: [ppml] question about 2006-3 In-Reply-To: <20061005181040.F1B083F4A1@pecan.tislabs.com> References: <20061005181040.F1B083F4A1@pecan.tislabs.com> Message-ID: In trying to form my own opinion about 2006-3, I am interested in the answers to some questions. First I'll start with what I think the problem statement is: ARIN knows to whom IP address ranges and AS numbers are assigned/allocated. As far as I know, in the ARIN Internet Resource Database, there is no association of IP address ranges and AS numbers. To build Route Origination Attestation (certificates), the association between IP address ranges, AS numbers, and organizations is needed. The information the ARIN Internet Resource Database lacks may exist in some other Internet Routing Registry, one predominate example is the RADB, in the ARIN operated Internet Routing Registry, or only in the client/LIR/ISP's internal infrastructure. 2006-3 is proposing a mechanism for getting the "missing" data to where the Route Origination Attestation can be made (ARIN). The pitfalls are 1) duplication of the data because of this and 2) whether or not this is required. Okay, I said I had a question...and I really do. To ISP's who would be represented by Route Origination Attestations - are the linkages between IP address ranges and AS numbers "you" are allocated/assigned already documented in some Internet Routing Registry? How many have the information in a registry that is not the RADB? The reason I ask is that perhaps the solution is for ARIN to retrieve the information from an Internet Routing Registry. Yes, we'd have to solve the transitive security issues for that to happen. But it would get around the problem of duplicate data repositories. As far as the mandatoriness of all this - that's beyond policy. ARIN can only offer up the attestations from the what it knows (securely), it's up to the routing industry to decide if anything is mandatory. I think. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From kloch at kl.net Thu Oct 5 16:41:12 2006 From: kloch at kl.net (Kevin Loch) Date: Thu, 05 Oct 2006 16:41:12 -0400 Subject: [ppml] Fwd: Keeping in reserve In-Reply-To: References: <9991A4A8-7922-4338-8AEC-DBF635DAD7AB@virtualized.org> Message-ID: <45256DE8.1030409@kl.net> Iljitsch van Beijnum wrote: > [Originally to ppml, CC to address-policy at ripe, prune as necessary] > > On 5-okt-2006, at 18:17, David Conrad wrote: > >> Is there any reason PI /48s shouldn't be allocated with the >> bisection method, thus removing the need to reserve space? > > The goal of filtering in BGP is either to keep out accidentally > injected prefixes, or keep out both accidentially and maliciously > injected prefixes. > > This means that a reasonable filter, i.e., one that can be configured > on a router with a relatively limited number of filter rules, must > allow through all prefixes that match legitimate allocations, and > reject as much of everything else as possible. I don't see how fixed sizes and contiguous assignments will prevent people from announcing space not delegated to them. Right now the best way to manage this is by filtering your own customers with an explicit list (manually or RR generated) and applying peer pressure to peers who don't. Hopefully in the near future we will have crypto-signed announcements to solve this problem for real. - Kevin From iljitsch at muada.com Thu Oct 5 16:40:36 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 5 Oct 2006 22:40:36 +0200 Subject: [ppml] Fwd: Keeping in reserve In-Reply-To: <200610051946.k95Jkdwp013327@cichlid.raleigh.ibm.com> References: <9991A4A8-7922-4338-8AEC-DBF635DAD7AB@virtualized.org> <200610051946.k95Jkdwp013327@cichlid.raleigh.ibm.com> Message-ID: <1AC4F96A-CD9B-4AD0-B638-5A42E948E61B@muada.com> On 5-okt-2006, at 21:46, Thomas Narten wrote: >> Is there any reason PI /48s shouldn't be allocated with the bisection >> method, thus removing the need to reserve space? > I too, have the same question. See my earlier message. > I think it is short-sighted to assume > that every end site will find a /48 to be enough space. Maybe most > will. But there is no reason to lock that in today if not really > necessary. So, better to allocate using sparse allocation. Keep our > options open. So what is the downside of simply giving out an additional, non- growable prefix when a /48 isn't enough? Or just give out the space that would have been reserved immediately, i.e., give out /44s instead of /48s? From kloch at kl.net Thu Oct 5 17:11:06 2006 From: kloch at kl.net (Kevin Loch) Date: Thu, 05 Oct 2006 17:11:06 -0400 Subject: [ppml] Fwd: Keeping in reserve In-Reply-To: <1AC4F96A-CD9B-4AD0-B638-5A42E948E61B@muada.com> References: <9991A4A8-7922-4338-8AEC-DBF635DAD7AB@virtualized.org> <200610051946.k95Jkdwp013327@cichlid.raleigh.ibm.com> <1AC4F96A-CD9B-4AD0-B638-5A42E948E61B@muada.com> Message-ID: <452574EA.2080806@kl.net> Iljitsch van Beijnum wrote: > So what is the downside of simply giving out an additional, non- > growable prefix when a /48 isn't enough? This results in involuntary fragmentation just like slow-start in IPv4. > Or just give out the space that would have been reserved immediately, > i.e., give out /44s instead of /48s? That provides more space with which to voluntarily deaggregate. That could be a feature or a problem depending on your perspective. It could also be seen as unnecessarily wasteful since /48 is already a very generous minimum assignment. I like the bisection method. It provides the maximum ability to expand delegations without fragmentation. It also removes any perceived relationship between reserved space and your delegation. - Kevin From andrew.dul at quark.net Thu Oct 5 17:28:55 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Thu, 05 Oct 2006 21:28:55 +0000 Subject: [ppml] Fwd: Keeping in reserve Message-ID: <20061005212855.4588.qmail@hoster908.com> > -------Original Message------- > From: Kevin Loch > Subject: Re: [ppml] Fwd: Keeping in reserve > Sent: 05 Oct '06 13:11 > > Iljitsch van Beijnum wrote: > > So what is the downside of simply giving out an additional, non- > > growable prefix when a /48 isn't enough? > > This results in involuntary fragmentation just like slow-start > in IPv4. > > > Or just give out the space that would have been reserved immediately, > > i.e., give out /44s instead of /48s? > > That provides more space with which to voluntarily deaggregate. That > could be a feature or a problem depending on your perspective. It could > also be seen as unnecessarily wasteful since /48 is already a very > generous minimum assignment. > > I like the bisection method. It provides the maximum ability to expand > delegations without fragmentation. It also removes any perceived > relationship between reserved space and your delegation. In general, bisection seems like a good strategy. The problem with bisection from my perspective is what happens when the super-block you are assigning from becomes close to "full." In this case ARIN has decided to assign IPv6 PI from the block 2620:0000:/23 (http://www.arin.net/reference/ip_blocks.html). Because of the IPv6 policy agreed to between IANA & the RIRs. ARIN can't go back and get more IPv6 address space until they have assigned/allocated/reserved 50% of the space they have been given. At least that is how I read the policy. (http://www.icann.org/policies/proposed-ipv6-policy-14jul06.htm) If you are assigning /48s without reservations then you force bisection down to the /47 level. If any org wants to grow bigger than a /47 then you force fragmentation by not having a reserve. The IPv6 policy between the RIRs & IANA recognizes reserved address space as "unavailable" for the purposes for obtaining additional address resources from IANA. The reserve method isn't perfect, but I believe it is reasonable based upon what we know now. Andrew From Lee.Howard at stanleyassociates.com Thu Oct 5 17:49:07 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 5 Oct 2006 17:49:07 -0400 Subject: [ppml] ARIN member in good standing? Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4037A33F5@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: Peter Sherbin [mailto:pesherb at yahoo.com] > Sent: Tuesday, October 03, 2006 12:06 AM > To: Howard, W. Lee; ppml at arin.net > Subject: Re: [ppml] ARIN member in good standing? > > > Can you describe the data capture mechanism? I mentioned the > > billing system that would be required. Even if you discard > > payload and only keep source and destination addresses and packet > > size, you're talking about increasing network load by a > > significant amount (30%?). Billing data for an OC3 could be > > 16TB per month. Multiply hundreds of circuits times a five-year > > record-retention policy, and I get a 97PB database. > > Assumption: need to count sent volumes only. A sending > network or a node (SN) is > identified by its source address (SA). SN is connected to > provider's distribution > router (DR). DR counts the length of all packets sent from SA > and reports the total > number of bits to a database server. Yes, that's the math I was doing. I had inferred from something you said earlier that you might charge different rates per destination. Even if not, if you have a 128 bit address field and a 16 bit length field, at a million packets per second, it's still a couple of terabytes per month. That's a good-sized database, and that's just one OC3. I think you suggest having a database server at every hub, gathering data for all circuits there, and transmitting summaries hourly to a central server, followed by a purge. You're still tracking millions of packets per second, hopefully without introducing latency, and rack space isn't cheap. > > I don't understand "unpaid volumes." You bill your customers. > > In some cases volume based billing is announced but it may > not necessarily be > enforced. Billing works OK for burstable circuits. A regular > T1 would be provisioned > to accommodate e.g. about 0.5Mbps at a busy hour. Three T1s > on a single DR may have > different usage patterns. E.g. one transmits at 1.2Mbps > during 3hrs in the morning. > Second sends at 1.1Mbps at night for 6hrs. The third sends at > 0.3Mbps 24hrs daily > with occasional bursts up to 1.5Mbps. Each pays $1,200 but > over the month #1 have > sent 49GB, #2 = 89GB, #3 = 110GB. Sometimes providers would > go after "abusers" who > exceed average usage tens or hundreds times. "Abusers" can be > looked at as an > opportunity assuming they have a need to move data and are > willing to pay for it. Sorry for leading the topic this way. How and what ARIN members charge for services is completely off-topic. If your proposal requires Internet providers to bill in a certain way, we don't have the authority to adopt it. > > You keep saying "proper," as if to say that there is an established > > right way to do things. > > "Proper" means following the basic logic of a process. I don't think that's what it means. > E.g. in a world of a regular > mail or cargo shipments a sender pays for moving a certain > number of molecules over > distance. Energy wise how does moving electrons fundamentally > differ from moving > molecules? If electrons are too many to count let's define a > countable network unit representing a fair amount of > electrons. I have it on good authority that the Internet isn't trucks, it's tubes. The fundamental difference is that there's no Internet oligopoly. In shipping, you have a single carrier end-to-end. In telecom, you may have two or three carriers, but they look the same, because of heredity and regulation. Another difference: we don't push electrons. Individual electrons don't move very far at all. Data have no mass. The basic issue at hand, though, is why the trucking model would be substantially better than the status quo. > > I am not familiar with telecommunications licensing, but I do not > > have the impression that licenses are available to anyone. My > > impression is that the "certain criteria" are high. Does each > > coffee shop and private interconnect have to get a license? > > The process is straightforward, as long as you meet all > "high" criteria you will get > the license. If network services are defined and regulated > then anyone who falls > under that definition is a subject to a license. You say it's straightforward, but what are those criteria? Does that mean that coffee shops need licenses? If I set up private interconnects between my enterprise network and four of my vendors, do I need a license? > > So does this mean a new kind of governmental licensing agency, > > which works closely with the government tax collection agency, > > and the two agencies direct ARIN? > > It is a matter of coordination between already established > agencies, e.g. Tax and > FCC. Agencies feed ARIN with the number of subscribers by > provider as well as > suggested fees. ARIN autonomously performs address allocation > practice. ARIN > collects fees from all holders of licenses for network services. How strong are the suggestions? > > I'm unclear on the taxpayer-node relationship. Each taxpaying > > individual with a tax ID gets an allocation? What size? > > Taxpayers are not homogeneous and need segmentation. How many > addresses is enough > for a single individual? Assuming that at some point we will > start fixing genes and > that human DNA consists of about 3 billion base pairs will > /96 be enough? For the > start we may want to reserve more space and start > experimenting with less. Do you have a proposal? > > Each taxpaying organization with a tax ID get an allocation? > > What size? > > Depending on what they can justify. Current ARIN approach > works well here. I think your proposal is to have the tax and licensing organizations provide ARIN a subscriber count. ARIN needs more information than that. Do we ask the organization for more information, or train the tax and licensing agenices to collect network diagrams and virtual host counts? > > I was talking about IP address allocation. Say my company has > > offices in 14 states and two provinces, with leased lines between > > them, and three Internet connections. Do I get three assignments > > from my carriers, or 14? Or since I have leased lines, do I get a > > telecom license? > > You will get your PI assignment directly from ARIN in the > amount you can justify. > Whichever provider(s) serve your Internet connection(s) they > will report it to ARIN. > You will get a telecom license if you meet all of the > criteria for it in your region > and if you want to be engaged in a telecom business and if a > contract with your > provider permits you to sub-lease lines. I still don't quite understand the threshold where a telecom license is required. The only telecom service I want to provide is to employees of my company. Do I need a license in your model? Do I meet the criteria? If the criteria include maintaining a billing database and providing wiretap facilities, then I don't. Would that mean my private WAN is illegal? [redacted: addresses for me, my wife, and her home business] So we could easily have three non-aggregatable prefixes at our house. Every organization and every individual would have a non-aggregatable prefix. Do you foresee any routing scalability problems with that? > > > What's a top level licensee? > E.g. FCC in the US or CRTC in Canada. Fees would be variable between countries, and set by the government, not by ARIN and its members. You propose significant regulation of the Internet and what look to me like significant additional costs for Internet access providers, both of which may (depending on how well I understand your proposal) reduce the number of providers and the flexibility of enterprises to bypass them. Who benefits from this? Or, put another way, I don't understand the problem we're trying to solve. Lee From sandy at tislabs.com Thu Oct 5 18:06:49 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 18:06:49 -0400 (EDT) Subject: [ppml] Policy Proposal writing In-Reply-To: Message-ID: <20061005220649.9F46A3F449@pecan.tislabs.com> >>I think it would be really nifty if there was an EASY button for >>converting database entries into PKI certificates. >... >But, yes, it would be nifty, but I wouldn't count on it. No, I am not counting on it. My use of "nifty" was meant to convey a bit of whimsy. --Sandy From sandy at tislabs.com Thu Oct 5 18:03:24 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 18:03:24 -0400 (EDT) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <2ADF5C7F-96FE-4E36-B655-408D58A9DA89@delong.com> Message-ID: <20061005220324.C10D03F446@pecan.tislabs.com> >As was discussed at the Montreal meeting, I just don't see the gain to >adding this to the template. If a recipient wants to provide this >information, >there is a process for providing it in a much more meaningful and useful >form using RPSL in ARIN's (or any of several other) routing registries. The suggestion of using the templates to collect the data had two motivations: - inherit the operator discipline of completing the templates (population of the routing registry is considerably more rare - piggyback on something people are familiar with) - inherit the scrutiny and authentication of the ARIN process of accepting templates If the discipline and scrutiny could be transferred somehow to the routing registry, that's great. The original proposal is a "reduce it to a problem that has already been solved" approach. Note also: security-wise, this is better than the status quo. As Geoff indicated at the mike, security-wise, this is not better than the PKI resource certificate approach. --Sandy From bicknell at ufp.org Thu Oct 5 20:33:10 2006 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 5 Oct 2006 20:33:10 -0400 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-1 In-Reply-To: References: Message-ID: <20061006003309.GA19359@ussenterprise.ufp.org> In a message written on Thu, Oct 05, 2006 at 02:16:46PM +0200, Edward Lewis wrote: > Me too. I applaud Leo's attempt over the past few years, even if > he eventually pulled the work from the table. We need it, and/but > it's a lot of work. Thank you for the perfect segue... While I don't have any proposals this time around I am on the schedule for Thursday with an informational presentation. I'm going to try and approach the problem from a different direction, but if you want to know more you'll have to watch the presentation! -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From sandy at tislabs.com Thu Oct 5 18:03:24 2006 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 5 Oct 2006 18:03:24 -0400 (EDT) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <2ADF5C7F-96FE-4E36-B655-408D58A9DA89@delong.com> Message-ID: <20061005220324.C10D03F446@pecan.tislabs.com> >As was discussed at the Montreal meeting, I just don't see the gain to >adding this to the template. If a recipient wants to provide this >information, >there is a process for providing it in a much more meaningful and useful >form using RPSL in ARIN's (or any of several other) routing registries. The suggestion of using the templates to collect the data had two motivations: - inherit the operator discipline of completing the templates (population of the routing registry is considerably more rare - piggyback on something people are familiar with) - inherit the scrutiny and authentication of the ARIN process of accepting templates If the discipline and scrutiny could be transferred somehow to the routing registry, that's great. The original proposal is a "reduce it to a problem that has already been solved" approach. Note also: security-wise, this is better than the status quo. As Geoff indicated at the mike, security-wise, this is not better than the PKI resource certificate approach. --Sandy From narten at us.ibm.com Thu Oct 5 21:49:27 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 05 Oct 2006 21:49:27 -0400 Subject: [ppml] Fwd: Keeping in reserve In-Reply-To: <20061005212855.4588.qmail@hoster908.com> References: <20061005212855.4588.qmail@hoster908.com> Message-ID: <200610060149.k961nR1e004819@cichlid.raleigh.ibm.com> > In general, bisection seems like a good strategy. The problem with > bisection from my perspective is what happens when the super-block > you are assigning from becomes close to "full." Well, about the time that happens (or well before it, actually!!!), I would hope/expect that there are periodic reports on how allocations are going and how the "reserved" space looks. And we'd ask whether the current "reserve" is doing what is intended and/or whether one needs to start allocating stuff out of a separate and/or bigger block. > Because of the IPv6 policy agreed to between IANA & the RIRs. ARIN > can't go back and get more IPv6 address space until they have > assigned/allocated/reserved 50% of the space they have been given. > At least that is how I read the policy. > (http://www.icann.org/policies/proposed-ipv6-policy-14jul06.htm) This policy can presumably be changed, if there is a good reason to. (And I view this policy as a good first step, but unlikely to be the perfect policy we will want a few years down the road.) And if we were doing sparse allocation, but needed more space in spite of the current policies, presumably we'd figure out how to change the policy. We are also a long way off from needing to do this stuff, I suspect, so we have at least some time to think about it. :-) The point is though, reserving only a /44 is an arbitrary number, and one that we may (say 10 or 20 years from now) view as having been a mistake. It seems prudent not to make these sorts of irreversable decisions now, if there is no real need to. Thomas From Michael.Dillon at btradianz.com Fri Oct 6 04:01:55 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 6 Oct 2006 09:01:55 +0100 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <20061005162928.94C173F497@pecan.tislabs.com> Message-ID: > However, the current ARIN IRR, according to recent messages on the ppml > list, contains information that is pulled in from other IRR sources. > The authenticity of this data can not be verified by ARIN. Sure it can. ARIN is the only one who CAN guarantee its authenticity since ARIN is the one who knows whether the data originated from its delegees or from another IRR. If ARIN adds a data field to all its IRR objects to inform users whether ARIN considers the data to be trustable or not, then ISPs can act accordingly. > For route objects stored in the ARIN IRR, according to information I > was told early this year, ARIN does not presently verify the person > registering the object against POC info in the resource database as > is done for address and AS objects. So ARIN could, but does not, > authenticate this information. ARIN is acting correctly in not authenticating this info because ARIN has no policy that defines the ARIN RIR as a source of trusted data. In the absence of a policy defining the scope of the ARIN IRR, what is the point in worrying about the processes followed internally? --Michael Dillon From Michael.Dillon at btradianz.com Fri Oct 6 04:26:00 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 6 Oct 2006 09:26:00 +0100 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <20061005164501.D2AAB3F4AC@pecan.tislabs.com> Message-ID: > I'm pretty sure that you use https, which might be complex if the > details were all subject to your configuration. > > If the interactions with the resource certificates were as > little needing of configuration, would you be as alarmed? My bank uses https to secure the communication channel so that it is secret and cannot be changed by 3rd parties. However, I still need my name, account number, secret password, and two letters chosen randomly from another secret word before I can gain access to the account. So, if the resource certificate needed as little config as a mere https session then I would be very alarmed indeed. At least https has a HUGE userbase and an equally large number of very smart people working to find potential flaws. This makes me confident in https. The userbase of any resource certification system is so small that the only thing which will make me feel confident in it is if it uses good old fashioned tried and true technology. Things like good business practices, passwords, and an https session to ARIN's web application. Back in the early 1990's it may have been necessary for Internet registries to reinvent the wheel, but in the 21st century we better learn to leverage cheap and effective off-the-shelf technology that is widely used in other business scenarios. ARIN is not an experimental lab. Or a lab rat... --Michael Dillon From Michael.Dillon at btradianz.com Fri Oct 6 04:33:36 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 6 Oct 2006 09:33:36 +0100 Subject: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) In-Reply-To: Message-ID: > I believe that the research and other value of having the > non-specific location data are beneficial to the community and > should be preserved. As such, while I accept the idea of not > publishing complete address information, I still think that it is > a bad idea to stop publishing City and non-specific postal > code information. Non-specific location data... A private residence Chicago A business office Peoria A factory Hamilton A hospital New York What legitimate research need requires more than this? > I remember a number of people coming to the microphone and > talking about their uses of the data. I don't remember CAIDA > being at the meeting, but, I think they use this data on a regular > basis. I know Martin Hannigan outlined several legitimate uses > of the data. Voices in the ether; here today, gone tomorrow. If there is no ARIN document that defines legitimate research uses of ARIN's published whois directory, then the need doesn't exist. Voices in the ether need not apply. --Michael Dillon From marla.azinger at frontiercorp.com Fri Oct 6 04:42:49 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 6 Oct 2006 04:42:49 -0400 Subject: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DCB5@nyrofcs2ke2k01.corp.pvt> Sam- I believe the impression you have is wrong. The objections put forward by the interent community were based on their own objections to this proposal and that they strongly felt adjustments should be made. I dont believe I heard one person not on ARIN staff say "we shouldnt do this because the staff doesnt want it". What I did hear people say was that they acknowledge your point and while they can understand your point they dont believe your policy as it is currently written is the right answer. This is why you have been sent so many suggestion on how to alter your proposal. I believe we work within a very intelligent internet community and they are self thinking people. Regards Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Sam Weiler Sent: Thursday, October 05, 2006 9:03 AM To: william(at)elan.net Cc: ppml at arin.net Subject: Re: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) On Wed, 4 Oct 2006, william(at)elan.net wrote: > I'd like to make additional comment regarding 2006-1 and potentially > offering a way to a solution that solves the issues but does not cause > as many problems and changes with ARIN system. > > As a reminder a primary justification for introducing this seems to > be that full ZIP codes (6 code in Canada or full 9 digit code in US) > and city is in some cases are too specific and is almost the same as > offering full street address. As I said in April[1] and repeated earlier this week[2], my impression from Montreal was that MOST of the objections to 2006-1 were fueled by the staff's concerns about not having access to data they need, not a desire to have city/state/postal codes published for all to see. I don't think we'd heard from many folks who want to use that data about their desire for it, particularly absent a name, street name, and number. If there are such folks out there, I'd really like to hear more about their need, and why it can't be satisfied in some other way. Then we, as a community, can desire whether their need for the data outweighs the individual users' rights to some privacy. Absent such voices, let's deal with the other objections and move along. -- Sam [1] http://lists.arin.net/pipermail/ppml/2006-April/005330.html [2] http://lists.arin.net/pipermail/ppml/2006-October/005712.html _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From ljb at merit.edu Fri Oct 6 05:34:03 2006 From: ljb at merit.edu (Larry Blunk) Date: Fri, 06 Oct 2006 05:34:03 -0400 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <20061005162928.94C173F497@pecan.tislabs.com> References: <20061005162928.94C173F497@pecan.tislabs.com> Message-ID: <4526230B.5020808@merit.edu> Sandy Murphy wrote: >> The policy duplicates >> capabilities of the routing registry and could be addressed by enhancing >> this existing functionality. >> > > It is true that RPSL route objects convey much the same origination > information as is proposed to be collected in templates. > > However, the current ARIN IRR, according to recent messages on the ppml > list, contains information that is pulled in from other IRR sources. > The authenticity of this data can not be verified by ARIN. > > If you are referring to the mirrored registries, these entries are clearly identified by the "source:" attribute. I guess I'm not sure what you mean by "pulled in". While these sources are available when querying the ARIN RR server, they are not actually "in" the ARIN RR (again, as identified by the source: attribute). > For route objects stored in the ARIN IRR, according to information I > was told early this year, ARIN does not presently verify the person > registering the object against POC info in the resource database as > is done for address and AS objects. So ARIN could, but does not, > authenticate this information. > > Because ARIN does authenticate that templates are received from the > proper contact, the info collected in templates has higher assurance. > (OK, not much higher assurance, given the common use of MAIL_FROM, > but still the concept is there.) > > Perhaps existing functionality could be enhanced to provide these > features. OTOH, existing functionality could be enhanced to add > a comment to templates, also. > > > RIPE supports a "mnt-routes:" attribute in their "inetnum" objects which refers to a maintainer in the routing registry who is allowed to create route objects which are covered by the given address space. Note that RIPE does not put AS information in the inetnum objects themselves. One could envision an attribute similar to mnt-routes in the ARIN address registry which would refer to a maintainer in the ARIN IRR who is allowed to create routes in the IRR covered by that address space. This avoids duplicate information in both the address and routing registries and would support existing RPSL based configuration tools. -Larry Blunk Merit From owen at delong.com Fri Oct 6 12:19:18 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Oct 2006 09:19:18 -0700 Subject: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) In-Reply-To: References: Message-ID: <325039B8-1EB1-4E43-86F8-D5F75AA8B80E@delong.com> On Oct 6, 2006, at 1:33 AM, Michael.Dillon at btradianz.com wrote: >> I believe that the research and other value of having the >> non-specific location data are beneficial to the community and >> should be preserved. As such, while I accept the idea of not >> publishing complete address information, I still think that it is >> a bad idea to stop publishing City and non-specific postal >> code information. > > > Non-specific location data... > > A private residence > Chicago > > A business office > Peoria > > A factory > Hamilton > > A hospital > New York > > > What legitimate research need requires more than this? > Research which cares whether you are talking about Peoria, AZ or Peoria, IL, or Peoria, IN for starters. All I am suggesting is: A private residence Chicago, IL 30201 Which I think is not significantly more specific, but, allows for a number of advantages to research over city name alone. First, having the state or province is useful. Second, the partial postal code provides a simpler and more useful input to geolocation. Postal codes tend to be roughly the same amount of geographic area covered, where cities vary widely. For example, San Jose, CA is a much bigger land mass than San Juan Bautista, CA. >> I remember a number of people coming to the microphone and >> talking about their uses of the data. I don't remember CAIDA >> being at the meeting, but, I think they use this data on a regular >> basis. I know Martin Hannigan outlined several legitimate uses >> of the data. > > Voices in the ether; here today, gone tomorrow. > If there is no ARIN document that defines legitimate > research uses of ARIN's published whois directory, then > the need doesn't exist. Voices in the ether need > not apply. > That is absurd. I realize you'd like to eliminate whois altogether, but, I don't think there is consensus for doing so, and whether you like the fact or not, others find this research useful and important. The fact that you do not does not make them voices in the ether, nor does it erase their purpose or make it illegitimate. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From owen at delong.com Fri Oct 6 12:21:28 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Oct 2006 09:21:28 -0700 Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <4526230B.5020808@merit.edu> References: <20061005162928.94C173F497@pecan.tislabs.com> <4526230B.5020808@merit.edu> Message-ID: <9B4DB6CA-331D-4A6A-99DC-DF6F51612F3F@delong.com> I think this is a much better approach and I would support a policy bringing ARIN templates and whois data in line with this approach. Owen > RIPE supports a "mnt-routes:" attribute in their "inetnum" > objects > which refers > to a maintainer in the routing registry who is allowed to create route > objects > which are covered by the given address space. Note that > RIPE does not put AS information in the inetnum objects themselves. > One could envision an attribute similar to mnt-routes in the ARIN > address > registry which would refer to a maintainer in the ARIN IRR who is > allowed to create > routes in the IRR covered by that address space. This avoids > duplicate > information in both the address and routing registries and would > support > existing RPSL based configuration tools. > > -Larry Blunk > Merit > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From heather.skanks at gmail.com Fri Oct 6 17:46:56 2006 From: heather.skanks at gmail.com (heather skanks) Date: Fri, 6 Oct 2006 17:46:56 -0400 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: References: <445B9208.9060700@arin.net> Message-ID: <616812070610061446v22b5efa0k3947bc85c4289eb3@mail.gmail.com> I don't see anything wrong with the AC reccommending that a problem a policy proposal is meant to address, might better be solved or addressed in another manner or in another forum. In fact, I can think of several reasons for why the AC should refer a policy proposal to some other forum and I will give you an example. Last spring we looked at 2005-9 (4 Byte AS Numbers) The policy gives clear dates over the next 3 years and starting in January of 2007, for when ARIN should begin handing out 32 bit AS's and cease to make a distinction between 32 bit and 16 bit AS's. However there is no RFC and only a Internet draft created last fall, that discusses the creation of 4byte AS's. It seemed to me that having the policy go through the local registrar's process, was a bit premature considering that the draft has not gone through the RFC process in IETF and that no hardware supports it. This is a case, where I would have liked to see the AC refer the author to the IETF process to flesh things out a bit more, and if necessary with a nod that "we support this idea" .. As it is now, ARIN can start handing out 32 bit AS's in a little more than 3 months and the draft is still a "proposed standard" "waiting for write up" https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6498 The AC, ARIN and the NRPM are just one part of community that guides the use of number resources. It seems a responsible thing to do, to evaluate policy proposals with consideration for the responsibilities of other resources involved, whether it's IETF, IANA, ICANN, other registrar's, the Board of Trustees, or ARIN staff, and to refer the author or policy to another organization when appropriate. --heather On 9/20/06, Sam Weiler wrote: > > ARIN's mail servers rejected this PPML post the first time. I'm > resending it just to make sure everyone received it. > > On Wed, 20 Sep 2006, Sam Weiler wrote: > > > Earlier this year, the AC rejected two public policy proposals on the > grounds > > that the "matter ... can best be addressed by the ARIN Board of > Trustees." > > [1] [2] > > > > I'd like to hear from each of the ten AC candidates as to whether they > agree > > that it's appropriate to reject a policy proposal merely because there's > > a "better" path for resolving the matter (rather than, for instance, > because > > the matter is "clearly inappropriate" for the public policy process). > > > > To be clear, I'm not asking if the AC made the right call on these > particular > > two proposals -- I'm asking if the candidates think it is appropriate to > > > reject a policy proposal merely because they see a better path to > > accomplishing its stated goals. (e.g., because they think the new > > Consultation and Suggestion Process (ACSP) [3] is a "better" venue for > the > > request than the full public policy process) > > > > Personally, I'm disappointed that the AC would reject a policy proposal > > merely because it would be "best" addressed outside the public policy > process > > rather than because it's "clearly inappropriate" for the public policy > > process -- the public policy process should at least be available as a > > fallback if the "best" path doesn't work or is unacceptable for some > reason. > > > > -- Sam Weiler > > > > [1] http://lists.arin.net/pipermail/ppml/2006-May/005478.html > > [2] http://lists.arin.net/pipermail/ppml/2006-June/005505.html > > [3] http://www.arin.net/about_us/corp_docs/acsp.html > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Fri Oct 6 17:55:59 2006 From: randy at psg.com (Randy Bush) Date: Fri, 06 Oct 2006 11:55:59 -1000 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: <616812070610061446v22b5efa0k3947bc85c4289eb3@mail.gmail.com> References: <445B9208.9060700@arin.net> <616812070610061446v22b5efa0k3947bc85c4289eb3@mail.gmail.com> Message-ID: <4526D0EF.7020707@psg.com> > Last spring we looked at 2005-9 (4 Byte AS Numbers) The policy gives > clear dates over the next 3 years and starting in January of 2007, for > when ARIN should begin handing out 32 bit AS's and cease to make a > distinction between 32 bit and 16 bit AS's. However there is no RFC and > only a Internet draft created last fall, that discusses the creation of > 4byte AS's. It seemed to me that having the policy go through the local > registrar's process, was a bit premature considering that the draft has > not gone through the RFC process in IETF and that no hardware supports > it. This is a case, where I would have liked to see the AC refer the > author to the IETF process to flesh things out a bit more, and if > necessary with a nod that "we support this idea" .. As it is now, ARIN > can start handing out 32 bit AS's in a little more than 3 months and the > draft is still a "proposed standard" "waiting for write up" the internet stopped waiting for the ivtf a while ago. they are good at inventing and embellishing the complex and delaying the obvious. in the meantime, the net kinda has to work. it might be wise if the operational and administrative infrastructures kept in synch. [ btw, the author of the 4-byte asn policy proposal is the same poor sob who is working his draft through the ivtf sausage machine ] randy From william at elan.net Fri Oct 6 19:24:13 2006 From: william at elan.net (william(at)elan.net) Date: Fri, 6 Oct 2006 16:24:13 -0700 (PDT) Subject: [ppml] Staff Comments Regarding Policy Proposal 2006-3 In-Reply-To: <4526230B.5020808@merit.edu> References: <20061005162928.94C173F497@pecan.tislabs.com> <4526230B.5020808@merit.edu> Message-ID: On Fri, 6 Oct 2006, Larry Blunk wrote: > RIPE supports a "mnt-routes:" attribute in their "inetnum" objects > which refers > to a maintainer in the routing registry who is allowed to create route > objects > which are covered by the given address space. Note that > RIPE does not put AS information in the inetnum objects themselves. > One could envision an attribute similar to mnt-routes in the ARIN address > registry which would refer to a maintainer in the ARIN IRR who is > allowed to create > routes in the IRR covered by that address space. This avoids duplicate > information in both the address and routing registries and would support > existing RPSL based configuration tools. The issue is trust in distributed system like this. You may put email address for maintainer in ARIN whois (which would be new contact most likely) and can check if this email address is listed in RR but you're completely at the mercy of RR maintainer to make sure the person who updated their registry was properly authenticated based on that email address at the time that routing registry data was entered. To provide proper verification security for whoever checks the RR you need something like PGP fingerprint (or just public key directly) corresponding to maintainer's PGP key as part of maintainer contact data in ARIN whois and then need PGP signature with RR data. But as I'm sure as some would quickly notice this all looks rather like SIDR.... [oh and did I mention about those fun pk roll-over issues that all come into play for distrbuted PKI like that ...] -- William Leibzon Elan Networks william at elan.net From gih at apnic.net Fri Oct 6 23:36:55 2006 From: gih at apnic.net (Geoff Huston) Date: Sat, 07 Oct 2006 13:36:55 +1000 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: <616812070610061446v22b5efa0k3947bc85c4289eb3@mail.gmail.co m> References: <445B9208.9060700@arin.net> <616812070610061446v22b5efa0k3947bc85c4289eb3@mail.gmail.com> Message-ID: <7.0.0.16.2.20061007124753.014d05b8@apnic.net> Heather, >Last spring we looked at 2005-9 (4 Byte AS Numbers) The policy >gives clear dates over the next 3 years and starting in January of >2007, for when ARIN should begin handing out 32 bit AS's and cease >to make a distinction between 32 bit and 16 bit AS's. However there >is no RFC and only a Internet draft created last fall, that >discusses the creation of 4byte AS's. You may find the following a helpful commentary on the IETF process, as it uses precisely this draft as its example: http://www.isoc.org/tools/blogs/ietfjournal/?p=66#more-66 The first internet draft on the topic, by Rekhter and Chen was submitted to the drafts editor back in September 2001. The current draft is at version 12. The IDR working group has had this on their agenda for 5 years, and 12 sets of revisions were made to the document over this period. This is a document with a rich history of IETF peer review, and in the larger scheme of things, one of the few documents that has accumulated a very extensive review over the years. > It seemed to me that having the policy go through the local > registrar's process, was a bit premature considering that the draft > has not gone through the RFC process in IETF The document was submitted to the Routing Area ADs back in December 2005. It was an expectation at the time that publication would take months rather than years. Yes, it is most unfortunate that the document's progress through the IESG has been glacial, or even geological. IETF last call was made in August and now its a case of awaiting the AD's write up. I do hope that this will occur within weeks rather than consuming further months of what I see as needless delay. The run out date for AS numbers has been a pretty constant projection of October 2010 for some years now (http://www.potaroo.net/tools/asns/), and the industry appears to be competing with this IETF Routing Area AD as to who can be slower in getting things done these days. We have around three years. If we are forced to wait for everything to happen in serial fashion then I'm concerned that we will be caught out. > and that no hardware supports it. Please see http://www.ietf.org/IESG/Implementations/bgp4_impleme.txt The vendors whose hardware supports 4 byte AS numbers in BGP are; Juniper Redback If your vendor is not in the above list then you should talk to them and ask why not. > This is a case, where I would have liked to see the AC refer the > author to the IETF process to flesh things out a bit more, The policy proposal's author has some knowledge of the IETF process, having been an active participant in the IETF since 1989, although not even the author truly appreciated how long a period can elapse these days between working group sign off (October 2005) and publication of an RFC (nothing yet in 12 months) with the document sitting in the Routing Area Director's lap throughout most of that time. Obviously, anyone claiming that the IETF process is fast and efficient these days has not tried to publish a document using its processes. Despite this geological pace of progress in the IETF, that does not negate the overall intention of the policy proposal to provide industry with good advance notice of a change in AS number syntax, and allow folk to plan ahead for this, rather than run around in a paniced blame-shift mode after the exhaustion event wondering what went wrong - again. > and if necessary with a nod that "we support this idea" .. Experience suggest that such a nod would appear to have little impact on the speed of the IETF process, nor the outcome. >As it is now, ARIN can start handing out 32 bit AS's in a little >more than 3 months and the draft is still a "proposed standard" >"waiting for write up" > >https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6498 I agree that it would be strongly preferable to see this document published as a Proposed Standard rather than a draft. And it would be strongly preferable for this to have already been published yesterday rather than some vague and uncommitted "tomorrow." Working with the document authors to produce the implementation report, and advocating within the working group at the start of 2005 that the document was ready for publication as a Proposed Standard, were the activities undertaken by the proposal's author that were intended to ensure that this IETF publication step was completed well before the present time. I'm appalled at the apparent moribund state of parts of the IETF such that you now have to allow up to a 24 month lead time after IETF working group consensus to get a relatively innocuous document, with a three year working group review period, published through the Routing Area of the IETF. It was not what I had anticipated. Nor, might I add, would many others anticipate, or truly appreciate, such protracted delays within the IETF process these days. > >The AC, ARIN and the NRPM are just one part of community that guides >the use of number resources. It seems a responsible thing to do, to >evaluate policy proposals with consideration for the >responsibilities of other resources involved, whether it's IETF, >IANA, ICANN, other registrar's, the Board of Trustees, or ARIN >staff, and to refer the author or policy to another organization >when appropriate. The author of the policy proposal was, and is, mindful of all of these considerations. The author is also mindful of the finite nature of the 16 bit AS number pool. The author is mindful of the rate of consumption of this resource. The author is mindful of the advance notice to vendors required to get any new functionality into deployed BGP, particularly so when the new functionality has marginal relevance to MPLS signalling. And the author is mindful of the critical role of the Internet today and the natural desire of network operators not to make changes to the infrastructure without careful testing and evaluation to ensure that such changes will not bring the entire structure, or even a small part of this structure, down. When I proposed this policy around a year ago it seemed that the policy's timelines allowed more than ample time to consider the policy and more than ample time for the IESG to consider, and publish, the 4 byte AS number draft. At the time both were relatively conservative expectations, based on previous direct experience of having RFCs published through this process. But, alas, the best of intentions and the most careful planning are sometimes just not sufficient, as you have observed. kind regards, Geoff Huston From gih at apnic.net Sat Oct 7 00:01:23 2006 From: gih at apnic.net (Geoff Huston) Date: Sat, 07 Oct 2006 14:01:23 +1000 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: <4526D0EF.7020707@psg.com> References: <445B9208.9060700@arin.net> <616812070610061446v22b5efa0k3947bc85c4289eb3@mail.gmail.com> <4526D0EF.7020707@psg.com> Message-ID: <7.0.0.16.2.20061007135747.02e3f430@apnic.net> >the internet stopped waiting for the ivtf a while ago. they are good at >inventing and embellishing the complex and delaying the obvious. in the >meantime, the net kinda has to work. it might be wise if the >operational and administrative infrastructures kept in synch. > >[ btw, the author of the 4-byte asn policy proposal is the same poor sob >who is working his draft through the ivtf sausage machine ] s/his draft/Enke's and Quaizar's (and Yakov's) draft/ Its these folk were responsible for the good ideas contained in the draft. I'm just trying to see the draft through the process, and I'm trying as hard as I can to interpret the subsequent IETF experience I've had as exceptional rather than exemplary. Geoff From heather.skanks at gmail.com Sat Oct 7 00:19:14 2006 From: heather.skanks at gmail.com (heather skanks) Date: Sat, 7 Oct 2006 00:19:14 -0400 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: <4526D0EF.7020707@psg.com> References: <445B9208.9060700@arin.net> <616812070610061446v22b5efa0k3947bc85c4289eb3@mail.gmail.com> <4526D0EF.7020707@psg.com> Message-ID: <616812070610062119j1177f388tc36ca59faa3aef17@mail.gmail.com> Yes, I know Geoff Houston is behind both the rfc draft and the policy proposals, but I don't find it relevant, just because it's the same person doesn't mean it will ever become an RFC. Isn't the RFC intended to outline what the new AS's are, how the they will be used, make IANA the authority to delegate them to the registrars and give something for the vendors to work with for implementation? (At the very least the latter!!) Just because the system is broke, does that mean that everyone (including the registrars) should just go off and do what they want? That seems like the path to anarchy, especially considering that this is something in which should require global acceptance and implementation. And let me play devil's advocate and ask, is the system really broken? or does it just take too long? Was the system broke last fall when the draft was created? If the author knew it to be broke, why submit a proposal to individual registrars that would change policy in about 6 months, for something you knew wouldn't get through the rfc process by the time it was implemented, and more importantly wouldn't be supported by any vendors? If the plan is to circumvent the rfc process, to motivate vendors, by going directly to individual registrars because the process is "broken", then what other process can be or is in place to make sure that all registrars agree to hand out whatever crazy new number resource thing someone dreams up? What happens when one registrar agrees to hand out something, and another registrar says no.. and there is no parent organization (IANA) doling out ranges, because no one ever informed them? What happens on January 1, 2007 when someone asks ARIN to give them a new 32 bit AS.. will ARIN have any to give out? I don't disagree that the net has to work in the meantime.. it just seems if we go down this path, there is potential for it not to work in the future! I see ARIN AC referring author's to a better path, as an attempt to help keep things in sync. --Heather On 10/6/06, Randy Bush wrote: > > > Last spring we looked at 2005-9 (4 Byte AS Numbers) The policy gives > > clear dates over the next 3 years and starting in January of 2007, for > > when ARIN should begin handing out 32 bit AS's and cease to make a > > distinction between 32 bit and 16 bit AS's. However there is no RFC and > > only a Internet draft created last fall, that discusses the creation of > > 4byte AS's. It seemed to me that having the policy go through the local > > registrar's process, was a bit premature considering that the draft has > > not gone through the RFC process in IETF and that no hardware supports > > it. This is a case, where I would have liked to see the AC refer the > > author to the IETF process to flesh things out a bit more, and if > > necessary with a nod that "we support this idea" .. As it is now, ARIN > > can start handing out 32 bit AS's in a little more than 3 months and the > > draft is still a "proposed standard" "waiting for write up" > > the internet stopped waiting for the ivtf a while ago. they are good at > inventing and embellishing the complex and delaying the obvious. in the > meantime, the net kinda has to work. it might be wise if the > operational and administrative infrastructures kept in synch. > > [ btw, the author of the 4-byte asn policy proposal is the same poor sob > who is working his draft through the ivtf sausage machine ] > > randy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sat Oct 7 00:22:10 2006 From: randy at psg.com (Randy Bush) Date: Fri, 06 Oct 2006 18:22:10 -1000 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: <616812070610062119j1177f388tc36ca59faa3aef17@mail.gmail.com> References: <445B9208.9060700@arin.net> <616812070610061446v22b5efa0k3947bc85c4289eb3@mail.gmail.com> <4526D0EF.7020707@psg.com> <616812070610062119j1177f388tc36ca59faa3aef17@mail.gmail.com> Message-ID: <45272B72.3080505@psg.com> > Yes, I know Geoff Houston is behind both the rfc draft and the policy > proposals, but I don't find it relevant, just because it's the same > person doesn't mean it will ever become an RFC. exercise for process politicians who do not touch routers: how long did we run the bgp we do today without an rfc? randy From heather.skanks at gmail.com Sat Oct 7 00:35:59 2006 From: heather.skanks at gmail.com (heather skanks) Date: Sat, 7 Oct 2006 00:35:59 -0400 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: <616812070610062119j1177f388tc36ca59faa3aef17@mail.gmail.com> References: <445B9208.9060700@arin.net> <616812070610061446v22b5efa0k3947bc85c4289eb3@mail.gmail.com> <4526D0EF.7020707@psg.com> <616812070610062119j1177f388tc36ca59faa3aef17@mail.gmail.com> Message-ID: <616812070610062135t666e4e5eua5c610cac099ed3c@mail.gmail.com> I feel the need to pre-emptively clarify and say, that it is not my intent to say that this draft will or will not become and RFC. Rather that, Geoff being involved with both the proposed policy AND the RFC does not add anything to the speed or odds that this will become an RFC, as I doubt that the policy being passed by the RIR's will affect the RFC process. And for Geoff, I had looked at the history of the draft prior to the ARIN meeting in the spring and just before I sent my previous email. I agree it seems to be a timing issue.. and it is a shame that the IETF process takes so dreadfully long, and gets little attention from the community.. but the question remains, will ARIN have any 32 bit addresses to hand out in January? --Heather On 10/7/06, heather skanks wrote: > > Yes, I know Geoff Houston is behind both the rfc draft and the policy > proposals, but I don't find it relevant, just because it's the same person > doesn't mean it will ever become an RFC. Isn't the RFC intended to outline > what the new AS's are, how the they will be used, make IANA the authority to > delegate them to the registrars and give something for the vendors to work > with for implementation? (At the very least the latter!!) Just because the > system is broke, does that mean that everyone (including the registrars) > should just go off and do what they want? That seems like the path to > anarchy, especially considering that this is something in which should > require global acceptance and implementation. > > And let me play devil's advocate and ask, is the system really broken? or > does it just take too long? Was the system broke last fall when the draft > was created? If the author knew it to be broke, why submit a proposal to > individual registrars that would change policy in about 6 months, for > something you knew wouldn't get through the rfc process by the time it was > implemented, and more importantly wouldn't be supported by any vendors? > If the plan is to circumvent the rfc process, to motivate vendors, by going > directly to individual registrars because the process is "broken", then what > other process can be or is in place to make sure that all registrars agree > to hand out whatever crazy new number resource thing someone dreams up? > What happens when one registrar agrees to hand out something, and another > registrar says no.. and there is no parent organization (IANA) doling out > ranges, because no one ever informed them? What happens on January 1, 2007 > when someone asks ARIN to give them a new 32 bit AS.. will ARIN have any to > give out? > > I don't disagree that the net has to work in the meantime.. it just seems > if we go down this path, there is potential for it not to work in the > future! I see ARIN AC referring author's to a better path, as an attempt > to help keep things in sync. > > --Heather > > > > On 10/6/06, Randy Bush wrote: > > > > > Last spring we looked at 2005-9 (4 Byte AS Numbers) The policy gives > > > clear dates over the next 3 years and starting in January of 2007, for > > > when ARIN should begin handing out 32 bit AS's and cease to make a > > > distinction between 32 bit and 16 bit AS's. However there is no RFC > > and > > > only a Internet draft created last fall, that discusses the creation > > of > > > 4byte AS's. It seemed to me that having the policy go through the > > local > > > registrar's process, was a bit premature considering that the draft > > has > > > not gone through the RFC process in IETF and that no hardware supports > > > it. This is a case, where I would have liked to see the AC refer the > > > > > author to the IETF process to flesh things out a bit more, and if > > > necessary with a nod that "we support this idea" .. As it is now, > > ARIN > > > can start handing out 32 bit AS's in a little more than 3 months and > > the > > > draft is still a "proposed standard" "waiting for write up" > > > > the internet stopped waiting for the ivtf a while ago. they are good at > > inventing and embellishing the complex and delaying the obvious. in the > > > > meantime, the net kinda has to work. it might be wise if the > > operational and administrative infrastructures kept in synch. > > > > [ btw, the author of the 4-byte asn policy proposal is the same poor sob > > who is working his draft through the ivtf sausage machine ] > > > > randy > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sat Oct 7 00:38:08 2006 From: randy at psg.com (Randy Bush) Date: Fri, 06 Oct 2006 18:38:08 -1000 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: <616812070610062135t666e4e5eua5c610cac099ed3c@mail.gmail.com> References: <445B9208.9060700@arin.net> <616812070610061446v22b5efa0k3947bc85c4289eb3@mail.gmail.com> <4526D0EF.7020707@psg.com> <616812070610062119j1177f388tc36ca59faa3aef17@mail.gmail.com> <616812070610062135t666e4e5eua5c610cac099ed3c@mail.gmail.com> Message-ID: <45272F30.4090009@psg.com> heather skanks wrote: > I feel the need to pre-emptively clarify and say, that it is not my > intent to say that this draft will or will not become and RFC. Rather > that, Geoff being involved with both the proposed policy AND the RFC > does not add anything to the speed or odds that this will become an RFC, > as I doubt that the policy being passed by the RIR's will affect the RFC > process. luckily, our routers don't care. the ietf stopped being relevant a long time ago. stop using it as an excuse to make delivering packets to my customers harder. randy From gih at apnic.net Sat Oct 7 00:42:23 2006 From: gih at apnic.net (Geoff Huston) Date: Sat, 07 Oct 2006 14:42:23 +1000 Subject: [ppml] Metric for rejecting policy proposals: AC candidate question In-Reply-To: <616812070610062135t666e4e5eua5c610cac099ed3c@mail.gmail.co m> References: <445B9208.9060700@arin.net> <616812070610061446v22b5efa0k3947bc85c4289eb3@mail.gmail.com> <4526D0EF.7020707@psg.com> <616812070610062119j1177f388tc36ca59faa3aef17@mail.gmail.com> <616812070610062135t666e4e5eua5c610cac099ed3c@mail.gmail.com> Message-ID: <7.0.0.16.2.20061007143903.02cc2dc0@apnic.net> I did not write the draft. Really. I was vocal in the IDR Working Group to say that we should conduct a working group last call and get the document to the IESG for publication. This happened. I believe that the timelines to 2010 are tight and we do need to plan ahead. I did not forsee that the IESG process with respect to this draft would be interminable. Geoff At 02:35 PM 7/10/2006, heather skanks wrote: >I feel the need to pre-emptively clarify and say, that it is not my >intent to say that this draft will or will not become and >RFC. Rather that, Geoff being involved with both the proposed >policy AND the RFC does not add anything to the speed or odds that >this will become an RFC, as I doubt that the policy being passed by >the RIR's will affect the RFC process. > >And for Geoff, I had looked at the history of the draft prior to the >ARIN meeting in the spring and just before I sent my previous >email. I agree it seems to be a timing issue.. and it is a shame >that the IETF process takes so dreadfully long, and gets little >attention from the community.. but the question remains, will ARIN >have any 32 bit addresses to hand out in January? > >--Heather > >On 10/7/06, heather skanks ><heather.skanks at gmail.com> wrote: >Yes, I know Geoff Houston is behind both the rfc draft and the >policy proposals, but I don't find it relevant, just because it's >the same person doesn't mean it will ever become an RFC. Isn't the >RFC intended to outline what the new AS's are, how the they will be >used, make IANA the authority to delegate them to the registrars and >give something for the vendors to work with for implementation? (At >the very least the latter!!) Just because the system is broke, does >that mean that everyone (including the registrars) should just go >off and do what they want? That seems like the path to anarchy, >especially considering that this is something in which should >require global acceptance and implementation. > >And let me play devil's advocate and ask, is the system really >broken? or does it just take too long? Was the system broke last >fall when the draft was created? If the author knew it to be broke, >why submit a proposal to individual registrars that would change >policy in about 6 months, for something you knew wouldn't get >through the rfc process by the time it was implemented, and more >importantly wouldn't be supported by any vendors? If the plan is >to circumvent the rfc process, to motivate vendors, by going >directly to individual registrars because the process is "broken", >then what other process can be or is in place to make sure that all >registrars agree to hand out whatever crazy new number resource >thing someone dreams up? What happens when one registrar agrees to >hand out something, and another registrar says no.. and there is no >parent organization (IANA) doling out ranges, because no one ever >informed them? What happens on January 1, 2007 when someone asks >ARIN to give them a new 32 bit AS.. will ARIN have any to give out? > >I don't disagree that the net has to work in the meantime.. it just >seems if we go down this path, there is potential for it not to work >in the future! I see ARIN AC referring author's to a better path, >as an attempt to help keep things in sync. > >--Heather > > > > >On 10/6/06, Randy Bush < randy at psg.com> wrote: > > Last spring we looked at 2005-9 (4 Byte AS Numbers) The policy gives > > clear dates over the next 3 years and starting in January of 2007, for > > when ARIN should begin handing out 32 bit AS's and cease to make a > > distinction between 32 bit and 16 bit AS's. However there is no RFC and > > only a Internet draft created last fall, that discusses the creation of > > 4byte AS's. It seemed to me that having the policy go through the local > > registrar's process, was a bit premature considering that the draft has > > not gone through the RFC process in IETF and that no hardware supports > > it. This is a case, where I would have liked to see the AC refer the > > author to the IETF process to flesh things out a bit more, and if > > necessary with a nod that "we support this idea" .. As it is now, ARIN > > can start handing out 32 bit AS's in a little more than 3 months and the > > draft is still a "proposed standard" "waiting for write up" > >the internet stopped waiting for the ivtf a while ago. they are good at >inventing and embellishing the complex and delaying the obvious. in the >meantime, the net kinda has to work. it might be wise if the >operational and administrative infrastructures kept in synch. > >[ btw, the author of the 4-byte asn policy proposal is the same poor sob >who is working his draft through the ivtf sausage machine ] > >randy > > > >_______________________________________________ >PPML mailing list >PPML at arin.net >http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Mon Oct 9 04:24:45 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 9 Oct 2006 09:24:45 +0100 Subject: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) In-Reply-To: <325039B8-1EB1-4E43-86F8-D5F75AA8B80E@delong.com> Message-ID: > > What legitimate research need requires more than this? > > > Research which cares whether you are talking about Peoria, AZ or > Peoria, IL, or > Peoria, IN for starters. That is not a definition of LEGITIMATE research. Consider a terrorist who is doing some research to identify the locality of a hated person in order to launch a poison gas attack in that locality. Yes, that is research but it is not legitimate research that ARIN and its members would wish to support. > > If there is no ARIN document that defines legitimate > > research uses of ARIN's published whois directory, then > > the need doesn't exist. Voices in the ether need > > not apply. > > > That is absurd. I realize you'd like to eliminate whois altogether, > but, > I don't think there is consensus for doing so, and whether you like the > fact or not, others find this research useful and important. If it is useful and important then it deserves to be defined in writing in ARIN's policy. --Michael Dillon From owen at delong.com Mon Oct 9 05:07:33 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 9 Oct 2006 02:07:33 -0700 Subject: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) In-Reply-To: References: Message-ID: <784C3740-D1CB-42EC-BDFE-27520C4999CD@delong.com> On Oct 9, 2006, at 1:24 AM, Michael.Dillon at btradianz.com wrote: >>> What legitimate research need requires more than this? >>> >> Research which cares whether you are talking about Peoria, AZ or >> Peoria, IL, or >> Peoria, IN for starters. > > That is not a definition of LEGITIMATE research. > Consider a terrorist who is doing some research to > identify the locality of a hated person in order to > launch a poison gas attack in that locality. > No, it's not a definition, but, it is a description of why the information is useful. There are MANY forms of legitimate research which care about which state a given city is in. These could include research into geographic distribution of traffic patterns hitting a given web site, geographic distribution of traffic traversing a link (to determine optimal location of additional exchange points, for example), etc. > Yes, that is research but it is not legitimate > research that ARIN and its members would wish > to support. > Any resource or data that is published can be used for legitimate or nefarious purposes. The mere fact that someone may be doing something nefarious is not a reason to stop publishing the data. Do you want to stop publishing encyclopedias because they contain information that could be used to build weapons? Data which has only nefarious use should (usually) not be published. Data which has both legitimate and nefarious use should (usually) be published. Data which has only legitimate use is rare, if it exists at all. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From stephen at sprunk.org Mon Oct 9 11:35:08 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 9 Oct 2006 10:35:08 -0500 Subject: [ppml] Comment on "Policy Proposal 2006-1" (ResidentialPrivacy modification) References: Message-ID: <009c01c6ebba$5f0ba180$6801a8c0@atlanta.polycom.com> Thus spake >> > What legitimate research need requires more than this? >> > >> Research which cares whether you are talking about Peoria, AZ or >> Peoria, IL, or Peoria, IN for starters. > > That is not a definition of LEGITIMATE research. > Consider a terrorist who is doing some research to > identify the locality of a hated person in order to > launch a poison gas attack in that locality. > > Yes, that is research but it is not legitimate > research that ARIN and its members would wish > to support. I think we need to extend Godwin's Law to include terrorists. Seriously. If you know the person's identity, there are far easier ways to figure out where they live, work, etc. than WHOIS. The supposed problem with WHOIS is that it lets you _discover_ someone's identity from their IP address, which is a completely different problem. Being able to distinguish between Peoria, AZ, and Peoria, IL, is trivial if we're going to allow even a single digit from the postal code, because that's all you need. You're arguing over a moot point here. And, since you can turn postal codes (in the US, a 5-digit ZIP, which the current proposal allows) into locality and state names via public databases (e.g. usps.com), the point is doubly moot. Removing part of a redundant set of data is useless. I don't see a need to define the particular research people are referring to. First of all, that only addresses research that's already in progress while ignoring whatever people may think of tomorrow. Second, we can easily accomodate unsubstantiated claims while still producing a policy that meets the claimed goal of making it difficult to turn an IP address into an identity. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From weiler at tislabs.com Tue Oct 10 11:24:05 2006 From: weiler at tislabs.com (Sam Weiler) Date: Tue, 10 Oct 2006 11:24:05 -0400 (EDT) Subject: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) In-Reply-To: References: Message-ID: On Wed, 4 Oct 2006, william(at)elan.net wrote: > (in fact for US even 5 letter code is not specific - zip > codes follow density as well so rural territories have very large > areas covered by same zipcode). In Montreal, I presented some results derived from the US Census bureau's ZCTA files (not quite the same as ZIP codes, but pretty close, and pleasantly easy to get to). From my observations, ZIP code density is not particularly even. Pulling some sample numbers: 2655 ZCTA's have fewer than 100 households (out of 33233 ZCTA's with non-zero population). I gave specific examples of ZCTA's scattered across the country with 8-48 households, and there was even a ZCTA within Washington, DC with only 23 households. > Regarding city this is indeed an issue for rural areas where city > may include only a dozen households (in many states they would not > even allow to incorporate in this case). I agree that this needs > to be addressed and there is actually a very simple solution by > allowing County name to be entered in case this is unincorporated > area (which is in fact exactly what is being done right now) as > well as if the city itself is smaller then say 1000 residents - > we can even do it by just renaming "city" field to "city/locality" > and leaving it to the discretion of the ISP if the are entering > actual city name there or name of local territorial unit (township, > borrough, county, etc) if user has privacy concerns. I'm glad you agree that these small areas need to be dealt with. First, as noted above, the issue is the same for ZIP codes and small towns. Second, I have concerns that specifying the details of such a policy would be intractable, particularly given the twenty-six different "countries" in ARIN's service region, some of which are likely to do their own thing with respect to postal codes. Thirdly, I'm concerned that even setting a threshhold to the size of the area identified, even if we agree that it's tractable to use such a threshhold, will wind up providing too little privacy for the end user. -- Sam From info at arin.net Wed Oct 11 09:58:31 2006 From: info at arin.net (Member Services) Date: Wed, 11 Oct 2006 08:58:31 -0500 Subject: [ppml] ARIN XVIII Meeting Report Now Available Message-ID: <003001c6ed3d$56584050$1e00080a@arin.net> The ARIN community recently concluded the ARIN XVIII Public Policy and Members Meetings, held in St. Louis, Missouri, 11-13 October 2006. The meeting report includes presentations, webcast archives, summary notes, and transcripts of these meetings, and is now available on the ARIN website at: http://www.arin.net/meetings/minutes/ARIN_XVIII/ In addition to these files, the page referenced above has links to presentations for the Sunday "Networking with IPv6" workshop and tutorials. We thank all in the community who participated either in person or remotely, and look forward to seeing you all again for ARIN XIX in San Juan, Puerto Rico, 22-25 April 2007. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Oct 11 10:07:09 2006 From: info at arin.net (Member Services) Date: Wed, 11 Oct 2006 09:07:09 -0500 Subject: [ppml] ARIN XVIII Now Underway [corrected] Message-ID: <003101c6ed3e$8b0a6f70$1e00080a@arin.net> The ARIN XVIII Public Policy and Members Meeting is now underway in St. Louis, Missouri. For those in the community unable to make it to St. Louis for the meeting, ARIN is once again offering a webcast of the Public Policy and Members Meetings via RealNetworks Helix Server. The times of the broadcast are as follows (All times are Central Daylight Time (CDT), (UTC/GMT -5 hours): Public Policy Meeting (Policy and technical discussions) Wednesday, 11 October 9AM - 5PM Thursday, 12 October 9AM - 5PM Members Meeting (ARIN reports and speeches by Board, Advisory Council and NRO NC candidates ) Friday, 13 October 9 AM - 12PM For those who already registered to participate remotely, you may send in questions or comments during the times listed above. The full agenda is available at http://www.arin.net/ARIN-XVIII/agenda.html. For details about how to connect to the webcast, or to refer to the Remote Participation Acceptable Use Policy, please see: http://www.arin.net/ARIN-XVIII/webcast.html Regards, Member Services American Registry for Internet Numbers (ARIN) P.S. Apologies for the premature posting of the meeting report availability. From Michael.Dillon at btradianz.com Wed Oct 11 10:49:06 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 11 Oct 2006 15:49:06 +0100 Subject: [ppml] ARIN XVIII Meeting Report Now Available In-Reply-To: <003001c6ed3d$56584050$1e00080a@arin.net> Message-ID: > The ARIN community recently concluded the ARIN XVIII Public Policy ^^^^^^^^^ > and Members Meetings, held in St. Louis, Missouri, 11-13 October 2006. Is that so...? ;-) From william at elan.net Wed Oct 11 14:31:31 2006 From: william at elan.net (william(at)elan.net) Date: Wed, 11 Oct 2006 11:31:31 -0700 (PDT) Subject: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) In-Reply-To: References: Message-ID: On Tue, 10 Oct 2006, Sam Weiler wrote: > On Wed, 4 Oct 2006, william(at)elan.net wrote: > >> (in fact for US even 5 letter code is not specific - zip >> codes follow density as well so rural territories have very large >> areas covered by same zipcode). > > In Montreal, I presented some results derived from the US Census > bureau's ZCTA files (not quite the same as ZIP codes, but pretty > close, and pleasantly easy to get to). From my observations, > ZIP code density is not particularly even. Its due to some special zip codes (i.e. for a university, government district) which would have few or no residential users. But for residential or normal city area they generally match except cases when smallcommunities are just way too far apart. But even then its not like dozen houses - its always measured in thousands of residents for each postal office. Now what does happen is that few areas have lost population but still retained separate zip code - now managed from some other post office. But actually there is no point in arguing about these rare corner cases - the proposal before was to make 3 digits of zip code required (including for US zip codes), which would make it possible to only include general geographic area if somebody is worried. >> Regarding city this is indeed an issue for rural areas where city >> may include only a dozen households (in many states they would not >> even allow to incorporate in this case). I agree that this needs >> to be addressed and there is actually a very simple solution by >> allowing County name to be entered in case this is unincorporated >> area (which is in fact exactly what is being done right now) as >> well as if the city itself is smaller then say 1000 residents - >> we can even do it by just renaming "city" field to "city/locality" >> and leaving it to the discretion of the ISP if the are entering >> actual city name there or name of local territorial unit (township, >> borrough, county, etc) if user has privacy concerns. > > I'm glad you agree that these small areas need to be dealt with. They are in a way already dealt with in practice, i.e. if you ever bothered to check, you'd see that it hapenns regular that large nearby city is entered instead of small suburban town or country name for rural area [would have been easier if I they actually added 'County' at the end instead of me having to guess it based on zip code]. This way of dealing with the issue just never been officialized by arin policies. > First, as noted above, the issue is the same for ZIP codes and small > towns. > > Second, I have concerns that specifying the details of such a policy > would be intractable, particularly given the twenty-six different > "countries" in ARIN's service region, some of which are likely to do > their own thing with respect to postal codes. I'm sure policy can be worked out to account for it (i.e. postal code entry requirement is 3 letters/digits except when country has no postal code or its postal code is 3 letters or less in which case entering it is not required). And do note that nobody from those countries has spoken - so don't presume that you can assume the residential privacy has the same issues there. > Thirdly, I'm concerned that even setting a threshhold to the size of > the area identified, even if we agree that it's tractable to use such > a threshhold, will wind up providing too little privacy for the end > user. And as I've noted I'm concerned that policy proposal justification is being made due to corner cases that are < 0.01% of arin db (and not even by those actually impacted or ISPs serving them) but proposal is done in such a way that would have very very wide scale difference for everyone else. -- William Leibzon Elan Networks william at elan.net From marla.azinger at frontiercorp.com Wed Oct 11 15:14:40 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 11 Oct 2006 15:14:40 -0400 Subject: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D04044@nyrofcs2ke2k01.corp.pvt> Very well said William. Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of william(at)elan.net Sent: Wednesday, October 11, 2006 11:32 AM To: Sam Weiler Cc: ppml at arin.net Subject: Re: [ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification) On Tue, 10 Oct 2006, Sam Weiler wrote: > On Wed, 4 Oct 2006, william(at)elan.net wrote: > >> (in fact for US even 5 letter code is not specific - zip >> codes follow density as well so rural territories have very large >> areas covered by same zipcode). > > In Montreal, I presented some results derived from the US Census > bureau's ZCTA files (not quite the same as ZIP codes, but pretty > close, and pleasantly easy to get to). From my observations, > ZIP code density is not particularly even. Its due to some special zip codes (i.e. for a university, government district) which would have few or no residential users. But for residential or normal city area they generally match except cases when smallcommunities are just way too far apart. But even then its not like dozen houses - its always measured in thousands of residents for each postal office. Now what does happen is that few areas have lost population but still retained separate zip code - now managed from some other post office. But actually there is no point in arguing about these rare corner cases - the proposal before was to make 3 digits of zip code required (including for US zip codes), which would make it possible to only include general geographic area if somebody is worried. >> Regarding city this is indeed an issue for rural areas where city >> may include only a dozen households (in many states they would not >> even allow to incorporate in this case). I agree that this needs >> to be addressed and there is actually a very simple solution by >> allowing County name to be entered in case this is unincorporated >> area (which is in fact exactly what is being done right now) as >> well as if the city itself is smaller then say 1000 residents - >> we can even do it by just renaming "city" field to "city/locality" >> and leaving it to the discretion of the ISP if the are entering >> actual city name there or name of local territorial unit (township, >> borrough, county, etc) if user has privacy concerns. > > I'm glad you agree that these small areas need to be dealt with. They are in a way already dealt with in practice, i.e. if you ever bothered to check, you'd see that it hapenns regular that large nearby city is entered instead of small suburban town or country name for rural area [would have been easier if I they actually added 'County' at the end instead of me having to guess it based on zip code]. This way of dealing with the issue just never been officialized by arin policies. > First, as noted above, the issue is the same for ZIP codes and small > towns. > > Second, I have concerns that specifying the details of such a policy > would be intractable, particularly given the twenty-six different > "countries" in ARIN's service region, some of which are likely to do > their own thing with respect to postal codes. I'm sure policy can be worked out to account for it (i.e. postal code entry requirement is 3 letters/digits except when country has no postal code or its postal code is 3 letters or less in which case entering it is not required). And do note that nobody from those countries has spoken - so don't presume that you can assume the residential privacy has the same issues there. > Thirdly, I'm concerned that even setting a threshhold to the size of > the area identified, even if we agree that it's tractable to use such > a threshhold, will wind up providing too little privacy for the end > user. And as I've noted I'm concerned that policy proposal justification is being made due to corner cases that are < 0.01% of arin db (and not even by those actually impacted or ISPs serving them) but proposal is done in such a way that would have very very wide scale difference for everyone else. -- William Leibzon Elan Networks william at elan.net _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From info at arin.net Wed Oct 11 18:46:50 2006 From: info at arin.net (Member Services) Date: Wed, 11 Oct 2006 18:46:50 -0400 Subject: [ppml] Proposed Policy: Changes to IPv6 initial allocation criteria Message-ID: <452D745A.3010409@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. Since this proposal was received within 10 days of the next scheduled meeting of the ARIN Advisory Council, the review period will be extended to the regularly scheduled meeting that occurs after the upcoming meeting. If the AC accepts the proposal or reaches an agreement with the author, then the proposal will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal or can not reach an agreement with the author, then the AC will notify the community of their decision with an explanation; at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Changes to IPv6 initial allocation criteria Author: Jordi Palet Martinez Proposal Version: 1 Submission Date: 11/10/2006 Proposal type: delete Policy term: permanent Policy statement: Delete section 6.5.1.1 d. of NRPM Rationale: The existing policy is fine for an existing and known ISP in the ARIN region, but is not considering the case of new ISPs, which may want to start offering IPv6 services. Is artificial to ask them for start with IPv4 services (which typically will do, but not necessarily), wait for weeks/months (?) to be "known", and then come back for the IPv6 allocation request. In addition to that, they need to have a plan for more than 200 /48 assignments. The first question here is that there is room for business with one or just a few IPv6 customers, and it seems irrational not allowing this type of business to be possible, may be even it can be considered against the anti-trust regulations. Second point is regarding the usage of the /48. An ISP may decide to assign a different prefix size, example a cellular operator with probably will use /64. Is important to clarify that the "200" comes from historical reasons when this proposal was jointly developed with RIPE and APNIC, but the situation is that other regions such as LACNIC and AfriNIC already got rid of this requirement, and in both, RIPE and APNIC is under discussion. This may even bring to a possible "untrue" plan to be suggested by an ISP if he needs to get an IPv6 prefix allocated. Regarding the restriction of the usage in 5 years, I think is enough with the criteria indicated in c that the address space is advertised, as there is no ISP interested in getting a prefix which is not being used. Is an operational cost that doesn't make sense if there is not business beyond covering it, never mind if we talk about a few months or a few years. In summary, the proposal will allow new ISPs, ISPs with a reduced number of customers, or ISPs willing to offer only IPv6 services, to immediately access this resource. No financial/liability implications for the community and ARIN are foreseen, on the other way around, it will allow ARIN better fulfilling its mission. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From jeroen at unfix.org Wed Oct 11 20:42:53 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 12 Oct 2006 01:42:53 +0100 Subject: [ppml] Proposed Policy: Changes to IPv6 initial allocation criteria In-Reply-To: <452D745A.3010409@arin.net> References: <452D745A.3010409@arin.net> Message-ID: <452D8F8D.90104@spaghetti.zurich.ibm.com> Member Services wrote: [..] > Policy Proposal Name: Changes to IPv6 initial allocation criteria [..] > In addition to that, they need to have a plan for more than 200 /48 > assignments. The first question here is that there is room for business > with one or just a few IPv6 customers, and it seems irrational not > allowing this type of business to be possible, may be even it can be > considered against the anti-trust regulations. There is already an IPv6 PI policy which covers these cases. Startup ISP's that need >=/32 address space can start out using the PI policy and don't need to be covered by the PA policy. If a startup can demonstrate the need for >=/44 which one can get with the IPv6 PI policy then they can under the current PA policy already get this space without much hassle or ado. Applying this 'delete' to the current PA policy will only make the PA policy so blatantly open that there will (maybe ;) be a landrush on the >=/32's blocks, effectively creating, again, the "class A" situation for early adopters even though the requesting entity will never use the full address space of the /32. Remember that 65536 /48's is a *lot* of space. As such, startups can use the PI policy which should satisfy their needs. Others, larger established ISP's, can use the PA policy. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From kloch at kl.net Wed Oct 11 21:29:37 2006 From: kloch at kl.net (Kevin Loch) Date: Wed, 11 Oct 2006 21:29:37 -0400 Subject: [ppml] Proposed Policy: Changes to IPv6 initial allocation criteria In-Reply-To: <452D8F8D.90104@spaghetti.zurich.ibm.com> References: <452D745A.3010409@arin.net> <452D8F8D.90104@spaghetti.zurich.ibm.com> Message-ID: <452D9A81.30907@kl.net> Jeroen Massar wrote: > There is already an IPv6 PI policy which covers these cases. > Startup ISP's that need >=/32 address space can start out using the PI > policy and don't need to be covered by the PA policy. If a startup can > demonstrate the need for >=/44 which one can get with the IPv6 PI policy > then they can under the current PA policy already get this space without > much hassle or ado. The current policy seems to prohibit this migration path. You should not apply for a PI /48 if your intent is to be an ISP and should not apply for a /32 if your intent was to use it as an end site. Allowing or requiring ISP's to go from a PI /48 to a /32 would mean each ISP having at least two prefixes. This kind of slow-start induced address fragmentation accounts for about half of the more specifics seen in IPv4 tables today. We should try to avoid that. Reducing the minimum for ISP allocations from /32 to something smaller would be ok as long as the same space (currently /29) is reserved for future expansion to prevent fragmentation, and it is made from the ISP address pool. If the requirements are reduced then it probably would be a good idea to reduce the minimum allocation size. > Applying this 'delete' to the current PA policy will only make the PA > policy so blatantly open that there will (maybe ;) be a landrush on the >> =/32's blocks, effectively creating, again, the "class A" situation for > early adopters even though the requesting entity will never use the full > address space of the /32. Remember that 65536 /48's is a *lot* of space. As you point out, anything less than the current policy would basically be a no justification "shall issue" /32 policy, and I do not support that either. > As such, startups can use the PI policy which should satisfy their > needs. Others, larger established ISP's, can use the PA policy. As noted above, startups that cannot come up with the plan required in 6.5.1.1 (d) could use PA space to establish themselves as an ISP, but should not use the PI policy if the plan to be an ISP. - Kevin From andrew.dul at quark.net Thu Oct 12 10:22:10 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Thu, 12 Oct 2006 14:22:10 +0000 Subject: [ppml] Proposed Policy: Changes to IPv6 initial allocation criteria Message-ID: <20061012142210.26919.qmail@hoster908.com> > Policy statement: > > Delete section 6.5.1.1 d. of NRPM > > d: be an existing, known ISP in the ARIN region or have a plan for making at least 200 /48 assignments to other > organizations within five years. My main understanding of why this policy might be needed is that some feel that the 200 /48 assignments is an arbitrary requirement. Some feel that this type of requirement would encourage a smaller LIR to provide false information to ARIN in order to obtain PA address space. If the problem is with the 200 /48 requirements, I would suggest just striking the words ?at least 200? from the policy rather than removing the entire requirement. I do not think that small ISPs should use the PI address space policy to a bootstrap to getting PA address space later. Andrew From stephen at sprunk.org Thu Oct 12 12:29:54 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 12 Oct 2006 11:29:54 -0500 Subject: [ppml] Proposed Policy: Changes to IPv6 initial allocationcriteria References: <20061012142210.26919.qmail@hoster908.com> Message-ID: <00f301c6ee1e$c99ee0a0$6501a8c0@atlanta.polycom.com> Thus spake "Andrew Dul" >> Policy statement: >> >> Delete section 6.5.1.1 d. of NRPM >> >> d: be an existing, known ISP in the ARIN region or have a plan for >> making at least 200 /48 assignments to other organizations within >> five >> years. > > My main understanding of why this policy might be needed is that > some feel that the 200 /48 assignments is an arbitrary requirement. > Some feel that this type of requirement would encourage a smaller > LIR to provide false information to ARIN in order to obtain PA address > space. > > If the problem is with the 200 /48 requirements, I would suggest just > striking the words "at least 200" from the policy rather than removing > the entire requirement. The requirement, as I understand it, is to prevent allocations to "flash in the pan" startups who have no track record or orgs who are not really LIRs from getting a routing table slot; the latter was a major concern before the PI policy was adopted (e.g. WTF did Cisco, IBM, et al qualify as LIRs and get /32s?). A lot of this hinges on the ARIN staff's interpretation of "have a plan". I would hope that any startup ISP with a reasonable business model would be accepted as "having a plan", and virtually no ISP is going to be economically viable without at least 200 customers. There may be some specialized orgs that cater to specific niches which might be under 200 users, but those would likely qualify under the "known ISP" category, or their customers may be large enough to get PI space now anyways. The other thing is that a small ISP is most likely to start up as a PA customer of another ISP; asking them to accumulate N customers before getting their own routing table slot seems reasonable, though there's room for debate on what N should be. I'd like to see stats on how many ISPs have been _denied_ an allocation under the existing rules, and why. I'd also be curious if ARIN's counsel has any comments on the anti-trust implications mentioned in the rationale. If neither of those turns up a motivation for change, I'm against this proposal by default on the grounds it's a solution in search of a problem. > I do not think that small ISPs should use the PI address space policy > to a bootstrap to getting PA address space later. Agreed; I'd rather have LIRs lying about their customer counts to get PA space than have them using PI space, which is specifically intended for direct assignment to end users. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From jordi.palet at consulintel.es Thu Oct 12 13:10:22 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 12 Oct 2006 12:10:22 -0500 Subject: [ppml] Proposed Policy: Changes to IPv6 initial allocationcriteria In-Reply-To: <00f301c6ee1e$c99ee0a0$6501a8c0@atlanta.polycom.com> Message-ID: Hi Stephen, My comments below, in-line. Regards, Jordi > De: Stephen Sprunk > Responder a: > Fecha: Thu, 12 Oct 2006 11:29:54 -0500 > Para: Andrew Dul , ARIN PPML > Asunto: Re: [ppml] Proposed Policy: Changes to IPv6 initial allocationcriteria > > Thus spake "Andrew Dul" >>> Policy statement: >>> >>> Delete section 6.5.1.1 d. of NRPM >>> >>> d: be an existing, known ISP in the ARIN region or have a plan for >>> making at least 200 /48 assignments to other organizations within >>> five >>> years. >> >> My main understanding of why this policy might be needed is that >> some feel that the 200 /48 assignments is an arbitrary requirement. >> Some feel that this type of requirement would encourage a smaller >> LIR to provide false information to ARIN in order to obtain PA address >> space. >> >> If the problem is with the 200 /48 requirements, I would suggest just >> striking the words "at least 200" from the policy rather than removing >> the entire requirement. > > The requirement, as I understand it, is to prevent allocations to "flash > in the pan" startups who have no track record or orgs who are not really > LIRs from getting a routing table slot; the latter was a major concern > before the PI policy was adopted (e.g. WTF did Cisco, IBM, et al qualify > as LIRs and get /32s?). This requirement comes from an historical perspective of the original policy developed jointly by APNIC, ARIN and RIPE NCC. Any allocation may "flash in the pan", but this is another issue, and that's why we have recovery processes. > > A lot of this hinges on the ARIN staff's interpretation of "have a > plan". I would hope that any startup ISP with a reasonable business > model would be accepted as "having a plan", and virtually no ISP is > going to be economically viable without at least 200 customers. There > may be some specialized orgs that cater to specific niches which might > be under 200 users, but those would likely qualify under the "known ISP" > category, or their customers may be large enough to get PI space now > anyways. A problem frequently raised by several RIRs with different policy proposals is that how a RIR staff "interprets" wordings as "have a plan". A plan may be good enough for them, but not for the community. It seems to me that there is a subtle line here ... I disagree in your vision that having less than 200 customers is not economically viable. There are many ISPs all around the world that have just a dozen of "big" customers, enough the be on business. And if that ISP is a new business, will not qualify as per the "known ISP" category. > > The other thing is that a small ISP is most likely to start up as a PA > customer of another ISP; asking them to accumulate N customers before > getting their own routing table slot seems reasonable, though there's > room for debate on what N should be. I think a small or new ISP doesn't necessarily going to have just one upstream provider. Even if has a single upstream, what about the cost of renumbering the ISP and its customers if he decides to change the upstream or just add a second upstream in a second stage ? How do you define that N is reasonable for 200 or any other number ? That's always absolutely subjective, and I don't think we do the right thing, as a community, setting up policies that are subjective in their terms or in their implementation by the RIR staff. > > I'd like to see stats on how many ISPs have been _denied_ an allocation > under the existing rules, and why. I'd also be curious if ARIN's > counsel has any comments on the anti-trust implications mentioned in the > rationale. If neither of those turns up a motivation for change, I'm > against this proposal by default on the grounds it's a solution in > search of a problem. > >> I do not think that small ISPs should use the PI address space policy >> to a bootstrap to getting PA address space later. > > Agreed; I'd rather have LIRs lying about their customer counts to get PA > space than have them using PI space, which is specifically intended for > direct assignment to end users. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From pesherb at yahoo.com Thu Oct 12 13:31:23 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Thu, 12 Oct 2006 10:31:23 -0700 (PDT) Subject: [ppml] ARIN member in good standing? In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4037A33F5@CL-S-EX-1.stanleyassociates.com> Message-ID: <20061012173123.59256.qmail@web54712.mail.yahoo.com> > I think you suggest having a database server at every hub, > gathering data for all circuits there, and transmitting > summaries hourly to a central server, followed by a purge. > You're still tracking millions of packets per second, > hopefully without introducing latency, and rack space isn't > cheap. By the same logic energy suppliers have counters at each point of consumption. For the Internet it is reversed with counters at each point of origination. > If your proposal requires Internet providers to bill in a certain > way, we don't have the authority to adopt it. Providers will follow the model naturally when it is clearly defined. > > "Proper" means following the basic logic of a process. > > I don't think that's what it means. That's what it means in this context. E.g. on the Internet someone who wants to distribute their data incurrs costs. > I have it on good authority that the Internet isn't trucks, > it's tubes. Sure, the facility fits the nature of the commodity it carries. > Another difference: we don't push electrons. Individual > electrons don't move very far at all. Data have no mass. Yes, data have no mass but the data carrier has it. How do you move the data without burning some energy? > The basic issue at hand, though, is why the trucking model > would be substantially better than the status quo. The model equips all participants with a guiding principle, e.g. originator of the data pays for the volume / destination. It assumes that market forces sort out the details. On the Internet there are at least two clear destinations: within the AS and outside the AS. > You say it's straightforward, but what are those criteria? According to the Telecommunications Act of Canada: "Canadian carrier'' means a telecommunications common carrier that is subject to the legislative authority of Parliament; "telecommunications common carrier'' means a person who owns or operates a transmission facility used by that person or another person to provide telecommunications services to the public for compensation; Apparently all you need is registering your business indicating "telecommunications" among your activities. Consequently you become regulated by the authorities. > Does that mean that coffee shops need licenses? Only if they chose. > If I set up private interconnects between my enterprise network and four > of my vendors, do I need a license? Your choice. As long as all five run data within the private network sharing costs and not profiting you are not a carrier and not a subject to regulations / fees. At the same time you may well need a block of PI addresses. > > suggested fees. > How strong are the suggestions? It is up to the license office to decide. It assumes that the office wants to support the competitiveness of their economy. > >For the start we may want to reserve more space and start experimenting with > >less. > > Do you have a proposal? Enterprise market first. If autoconfiguration is a must then /96. Otherwise /64. Reservation happens at /16. > I think your proposal is to have the tax and licensing > organizations provide ARIN a subscriber count. ARIN needs > more information... Do we ask the organization for > more information, or train the tax and licensing agenices to > collect network diagrams and virtual host counts? >From the office get only a number of licensees with the subscriber count (for fee calculation). For all the rest use the current ARIN process. > I still don't quite understand the threshold where a telecom > license is required. The only telecom service I want to > provide is to employees of my company. Do I need a license > in your model? Do I meet the criteria? If the criteria > include maintaining a billing database and providing wiretap > facilities, then I don't. Would that mean my private WAN is > illegal? You are not in violation as long as you are not profiting from telecom services you provide. > So we could easily have three non-aggregatable prefixes at > our house. Every organization and every individual would > have a non-aggregatable prefix. Do you foresee any routing > scalability problems with that? Not really assuming that IPv6 prime practical benefit is for private networks to track devices / automate processes. > Fees would be variable between countries, and set by the > government, not by ARIN and its members. That is probably practical in a world with different economies where governments pursue local competitiveness. Global market forces would take care of fees as long as all RIR adopt a common and "fair" PI address allocation policy. > You propose significant regulation of the Internet and what > look to me like significant additional costs for Internet > access providers, both of which may (depending on how well > I understand your proposal) reduce the number of providers > and the flexibility of enterprises to bypass them. Who > benefits from this? > > Or, put another way, I don't understand the problem The model aims at identifying a fundamental cost driver on the Internet, e.g. a certain amount of electrons carrying data from the origination point to its destination. Subsequent arrangements will follow naturally shaped by whichever local circumstances. --- "Howard, W. Lee" wrote: > > -----Original Message----- > > From: Peter Sherbin [mailto:pesherb at yahoo.com] > > Sent: Tuesday, October 03, 2006 12:06 AM > > To: Howard, W. Lee; ppml at arin.net > > Subject: Re: [ppml] ARIN member in good standing? > > > > > Can you describe the data capture mechanism? I mentioned the > > > billing system that would be required. Even if you discard > > > payload and only keep source and destination addresses and packet > > > size, you're talking about increasing network load by a > > > significant amount (30%?). Billing data for an OC3 could be > > > 16TB per month. Multiply hundreds of circuits times a five-year > > > record-retention policy, and I get a 97PB database. > > > > Assumption: need to count sent volumes only. A sending > > network or a node (SN) is > > identified by its source address (SA). SN is connected to > > provider's distribution > > router (DR). DR counts the length of all packets sent from SA > > and reports the total > > number of bits to a database server. > > Yes, that's the math I was doing. I had inferred from > something you said earlier that you might charge different > rates per destination. Even if not, if you have a 128 bit > address field and a 16 bit length field, at a million packets > per second, it's still a couple of terabytes per month. > That's a good-sized database, and that's just one OC3. > > I think you suggest having a database server at every hub, > gathering data for all circuits there, and transmitting > summaries hourly to a central server, followed by a purge. > You're still tracking millions of packets per second, > hopefully without introducing latency, and rack space isn't > cheap. > > > > > I don't understand "unpaid volumes." You bill your customers. > > > > In some cases volume based billing is announced but it may > > not necessarily be > > enforced. Billing works OK for burstable circuits. A regular > > T1 would be provisioned > > to accommodate e.g. about 0.5Mbps at a busy hour. Three T1s > > on a single DR may have > > different usage patterns. E.g. one transmits at 1.2Mbps > > during 3hrs in the morning. > > Second sends at 1.1Mbps at night for 6hrs. The third sends at > > 0.3Mbps 24hrs daily > > with occasional bursts up to 1.5Mbps. Each pays $1,200 but > > over the month #1 have > > sent 49GB, #2 = 89GB, #3 = 110GB. Sometimes providers would > > go after "abusers" who > > exceed average usage tens or hundreds times. "Abusers" can be > > looked at as an > > opportunity assuming they have a need to move data and are > > willing to pay for it. > > Sorry for leading the topic this way. How and what ARIN > members charge for services is completely off-topic. If > your proposal requires Internet providers to bill in a certain > way, we don't have the authority to adopt it. > > > > You keep saying "proper," as if to say that there is an established > > > right way to do things. > > > > "Proper" means following the basic logic of a process. > > I don't think that's what it means. > > > E.g. in a world of a regular > > mail or cargo shipments a sender pays for moving a certain > > number of molecules over > > distance. Energy wise how does moving electrons fundamentally > > differ from moving > > molecules? If electrons are too many to count let's define a > > countable network unit representing a fair amount of > > electrons. > > I have it on good authority that the Internet isn't trucks, > it's tubes. > > The fundamental difference is that there's no Internet > oligopoly. In shipping, you have a single carrier end-to-end. > In telecom, you may have two or three carriers, but they look > the same, because of heredity and regulation. > > Another difference: we don't push electrons. Individual > electrons don't move very far at all. Data have no mass. > > The basic issue at hand, though, is why the trucking model > would be substantially better than the status quo. > > > > > I am not familiar with telecommunications licensing, but I do not > > > have the impression that licenses are available to anyone. My > > > impression is that the "certain criteria" are high. Does each > > > coffee shop and private interconnect have to get a license? > > > > The process is straightforward, as long as you meet all > > "high" criteria you will get > > the license. If network services are defined and regulated > > then anyone who falls > > under that definition is a subject to a license. > > You say it's straightforward, but what are those criteria? > Does that mean that coffee shops need licenses? If I set up > private interconnects between my enterprise network and four > of my vendors, do I need a license? > > > > > So does this mean a new kind of governmental licensing agency, > > > which works closely with the government tax collection agency, > > > and the two agencies direct ARIN? > > > > It is a matter of coordination between already established > > agencies, e.g. Tax and > > FCC. Agencies feed ARIN with the number of subscribers by > > provider as well as > > suggested fees. ARIN autonomously performs address allocation > > practice. ARIN > > collects fees from all holders of licenses for network services. > > How strong are the suggestions? > > > > I'm unclear on the taxpayer-node relationship. Each taxpaying > > > individual with a tax ID gets an allocation? What size? > > > > Taxpayers are not homogeneous and need segmentation. How many > > addresses is enough > > for a single individual? Assuming that at some point we will > > start fixing genes and > > that human DNA consists of about 3 billion base pairs will > > /96 be enough? For the > > start we may want to reserve more space and start > > experimenting with less. > > Do you have a proposal? > > > > Each taxpaying organization with a tax ID get an allocation? > > > What size? > > > > Depending on what they can justify. Current ARIN approach > > works well here. > > I think your proposal is to have the tax and licensing > organizations provide ARIN a subscriber count. ARIN needs > more information than that. Do we ask the organization for > more information, or train the tax and licensing agenices to > collect network diagrams and virtual host counts? > > > > > I was talking about IP address allocation. Say my company has > > > offices in 14 states and two provinces, with leased lines between > > > them, and three Internet connections. Do I get three assignments > > > from my carriers, or 14? Or since I have leased lines, do I get a > > > telecom license? > > > > You will get your PI assignment directly from ARIN in the > > amount you can justify. > > Whichever provider(s) serve your Internet connection(s) they > > will report it to ARIN. > > You will get a telecom license if you meet all of the > > criteria for it in your region > > and if you want to be engaged in a telecom business and if a > > contract with your > > provider permits you to sub-lease lines. > > I still don't quite understand the threshold where a telecom > license is required. The only telecom service I want to > provide is to employees of my company. Do I need a license > in your model? Do I meet the criteria? If the criteria > include maintaining a billing database and providing wiretap > facilities, then I don't. Would that mean my private WAN is > illegal? > > > [redacted: addresses for me, my wife, and her home business] > > So we could easily have three non-aggregatable prefixes at > our house. Every organization and every individual would > have a non-aggregatable prefix. Do you foresee any routing > scalability problems with that? > > > > > > What's a top level licensee? > > E.g. FCC in the US or CRTC in Canada. > > Fees would be variable between countries, and set by the > government, not by ARIN and its members. > > > > You propose significant regulation of the Internet and what > look to me like significant additional costs for Internet > access providers, both of which may (depending on how well > I understand your proposal) reduce the number of providers > and the flexibility of enterprises to bypass them. Who > benefits from this? > > Or, put another way, I don't understand the problem we're > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From terry.l.davis at boeing.com Thu Oct 12 13:55:27 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Thu, 12 Oct 2006 10:55:27 -0700 Subject: [ppml] Proposed Policy: Changes to IPv6 initialallocationcriteria In-Reply-To: Message-ID: <0D090F1E0F5536449C7E6527AFFA280A01BD28BA@XCH-NW-8V1.nw.nos.boeing.com> Jordi/Stephen/Andrew As you consider your address allocation planning, consider that there will be industry groups asking for allocations that will region-wide or global for inter-industry communications that are not ISP's. Take care Terry > -----Original Message----- > From: JORDI PALET MARTINEZ [mailto:jordi.palet at consulintel.es] > Sent: Thursday, October 12, 2006 10:10 AM > To: ppml at arin.net > Subject: Re: [ppml] Proposed Policy: Changes to IPv6 > initialallocationcriteria > > Hi Stephen, > > My comments below, in-line. > > Regards, > Jordi > > > > > > De: Stephen Sprunk > > Responder a: > > Fecha: Thu, 12 Oct 2006 11:29:54 -0500 > > Para: Andrew Dul , ARIN PPML > > Asunto: Re: [ppml] Proposed Policy: Changes to IPv6 initial > allocationcriteria > > > > Thus spake "Andrew Dul" > >>> Policy statement: > >>> > >>> Delete section 6.5.1.1 d. of NRPM > >>> > >>> d: be an existing, known ISP in the ARIN region or have a plan for > >>> making at least 200 /48 assignments to other organizations within > >>> five > >>> years. > >> > >> My main understanding of why this policy might be needed is that > >> some feel that the 200 /48 assignments is an arbitrary requirement. > >> Some feel that this type of requirement would encourage a smaller > >> LIR to provide false information to ARIN in order to obtain PA address > >> space. > >> > >> If the problem is with the 200 /48 requirements, I would suggest just > >> striking the words "at least 200" from the policy rather than removing > >> the entire requirement. > > > > The requirement, as I understand it, is to prevent allocations to "flash > > in the pan" startups who have no track record or orgs who are not really > > LIRs from getting a routing table slot; the latter was a major concern > > before the PI policy was adopted (e.g. WTF did Cisco, IBM, et al qualify > > as LIRs and get /32s?). > > This requirement comes from an historical perspective of the original > policy > developed jointly by APNIC, ARIN and RIPE NCC. > > Any allocation may "flash in the pan", but this is another issue, and > that's > why we have recovery processes. > > > > > A lot of this hinges on the ARIN staff's interpretation of "have a > > plan". I would hope that any startup ISP with a reasonable business > > model would be accepted as "having a plan", and virtually no ISP is > > going to be economically viable without at least 200 customers. There > > may be some specialized orgs that cater to specific niches which might > > be under 200 users, but those would likely qualify under the "known ISP" > > category, or their customers may be large enough to get PI space now > > anyways. > > A problem frequently raised by several RIRs with different policy > proposals > is that how a RIR staff "interprets" wordings as "have a plan". A plan may > be good enough for them, but not for the community. It seems to me that > there is a subtle line here ... > > I disagree in your vision that having less than 200 customers is not > economically viable. There are many ISPs all around the world that have > just > a dozen of "big" customers, enough the be on business. And if that ISP is > a > new business, will not qualify as per the "known ISP" category. > > > > > The other thing is that a small ISP is most likely to start up as a PA > > customer of another ISP; asking them to accumulate N customers before > > getting their own routing table slot seems reasonable, though there's > > room for debate on what N should be. > > I think a small or new ISP doesn't necessarily going to have just one > upstream provider. > > Even if has a single upstream, what about the cost of renumbering the ISP > and its customers if he decides to change the upstream or just add a > second > upstream in a second stage ? > > How do you define that N is reasonable for 200 or any other number ? > That's > always absolutely subjective, and I don't think we do the right thing, as > a > community, setting up policies that are subjective in their terms or in > their implementation by the RIR staff. > > > > > I'd like to see stats on how many ISPs have been _denied_ an allocation > > under the existing rules, and why. I'd also be curious if ARIN's > > counsel has any comments on the anti-trust implications mentioned in the > > rationale. If neither of those turns up a motivation for change, I'm > > against this proposal by default on the grounds it's a solution in > > search of a problem. > > > >> I do not think that small ISPs should use the PI address space policy > >> to a bootstrap to getting PA address space later. > > > > Agreed; I'd rather have LIRs lying about their customer counts to get PA > > space than have them using PI space, which is specifically intended for > > direct assignment to end users. > > > > S > > > > Stephen Sprunk "God does not play dice." --Albert Einstein > > CCIE #3723 "God is an inveterate gambler, and He throws the > > K5SSS dice at every possible opportunity." --Stephen Hawking > > > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From jordi.palet at consulintel.es Thu Oct 12 14:14:00 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 12 Oct 2006 13:14:00 -0500 Subject: [ppml] Proposed Policy: Changes to IPv6 initialallocationcriteria In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A01BD28BA@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: Hi Terry, Not sure if I'm getting your point here. In my opinion those industry groups may be considered ISPs and then will fall into the existing allocation criteria (with or w/o the proposed modifications). Otherwise, they will fall into the IPv6 PI category ? Regards, Jordi > De: "Davis, Terry L" > Responder a: > Fecha: Thu, 12 Oct 2006 10:55:27 -0700 > Para: , > Conversaci?n: [ppml] Proposed Policy: Changes to IPv6 > initialallocationcriteria > Asunto: RE: [ppml] Proposed Policy: Changes to IPv6 initialallocationcriteria > > Jordi/Stephen/Andrew > > As you consider your address allocation planning, consider that there > will be industry groups asking for allocations that will region-wide or > global for inter-industry communications that are not ISP's. > > Take care > Terry > >> -----Original Message----- >> From: JORDI PALET MARTINEZ [mailto:jordi.palet at consulintel.es] >> Sent: Thursday, October 12, 2006 10:10 AM >> To: ppml at arin.net >> Subject: Re: [ppml] Proposed Policy: Changes to IPv6 >> initialallocationcriteria >> >> Hi Stephen, >> >> My comments below, in-line. >> >> Regards, >> Jordi >> >> >> >> >>> De: Stephen Sprunk >>> Responder a: >>> Fecha: Thu, 12 Oct 2006 11:29:54 -0500 >>> Para: Andrew Dul , ARIN PPML >>> Asunto: Re: [ppml] Proposed Policy: Changes to IPv6 initial >> allocationcriteria >>> >>> Thus spake "Andrew Dul" >>>>> Policy statement: >>>>> >>>>> Delete section 6.5.1.1 d. of NRPM >>>>> >>>>> d: be an existing, known ISP in the ARIN region or have a plan > for >>>>> making at least 200 /48 assignments to other organizations within >>>>> five >>>>> years. >>>> >>>> My main understanding of why this policy might be needed is that >>>> some feel that the 200 /48 assignments is an arbitrary requirement. >>>> Some feel that this type of requirement would encourage a smaller >>>> LIR to provide false information to ARIN in order to obtain PA > address >>>> space. >>>> >>>> If the problem is with the 200 /48 requirements, I would suggest > just >>>> striking the words "at least 200" from the policy rather than > removing >>>> the entire requirement. >>> >>> The requirement, as I understand it, is to prevent allocations to > "flash >>> in the pan" startups who have no track record or orgs who are not > really >>> LIRs from getting a routing table slot; the latter was a major > concern >>> before the PI policy was adopted (e.g. WTF did Cisco, IBM, et al > qualify >>> as LIRs and get /32s?). >> >> This requirement comes from an historical perspective of the original >> policy >> developed jointly by APNIC, ARIN and RIPE NCC. >> >> Any allocation may "flash in the pan", but this is another issue, and >> that's >> why we have recovery processes. >> >>> >>> A lot of this hinges on the ARIN staff's interpretation of "have a >>> plan". I would hope that any startup ISP with a reasonable business >>> model would be accepted as "having a plan", and virtually no ISP is >>> going to be economically viable without at least 200 customers. > There >>> may be some specialized orgs that cater to specific niches which > might >>> be under 200 users, but those would likely qualify under the "known > ISP" >>> category, or their customers may be large enough to get PI space now >>> anyways. >> >> A problem frequently raised by several RIRs with different policy >> proposals >> is that how a RIR staff "interprets" wordings as "have a plan". A plan > may >> be good enough for them, but not for the community. It seems to me > that >> there is a subtle line here ... >> >> I disagree in your vision that having less than 200 customers is not >> economically viable. There are many ISPs all around the world that > have >> just >> a dozen of "big" customers, enough the be on business. And if that ISP > is >> a >> new business, will not qualify as per the "known ISP" category. >> >>> >>> The other thing is that a small ISP is most likely to start up as a > PA >>> customer of another ISP; asking them to accumulate N customers > before >>> getting their own routing table slot seems reasonable, though > there's >>> room for debate on what N should be. >> >> I think a small or new ISP doesn't necessarily going to have just one >> upstream provider. >> >> Even if has a single upstream, what about the cost of renumbering the > ISP >> and its customers if he decides to change the upstream or just add a >> second >> upstream in a second stage ? >> >> How do you define that N is reasonable for 200 or any other number ? >> That's >> always absolutely subjective, and I don't think we do the right thing, > as >> a >> community, setting up policies that are subjective in their terms or > in >> their implementation by the RIR staff. >> >>> >>> I'd like to see stats on how many ISPs have been _denied_ an > allocation >>> under the existing rules, and why. I'd also be curious if ARIN's >>> counsel has any comments on the anti-trust implications mentioned in > the >>> rationale. If neither of those turns up a motivation for change, > I'm >>> against this proposal by default on the grounds it's a solution in >>> search of a problem. >>> >>>> I do not think that small ISPs should use the PI address space > policy >>>> to a bootstrap to getting PA address space later. >>> >>> Agreed; I'd rather have LIRs lying about their customer counts to > get PA >>> space than have them using PI space, which is specifically intended > for >>> direct assignment to end users. >>> >>> S >>> >>> Stephen Sprunk "God does not play dice." --Albert Einstein >>> CCIE #3723 "God is an inveterate gambler, and He throws the >>> K5SSS dice at every possible opportunity." --Stephen Hawking >>> >>> >>> _______________________________________________ >>> PPML mailing list >>> PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/ppml >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Bye 6Bone. Hi, IPv6 ! >> http://www.ipv6day.org >> >> This electronic message contains information which may be privileged > or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be > aware >> that any disclosure, copying, distribution or use of the contents of > this >> information, including attached files, is prohibited. >> >> >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Thu Oct 12 14:34:23 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 12 Oct 2006 13:34:23 -0500 Subject: [ppml] Proposed Policy: Changes to IPv6 initial allocation criteria In-Reply-To: <20061012142210.26919.qmail@hoster908.com> Message-ID: Hi Andrew, I see your point. I don't think that makes too much difference and the people that apply for a prefix is really because they want to do business with that prefix. However, I agree that an alternative text (removing also the /48) could be: "be an existing, known ISP in the ARIN region or have a plan for making assignments to other organizations within five years." My understanding is that this is different policy proposal and I will be happy to submit it also, so we have two choices (this one a bit more "conservative"). The question here is to ask for ARIN staff or AC advise. Should I submit one more proposal, or can both choices somehow be considered as part of the same one ? Regards, Jordi > De: Andrew Dul > Responder a: Andrew Dul > Fecha: Thu, 12 Oct 2006 14:22:10 +0000 > Para: > Asunto: Re: [ppml] Proposed Policy: Changes to IPv6 initial allocation > criteria > >> Policy statement: >> >> Delete section 6.5.1.1 d. of NRPM >> >> d: be an existing, known ISP in the ARIN region or have a plan for making at >> least 200 /48 assignments to other > organizations within five years. > > My main understanding of why this policy might be needed is that some feel > that the 200 /48 assignments is an arbitrary requirement. Some feel that this > type of requirement would encourage a smaller LIR to provide false information > to ARIN in order to obtain PA address space. > > If the problem is with the 200 /48 requirements, I would suggest just striking > the words ?at least 200? from the policy rather than removing the entire > requirement. > > I do not think that small ISPs should use the PI address space policy to a > bootstrap to getting PA address space later. > > Andrew > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From terry.l.davis at boeing.com Thu Oct 12 14:36:51 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Thu, 12 Oct 2006 11:36:51 -0700 Subject: [ppml] Proposed Policy: Changes to IPv6initialallocationcriteria In-Reply-To: Message-ID: <0D090F1E0F5536449C7E6527AFFA280A01BD28BF@XCH-NW-8V1.nw.nos.boeing.com> Jordi I think you got it. Consider the electric power industry and aviation whose companies, products, and parts MUST communicate control and status information regionally or globally in order for the industry to function. I like your first sentence,that view would work nicely. Take care Terry > -----Original Message----- > From: JORDI PALET MARTINEZ [mailto:jordi.palet at consulintel.es] > Sent: Thursday, October 12, 2006 11:14 AM > To: ppml at arin.net > Subject: Re: [ppml] Proposed Policy: Changes to > IPv6initialallocationcriteria > > Hi Terry, > > Not sure if I'm getting your point here. > > In my opinion those industry groups may be considered ISPs and then will > fall into the existing allocation criteria (with or w/o the proposed > modifications). Otherwise, they will fall into the IPv6 PI category ? > > Regards, > Jordi > > > > > > De: "Davis, Terry L" > > Responder a: > > Fecha: Thu, 12 Oct 2006 10:55:27 -0700 > > Para: , > > Conversaci?n: [ppml] Proposed Policy: Changes to IPv6 > > initialallocationcriteria > > Asunto: RE: [ppml] Proposed Policy: Changes to IPv6 > initialallocationcriteria > > > > Jordi/Stephen/Andrew > > > > As you consider your address allocation planning, consider that there > > will be industry groups asking for allocations that will region-wide or > > global for inter-industry communications that are not ISP's. > > > > Take care > > Terry > > > >> -----Original Message----- > >> From: JORDI PALET MARTINEZ [mailto:jordi.palet at consulintel.es] > >> Sent: Thursday, October 12, 2006 10:10 AM > >> To: ppml at arin.net > >> Subject: Re: [ppml] Proposed Policy: Changes to IPv6 > >> initialallocationcriteria > >> > >> Hi Stephen, > >> > >> My comments below, in-line. > >> > >> Regards, > >> Jordi > >> > >> > >> > >> > >>> De: Stephen Sprunk > >>> Responder a: > >>> Fecha: Thu, 12 Oct 2006 11:29:54 -0500 > >>> Para: Andrew Dul , ARIN PPML > >>> Asunto: Re: [ppml] Proposed Policy: Changes to IPv6 initial > >> allocationcriteria > >>> > >>> Thus spake "Andrew Dul" > >>>>> Policy statement: > >>>>> > >>>>> Delete section 6.5.1.1 d. of NRPM > >>>>> > >>>>> d: be an existing, known ISP in the ARIN region or have a plan > > for > >>>>> making at least 200 /48 assignments to other organizations within > >>>>> five > >>>>> years. > >>>> > >>>> My main understanding of why this policy might be needed is that > >>>> some feel that the 200 /48 assignments is an arbitrary requirement. > >>>> Some feel that this type of requirement would encourage a smaller > >>>> LIR to provide false information to ARIN in order to obtain PA > > address > >>>> space. > >>>> > >>>> If the problem is with the 200 /48 requirements, I would suggest > > just > >>>> striking the words "at least 200" from the policy rather than > > removing > >>>> the entire requirement. > >>> > >>> The requirement, as I understand it, is to prevent allocations to > > "flash > >>> in the pan" startups who have no track record or orgs who are not > > really > >>> LIRs from getting a routing table slot; the latter was a major > > concern > >>> before the PI policy was adopted (e.g. WTF did Cisco, IBM, et al > > qualify > >>> as LIRs and get /32s?). > >> > >> This requirement comes from an historical perspective of the original > >> policy > >> developed jointly by APNIC, ARIN and RIPE NCC. > >> > >> Any allocation may "flash in the pan", but this is another issue, and > >> that's > >> why we have recovery processes. > >> > >>> > >>> A lot of this hinges on the ARIN staff's interpretation of "have a > >>> plan". I would hope that any startup ISP with a reasonable business > >>> model would be accepted as "having a plan", and virtually no ISP is > >>> going to be economically viable without at least 200 customers. > > There > >>> may be some specialized orgs that cater to specific niches which > > might > >>> be under 200 users, but those would likely qualify under the "known > > ISP" > >>> category, or their customers may be large enough to get PI space now > >>> anyways. > >> > >> A problem frequently raised by several RIRs with different policy > >> proposals > >> is that how a RIR staff "interprets" wordings as "have a plan". A plan > > may > >> be good enough for them, but not for the community. It seems to me > > that > >> there is a subtle line here ... > >> > >> I disagree in your vision that having less than 200 customers is not > >> economically viable. There are many ISPs all around the world that > > have > >> just > >> a dozen of "big" customers, enough the be on business. And if that ISP > > is > >> a > >> new business, will not qualify as per the "known ISP" category. > >> > >>> > >>> The other thing is that a small ISP is most likely to start up as a > > PA > >>> customer of another ISP; asking them to accumulate N customers > > before > >>> getting their own routing table slot seems reasonable, though > > there's > >>> room for debate on what N should be. > >> > >> I think a small or new ISP doesn't necessarily going to have just one > >> upstream provider. > >> > >> Even if has a single upstream, what about the cost of renumbering the > > ISP > >> and its customers if he decides to change the upstream or just add a > >> second > >> upstream in a second stage ? > >> > >> How do you define that N is reasonable for 200 or any other number ? > >> That's > >> always absolutely subjective, and I don't think we do the right thing, > > as > >> a > >> community, setting up policies that are subjective in their terms or > > in > >> their implementation by the RIR staff. > >> > >>> > >>> I'd like to see stats on how many ISPs have been _denied_ an > > allocation > >>> under the existing rules, and why. I'd also be curious if ARIN's > >>> counsel has any comments on the anti-trust implications mentioned in > > the > >>> rationale. If neither of those turns up a motivation for change, > > I'm > >>> against this proposal by default on the grounds it's a solution in > >>> search of a problem. > >>> > >>>> I do not think that small ISPs should use the PI address space > > policy > >>>> to a bootstrap to getting PA address space later. > >>> > >>> Agreed; I'd rather have LIRs lying about their customer counts to > > get PA > >>> space than have them using PI space, which is specifically intended > > for > >>> direct assignment to end users. > >>> > >>> S > >>> > >>> Stephen Sprunk "God does not play dice." --Albert Einstein > >>> CCIE #3723 "God is an inveterate gambler, and He throws the > >>> K5SSS dice at every possible opportunity." --Stephen Hawking > >>> > >>> > >>> _______________________________________________ > >>> PPML mailing list > >>> PPML at arin.net > >>> http://lists.arin.net/mailman/listinfo/ppml > >> > >> > >> > >> > >> ********************************************** > >> The IPv6 Portal: http://www.ipv6tf.org > >> > >> Bye 6Bone. Hi, IPv6 ! > >> http://www.ipv6day.org > >> > >> This electronic message contains information which may be privileged > > or > >> confidential. The information is intended to be for the use of the > >> individual(s) named above. If you are not the intended recipient be > > aware > >> that any disclosure, copying, distribution or use of the contents of > > this > >> information, including attached files, is prohibited. > >> > >> > >> > >> _______________________________________________ > >> PPML mailing list > >> PPML at arin.net > >> http://lists.arin.net/mailman/listinfo/ppml > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From andrew.dul at quark.net Thu Oct 12 14:56:53 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Thu, 12 Oct 2006 18:56:53 +0000 Subject: [ppml] Proposed Policy: Changes to IPv6 initial allocation criteria Message-ID: <20061012185655.11479.qmail@hoster908.com> > -------Original Message------- > From: JORDI PALET MARTINEZ > Subject: Re: [ppml] Proposed Policy: Changes to IPv6 initial allocation criteria > Sent: 12 Oct '06 10:34 > > Hi Andrew, > > I see your point. > > I don't think that makes too much difference and the people that apply for a > prefix is really because they want to do business with that prefix. However, > I agree that an alternative text (removing also the /48) could be: > > "be an existing, known ISP in the ARIN region or have a plan for making > assignments to other organizations within five years." > > My understanding is that this is different policy proposal and I will be > happy to submit it also, so we have two choices (this one a bit more > "conservative"). > > The question here is to ask for ARIN staff or AC advise. Should I submit one > more proposal, or can both choices somehow be considered as part of the same > one ? > I don't think we need seperate policies. I don't see the differences between them as very large. I would hope over time that people would draw to consenus on one version of the text. I think that can be done through the mailing list and at the next meeting. Andrew From tvest at pch.net Thu Oct 12 14:43:41 2006 From: tvest at pch.net (Tom Vest) Date: Thu, 12 Oct 2006 14:43:41 -0400 Subject: [ppml] ARIN member in good standing? In-Reply-To: <20061012173123.59256.qmail@web54712.mail.yahoo.com> References: <20061012173123.59256.qmail@web54712.mail.yahoo.com> Message-ID: <426F261F-63AD-4BF2-A40C-20E1ED092AE9@pch.net> On Oct 12, 2006, at 1:31 PM, Peter Sherbin wrote: >> Or, put another way, I don't understand the problem > > The model aims at identifying a fundamental *cost driver* on the > Internet, e.g. a > certain amount of electrons carrying data from the origination > point to its > destination. Subsequent arrangements will follow naturally shaped > by whichever local > circumstances. *(emphasis mine)* Are you suggesting that incremental cost of service delivery should the basis for pricing inter-provider network services? Would that rule also apply to provider-to-end customer pricing? Should costs define the upper as well as lower limit for pricing? Who calculates what costs "really" are? You proposal suggests to me that you don't think the market is taking care of at least some elements of this equation now -- i.e., that pricing is "irrational" in the economic sense. Could this perception be based on the fact that some pricing and "arrangements" are based on regional/global rather than locally bounded circumstances? Put another way, doesn't your proposal entail the elimination of bypass and the restoration of closed territorial markets (aka "local circumstance sovereignty") that only exchange traffic at the border? Do you think that markets like that -- there are still many many around the world -- are more rational, and should be emulated? Forgive my cognitive dissonance, but we got to where we are today because globalization (erosion of local market sovereignty) exposed places with different prices and cost structures to pressure from the prices and cost structures of other places, i.e., "competition." Your proposed goal of exposing cost drivers is redundant if local costs continue to be subject to extra-local competition, and your proposed mechanism for exposing costs would almost certainly devolve into a mechanism for eliminating such competition. Or am I missing some element that might forestall this outcome? TV From marla.azinger at frontiercorp.com Fri Oct 13 11:32:28 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 13 Oct 2006 11:32:28 -0400 Subject: [ppml] Multihome Pro Con Document Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D0405E@nyrofcs2ke2k01.corp.pvt> Hello- Attached is a living document, version 1.0 on IPv6 Multi-homing Solutions and their Pro's and Con's. This document will be housed on the NRO site in the near future. Due the number of requests and the large immediate interest in this document, I am sending it out ahead of the posting on NRO. NRO link is soon to come. This document attempts to address all the IPv6 Multi-homing Solutions and their Pro's and Con's, put forward by the Internet Community as a collective. The use of this document is intended for the sole purpose of providing clarification of the IPv6 Multi-homing Solutions and their pro's and con's, in order to assist the Internet Community on deciding what solution are currently available to use Globally as a United Internet Community. The ultimate solution may or may not be as written in this document. However, these are the suggested solutions put forward to date and the ones we have to work with and adjust as needed. Additional suggested solutions and pro's and con's will be added to this document as members in the Internet Community bring them forward. Please send any additions you would like to see added to this living document in the same format as the document currently reads. I understand this is a difficult subject with alot of angles and opinions, and as much as I enjoy listening to all of the above, please only send straightward applicable suggestions and pro's and con's. I thank everyone for their time spent on this subject and look forward to working on the resolution of our IPv6 routing issue. <> Thank you for your time spent on IPv6 Marla Azinger Frontier Communications ARIN AC -------------- next part -------------- A non-text attachment was scrubbed... Name: MultihomeIPv6procon.doc Type: application/msword Size: 157696 bytes Desc: MultihomeIPv6procon.doc URL: From info at arin.net Fri Oct 13 14:31:07 2006 From: info at arin.net (Member Services) Date: Fri, 13 Oct 2006 14:31:07 -0400 Subject: [ppml] Policy Proposal 2006-1: Residential Customer Privacy - Abandoned Message-ID: <452FDB6B.2000509@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2006-1: Residential Customer Privacy. It has determined that there is no community consensus in favor of the proposal and should thus be abandoned. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 12 October 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVIII/mem.html In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 20 October 2006. The current policy proposal text is provided below and is also available http://www.arin.net/policy/proposals/2006_1.html The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-1: Residential Customer Privacy Policy statement Proposal type: modify (NRPM sections 4.2.3.7.6 and 6.5.5.1) Policy Term: permanent An organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private customer - XYZ Network', and the customer's entire address may be replaced with 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. NRPM Section 3.2 on Distributed Information Server Use Requirements (from policy proposal 2003-5) is also updated by striking the words "that includes displaying only the city, state, zip code, and country". Policy Rationale This policy allows for a residential customer's entire physical address to be suppressed, not just the street name and number. It also removes the US-centric phrases "state" and "zip code" from the NRPM, reflecting ARIN's broader service area. In many cases, a postal code or even a city name can identify few enough individuals, particularly considering the set of those likely to have their own IP assignments, that the intent of policy proposal 2003-3 is constructively defeated. Timetable for implementation: Immediately upon approval. From info at arin.net Fri Oct 13 14:31:18 2006 From: info at arin.net (Member Services) Date: Fri, 13 Oct 2006 14:31:18 -0400 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal infrastructure - Last Call Message-ID: <452FDB76.10404@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 12 October 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVIII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2006_2.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 27 October 2006. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure Policy statement Proposal type: modify Policy term: permanent Policy statement: 6.10.1 Micro-allocations for Internal Infrastructure Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide technical justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations must be allocated from specific blocks reserved only for this purpose. Policy Rationale Organizations that have only a single aggregate may require additional noncontiguous IP space for their internal infrastructure. This space should not be routed in the global Internet routing table. This will provide for the protection of internal infrastructure and support for applications that are sensitive to long convergence times like VoIP. It is important to note that the additional prefix allocation will not negatively impact the global routing table size as the additional prefix should not be routed. BGP Re-Convergence ISPs use BGP to originate their aggregate from multiple nodes within their infrastructure. They do this by routing their aggregate to discard on multiple devices. This ensures the Internet can reach the aggregate even when one or more nodes fail. If the next hop for a route is reachable via an aggregate that is in the routing table, then failures affecting the reachability of the next hop are subject to BGP hold timers, which can cause traffic to be dropped for the length of the bgp hold time (typically 3 minutes) The BGP re-convergence problem results when a multi-homed customer is announcing the same route to two different edge routers. When the edge router sourcing the primary path fails, the local address which is acting as the next hop, is removed from the IGP. If the next hop is still reachable through an aggregate or covering route, then the route will not be immediately invalidated in bgp. Until the bgp session with the failed device times out, traffic will be drawn to the device originating the aggregate, which is routed to discard and traffic will be dropped. After the bgp session with the failed device times out, the route will be removed and the next best route will be used. To minimize route failover time, you must ensure that the local addresses of the infrastructure, that act as next-hops for Internet routes, are NOT numbered with addresses that are a more specific than the aggregate. A detailed description of the problem space follows in the next three paragraphs. Having BGP next-hops that are not aggregated can cause faster convergence for customers who have multiple links to multiple routers of a single upstream AS. Take the case where a customer has two connections, link1 to edge-router1 and link2 to edge-router2, to a single upstream AS. The customer has an eBGP session with the loopback 2001:DB8::1/128 on edge-router1 and with loopback 2001:DB8::2/128 on edge-router2. The customer advertises a single prefix 2001:DB8:1000::/48 to both edge-router1 and edge-router2. The edge routers set next-hop self. The upstream ISP will have two paths to the prefix 2001:DB8:1000::/48, one with a protocol next-hop of 2001:DB8::1 and one with a protocol next-hop of 2001:DB8::2. Assume the upstream ISP's entire network prefers the path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 due to lower BGP MED value. Also assume that all of the address space owned by the upstream ISP is 2001:DB8::/32, and the loopbacks of both edge routers are a more specific of the aggregate /32. The upstream ISP has a pull-up route for 2001:DB8::/32 in the core of the network. This allows for the aggregation of all the more specific routes of 2001:DB8::/32. It insures the stability of the 2001:DB8::/32 announcement, while preventing an isolated edge router from advertising reachability to the network. If edge-router1 fails then 2001:DB8::1/128 will be immediately removed from the IGP. The preferred prefix for 2001:DB8:1000::/48 with a next-hop of 2001:DB8::1 will remain a valid bgp route and will continue to be the best path because 2001:DB8::1 is reachable through the pull-up route 2001:DB8::/32. Traffic will get blackholed for up to three minutes (BGP default hold time) until the BGP prefix 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 times out. Only then will traffic get forwarded to the next best path for 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::2. If instead the loopbacks of the edge routers (or any BGP protocol next-hop addresses) are not part of the 2001:DB8::/32 aggregate, and there is no aggregate that covers the edge router loopbacks, then convergence will be much quicker. Assume that edge-router1 is using 2001:408::1 and edge-router2 is using 2001:408::2, and the only pull-up route is 2001:DB8::/32. In this case once edge-router1 fails, the IGP will detect it and remove 2001:408::1/128 from the IGP. This will invalidate the preferred path to 201:DB8:1000::/48 with a protocol next-hop of 2001:408:1 as there will be no route to the next hop (or even a less specific of this address). Once the path is invalidated, then the next best path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:408::2 will be declared best. Convergence times will be on the order of magnitude of the IGP failure detection and path re-calculation, typically less than one second. --------------- | Core Router |static route | |2001:DB8::/32 discard ----+------+--- | | / \ /-------------/ \--------\ / \ / /----------------------------\ \ | | | | ------+---+-- --+---+------ |Core Router|static route |Core Router|static route | |2001:DB8::/32 discard | |2001:DB8::/32 discard ---------+--- ---------+--- | | ---------+--------- ---------+--------- | edge-router1 | | edge-router2 | | 2001:DB8::1/128 | | 2001:DB8::2/128 | ---------+--------- ---------+--------- | | \ link1 link2 / \------------\ /---------/ \ / | | ----+---------+---- | CPE | | | ---------+--------- | LAN 2001:DB8:1000::/48 Internal Infrastructure Security Considerations Internal infrastructure could be numbered out of space that is not routed or reachable by the public Internet. This could be used to secure internal only services in a multi-layered approach by filtering direct network connections in the forwarding plane, and not routing the network in the global Internet routing table. Internal services which could take advantage of these layers of protection include: SNMP services, iBGP mesh, Out-of-Band management network(s), remote access to the network devices that make up the network in question. A layered security approach will help to prevent breaches in security via singular config management problems. Additionally, having all of the services out of an aggregate block will simplify the configuration management situation. In essence, this allows for a two tier approach of protecting infrastructure, both in the control plane by not routing the network, and in the forwarding plane by utilizing packet filters which are easily constructed and managed due to the uniqueness of the internal infrastructure block. Private Address Considerations Private addresses are not appropriate for a number of reasons. A public Internet network using private addresses internally may create confusion if trace routes contain private addresses. Additional problems may result due to wide spread filtering of private address space. ICMP messages may get dropped due to such a policy. This can lead to perceived odd behavior and make troubleshooting difficult. Additionally, the consequences of accidentally routing private ip space that is not globally unique, are potentially worse than if you accidentally announced globally unique space. DNS for private address space is today provided by blackhole-1.iana.org. and blackhole-2.iana.org. A provider who wants to maintain forward and reverse DNS sanity has to hijack those ip addresses to provide consistent DNS resolution. This will cause any users who's traffic transits that provider's network to also get 'inconsistent' answers with respect to the private address space in question. For management and troubleshooting purposes, it is important that infrastructure which provides Internet route reachability be numbered with addresses that resolve through DNS. Also, global uniqueness of addressing is important in minimizing renumbering efforts as organizations (and their networks) merge. RFC 4193 provides for neither of these needs. Timetable for implementation: Immediate From info at arin.net Fri Oct 13 14:31:33 2006 From: info at arin.net (Member Services) Date: Fri, 13 Oct 2006 14:31:33 -0400 Subject: [ppml] Policy Proposal 2006-3: Capturing Originations in Templates - Last Call Message-ID: <452FDB85.6070906@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy Proposal 2006-3: Capturing Originations in Templates and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 12 October 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVIII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2006_3.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 27 October 2006. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-3: Capturing Originations in Templates Policy statement Proposal type: new Policy term: permanent Policy statement: ARIN will collect an optional field in all IPv4 and IPv6 address block transactions (allocation and assignment requests, reallocation and reassignment actions, transfer and experimental requests). This additional field will be used to record a list of the ASes that the user permits to originate address prefixes within the address block. ARIN will produce a collection of the mappings from address blocks to ASes permitted to originate that address block, The collection will consist of a list where each entry will consist, at a minimum, of an address block, a list of AS numbers, and a tag indicating the type of delegation of the address block. This collection will be produced at least daily. ARIN will make the collected mappings from address blocks to AS numbers available for bulk transfer in one or more formats chosen at its own discretion, informed by the community's current needs. This data will not be subject to any redistribution restrictions -- it may be republished or repackaged it any form. Should ARIN choose to use WHOIS bulk transfer as the bulk form of data access required by this paragraph, the address block to AS mappings will not be subject to any redistribution restrictions, but the remainder of the WHOIS data will remain subject to the terms of the then-current AUP regarding bulk access to WHOIS data. ARIN may also make the collected or individual mappings from address blocks to AS numbers available in other forms, possibly query services, chosen at its own discretion, informed by the community's current needs. ARIN may require agreement to an acceptable use policy for access to the data in these forms. Policy Rationale Origination of prefixes by ASes that have no authority for the origination is a recurring problem in the Internet routing system. A list of authorized prefix originations would be beneficial to operators in * constructing routing filter lists to counter bogus originations, * interacting with customers requesting routing of a prefix, and * diagnosing routing problems. A list of authorized prefix originations is also the necessary first step for any known solution for securing the routing system. Prefix originations can be stored in routing registry RPSL route objects. However, the authority for addresses and for ASes belongs to the RIRs. There is presently no mechanism to translate ARIN's authority for number resources to an IRR. Furthermore, operators have been less than diligent in creating and maintaining route objects. Capturing the prefix origination authorization in number resource registrations with ARIN has two main goals: * benefit from the scrutiny with which ARIN verifies initial requests and authenticates subsequent transactions, and * inherit the operators' self-discipline in completing resource requests and transactions. As an additional benefit, this could take a step toward populating the IRR with data known to be accurate. The intended use of this data means that both query for individual entries and bulk access to a list of the collected entries, without restriction on redistribution, is required. This policy requires that the additional data be provided through the usual whois query service and some bulk access service that has no restrictions. It permits ARIN to provide the bulk access through the existing bulk whois service if the new additional data is not subject to the bulk whois AUP restrictions. The policy does not limit ARIN to providing only those two services (whois query and unrestricted bulk access); other additional services may be developed at ARIN's discretion. It is expected that entries in the list of collected entries will include at a minimum the present NetRange and NetType attributes, with a new attribute, perhaps named OriginatingASList, for the list of permitted originating ASes. This policy will presumably be incorporated into NRPM section 3.4. Timetable for implementation: Within sixty (60) days of approval. From info at arin.net Fri Oct 13 14:31:47 2006 From: info at arin.net (Member Services) Date: Fri, 13 Oct 2006 14:31:47 -0400 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria Message-ID: <452FDB93.3090605@arin.net> On 12 October 2006 the ARIN Advisory Council (AC) concluded its review of 'Changes to IPv6 initial allocation criteria' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2006_7.html All persons in the community are encouraged to discuss Policy Proposal 2006-7 prior to it being presented at the ARIN Public Policy Meeting in the spring of 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria Author: Jordi Palet Martinez Proposal Version: 1 Submission Date: 11/10/2006 Proposal type: delete Policy term: permanent Policy statement: Delete section 6.5.1.1 d. of NRPM Rationale: The existing policy is fine for an existing and known ISP in the ARIN region, but is not considering the case of new ISPs, which may want to start offering IPv6 services. Is artificial to ask them for start with IPv4 services (which typically will do, but not necessarily), wait for weeks/months (?) to be "known", and then come back for the IPv6 allocation request. In addition to that, they need to have a plan for more than 200 /48 assignments. The first question here is that there is room for business with one or just a few IPv6 customers, and it seems irrational not allowing this type of business to be possible, may be even it can be considered against the anti-trust regulations. Second point is regarding the usage of the /48. An ISP may decide to assign a different prefix size, example a cellular operator with probably will use /64. Is important to clarify that the "200" comes from historical reasons when this proposal was jointly developed with RIPE and APNIC, but the situation is that other regions such as LACNIC and AfriNIC already got rid of this requirement, and in both, RIPE and APNIC is under discussion. This may even bring to a possible "untrue" plan to be suggested by an ISP if he needs to get an IPv6 prefix allocated. Regarding the restriction of the usage in 5 years, I think is enough with the criteria indicated in c that the address space is advertised, as there is no ISP interested in getting a prefix which is not being used. Is an operational cost that doesn't make sense if there is not business beyond covering it, never mind if we talk about a few months or a few years. In summary, the proposal will allow new ISPs, ISPs with a reduced number of customers, or ISPs willing to offer only IPv6 services, to immediately access this resource. No financial/liability implications for the community and ARIN are foreseen, on the other way around, it will allow ARIN better fulfilling its mission. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From william at elan.net Fri Oct 13 16:49:00 2006 From: william at elan.net (william(at)elan.net) Date: Fri, 13 Oct 2006 13:49:00 -0700 (PDT) Subject: [ppml] RFC 4698 on IRIS: An Address Registry (areg) Type for the Internet Registry Information Service (fwd) Message-ID: Yesterday at the meeting (I listed to part of it remotely) you discussed CRISP protocol. For those interested in its technical specification as it related to IPs & ASNs below is info on just published RFC for it. ---------- Forwarded message ---------- Date: Thu, 12 Oct 2006 18:17:34 -0700 From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org Cc: crisp at ietf.org, rfc-editor at rfc-editor.org Subject: RFC 4698 on IRIS: An Address Registry (areg) Type for the Internet Registry Information Service A new Request for Comments is now available in online RFC libraries. RFC 4698 Title: IRIS: An Address Registry (areg) Type for the Internet Registry Information Service Author: E. Gunduz, A. Newton, S. Kerr Status: Standards Track Date: October 2006 Mailbox: e.gunduz at computer.org, andy at hxr.us, shane at time-travellers.org Pages: 48 Characters: 89932 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-crisp-iris-areg-15.txt URL: http://www.rfc-editor.org/rfc/rfc4698.txt This document describes an IRIS registry schema for IP address and Autonomous System Number information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. [STANDARDS TRACK] This document is a product of the Cross Registry Information Service Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From Ed.Lewis at neustar.biz Fri Oct 13 17:32:06 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 13 Oct 2006 16:32:06 -0500 Subject: [ppml] RFC 4698 on IRIS: An Address Registry (areg) Type for the Internet Registry Information Service (fwd) In-Reply-To: References: Message-ID: To clarify...CRISP is the name of a IETF WG, not the name of a protocol. IRIS is the main product of the CRISP WG. At 13:49 -0700 10/13/06, william(at)elan.net wrote: >Yesterday at the meeting (I listed to part of it remotely) you discussed >CRISP protocol. For those interested in its technical specification as >it related to IPs & ASNs below is info on just published RFC for it. > >---------- Forwarded message ---------- >Date: Thu, 12 Oct 2006 18:17:34 -0700 >From: rfc-editor at rfc-editor.org >To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org >Cc: crisp at ietf.org, rfc-editor at rfc-editor.org >Subject: RFC 4698 on IRIS: An Address Registry (areg) Type for the Internet > Registry Information Service > >A new Request for Comments is now available in online RFC libraries. > > > RFC 4698 > > Title: IRIS: An Address Registry (areg) > Type for the Internet Registry Information > Service > Author: E. Gunduz, A. Newton, > S. Kerr > Status: Standards Track > Date: October 2006 > Mailbox: e.gunduz at computer.org, > andy at hxr.us, > shane at time-travellers.org > Pages: 48 > Characters: 89932 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-crisp-iris-areg-15.txt > > URL: http://www.rfc-editor.org/rfc/rfc4698.txt > >This document describes an IRIS registry schema for IP address and >Autonomous System Number information. The schema extends the >necessary query and result operations of IRIS to provide the >functional information service needs for syntaxes and results used by >Internet Protocol address registries. [STANDARDS TRACK] > >This document is a product of the Cross Registry Information Service >Protocol Working Group of the IETF. > >This is now a Proposed Standard Protocol. > >STANDARDS TRACK: This document specifies an Internet standards track >protocol for the Internet community,and requests discussion and >suggestions for improvements.Please refer to the current edition of the >Internet Official Protocol Standards (STD 1) for the standardization state >and status of this protocol. Distribution of this memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST at IETF.ORG. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body > >help: ways_to_get_rfcs. For example: > > To: rfc-info at RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution. > >Submissions for Requests for Comments should be sent to >RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds and Sandy Ginoza >USC/Information Sciences Institute > >... >_______________________________________________ >IETF-Announce mailing list >IETF-Announce at ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce > >_______________________________________________ >PPML mailing list >PPML at arin.net >http://lists.arin.net/mailman/listinfo/ppml -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From Lee.Howard at stanleyassociates.com Sat Oct 14 10:02:21 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Sat, 14 Oct 2006 10:02:21 -0400 Subject: [ppml] ARIN member in good standing? Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4038EFA0B@CL-S-EX-1.stanleyassociates.com> I think I have enough detail to understand what you're proposing. This doesn't sound like a policy proposal, per se; you could submit it through the suggestion process http://www.arin.net/about_us/corp_docs/acsp.html (there's a link to "Submit a Suggestion" on the top right of the page, but read Part B first). I would suppose that staff and legal analysis would be significant. Then the Board would have to review, and it would probably go before the community, and I imagine it would require a member vote. I think this would require the support of the relevant government agencies in every nation in our region, since ARIN can't adopt it unilaterally. http://www.arin.net/community/ARINcountries.html I don't know that we could adopt fundamentally different structures in each nation. You can contact the relevant agencies and see if they will support your model. Or, after conensus is found to exist, ARIN could begin contacting those agencies. This would be a significant change to the structure of ARIN, and would require a lot of coordination, so I wouldn't expect it to happen quickly. There is a process to consider it, so if you're serious about trying to effect change, I encourage you to try. Lee > -----Original Message----- > From: Peter Sherbin [mailto:pesherb at yahoo.com] > Sent: Thursday, October 12, 2006 1:31 PM > To: Howard, W. Lee; ppml at arin.net > Subject: RE: [ppml] ARIN member in good standing? > > > I think you suggest having a database server at every hub, > > gathering data for all circuits there, and transmitting > > summaries hourly to a central server, followed by a purge. > > You're still tracking millions of packets per second, > > hopefully without introducing latency, and rack space isn't > > cheap. > > By the same logic energy suppliers have counters at each > point of consumption. For > the Internet it is reversed with counters at each point of > origination. > > > If your proposal requires Internet providers to bill in a certain > > way, we don't have the authority to adopt it. > > Providers will follow the model naturally when it is clearly defined. > > > > "Proper" means following the basic logic of a process. > > > > I don't think that's what it means. > > That's what it means in this context. E.g. on the Internet > someone who wants to > distribute their data incurrs costs. > > > I have it on good authority that the Internet isn't trucks, > > it's tubes. > > Sure, the facility fits the nature of the commodity it carries. > > > Another difference: we don't push electrons. Individual > > electrons don't move very far at all. Data have no mass. > > Yes, data have no mass but the data carrier has it. How do > you move the data without > burning some energy? > > > The basic issue at hand, though, is why the trucking model > > would be substantially better than the status quo. > > The model equips all participants with a guiding principle, > e.g. originator of the > data pays for the volume / destination. It assumes that > market forces sort out the > details. On the Internet there are at least two clear > destinations: within the AS > and outside the AS. > > > You say it's straightforward, but what are those criteria? > > According to the Telecommunications Act of Canada: > > "Canadian carrier'' means a telecommunications common carrier > that is subject to the > legislative authority of Parliament; > > "telecommunications common carrier'' means a person who owns > or operates a > transmission facility used by that person or another person to provide > telecommunications services to the public for compensation; > > Apparently all you need is registering your business > indicating "telecommunications" > among your activities. Consequently you become regulated by > the authorities. > > > Does that mean that coffee shops need licenses? > Only if they chose. > > > If I set up private interconnects between my enterprise > network and four > > of my vendors, do I need a license? > Your choice. As long as all five run data within the private > network sharing costs > and not profiting you are not a carrier and not a subject to > regulations / fees. At > the same time you may well need a block of PI addresses. > > > > suggested fees. > > How strong are the suggestions? > It is up to the license office to decide. It assumes that > the office wants to > support the competitiveness of their economy. > > > >For the start we may want to reserve more space and start > experimenting with > > >less. > > > > Do you have a proposal? > > Enterprise market first. If autoconfiguration is a must then > /96. Otherwise /64. > Reservation happens at /16. > > > I think your proposal is to have the tax and licensing > > organizations provide ARIN a subscriber count. ARIN needs > > more information... Do we ask the organization for > > more information, or train the tax and licensing agenices to > > collect network diagrams and virtual host counts? > > From the office get only a number of licensees with the > subscriber count (for fee > calculation). For all the rest use the current ARIN process. > > > I still don't quite understand the threshold where a telecom > > license is required. The only telecom service I want to > > provide is to employees of my company. Do I need a license > > in your model? Do I meet the criteria? If the criteria > > include maintaining a billing database and providing wiretap > > facilities, then I don't. Would that mean my private WAN is > > illegal? > > You are not in violation as long as you are not profiting > from telecom services you > provide. > > > So we could easily have three non-aggregatable prefixes at > > our house. Every organization and every individual would > > have a non-aggregatable prefix. Do you foresee any routing > > scalability problems with that? > > Not really assuming that IPv6 prime practical benefit is for > private networks to > track devices / automate processes. > > > Fees would be variable between countries, and set by the > > government, not by ARIN and its members. > > That is probably practical in a world with different > economies where governments > pursue local competitiveness. Global market forces would take > care of fees as long > as all RIR adopt a common and "fair" PI address allocation policy. > > > You propose significant regulation of the Internet and what > > look to me like significant additional costs for Internet > > access providers, both of which may (depending on how well > > I understand your proposal) reduce the number of providers > > and the flexibility of enterprises to bypass them. Who > > benefits from this? > > > > Or, put another way, I don't understand the problem > > The model aims at identifying a fundamental cost driver on > the Internet, e.g. a > certain amount of electrons carrying data from the > origination point to its > destination. Subsequent arrangements will follow naturally > shaped by whichever local > circumstances. > > > --- "Howard, W. Lee" wrote: > > > > -----Original Message----- > > > From: Peter Sherbin [mailto:pesherb at yahoo.com] > > > Sent: Tuesday, October 03, 2006 12:06 AM > > > To: Howard, W. Lee; ppml at arin.net > > > Subject: Re: [ppml] ARIN member in good standing? > > > > > > > Can you describe the data capture mechanism? I mentioned the > > > > billing system that would be required. Even if you discard > > > > payload and only keep source and destination addresses > and packet > > > > size, you're talking about increasing network load by a > > > > significant amount (30%?). Billing data for an OC3 could be > > > > 16TB per month. Multiply hundreds of circuits times a > five-year > > > > record-retention policy, and I get a 97PB database. > > > > > > Assumption: need to count sent volumes only. A sending > > > network or a node (SN) is > > > identified by its source address (SA). SN is connected to > > > provider's distribution > > > router (DR). DR counts the length of all packets sent from SA > > > and reports the total > > > number of bits to a database server. > > > > Yes, that's the math I was doing. I had inferred from > > something you said earlier that you might charge different > > rates per destination. Even if not, if you have a 128 bit > > address field and a 16 bit length field, at a million packets > > per second, it's still a couple of terabytes per month. > > That's a good-sized database, and that's just one OC3. > > > > I think you suggest having a database server at every hub, > > gathering data for all circuits there, and transmitting > > summaries hourly to a central server, followed by a purge. > > You're still tracking millions of packets per second, > > hopefully without introducing latency, and rack space isn't > > cheap. > > > > > > > > I don't understand "unpaid volumes." You bill your customers. > > > > > > In some cases volume based billing is announced but it may > > > not necessarily be > > > enforced. Billing works OK for burstable circuits. A regular > > > T1 would be provisioned > > > to accommodate e.g. about 0.5Mbps at a busy hour. Three T1s > > > on a single DR may have > > > different usage patterns. E.g. one transmits at 1.2Mbps > > > during 3hrs in the morning. > > > Second sends at 1.1Mbps at night for 6hrs. The third sends at > > > 0.3Mbps 24hrs daily > > > with occasional bursts up to 1.5Mbps. Each pays $1,200 but > > > over the month #1 have > > > sent 49GB, #2 = 89GB, #3 = 110GB. Sometimes providers would > > > go after "abusers" who > > > exceed average usage tens or hundreds times. "Abusers" can be > > > looked at as an > > > opportunity assuming they have a need to move data and are > > > willing to pay for it. > > > > Sorry for leading the topic this way. How and what ARIN > > members charge for services is completely off-topic. If > > your proposal requires Internet providers to bill in a certain > > way, we don't have the authority to adopt it. > > > > > > You keep saying "proper," as if to say that there is an > established > > > > right way to do things. > > > > > > "Proper" means following the basic logic of a process. > > > > I don't think that's what it means. > > > > > E.g. in a world of a regular > > > mail or cargo shipments a sender pays for moving a certain > > > number of molecules over > > > distance. Energy wise how does moving electrons fundamentally > > > differ from moving > > > molecules? If electrons are too many to count let's define a > > > countable network unit representing a fair amount of > > > electrons. > > > > I have it on good authority that the Internet isn't trucks, > > it's tubes. > > > > The fundamental difference is that there's no Internet > > oligopoly. In shipping, you have a single carrier end-to-end. > > In telecom, you may have two or three carriers, but they look > > the same, because of heredity and regulation. > > > > Another difference: we don't push electrons. Individual > > electrons don't move very far at all. Data have no mass. > > > > The basic issue at hand, though, is why the trucking model > > would be substantially better than the status quo. > > > > > > > > I am not familiar with telecommunications licensing, > but I do not > > > > have the impression that licenses are available to anyone. My > > > > impression is that the "certain criteria" are high. Does each > > > > coffee shop and private interconnect have to get a license? > > > > > > The process is straightforward, as long as you meet all > > > "high" criteria you will get > > > the license. If network services are defined and regulated > > > then anyone who falls > > > under that definition is a subject to a license. > > > > You say it's straightforward, but what are those criteria? > > Does that mean that coffee shops need licenses? If I set up > > private interconnects between my enterprise network and four > > of my vendors, do I need a license? > > > > > > > > So does this mean a new kind of governmental licensing agency, > > > > which works closely with the government tax collection agency, > > > > and the two agencies direct ARIN? > > > > > > It is a matter of coordination between already established > > > agencies, e.g. Tax and > > > FCC. Agencies feed ARIN with the number of subscribers by > > > provider as well as > > > suggested fees. ARIN autonomously performs address allocation > > > practice. ARIN > > > collects fees from all holders of licenses for network services. > > > > How strong are the suggestions? > > > > > > I'm unclear on the taxpayer-node relationship. Each taxpaying > > > > individual with a tax ID gets an allocation? What size? > > > > > > Taxpayers are not homogeneous and need segmentation. How many > > > addresses is enough > > > for a single individual? Assuming that at some point we will > > > start fixing genes and > > > that human DNA consists of about 3 billion base pairs will > > > /96 be enough? For the > > > start we may want to reserve more space and start > > > experimenting with less. > > > > Do you have a proposal? > > > > > > Each taxpaying organization with a tax ID get an allocation? > > > > What size? > > > > > > Depending on what they can justify. Current ARIN approach > > > works well here. > > > > I think your proposal is to have the tax and licensing > > organizations provide ARIN a subscriber count. ARIN needs > > more information than that. Do we ask the organization for > > more information, or train the tax and licensing agenices to > > collect network diagrams and virtual host counts? > > > > > > > > I was talking about IP address allocation. Say my company has > > > > offices in 14 states and two provinces, with leased > lines between > > > > them, and three Internet connections. Do I get three > assignments > > > > from my carriers, or 14? Or since I have leased lines, > do I get a > > > > telecom license? > > > > > > You will get your PI assignment directly from ARIN in the > > > amount you can justify. > > > Whichever provider(s) serve your Internet connection(s) they > > > will report it to ARIN. > > > You will get a telecom license if you meet all of the > > > criteria for it in your region > > > and if you want to be engaged in a telecom business and if a > > > contract with your > > > provider permits you to sub-lease lines. > > > > I still don't quite understand the threshold where a telecom > > license is required. The only telecom service I want to > > provide is to employees of my company. Do I need a license > > in your model? Do I meet the criteria? If the criteria > > include maintaining a billing database and providing wiretap > > facilities, then I don't. Would that mean my private WAN is > > illegal? > > > > > > [redacted: addresses for me, my wife, and her home business] > > > > So we could easily have three non-aggregatable prefixes at > > our house. Every organization and every individual would > > have a non-aggregatable prefix. Do you foresee any routing > > scalability problems with that? > > > > > > > > > What's a top level licensee? > > > E.g. FCC in the US or CRTC in Canada. > > > > Fees would be variable between countries, and set by the > > government, not by ARIN and its members. > > > > > > > > You propose significant regulation of the Internet and what > > look to me like significant additional costs for Internet > > access providers, both of which may (depending on how well > > I understand your proposal) reduce the number of providers > > and the flexibility of enterprises to bypass them. Who > > benefits from this? > > > > Or, put another way, I don't understand the problem we're > > > === message truncated === > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > From michel at arneill-py.sacramento.ca.us Sat Oct 14 19:36:42 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 14 Oct 2006 16:36:42 -0700 Subject: [ppml] Multihome Pro Con Document In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01D0405E@nyrofcs2ke2k01.corp.pvt> Message-ID: Hi Marla, While this document does a decent job at describing solutions, it does not address the #1 reason why no solution is deployed a decade after we started working on finding one: palatability of the solution to the end users. In other words: what are the realistic chances of a given solution to be successfully deployed in the real world. The main issue with IPv6 multihoming is not the pros and cons of solutions, but their deployability. Failure to understand this is why, 10 years after, we still are discussing the pros and cons of solutions. Michel. From pesherb at yahoo.com Sat Oct 14 19:42:42 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Sat, 14 Oct 2006 16:42:42 -0700 (PDT) Subject: [ppml] ARIN member in good standing? In-Reply-To: <426F261F-63AD-4BF2-A40C-20E1ED092AE9@pch.net> Message-ID: <20061014234242.16339.qmail@web54715.mail.yahoo.com> > Are you suggesting that incremental cost of service delivery should > the basis for pricing inter-provider network services? > Would that rule also apply to provider-to-end customer pricing? The model only states that a packet originator has to cover transfer costs, at any level an individual or a provider. Pricing is determined by the market. > Should costs define the upper as well as lower limit for pricing? > Who calculates what costs "really" are? The cost is a fundamental business variable but not the only determinant of the price. It is assumed that business entities understand their costs. > You proposal suggests to me that you don't think the market is taking > care of at least some elements of this equation now -- i.e., that > pricing is "irrational" in the economic sense. Models from a few Tier 2 ISPs that I have seen indicated a vague understanding of the Internet costs. IMO the Internet from its start has been and still continues to be subsidized by a local telephony and/or a local cable. Pure-play ISPs exist because they pay for the access below cost. > Put another way, doesn't your proposal entail the elimination of > bypass and the restoration of closed territorial markets (aka "local > circumstance sovereignty") that only exchange traffic at the border? > Do you think that markets like that -- there are still many many > around the world -- are more rational, and should be emulated? On the Internet a territory is determined by AS boundary rather than geography. The model suggests that a provider charges a "fair" price covering the transit of originators' packets. Based on costs/traffic patterns a provider negotiates a deal with a bordering AS(s). Geography where AS is located could influence costs. > Your proposed goal of exposing cost drivers is redundant if local costs > continue to be subject to extra-local competition, and your proposed > mechanism for exposing costs would almost certainly devolve into a > mechanism for eliminating such competition. > Or am I missing some element that might forestall this outcome? Here is the model: 1. Bob is willing to send a packet to Alice 2. Bob must cover the cost 3. Cost unit/driver = 1GB upload The above applies at all levels: node, network, AS. Providers compete freely with no requirement or need to expose costs. Peter --- Tom Vest wrote: > > On Oct 12, 2006, at 1:31 PM, Peter Sherbin wrote: > > >> Or, put another way, I don't understand the problem > > > > The model aims at identifying a fundamental *cost driver* on the > > Internet, e.g. a > > certain amount of electrons carrying data from the origination > > point to its > > destination. Subsequent arrangements will follow naturally shaped > > by whichever local > > circumstances. > > *(emphasis mine)* > > Are you suggesting that incremental cost of service delivery should > the basis for pricing inter-provider network services? > Would that rule also apply to provider-to-end customer pricing? > Should costs define the upper as well as lower limit for pricing? > Who calculates what costs "really" are? > > You proposal suggests to me that you don't think the market is taking > care of at least some elements of this equation now -- i.e., that > pricing is "irrational" in the economic sense. Could this perception > be based on the fact that some pricing and "arrangements" are based > on regional/global rather than locally bounded circumstances? > > Put another way, doesn't your proposal entail the elimination of > bypass and the restoration of closed territorial markets (aka "local > circumstance sovereignty") that only exchange traffic at the border? > Do you think that markets like that -- there are still many many > around the world -- are more rational, and should be emulated? > > Forgive my cognitive dissonance, but we got to where we are today > because globalization (erosion of local market sovereignty) exposed > places with different prices and cost structures to pressure from the > prices and cost structures of other places, i.e., "competition." Your > proposed goal of exposing cost drivers is redundant if local costs > continue to be subject to extra-local competition, and your proposed > mechanism for exposing costs would almost certainly devolve into a > mechanism for eliminating such competition. > > Or am I missing some element that might forestall this outcome? > > TV > > > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From woody at pch.net Sat Oct 14 23:51:04 2006 From: woody at pch.net (Bill Woodcock) Date: Sat, 14 Oct 2006 20:51:04 -0700 (PDT) Subject: [ppml] ARIN member in good standing? In-Reply-To: <20061014234242.16339.qmail@web54715.mail.yahoo.com> References: <20061014234242.16339.qmail@web54715.mail.yahoo.com> Message-ID: On Sat, 14 Oct 2006, Peter Sherbin wrote: > Models from a few Tier 2 ISPs that I have seen indicated a vague > understanding of the Internet costs. This I can absolutely corroborate. > IMO the Internet from its start has been and still continues to > be subsidized by a local telephony and/or a local cable. Pure-play > ISPs exist because they pay for the access below cost. But this is absolutely false. I'm guessing that you're deriving this from observation of only the U.S. market. I can see how you could come to this conclusion using valid logic from observation of the U.S. market. I'd strongly suggest that you check out healthier, more rational markets in Asia and parts of Europe, as a source of additional information. Also, I think this has gone well beyond the scope of PPML... It's a thred I'm very interested in, but perhaps there's a better place for it? -Bill From tvest at pch.net Sun Oct 15 01:30:58 2006 From: tvest at pch.net (Tom Vest) Date: Sun, 15 Oct 2006 01:30:58 -0400 Subject: [ppml] ARIN member in good standing? In-Reply-To: <20061014234242.16339.qmail@web54715.mail.yahoo.com> References: <20061014234242.16339.qmail@web54715.mail.yahoo.com> Message-ID: <8BF718D6-FF88-4489-822B-636FFD3C5291@pch.net> On Oct 14, 2006, at 7:42 PM, Peter Sherbin wrote: >> Are you suggesting that incremental cost of service delivery should >> the basis for pricing inter-provider network services? >> Would that rule also apply to provider-to-end customer pricing? > > The model only states that a packet originator has to cover > transfer costs, at any > level an individual or a provider. Pricing is determined by the > market. > >> Should costs define the upper as well as lower limit for pricing? >> Who calculates what costs "really" are? > > The cost is a fundamental business variable but not the only > determinant of the > price. It is assumed that business entities understand their costs. > >> You proposal suggests to me that you don't think the market is taking >> care of at least some elements of this equation now -- i.e., that >> pricing is "irrational" in the economic sense. > > Models from a few Tier 2 ISPs that I have seen indicated a vague > understanding of > the Internet costs. Generalizing from that set of observations is perilous, for many reasons. Out of curiosity, have you seen cost models of Tier 1 ISPs or access facility / local telephony providers that inspire greater confidence? > IMO the Internet from its start has been and still continues to > be subsidized by a local telephony and/or a local cable. This is a common belief/assertion among PSTN employees. Local telephony providers also thought they they subsidized long-distance and international voice services -- all "value-added services" in fact, wherever these are treated differently from "basic services" by local law. The same special interest groups also generally believed that third-party devices (voice terminals, faxes, modems, etc.) were too risky and unpredictable to be allowed to attach to the local access platform. In some places, those views remained unchanged, and continue to dominate -- and in those places value-added services still tend to cost an arm and a leg, and the Internet often barely exists at all. IMO this view is one of the biggest reasons why the Internet continues to be more concentrated than one might expect given rapid global growth. Mobile factors tend to exit expensive markets and take up residence overseas, in exactly the same way that "outsourcing" works in every other commercial sector. The possible adaptations are basically the same too -- normalize up, normalize down, or close the border and go your own way. > Pure-play ISPs exist because they pay for the access below cost. What is a pure-play ISP anyway? Is it any ISP that is not a telco, i.e., an incumbent access facilities owner? How is that cost calculated, exactly? Is it "whatever we (access facilities owner) choose to spend on whatever we choose to spend it on" (ala rate-of-return arrangements)? If so, then of course the cost is completely subjective/fictitious/arbitrary. That pure arbitrariness, and the harm that it inflicts on the rest of the economy is what typically causes telecom regulators to create and maintain a "wholesale telecom" market segment -- which is the thing that makes it economically feasible for non-incumbent facilities owners to offer communications services of any kind. >> Put another way, doesn't your proposal entail the elimination of >> bypass and the restoration of closed territorial markets (aka "local >> circumstance sovereignty") that only exchange traffic at the border? >> Do you think that markets like that -- there are still many many >> around the world -- are more rational, and should be emulated? > > On the Internet a territory is determined by AS boundary rather > than geography. The > model suggests that a provider charges a "fair" price covering the > transit of > originators' packets. This seems to me to get the equation backwards. Operators extend ASes / logical boundaries across physical segments in order to improve their terms of business. Sometimes business is served by insourcing -- extending the AS to new territories or market segments; sometimes by outsourcing -- handing off the traffic to someone else. So my question remains unanswered -- doesn't your proposal require that ASes revert to being explicitly geographic-territorial? > Based on costs/traffic patterns a provider negotiates a deal > with a bordering AS(s). Geography where AS is located could > influence costs. If ASes are explicitly geographic, then this is a description of something like the traditional (pre-1996) ITU settlements system. If ASes are not explicitly geographic, then this is just a description of the internet as it exists today. >> Your proposed goal of exposing cost drivers is redundant if local >> costs >> continue to be subject to extra-local competition, and your proposed >> mechanism for exposing costs would almost certainly devolve into a >> mechanism for eliminating such competition. >> Or am I missing some element that might forestall this outcome? > > Here is the model: > 1. Bob is willing to send a packet to Alice > 2. Bob must cover the cost What is the cost? Who calculates the cost? By what mechanism? (refer to previous) > 3. Cost unit/driver = 1GB upload When your cost unit/driver goes down -- as it did by several orders of magnitude during the last decade -- how does that affect the calculation of "fair" "costs" or "prices"? Bob's demand for connectivity with Alice is price elastic, but Bob's service provider would be much happier to sell him 2mb of traffic exchange for $50 than to support 2mbps monthly flat rate service for the same price -- no matter what the cost of service delivery is. In places without competition and/or a strong regulator Bob tends to get the former; in other places Bob gets the latter, or maybe 20Mbps or 200Mbps. Bob would want to know how your proposal would affect the calculation of his cost of service, because he really likes Alice ;-) > The above applies at all levels: node, network, AS. Providers > compete freely with no > requirement or need to expose costs. Today there are many places where multiple ASes straddle the same territory, and offer interchangeable/competing services. Why is that not "free competition"? If it is "free competition," what advantage would be achieved by redefining this concept in the terms that you propose? TV > Peter > > > --- Tom Vest wrote: > >> >> On Oct 12, 2006, at 1:31 PM, Peter Sherbin wrote: >> >>>> Or, put another way, I don't understand the problem >>> >>> The model aims at identifying a fundamental *cost driver* on the >>> Internet, e.g. a >>> certain amount of electrons carrying data from the origination >>> point to its >>> destination. Subsequent arrangements will follow naturally shaped >>> by whichever local >>> circumstances. >> >> *(emphasis mine)* >> >> Are you suggesting that incremental cost of service delivery should >> the basis for pricing inter-provider network services? >> Would that rule also apply to provider-to-end customer pricing? >> Should costs define the upper as well as lower limit for pricing? >> Who calculates what costs "really" are? >> >> You proposal suggests to me that you don't think the market is taking >> care of at least some elements of this equation now -- i.e., that >> pricing is "irrational" in the economic sense. Could this perception >> be based on the fact that some pricing and "arrangements" are based >> on regional/global rather than locally bounded circumstances? >> >> Put another way, doesn't your proposal entail the elimination of >> bypass and the restoration of closed territorial markets (aka "local >> circumstance sovereignty") that only exchange traffic at the border? >> Do you think that markets like that -- there are still many many >> around the world -- are more rational, and should be emulated? >> >> Forgive my cognitive dissonance, but we got to where we are today >> because globalization (erosion of local market sovereignty) exposed >> places with different prices and cost structures to pressure from the >> prices and cost structures of other places, i.e., "competition." Your >> proposed goal of exposing cost drivers is redundant if local costs >> continue to be subject to extra-local competition, and your proposed >> mechanism for exposing costs would almost certainly devolve into a >> mechanism for eliminating such competition. >> >> Or am I missing some element that might forestall this outcome? >> >> TV >> >> >> >> >> >> >> >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com From Lee.Howard at stanleyassociates.com Sun Oct 15 08:40:20 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Sun, 15 Oct 2006 08:40:20 -0400 Subject: [ppml] Multihome Pro Con Document Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4038EFA61@CL-S-EX-1.stanleyassociates.com> Would it be fair, in your opinion, to distinguish three classes of network that might require multihoming? End-user networks may require some means of switching from two types of residential access, but may be generally assumed to have no more than two simultaneous links, a single prefix, and no need for traffic engineering. Enterprise networks need multihoming primarily for reliability, but may also need some level of best-path selection, and may need some degree of load distribution. In IPv6, they will generally have no more than two prefixes. ISP networks need lots of peers and lots of knobs for traffic engineering, load distribution, best-path selection, and ways to manage routing table bloat. It seems perfectly reasonable to have a host-based solution for end users, a feature-rich BGP for ISPs, and for enterprise networks to choose the solution that fits best. Your mileage may vary. Lee > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michel Py > Sent: Saturday, October 14, 2006 7:37 PM > To: Azinger, Marla; ppml at arin.net > Subject: Re: [ppml] Multihome Pro Con Document > > Hi Marla, > > While this document does a decent job at describing solutions, it does > not address the #1 reason why no solution is deployed a > decade after we > started working on finding one: palatability of the solution > to the end > users. In other words: what are the realistic chances of a given > solution to be successfully deployed in the real world. > > The main issue with IPv6 multihoming is not the pros and cons of > solutions, but their deployability. Failure to understand this is why, > 10 years after, we still are discussing the pros and cons of > solutions. > > Michel. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Sun Oct 15 10:26:28 2006 From: randy at psg.com (Randy Bush) Date: Sun, 15 Oct 2006 09:26:28 -0500 Subject: [ppml] Multihome Pro Con Document References: <369EB04A0951824ABE7D8BAC67AF9BB4038EFA61@CL-S-EX-1.stanleyassociates.com> Message-ID: <17714.17684.971139.270978@roam.psg.com> > End-user networks may require some means of switching from two > types of residential access, but may be generally assumed to have > no more than two simultaneous links, a single prefix, and no need > for traffic engineering. why the assumption of only two and why the assumption of no te? i want voip out the left and quake out the right, for example. > Enterprise networks need multihoming primarily for reliability, > but may also need some level of best-path selection, and may need > some degree of load distribution. In IPv6, they will generally > have no more than two prefixes. wait a sec! i was told that we would not have the prefix explosion in v6 because we could give each site enough space so that it would only need to announce one prefix into the global routing state. randy From Lee.Howard at stanleyassociates.com Sun Oct 15 10:51:51 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Sun, 15 Oct 2006 10:51:51 -0400 Subject: [ppml] Multihome Pro Con Document Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4038EFA6E@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Sunday, October 15, 2006 10:26 AM > To: Howard, W. Lee > Cc: ppml at arin.net > Subject: Re: [ppml] Multihome Pro Con Document > > > End-user networks may require some means of switching from two > > types of residential access, but may be generally assumed to have > > no more than two simultaneous links, a single prefix, and no need > > for traffic engineering. > > why the assumption of only two and why the assumption of no te? > i want voip out the left and quake out the right, for example. I use adverbs carefully. You're special, and clueful, and can build complex networks. If we're not allowed to make assumptions, we can't define requirements, and can't do anything. > > Enterprise networks need multihoming primarily for reliability, > > but may also need some level of best-path selection, and may need > > some degree of load distribution. In IPv6, they will generally > > have no more than two prefixes. > > wait a sec! i was told that we would not have the prefix explosion > in v6 because we could give each site enough space so that it would > only need to announce one prefix into the global routing state. Did you get a receipt? Most enterprise networks should only have one prefix, but some may need multiple /56 (depending on ISP policy) or even /48. If we can converge on 1-3 technologies, then they can be applied where needed. A residential customer may desire an ISP technology, but finding a provider who can support it may be tricky. Lee > > randy > From randy at psg.com Sun Oct 15 11:47:57 2006 From: randy at psg.com (Randy Bush) Date: Sun, 15 Oct 2006 10:47:57 -0500 Subject: [ppml] Multihome Pro Con Document References: <369EB04A0951824ABE7D8BAC67AF9BB4038EFA6E@CL-S-EX-1.stanleyassociates.com> Message-ID: <17714.22573.227999.243286@roam.psg.com> >>> End-user networks may require some means of switching from two >>> types of residential access, but may be generally assumed to have >>> no more than two simultaneous links, a single prefix, and no need >>> for traffic engineering. >> why the assumption of only two and why the assumption of no te? >> i want voip out the left and quake out the right, for example. > You're special, and clueful, and can build complex networks. > If we're not allowed to make assumptions, we can't define requirements, > and can't do anything. the assumption to make is that, if the home user is multi-homed, that they did it for a reason. and that reason is likely traffic engineering. the two most common reasons for this in the states are precisely the examples i gave, voip and games. randy From terry.l.davis at boeing.com Sun Oct 15 17:50:51 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Sun, 15 Oct 2006 14:50:51 -0700 Subject: [ppml] Multihome Pro Con Document In-Reply-To: <17714.17684.971139.270978@roam.psg.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A01BD28D2@XCH-NW-8V1.nw.nos.boeing.com> Randy I agree completely on the residential issues. But I'm not sure that the enterprises will advertise the same prefix in DC, St Louis, Seattle, and LA. And Moscow, Delhi, London. Same reason, te. Take care Terry > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Sunday, October 15, 2006 7:26 AM > To: Howard, W. Lee > Cc: ppml at arin.net > Subject: Re: [ppml] Multihome Pro Con Document > > > End-user networks may require some means of switching from two > > types of residential access, but may be generally assumed to have > > no more than two simultaneous links, a single prefix, and no need > > for traffic engineering. > > why the assumption of only two and why the assumption of no te? > i want voip out the left and quake out the right, for example. > > > Enterprise networks need multihoming primarily for reliability, > > but may also need some level of best-path selection, and may need > > some degree of load distribution. In IPv6, they will generally > > have no more than two prefixes. > > wait a sec! i was told that we would not have the prefix explosion > in v6 because we could give each site enough space so that it would > only need to announce one prefix into the global routing state. > > randy > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From schiller at uu.net Sun Oct 15 23:38:08 2006 From: schiller at uu.net (Jason Schiller) Date: Sun, 15 Oct 2006 23:38:08 -0400 (EDT) Subject: [ppml] Multihome Pro Con Document In-Reply-To: Message-ID: Michael, It might be useful to explain why each of these solutions is not deployable for one or more types of multi-homing users. Adding this text may help to let people know how far off we are from a deployable solution. I'd suggest you provide some text to Marla on a solution by solution basis. Depending on the text, she can either include this info either under "cons", or "Questions to consider", or under a new section "Deployability Concerns". I suspect this is exactly what Marla was trying to do in a non-negative constructive sort of way. ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Sat, 14 Oct 2006, Michel Py wrote: > Date: Sat, 14 Oct 2006 16:36:42 -0700 > From: Michel Py > To: "Azinger, Marla" , ppml at arin.net > Subject: Re: [ppml] Multihome Pro Con Document > > Hi Marla, > > While this document does a decent job at describing solutions, it does > not address the #1 reason why no solution is deployed a decade after we > started working on finding one: palatability of the solution to the end > users. In other words: what are the realistic chances of a given > solution to be successfully deployed in the real world. > > The main issue with IPv6 multihoming is not the pros and cons of > solutions, but their deployability. Failure to understand this is why, > 10 years after, we still are discussing the pros and cons of solutions. > > Michel. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From Lee.Howard at stanleyassociates.com Mon Oct 16 09:48:13 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 16 Oct 2006 09:48:13 -0400 Subject: [ppml] Multihome Pro Con Document Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4038EFC0F@CL-S-EX-1.stanleyassociates.com> > >> why the assumption of only two and why the assumption of no te? > >> i want voip out the left and quake out the right, for example. > > You're special, and clueful, and can build complex networks. > > If we're not allowed to make assumptions, we can't define > requirements, > > and can't do anything. > > the assumption to make is that, if the home user is multi-homed, > that they did it for a reason. and that reason is likely traffic > engineering. the two most common reasons for this in the states > are precisely the examples i gave, voip and games. Sorry, I misunderstood. So you think the requirements are the same for residential users and ISPs? I'm having a failure of imagination, and can only imagine residential "TE" where a user gets a PA prefix from both her VOIP provider and her gaming provider. Maybe she wants failover with her prefixes, but I don't see TE as I understand it. If true, we need a BGP with more knobs than the current one, but which is usable by Joe Homeuser. Lee From dlw+arin at tellme.com Mon Oct 16 10:34:16 2006 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 16 Oct 2006 07:34:16 -0700 Subject: [ppml] Multihome Pro Con Document In-Reply-To: References: Message-ID: <20061016143416.GD26506@shell01.corp.tellme.com> On Sun, Oct 15, 2006 at 11:38:08PM -0400, Jason Schiller wrote: > It might be useful to explain why each of these solutions is not > deployable for one or more types of multi-homing users. Adding this text > may help to let people know how far off we are from a deployable solution. Just to second this comment - this is probably the most productive thing anyone could contribute to this effort at this point. It's clear that the taxonomy of multi-homing users is unclear, so I'd stick to single examples of where each method won't work to get started. > I suspect this is exactly what Marla was trying to do in a non-negative > constructive sort of way. ...and double kudos to Marla for taking this on! This is certainly a thankless job, but getting all of this information in one place will be invaluable as the community looks for solutions. -David From michel at arneill-py.sacramento.ca.us Mon Oct 16 23:07:30 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 16 Oct 2006 20:07:30 -0700 Subject: [ppml] Multihome Pro Con Document In-Reply-To: Message-ID: Hi Jason, > Jason Schiller wrote: > I suspect this is exactly what Marla was trying to > do in a non-negative constructive sort of way. I don't doubt that a minute. I have done something similar a few years back (and did not listen then to the nay-sayers that said they tried before...). While I'm it, allow me to acknowledge the following as well: > Howard, W. Lee wrote: > Would it be fair, in your opinion, to distinguish three > classes of network that might require multihoming? > [..] It seems perfectly reasonable to have a host-based > solution for end users, a feature-rich BGP for ISPs, and > for enterprise networks to choose the solution that fits best. Perfectly reasonable and fair yes. Good enough, no. That being said, > Jason Schiller wrote: > It might be useful to explain why each of these solutions > is not deployable for one or more types of multi-homing users. > Adding this text may help to let people know how far off we > are from a deployable solution. > David Williamson wrote: > Just to second this comment - this is probably the most > productive thing anyone could contribute to this effort > at this point. It's clear that the taxonomy of multi-homing > users is unclear, so I'd stick to single examples of where > each method won't work to get started. I'm sorry to rain on the parade, but we have been through this process of taxonomy documents and requirement documents for a decade, inside and outside the IETF. I realize that some of you might not have followed it, but plenty of smart and well-connected engineers have put a considerable amount of work in this already. I regret to say that what I see today here is yet-another-occurrence of d?j?-vu all over again. A decade of failures to launch shows me that the process is flawed. Trying to think out of the box and stay positive, I offer the following two suggestions: 1. Think of a product, not a protocol. Instead of designing it then trying to figure out how to sell it, imagine something that looks hot in the eyes of the corporate IT manager and then figure it if you can make it work. 2. Replace BGP with a protocol that does not care about routing table bloat. Memory is cheap; the days that led to the "aggregated" IPv6 design when a 7500/RSP2/128 was the baddest core router one could buy are long gone. Today people are running dual full feeds on a 1800... Michel. From Lee.Howard at stanleyassociates.com Tue Oct 17 10:07:00 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 17 Oct 2006 10:07:00 -0400 Subject: [ppml] Multihome Pro Con Document Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4038F0208@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michel Py > > 2. Replace BGP with a protocol that does not care about > routing table bloat. Memory is cheap; the days that led to > the "aggregated" IPv6 design when a 7500/RSP2/128 was the > baddest core router one could buy are long gone. Today people > are running dual full feeds on a 1800... My understanding of the problem (I don't work on a default-free network anymore) is that keeping up with changes is expensive in CPU, not in memory, and that lookups against a large table are expensive in latency. What is the appropriate IETF WG for design of IPv6 multihoming solutions? shim6 is a specific solution; v6ops doesn't sound quite right. Lee > > Michel. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Tue Oct 17 10:20:15 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 17 Oct 2006 10:20:15 -0400 (EDT) Subject: [ppml] Multihome Pro Con Document In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4038F0208@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4038F0208@CL-S-EX-1.stanleyassociates.com> Message-ID: On 10/17/06 at 10:07am -0400, Howard, W. Lee What is the appropriate IETF WG for design of IPv6 multihoming > solutions? shim6 is a specific solution; v6ops doesn't sound > quite right. That *was* multi6, which concluded a while back, around the time shim6 was chartered. There is currently no other working group working on alternate multihoming solutions to shim6. If you think the IETF should be working on something other than shim6 or IPv4-style BGP multihoming for IPv6 (which doesn't require anything new from the IETF), then you'd need to get enough people to agree with you to hold a BOF and get a new WG started. With this topic I'm sure there would be political issues, but the biggest impediment to getting a WG going is usually getting enough people interested and committed to actually participate in the WG and do the work required. -Scott From heldal at eml.cc Tue Oct 17 10:28:49 2006 From: heldal at eml.cc (Per Heldal) Date: Tue, 17 Oct 2006 16:28:49 +0200 Subject: [ppml] Multihome Pro Con Document In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4038F0208@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4038F0208@CL-S-EX-1.stanleyassociates.com> Message-ID: <1161095329.15868.4.camel@localhost.localdomain> On Tue, 2006-10-17 at 10:07 -0400, Howard, W. Lee wrote: > What is the appropriate IETF WG for design of IPv6 multihoming > solutions? shim6 is a specific solution; v6ops doesn't sound > quite right. Multi6 is the relevant WG for the discussion and evaluation of various MHv6 alternatives, but there isn't much activity there anymore. http://ops.ietf.org/multi6/ http://www.ietf.org/html.charters/multi6-charter.html -- Per Heldal - http://heldal.eml.cc/ From heldal at eml.cc Tue Oct 17 10:38:24 2006 From: heldal at eml.cc (Per Heldal) Date: Tue, 17 Oct 2006 16:38:24 +0200 Subject: [ppml] Multihome Pro Con Document In-Reply-To: <1161095329.15868.4.camel@localhost.localdomain> References: <369EB04A0951824ABE7D8BAC67AF9BB4038F0208@CL-S-EX-1.stanleyassociates.com> <1161095329.15868.4.camel@localhost.localdomain> Message-ID: <1161095904.15868.9.camel@localhost.localdomain> On Tue, 2006-10-17 at 16:28 +0200, Per Heldal wrote: > > Multi6 is the relevant WG for the discussion and evaluation of various > MHv6 alternatives, but there isn't much activity there anymore. Bad choice of words. This workgroup has concluded its work about the time the shim6-group got started. Still, nothing should prevent new people with new ideas from starting a similar initiative, or maybe even revive the old WG with new chair-person(s). -- Per Heldal - http://heldal.eml.cc/ From kloch at kl.net Tue Oct 17 10:51:47 2006 From: kloch at kl.net (Kevin Loch) Date: Tue, 17 Oct 2006 10:51:47 -0400 Subject: [ppml] Multihome Pro Con Document In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB4038F0208@CL-S-EX-1.stanleyassociates.com> Message-ID: <4534EE03.3060403@kl.net> Scott Leibrand wrote: > If you think the IETF should be working > on something other than shim6 or IPv4-style BGP multihoming for IPv6 > (which doesn't require anything new from the IETF), then you'd need to get > enough people to agree with you to hold a BOF and get a new WG started. We need more engineers experimenting with code and less trying to get WG's started. - Kevin From ppml at rs.seastrom.com Tue Oct 17 12:23:36 2006 From: ppml at rs.seastrom.com (Robert E.Seastrom) Date: Tue, 17 Oct 2006 12:23:36 -0400 Subject: [ppml] Multihome Pro Con Document In-Reply-To: <4534EE03.3060403@kl.net> (Kevin Loch's message of "Tue, 17 Oct 2006 10:51:47 -0400") References: <369EB04A0951824ABE7D8BAC67AF9BB4038F0208@CL-S-EX-1.stanleyassociates.com> <4534EE03.3060403@kl.net> Message-ID: <87wt6yvrlj.fsf@valhalla.seastrom.com> Kevin Loch writes: > Scott Leibrand wrote: >> If you think the IETF should be working >> on something other than shim6 or IPv4-style BGP multihoming for IPv6 >> (which doesn't require anything new from the IETF), then you'd need to get >> enough people to agree with you to hold a BOF and get a new WG started. > > We need more engineers experimenting with code and less trying to get > WG's started. Hear, hear. "Rough consensus and working code" unfortunately gives people the wrong impression, that consensus comes before the code. "Working code before you bother trying for rough consensus" is what historically differentiated the ARPAnet folks from the CCITT guys. Forgetting our roots has caused stagnation. Padlipsky's magnum opus is back in print (thanks to backinprint.com). Buyitreaditlearnitliveit. ---Rob From marla.azinger at frontiercorp.com Tue Oct 17 16:01:47 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Tue, 17 Oct 2006 16:01:47 -0400 Subject: [ppml] Multihome Pro Con Document Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D04089@nyrofcs2ke2k01.corp.pvt> Michel- That is true. When reading through the Pro's and Cons you will see that they address that point. Granted, it doesnt say it point blank and you have to comprehend what the pro's and con's are, but yes, this is true to be one of the hurdles we face. -----Original Message----- From: Michel Py [mailto:michel at arneill-py.sacramento.ca.us] Sent: Saturday, October 14, 2006 4:37 PM To: Azinger, Marla; ppml at arin.net Subject: RE: [ppml] Multihome Pro Con Document Hi Marla, While this document does a decent job at describing solutions, it does not address the #1 reason why no solution is deployed a decade after we started working on finding one: palatability of the solution to the end users. In other words: what are the realistic chances of a given solution to be successfully deployed in the real world. The main issue with IPv6 multihoming is not the pros and cons of solutions, but their deployability. Failure to understand this is why, 10 years after, we still are discussing the pros and cons of solutions. Michel. From marla.azinger at frontiercorp.com Tue Oct 17 16:04:53 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Tue, 17 Oct 2006 16:04:53 -0400 Subject: [ppml] Multihome Pro Con Document Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D0408A@nyrofcs2ke2k01.corp.pvt> Correct. Thank you Marla -----Original Message----- From: Jason Schiller [mailto:schiller at uu.net] Sent: Sunday, October 15, 2006 8:38 PM To: Michel Py Cc: Azinger, Marla; ppml at arin.net Subject: Re: [ppml] Multihome Pro Con Document Michael, It might be useful to explain why each of these solutions is not deployable for one or more types of multi-homing users. Adding this text may help to let people know how far off we are from a deployable solution. I'd suggest you provide some text to Marla on a solution by solution basis. Depending on the text, she can either include this info either under "cons", or "Questions to consider", or under a new section "Deployability Concerns". I suspect this is exactly what Marla was trying to do in a non-negative constructive sort of way. ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Sat, 14 Oct 2006, Michel Py wrote: > Date: Sat, 14 Oct 2006 16:36:42 -0700 > From: Michel Py > To: "Azinger, Marla" , ppml at arin.net > Subject: Re: [ppml] Multihome Pro Con Document > > Hi Marla, > > While this document does a decent job at describing solutions, it does > not address the #1 reason why no solution is deployed a decade after we > started working on finding one: palatability of the solution to the end > users. In other words: what are the realistic chances of a given > solution to be successfully deployed in the real world. > > The main issue with IPv6 multihoming is not the pros and cons of > solutions, but their deployability. Failure to understand this is why, > 10 years after, we still are discussing the pros and cons of solutions. > > Michel. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From marla.azinger at frontiercorp.com Tue Oct 17 16:22:24 2006 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Tue, 17 Oct 2006 16:22:24 -0400 Subject: [ppml] Multihome Pro Con Document Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D0408C@nyrofcs2ke2k01.corp.pvt> Outside of the IETF I have been in brief contact with two new groups that are forming to look at these routing issues. They have not publicly announced their existance yet (as far as I know), and I do not see it my place to do so. However, I will do my best to collaborate with them and keep my document updated with what comes out of those groups. As for IETF, yes, there is discussion regarding this subject going on in V6WG OPS and a document is being worked on. Should the discussion grow into a new WG? Possibly, and with input from the community this very well could happen. Thank you Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Howard, W. Lee Sent: Tuesday, October 17, 2006 7:07 AM To: ppml at arin.net Subject: Re: [ppml] Multihome Pro Con Document > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michel Py > > 2. Replace BGP with a protocol that does not care about > routing table bloat. Memory is cheap; the days that led to > the "aggregated" IPv6 design when a 7500/RSP2/128 was the > baddest core router one could buy are long gone. Today people > are running dual full feeds on a 1800... My understanding of the problem (I don't work on a default-free network anymore) is that keeping up with changes is expensive in CPU, not in memory, and that lookups against a large table are expensive in latency. What is the appropriate IETF WG for design of IPv6 multihoming solutions? shim6 is a specific solution; v6ops doesn't sound quite right. Lee > > Michel. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From woody at pch.net Tue Oct 24 17:37:29 2006 From: woody at pch.net (Bill Woodcock) Date: Tue, 24 Oct 2006 14:37:29 -0700 Subject: [ppml] Policy Proposal: Reinstatement of PGP Authentication Method Message-ID: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> 1. Policy Proposal Name: Reinstatement of PGP Authentication Method 2. Authors: 1. name: Paul Vixie 2. email: paul at vix.com 3. telephone: +1 650 423 1300 4. organization: Internet Systems Consortium 1. name: Mark Kosters 2. email: markk at verisignlabs.com 3. telephone: +1 703 948 3200 4. organization: Verisign 1. name: Chris Morrow 2. email: christopher.morrow at verizonbusiness.com 3. telephone: +1 703 886 3823 4. organization: Verizon Business/UUnet 1. name: Jared Mauch 2. email: jmauch at us.ntt.net 3. telephone: +1 214 915 1356 4. organization: NTT/Verio 1. name: Bill Woodcock 2. email: woody at pch.net 3. telephone: +1 415 831 3100 4. organization: Packet Clearing House 3. Proposal Version: 1 4. Submission Date: Tuesday, October 24, 2006 5. Proposal type: New 6. Policy term: Permanent 7. Policy statement: ADDITION TO NRPM 3.5 Authentication Methods ARIN supports three authentication methods for communication with resource recipients. 3.5.1 Mail-From This section intentionally left blank. 3.5.2 PGP ARIN accepts PGP-signed email as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 3.5.3 X.509 This section intentionally left blank. UPDATES TO TEMPLATES ARIN shall include the auth-type field in request templates as necessary to distinguish between cryptographic and mail-from authentication methods. UPDATES TO DOCUMENTATION ARIN shall update documentation as appropriate, to explain the differences between mail-from, PGP, and X.509 authentication methods. KEY USE IN COMMUNICATION: ARIN shall accept PGP-signed communications, validate the signature, compare it to the identity of the authorized POCs for records referenced in the correspondence, and act appropriately based upon the validity or invalidity of the signature. ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail which they originate with their own individual keys. ARIN shall accept PGP-encrypted communications which are encrypted using ARIN's hostmaster public key. ARIN shall not encrypt any outgoing communications, except by explicit mutual prior agreement with the recipient. NON-BINDING RECOMMENDED KEY MANAGEMENT PRACTICES: It is recommended that ARIN utilize normal POC-verification processes as necessary to accommodate users who lose the private key or passphrase associated with the POCs for their crypt-auth protected resources. It is recommended that ARIN exercise reasonable caution in preventing the proliferation of copies of the hostmaster private key and passphrase. It is recommended that ARIN print out a copy of the private key and passphrase, and secure them in a safe-deposit box outside of ARIN's physical premises, which any two ARIN officers might access in the event that the operating copy of the key is lost or compromised. It is recommended that ARIN publish the hostmaster public key on the ARIN web site, in a manner similar to that of the other RIRs: http://lacnic.net/hostmaster-pub-key.txt https://www.ripe.net/rs/pgp/ncc-pgpkey-2006.asc ftp://ftp.apnic.net/pub/zones/PUBLIC_KEY It is recommended that ARIN publish the hostmaster public key by submitting it to common PGP keyservers which, among others, might include: pgp.mit.edu www.pgp.net It is recommended that ARIN attempt to cross-sign the hostmaster PGP keys of the other four RIRs and ICANN. It is recommended that ARIN's hostmaster public key be signed by members of the ARIN board of trustees. 8. Rationale: Globally, PGP is the most commonly used cryptographic authentication method between RIRs and resource recipients who wish to protect their resource registration records against unauthorized modification. The PGP-auth authentication method is supported by RIPE, APNIC, LACNIC, and AfriNIC, and it was historically supported by the InterNIC prior to ARIN's formation. By contrast, current ARIN resource recipients have only two options: "mail-from," which is trivially spoofed and should not be relied upon to protect important database objects, and X.509, which involves a rigorous and lengthy proof-of-identity process and compels use of a compatible MUA, a combination which has dissuaded virtually all of ARIN's constituents. There isn't a lot of work to do here, and certainly nothing tricky. The hostmaster key has existed since InterNIC days, and ARIN staff have verified that the key and passphrase are still known and working fine. This is simple code, which all the other RIRs deployed without a second thought or complaint. If RIPE and APNIC have always done this, the InterNIC did it before ARIN was formed, and LACNIC and AfriNIC took this for granted as a part of their startup process, we see no reason why ARIN should be the only RIR to not offer this most basic of protections to its members. We need to get PGP support reinstated, so that our records can be protected against hijacking and vandalism, and so we won't look like idiots as the only one of the five regions that can't figure this stuff out. 9. Timetable for implementation: Immediate 10. Meeting presenter: Bill Woodcock END OF TEMPLATE -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From woody at pch.net Tue Oct 24 17:38:33 2006 From: woody at pch.net (Bill Woodcock) Date: Tue, 24 Oct 2006 14:38:33 -0700 Subject: [ppml] Policy Proposal: Documentation of the Mail-From Authentication Method Message-ID: 1. Policy Proposal Name: Documentation of the Mail-From Authentication Method 2. Authors: 1. name: Paul Vixie 2. email: paul at vix.com 3. telephone: +1 650 423 1300 4. organization: Internet Systems Consortium 1. name: Mark Kosters 2. email: markk at verisignlabs.com 3. telephone: +1 703 948 3200 4. organization: Verisign 1. name: Chris Morrow 2. email: christopher.morrow at verizonbusiness.com 3. telephone: +1 703 886 3823 4. organization: Verizon Business/UUnet 1. name: Jared Mauch 2. email: jmauch at us.ntt.net 3. telephone: +1 214 915 1356 4. organization: NTT/Verio 1. name: Bill Woodcock 2. email: woody at pch.net 3. telephone: +1 415 831 3100 4. organization: Packet Clearing House 3. Proposal Version: 1 4. Submission Date: Tuesday, October 24, 2006 5. Proposal type: New 6. Policy term: Permanent 7. Policy statement: DELETION FROM THE NRPM 3.5.1 Mail-From This section intentionally left blank. ADDITION TO THE NRPM 3.5.1 Mail-From Mail-From is the default authentication method by which registration records are protected from vandalism. If a registrant fails to designate a more secure method, any subsequent email which bears the sender address of an authorized Point of Contact may be deemed authentic with regard to the registrant's records. Since it is trivial to forge a sender address, Mail-From should not be regarded as secure. Use of Mail-From authentication is not recommended to any registrant who has the means to implement either of the more secure cryptographic authentication methods. 8. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 3.5 to the NRPM. Section 3.5 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the mail-from authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. 9. Timetable for implementation: Immediate 10. Meeting presenter: Bill Woodcock END OF TEMPLATE -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From woody at pch.net Tue Oct 24 17:38:45 2006 From: woody at pch.net (Bill Woodcock) Date: Tue, 24 Oct 2006 14:38:45 -0700 Subject: [ppml] Policy Proposal: Documentation of the X.509 Authentication Method Message-ID: 1. Policy Proposal Name: Documentation of the X.509 Authentication Method 2. Authors: 1. name: Paul Vixie 2. email: paul at vix.com 3. telephone: +1 650 423 1300 4. organization: Internet Systems Consortium 1. name: Mark Kosters 2. email: markk at verisignlabs.com 3. telephone: +1 703 948 3200 4. organization: Verisign 1. name: Chris Morrow 2. email: christopher.morrow at verizonbusiness.com 3. telephone: +1 703 886 3823 4. organization: Verizon Business/UUnet 1. name: Jared Mauch 2. email: jmauch at us.ntt.net 3. telephone: +1 214 915 1356 4. organization: NTT/Verio 1. name: Bill Woodcock 2. email: woody at pch.net 3. telephone: +1 415 831 3100 4. organization: Packet Clearing House 3. Proposal Version: 1 4. Submission Date: Tuesday, October 24, 2006 5. Proposal type: New 6. Policy term: Permanent 7. Policy statement: DELETION FROM THE NRPM 3.5.3 X.509 This section intentionally left blank. ADDITION TO THE NRPM 3.5.3 X.509 ARIN accepts X.509-signed transactions as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 8. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 3.5 to the NRPM. Section 3.5 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the X.509 authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. 9. Timetable for implementation: Immediate 10. Meeting presenter: Bill Woodcock END OF TEMPLATE -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From owen at delong.com Tue Oct 24 18:26:55 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Oct 2006 15:26:55 -0700 Subject: [ppml] Policy Proposal: Reinstatement of PGP Authentication Method In-Reply-To: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> References: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> Message-ID: <1B27D09D-6093-427C-8A6D-78B4E9DABD26@delong.com> I completely support this policy as written. Well done. Owen On Oct 24, 2006, at 2:37 PM, Bill Woodcock wrote: > 1. Policy Proposal Name: Reinstatement of PGP Authentication Method > > 2. Authors: > > 1. name: Paul Vixie > 2. email: paul at vix.com > 3. telephone: +1 650 423 1300 > 4. organization: Internet Systems Consortium > > 1. name: Mark Kosters > 2. email: markk at verisignlabs.com > 3. telephone: +1 703 948 3200 > 4. organization: Verisign > > 1. name: Chris Morrow > 2. email: christopher.morrow at verizonbusiness.com > 3. telephone: +1 703 886 3823 > 4. organization: Verizon Business/UUnet > > 1. name: Jared Mauch > 2. email: jmauch at us.ntt.net > 3. telephone: +1 214 915 1356 > 4. organization: NTT/Verio > > 1. name: Bill Woodcock > 2. email: woody at pch.net > 3. telephone: +1 415 831 3100 > 4. organization: Packet Clearing House > > 3. Proposal Version: 1 > > 4. Submission Date: Tuesday, October 24, 2006 > > 5. Proposal type: New > > 6. Policy term: Permanent > > 7. Policy statement: > > ADDITION TO NRPM > > 3.5 Authentication Methods > ARIN supports three authentication methods for > communication with resource recipients. > > 3.5.1 Mail-From > This section intentionally left blank. > > 3.5.2 PGP > ARIN accepts PGP-signed email as authentic > communication from authorized Points of Contact. > POCs > may denote their records "crypt-auth," subsequent to > which unsigned communications shall not be deemed > authentic with regard to those records. > > 3.5.3 X.509 > This section intentionally left blank. > > UPDATES TO TEMPLATES > > ARIN shall include the auth-type field in request templates as > necessary to distinguish between cryptographic and mail-from > authentication methods. > > UPDATES TO DOCUMENTATION > > ARIN shall update documentation as appropriate, to explain the > differences between mail-from, PGP, and X.509 authentication > methods. > > KEY USE IN COMMUNICATION: > > ARIN shall accept PGP-signed communications, validate the > signature, compare it to the identity of the authorized POCs > for records referenced in the correspondence, and act > appropriately based upon the validity or invalidity of the > signature. > > ARIN shall PGP-sign all outgoing hostmaster email with the > hostmaster role key, and staff members may optionally also > sign mail which they originate with their own individual keys. > > ARIN shall accept PGP-encrypted communications > which are encrypted using ARIN's hostmaster public key. > > ARIN shall not encrypt any outgoing communications, except by > explicit mutual prior agreement with the recipient. > > NON-BINDING RECOMMENDED KEY MANAGEMENT PRACTICES: > > It is recommended that ARIN utilize normal POC-verification > processes as necessary to accommodate users who lose the > private key or passphrase associated with the POCs for their > crypt-auth protected resources. > > It is recommended that ARIN exercise reasonable caution in > preventing the proliferation of copies of the hostmaster > private key and passphrase. > > It is recommended that ARIN print out a copy of the private > key > and passphrase, and secure them in a safe-deposit box outside > of ARIN's physical premises, which any two ARIN officers might > access in the event that the operating copy of the key is lost > or compromised. > > It is recommended that ARIN publish the hostmaster public key > on the ARIN web site, in a manner similar to that of the other > RIRs: > http://lacnic.net/hostmaster-pub-key.txt > https://www.ripe.net/rs/pgp/ncc-pgpkey-2006.asc > ftp://ftp.apnic.net/pub/zones/PUBLIC_KEY > > It is recommended that ARIN publish the hostmaster public key > by submitting it to common PGP keyservers which, among others, > might include: > pgp.mit.edu > www.pgp.net > > It is recommended that ARIN attempt to cross-sign the > hostmaster PGP keys of the other four RIRs and ICANN. > > It is recommended that ARIN's hostmaster public key be signed > by members of the ARIN board of trustees. > > 8. Rationale: > > Globally, PGP is the most commonly used cryptographic > authentication method between RIRs and resource recipients who > wish to protect their resource registration records against > unauthorized modification. The PGP-auth authentication method > is supported by RIPE, APNIC, LACNIC, and AfriNIC, and it was > historically supported by the InterNIC prior to ARIN's > formation. By contrast, current ARIN resource recipients have > only two options: "mail-from," which is trivially spoofed and > should not be relied upon to protect important database > objects, and X.509, which involves a rigorous and lengthy > proof-of-identity process and compels use of a compatible MUA, > a combination which has dissuaded virtually all of ARIN's > constituents. > > There isn't a lot of work to do here, and certainly nothing > tricky. The hostmaster key has existed since InterNIC days, > and > ARIN staff have verified that the key and passphrase are still > known and working fine. This is simple code, which all the > other RIRs deployed without a second thought or complaint. If > RIPE and APNIC have always done this, the InterNIC did it > before ARIN was formed, and LACNIC and AfriNIC took this for > granted as a part of their startup process, we see no reason > why ARIN should be the only RIR to not offer this most > basic of > protections to its members. > > We need to get PGP support reinstated, so that our records can > be protected against hijacking and vandalism, and so we won't > look like idiots as the only one of the five regions that > can't > figure this stuff out. > > 9. Timetable for implementation: Immediate > > 10. Meeting presenter: Bill Woodcock > > END OF TEMPLATE > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Tue Oct 24 21:29:32 2006 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 24 Oct 2006 21:29:32 -0400 Subject: [ppml] Policy Proposal: Documentation of the X.509 Authentication Method In-Reply-To: References: Message-ID: <20061025012932.GA81663@ussenterprise.ufp.org> I'm supportive of this additional clarity in the NRPM, however I think the X.509 documentation is missing two key points: 1) ARIN accepts only ARIN provided certificates, so users who want to use this method will need to request a certificate from ARIN. 2) Some sort of pointer to where to find more information about how to get an ARIN certificate. I'm not sure we want a URL in the text, but the information is at http://www.arin.net/CA/. It may be better to reference the location via the name of some document, or other reference. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Tue Oct 24 21:40:55 2006 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 24 Oct 2006 21:40:55 -0400 Subject: [ppml] Policy Proposal: Reinstatement of PGP Authentication Method In-Reply-To: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> References: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> Message-ID: <20061025014055.GB81663@ussenterprise.ufp.org> In a message written on Tue, Oct 24, 2006 at 02:37:29PM -0700, Bill Woodcock wrote: > There isn't a lot of work to do here, and certainly nothing > tricky. The hostmaster key has existed since InterNIC days, and > ARIN staff have verified that the key and passphrase are still > known and working fine. This is simple code, which all the I support this policy, however I have a minor issue with the text above that goes with it. Internet != ARIN. Since a key isn't referenced by Key ID or Fingerprint it's impossible to tell for sure which key is being referenced, however I assume the author intends for ARIN to continue using the original InterNIC key. Since ARIN is not InterNIC, I don't think it would be appropriate for them to use the InterNIC hostmaster key, even if they now have the private key and passphrase. ARIN should have an ARIN key, properly cross signed by other RIR's and various other entities as suggested and use it to sign ARIN published material. This will allow cryptographic proof of things that came from InterNIC, and things that came from ARIN. Also, while I don't know which key is specifically being referenced, I suspect a key from the InterNIC time frame may not meet current standards for algorithm or key length. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From dsd at servervault.com Tue Oct 24 23:22:50 2006 From: dsd at servervault.com (Divins, David) Date: Tue, 24 Oct 2006 23:22:50 -0400 Subject: [ppml] Policy Proposal: Documentation of the X.509 AuthenticationMethod In-Reply-To: Message-ID: Thank you! I support all of three of these. -dsd David Divins Principal Engineer ServerVault Corp. ________________________________ From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Bill Woodcock Sent: Tuesday, October 24, 2006 5:39 PM To: ppml at arin.net Subject: [ppml] Policy Proposal: Documentation of the X.509 AuthenticationMethod 1. Policy Proposal Name: Documentation of the X.509 Authentication Method 2. Authors: 1. name: Paul Vixie 2. email: paul at vix.com 3. telephone: +1 650 423 1300 4. organization: Internet Systems Consortium 1. name: Mark Kosters 2. email: markk at verisignlabs.com 3. telephone: +1 703 948 3200 4. organization: Verisign 1. name: Chris Morrow 2. email: christopher.morrow at verizonbusiness.com 3. telephone: +1 703 886 3823 4. organization: Verizon Business/UUnet 1. name: Jared Mauch 2. email: jmauch at us.ntt.net 3. telephone: +1 214 915 1356 4. organization: NTT/Verio 1. name: Bill Woodcock 2. email: woody at pch.net 3. telephone: +1 415 831 3100 4. organization: Packet Clearing House 3. Proposal Version: 1 4. Submission Date: Tuesday, October 24, 2006 5. Proposal type: New 6. Policy term: Permanent 7. Policy statement: DELETION FROM THE NRPM 3.5.3 X.509 This section intentionally left blank. ADDITION TO THE NRPM 3.5.3 X.509 ARIN accepts X.509-signed transactions as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 8. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 3.5 to the NRPM. Section 3.5 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the X.509 authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. 9. Timetable for implementation: Immediate 10. Meeting presenter: Bill Woodcock END OF TEMPLATE -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Oct 25 00:07:00 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Oct 2006 21:07:00 -0700 Subject: [ppml] Policy Proposal: Documentation of the X.509Authentication Method Message-ID: <200610250407.k9P47ekU010416@mailhost.delong.com> I would suggest ARIN signed vs. ARIN "provided". Signed has a specific meaning. Provided does not and the likely meanings I consider for it are NOT what I think is intended. ORG should generate key-pair and CSR. ARIN should sign and return signed cert. Owen -----Original Message----- From: Leo Bicknell Subj: Re: [ppml] Policy Proposal: Documentation of the X.509Authentication Method Date: Tue 2006 Oct 24 18:29 Size: 705 bytes To: ppml at arin.net I'm supportive of this additional clarity in the NRPM, however I think the X.509 documentation is missing two key points: 1) ARIN accepts only ARIN provided certificates, so users who want to use this method will need to request a certificate from ARIN. 2) Some sort of pointer to where to find more information about how to get an ARIN certificate. I'm not sure we want a URL in the text, but the information is at http://www.arin.net/CA/. It may be better to reference the location via the name of some document, or other reference. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From woody at pch.net Wed Oct 25 04:51:39 2006 From: woody at pch.net (Bill Woodcock) Date: Wed, 25 Oct 2006 01:51:39 -0700 (PDT) Subject: [ppml] Policy Proposal: Reinstatement of PGP Authentication Method In-Reply-To: <20061025014055.GB81663@ussenterprise.ufp.org> References: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> <20061025014055.GB81663@ussenterprise.ufp.org> Message-ID: On Tue, 24 Oct 2006, Leo Bicknell wrote: > Since a key isn't referenced by Key ID or Fingerprint it's > impossible to tell for sure which key is being referenced, however I > assume the author intends for ARIN to continue using the original > InterNIC key. The document is not intended to be prescriptive at that level of nanomanagement. The ARIN staff have assured us that they have an appropriate key, and they're able to make it work in the necessary way. We assume that they know what they're talking about. Your point is well taken, and that key being identifiably different than a preexisting InterNIC key would have some value. You're on the AC, and you may be able to work that in, if the rest of the AC feels it's appropriate, or you could create an additional and complementary policy, if you feel taht it's necessary, or you could just let your clearly-communicated suggestion stand, knowing that the staff read the PPML and are intelligent people who will weigh the idea judiciously. -Bill From Michael.Dillon at btradianz.com Wed Oct 25 05:41:14 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 25 Oct 2006 10:41:14 +0100 Subject: [ppml] Policy Proposal: Reinstatement of PGP Authentication Method In-Reply-To: <20061025014055.GB81663@ussenterprise.ufp.org> Message-ID: > ARIN should have an ARIN key, properly cross signed by other RIR's > and various other entities as suggested and use it to sign ARIN > published material. I agree with this. ARIN should not reuse the old InterNIC hostmaster key because ARIN is not the InterNIC and ARIN is also not the only successor of the InterNIC. Creating a new ARIN key is trivial and ensures that the PRIVACY of this key can be known and maintained. --Michael Dillon From info at arin.net Wed Oct 25 09:34:37 2006 From: info at arin.net (Member Services) Date: Wed, 25 Oct 2006 09:34:37 -0400 Subject: [ppml] Policy Proposal: Reinstatement of PGP Authentication Method In-Reply-To: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> References: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> Message-ID: <453F67ED.3020306@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. This proposal was received within 10 days of the next scheduled meeting of the ARIN Advisory Council; the review period may be extended to the regularly scheduled meeting that occurs after the upcoming meeting. If the AC accepts the proposal or reaches an agreement with the author, then the proposal will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal or can not reach an agreement with the author, then the AC will notify the community of their decision with an explanation; at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Reinstatement of PGP Authentication Method Authors: Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Submission Date: Tuesday, October 24, 2006 Proposal type: New Policy term: Permanent Policy statement: ADDITION TO NRPM 3.5 Authentication Methods ARIN supports three authentication methods for communication with resource recipients. 3.5.1 Mail-From This section intentionally left blank. 3.5.2 PGP ARIN accepts PGP-signed email as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 3.5.3 X.509 This section intentionally left blank. UPDATES TO TEMPLATES ARIN shall include the auth-type field in request templates as necessary to distinguish between cryptographic and mail-from authentication methods. UPDATES TO DOCUMENTATION ARIN shall update documentation as appropriate, to explain the differences between mail-from, PGP, and X.509 authentication methods. KEY USE IN COMMUNICATION: ARIN shall accept PGP-signed communications, validate the signature, compare it to the identity of the authorized POCs for records referenced in the correspondence, and act appropriately based upon the validity or invalidity of the signature. ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail which they originate with their own individual keys. ARIN shall accept PGP-encrypted communications which are encrypted using ARIN's hostmaster public key. ARIN shall not encrypt any outgoing communications, except by explicit mutual prior agreement with the recipient. NON-BINDING RECOMMENDED KEY MANAGEMENT PRACTICES: It is recommended that ARIN utilize normal POC-verification processes as necessary to accommodate users who lose the private key or passphrase associated with the POCs for their crypt-auth protected resources. It is recommended that ARIN exercise reasonable caution in preventing the proliferation of copies of the hostmaster private key and passphrase. It is recommended that ARIN print out a copy of the private key and passphrase, and secure them in a safe-deposit box outside of ARIN's physical premises, which any two ARIN officers might access in the event that the operating copy of the key is lost or compromised. It is recommended that ARIN publish the hostmaster public key on the ARIN web site, in a manner similar to that of the other RIRs: http://lacnic.net/hostmaster-pub-key.txt https://www.ripe.net/rs/pgp/ncc-pgpkey-2006.asc ftp://ftp.apnic.net/pub/zones/PUBLIC_KEY It is recommended that ARIN publish the hostmaster public key by submitting it to common PGP keyservers which, among others, might include: pgp.mit.edu www.pgp.net It is recommended that ARIN attempt to cross-sign the hostmaster PGP keys of the other four RIRs and ICANN. It is recommended that ARIN's hostmaster public key be signed by members of the ARIN board of trustees. Rationale: Globally, PGP is the most commonly used cryptographic authentication method between RIRs and resource recipients who wish to protect their resource registration records against unauthorized modification. The PGP-auth authentication method is supported by RIPE, APNIC, LACNIC, and AfriNIC, and it was historically supported by the InterNIC prior to ARIN's formation. By contrast, current ARIN resource recipients have only two options: "mail-from," which is trivially spoofed and should not be relied upon to protect important database objects, and X.509, which involves a rigorous and lengthy proof-of-identity process and compels use of a compatible MUA, a combination which has dissuaded virtually all of ARIN's constituents. There isn't a lot of work to do here, and certainly nothing tricky. The hostmaster key has existed since InterNIC days, and ARIN staff have verified that the key and passphrase are still known and working fine. This is simple code, which all the other RIRs deployed without a second thought or complaint. If RIPE and APNIC have always done this, the InterNIC did it before ARIN was formed, and LACNIC and AfriNIC took this for granted as a part of their startup process, we see no reason why ARIN should be the only RIR to not offer this most basic of protections to its members. We need to get PGP support reinstated, so that our records can be protected against hijacking and vandalism, and so we won't look like idiots as the only one of the five regions that can't figure this stuff out. Timetable for implementation: Immediate From info at arin.net Wed Oct 25 09:34:48 2006 From: info at arin.net (Member Services) Date: Wed, 25 Oct 2006 09:34:48 -0400 Subject: [ppml] Policy Proposal: Documentation of the Mail-From Authentication Method In-Reply-To: References: Message-ID: <453F67F8.5050307@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. This proposal was received within 10 days of the next scheduled meeting of the ARIN Advisory Council; the review period may be extended to the regularly scheduled meeting that occurs after the upcoming meeting. If the AC accepts the proposal or reaches an agreement with the author, then the proposal will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal or can not reach an agreement with the author, then the AC will notify the community of their decision with an explanation; at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Documentation of the Mail-From Authentication Method Authors: Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Proposal Version: 1 Submission Date: Tuesday, October 24, 2006 Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 3.5.1 Mail-From This section intentionally left blank. ADDITION TO THE NRPM 3.5.1 Mail-From Mail-From is the default authentication method by which registration records are protected from vandalism. If a registrant fails to designate a more secure method, any subsequent email which bears the sender address of an authorized Point of Contact may be deemed authentic with regard to the registrant's records. Since it is trivial to forge a sender address, Mail-From should not be regarded as secure. Use of Mail-From authentication is not recommended to any registrant who has the means to implement either of the more secure cryptographic authentication methods. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 3.5 to the NRPM. Section 3.5 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the mail-from authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Wed Oct 25 09:35:01 2006 From: info at arin.net (Member Services) Date: Wed, 25 Oct 2006 09:35:01 -0400 Subject: [ppml] Policy Proposal: Documentation of the X.509 Authentication Method In-Reply-To: References: Message-ID: <453F6805.3010100@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. This proposal was received within 10 days of the next scheduled meeting of the ARIN Advisory Council; the review period may be extended to the regularly scheduled meeting that occurs after the upcoming meeting. If the AC accepts the proposal or reaches an agreement with the author, then the proposal will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal or can not reach an agreement with the author, then the AC will notify the community of their decision with an explanation; at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Documentation of the X.509 Authentication Method Authors: Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Proposal Version: 1 Submission Date: Tuesday, October 24, 2006 Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 3.5.3 X.509 This section intentionally left blank. ADDITION TO THE NRPM 3.5.3 X.509 ARIN accepts X.509-signed transactions as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 3.5 to the NRPM. Section 3.5 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the X.509 authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From owen at delong.com Wed Oct 25 12:33:50 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Oct 2006 09:33:50 -0700 Subject: [ppml] Policy Proposal: Reinstatement of PGP Authentication Method In-Reply-To: References: Message-ID: <39311480-4B79-4BF1-AE98-1F849FBBE9E3@delong.com> While I agree that this is the right course of action and strongly encourage staff to do so, I also agree with Woody that it is an operational issue best addressed by the staff and not an something which should be micro- managed by policy. Owen From info at arin.net Wed Oct 25 12:48:24 2006 From: info at arin.net (Member Services) Date: Wed, 25 Oct 2006 12:48:24 -0400 Subject: [ppml] ARIN XVIII Meeting Report Now Available Message-ID: <453F9558.5010300@arin.net> The ARIN community recently concluded the ARIN XVIII Public Policy and Members Meetings, held in St. Louis, Missouri, 11-13 October 2006. The meeting report includes presentations, summary notes, and transcripts of these meetings, and is now available on the ARIN website at: http://www.arin.net/meetings/minutes/ARIN_XVIII/ The archives of the webcast will be added to the meeting report when they become available. In addition to these files, the page referenced above has links to presentations for the Sunday "Networking with IPv6" workshop and tutorials. We thank all in the community who participated either in person or remotely, and look forward to seeing you all again for ARIN XIX, which will take place 22-25 April 2007. Regards, Member Services American Registry for Internet Numbers (ARIN) From bicknell at ufp.org Wed Oct 25 15:06:07 2006 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 25 Oct 2006 15:06:07 -0400 Subject: [ppml] Policy Proposal: Reinstatement of PGP Authentication Method In-Reply-To: References: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> <20061025014055.GB81663@ussenterprise.ufp.org> Message-ID: <20061025190607.GB38561@ussenterprise.ufp.org> Fortunately it's in the rational, not the policy as the authors did a wonderful job separating the two items. As such I believe this point will be a minor footnote staff can handle if the policy moves forward. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Thu Oct 26 06:24:59 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 26 Oct 2006 11:24:59 +0100 Subject: [ppml] US District Court, Oct 23rd Message-ID: Any news on what happened? ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon at btradianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com One Community One Connection One Focus From jcurran at istaff.org Thu Oct 26 06:31:30 2006 From: jcurran at istaff.org (John Curran) Date: Thu, 26 Oct 2006 06:31:30 -0400 Subject: [ppml] US District Court, Oct 23rd In-Reply-To: References: Message-ID: Michael, Very hard to comment publicly on an active case... I will check with ARIN counsel to see if anything can be said and get back shortly. /John John Curran Chairman, ARIN Board of Trustees From sleibrand at internap.com Thu Oct 26 08:24:40 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 26 Oct 2006 08:24:40 -0400 (EDT) Subject: [ppml] US District Court, Oct 23rd In-Reply-To: References: Message-ID: Does anyone have links to any filings or news articles they can post? IANAL, but AFAIK pointing people to public information can't be considered "comment"... -Scott On 10/26/06 at 6:31am -0400, John Curran wrote: > Michael, > > Very hard to comment publicly on an active case... I will check > with ARIN counsel to see if anything can be said and get back > shortly. > > /John > > John Curran > Chairman, ARIN Board of Trustees > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From owen at delong.com Thu Oct 26 09:00:35 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Oct 2006 06:00:35 -0700 Subject: [ppml] US District Court, Oct 23rd In-Reply-To: References: Message-ID: I was there. The judge took the matter under submission, so, effectively, nothing happened yet. He did state that he would rule "soon" on the two motions before the court. I'll leave it to counsel to make any further comment on the proceedings. Owen On Oct 26, 2006, at 3:31 AM, John Curran wrote: > Michael, > > Very hard to comment publicly on an active case... I will check > with ARIN counsel to see if anything can be said and get back > shortly. > > /John > > John Curran > Chairman, ARIN Board of Trustees > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Thu Oct 26 11:57:09 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 26 Oct 2006 16:57:09 +0100 Subject: [ppml] Fw: US District Court, Oct 23rd Message-ID: > Any news on what happened? Some have asked me personally, "What on earth are you talking about?". If you were at the meeting then you know, and if you read the transcript of the meeting here (scroll down to MR. RYAN) http://www.arin.net/meetings/minutes/ARIN_XVIII/ppm1_transcript.html#anchor_1 then you also know. Basically, ARIN counsel stated at the meeting that the lawsuit where Kremen is suing ARIN, would come before Judge Ware of the US District Court in San Jose on Oct 23rd. This happens to be the same judge who earlier ruled that Kremen was the rightful owner of the domain sex.com. In a nutshell, Kremen is claiming that he owns some IP addresses and that ARIN should give them to him right away with no formalities, which seems to imply that he doesn't have to comply with any of ARIN's policies and procedures. For instance, he has refused to sign a registration services agreement. The results of this are important, because it could undermine ARIN's fundamental democratic nature and serve as a precedent for US government regulation of stuff like ARIN does. After all, if a court can simply set aside ARIN's open processes and democratically-made decisions in favor of someone who can afford to launch a lawsuit, then all of us are in a rather unstable position regarding our right to use the IP addresses that we have been allocated. It also raises doubts about an ISPs ability to withdraw assigned addresses when a customer ceases to be connected to their network. If ARIN's right to run things our own way is not recognized by the courts then the only way I can see to fix that is via new legislation which could well lead to regulation. This is darned important stuff and I wish that someone was following it in the way that groklaw.net follows the SCO-IBM dispute. --Michael Dillon From sleibrand at internap.com Thu Oct 26 14:17:52 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 26 Oct 2006 14:17:52 -0400 Subject: [ppml] Fw: US District Court, Oct 23rd In-Reply-To: References: Message-ID: <4540FBD0.8020001@internap.com> Well put. The other thing that this lawsuit could do (if the plaintiff prevails against ARIN) is put in place a precedent that IP addresses are property, thereby opening the door for companies to buy and sell IPs without regard to ARIN policies. In the extreme, this could open the door wide open to market (re-)distribution of IPs, which is controversial to say the least. -Scott Michael.Dillon at btradianz.com wrote: >> Any news on what happened? >> > > Some have asked me personally, "What on earth are > you talking about?". If you were at the meeting > then you know, and if you read the transcript > of the meeting here (scroll down to MR. RYAN) > http://www.arin.net/meetings/minutes/ARIN_XVIII/ppm1_transcript.html#anchor_1 > then you also know. > > Basically, ARIN counsel stated at the meeting > that the lawsuit where Kremen is suing ARIN, > would come before Judge Ware of the US District > Court in San Jose on Oct 23rd. This happens to > be the same judge who earlier ruled that Kremen > was the rightful owner of the domain sex.com. > > In a nutshell, Kremen is claiming that he owns some > IP addresses and that ARIN should give them to him > right away with no formalities, which seems to imply > that he doesn't have to comply with any of ARIN's > policies and procedures. For instance, he has refused > to sign a registration services agreement. > > The results of this are important, because it could > undermine ARIN's fundamental democratic nature and > serve as a precedent for US government regulation of > stuff like ARIN does. After all, if a court can simply > set aside ARIN's open processes and democratically-made > decisions in favor of someone who can afford to launch > a lawsuit, then all of us are in a rather unstable > position regarding our right to use the IP addresses > that we have been allocated. It also raises doubts about > an ISPs ability to withdraw assigned addresses when a > customer ceases to be connected to their network. > If ARIN's right to run things our own way is not > recognized by the courts then the only way I can see > to fix that is via new legislation which could well > lead to regulation. > > This is darned important stuff and I wish that someone > was following it in the way that groklaw.net follows > the SCO-IBM dispute. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From tli at tropos.com Thu Oct 26 16:50:16 2006 From: tli at tropos.com (Tony Li) Date: Thu, 26 Oct 2006 13:50:16 -0700 Subject: [ppml] Fw: US District Court, Oct 23rd In-Reply-To: <4540FBD0.8020001@internap.com> Message-ID: <001801c6f940$57c836c0$9b01a8c0@tropos.com> Of course, it would also have to stand up to an appeal. Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Thursday, October 26, 2006 11:18 AM > To: Michael.Dillon at btradianz.com > Cc: ppml at arin.net > Subject: Re: [ppml] Fw: US District Court, Oct 23rd > > Well put. The other thing that this lawsuit could do (if the > plaintiff > prevails against ARIN) is put in place a precedent that IP > addresses are > property, thereby opening the door for companies to buy and sell IPs > without regard to ARIN policies. In the extreme, this could open the > door wide open to market (re-)distribution of IPs, which is > controversial to say the least. > > -Scott > > Michael.Dillon at btradianz.com wrote: > >> Any news on what happened? > >> > > > > Some have asked me personally, "What on earth are > > you talking about?". If you were at the meeting > > then you know, and if you read the transcript > > of the meeting here (scroll down to MR. RYAN) > > > http://www.arin.net/meetings/minutes/ARIN_XVIII/ppm1_transcrip > t.html#anchor_1 > > then you also know. > > > > Basically, ARIN counsel stated at the meeting > > that the lawsuit where Kremen is suing ARIN, > > would come before Judge Ware of the US District > > Court in San Jose on Oct 23rd. This happens to > > be the same judge who earlier ruled that Kremen > > was the rightful owner of the domain sex.com. > > > > In a nutshell, Kremen is claiming that he owns some > > IP addresses and that ARIN should give them to him > > right away with no formalities, which seems to imply > > that he doesn't have to comply with any of ARIN's > > policies and procedures. For instance, he has refused > > to sign a registration services agreement. > > > > The results of this are important, because it could > > undermine ARIN's fundamental democratic nature and > > serve as a precedent for US government regulation of > > stuff like ARIN does. After all, if a court can simply > > set aside ARIN's open processes and democratically-made > > decisions in favor of someone who can afford to launch > > a lawsuit, then all of us are in a rather unstable > > position regarding our right to use the IP addresses > > that we have been allocated. It also raises doubts about > > an ISPs ability to withdraw assigned addresses when a > > customer ceases to be connected to their network. > > If ARIN's right to run things our own way is not > > recognized by the courts then the only way I can see > > to fix that is via new legislation which could well > > lead to regulation. > > > > This is darned important stuff and I wish that someone > > was following it in the way that groklaw.net follows > > the SCO-IBM dispute. > > > > --Michael Dillon > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From michel at arneill-py.sacramento.ca.us Fri Oct 27 00:02:17 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 26 Oct 2006 21:02:17 -0700 Subject: [ppml] Fw: US District Court, Oct 23rd In-Reply-To: <001801c6f940$57c836c0$9b01a8c0@tropos.com> Message-ID: > Scott Leibrand wrote: > The other thing that this lawsuit could do (if the plaintiff > prevails against ARIN) is put in place a precedent that IP > addresses are property, thereby opening the door for companies > to buy and sell IPs without regard to ARIN policies. In the > extreme, this could open the door wide open to market (re-) > distribution of IPs, which is controversial to say the least. Indeed. That being said, in every problem there is an opportunity, and I do see one here. Regardless of the outcome, I think this lawsuit is not the last one of its kind; even if ARIN prevails and even if Kremen does not appeal or loses all the appeals all the way up to the Supreme Court, it is my opinion that more lawsuits will come. Like it or not and regardless who wins, the closer we get closer to IPv4 exhaustion, the more IPv4 blocks will become a traded commodity. Valid or not, claims of ownership of IP blocks will be brought to courts. I don't like the way our (*) legal system works, but it has been proven many times that a bad settlement is better than a good trial, and that a jerk with money and friends can use the legal system at his advantage regardless of merits. Swamp blocks hijacked with clever tricks involving re-registering expired domains and other ruses have "sold" (note the quotes) on eBay and on the black market before, I don't see it stopping. Although I do have my views on how to address this (**), it's not the point I'm trying to make today; IP blocks WILL "sell". How many will change hands and for how much per IP address remains to be seen; maybe they'll "sell" on the black market; maybe the RIRs will control it. This has to be decided yet. The point I'm trying to make is as follows: I think it is important that the community leverages the legal knowledge that will be acquired in this Kremen deal to lobby for legislature that will insure that future copycat lawsuits have better legal ground that what we have today. Legislature based on community wishes, not on who can afford the best attorneys. (***) Michel. (*) Given the subject line and my email address, "our" obviously means "the USA's". That being said, I have lived in several countries and traveled to many more; the sentence "a bad settlement is better than a good trial" seems to be a popular saying all over the world. (**) For the record, my position is that, when the time comes, the RIRs should authorize transfer of IP blocks between entities, even if the transfer involves money, as long as the new recipient entity signs the registration services agreement and pays the annual fees. No service agreement, no IP. IP addresses are not property of individuals or corporations. The RIRs lease IP blocks. Failure to recognize market forces or failure to secure relevant legislation will result it black market deals and endless lawsuits on shaky legal grounds. (***) Unfortunately, lobbying for legislature involves getting involved with lobbyists, many of which are attorneys and all of which have very deep pockets. I realize the ambiguity of my recommendation. For a very reasonable 15% fee, I am willing to introduce ARIN to successful California lobbyists :-D From heldal at eml.cc Fri Oct 27 07:30:16 2006 From: heldal at eml.cc (Per Heldal) Date: Fri, 27 Oct 2006 13:30:16 +0200 Subject: [ppml] Fw: US District Court, Oct 23rd In-Reply-To: References: Message-ID: <1161948616.17115.65.camel@localhost.localdomain> On Thu, 2006-10-26 at 21:02 -0700, Michel Py wrote: > Although I do have my views on how to address this (**), it's not the > point I'm trying to make today; IP blocks WILL "sell". How many will > change hands and for how much per IP address remains to be seen; maybe > they'll "sell" on the black market; maybe the RIRs will control it. This > has to be decided yet. Don't forget that a significant part of the internet is outside US jurisdiction. What happens if you look at it as buying a slot in the DFZ as opposed to a block of addresses? Then: - How do you ensure fair compensation to all DFZ operators? - Can you force everyone operating in the DFZ (globally) to carry your prefix(es)? What regulation would be necessary? - What if a significant group of international transit providers choose to reject the trade of addresses and choose to quarantine traded addresses (drop them from their view of the DFZ like bogons)? - How do you isolate a local commercial market trading global resources which can be had for free elsewhere? Keep in mind that a shortage in v4 addresses if and when it happens most likely will be compensated by a transition to v6 or some other yet unknown/better solution. -- Per Heldal - http://heldal.eml.cc/