From leo at ripe.net Sat Mar 1 06:28:44 2003 From: leo at ripe.net (leo vegoda) Date: Sat, 1 Mar 2003 12:28:44 +0100 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: References: <2147483647.1046379118@d57.wireless.hilander.com> Message-ID: Hi William, william at elan.net writes: [...] >> IPv4 CIDR block Default RIPE NCC Smallest RIPE NCC >> Allocation Allocation / Assignment >> 62/8 /19 /19 >> 80/8 /20 /20 >> 81/8 /20 /20 >> 82/8 /20 /20 >> 193/8 /19 /29 >> 194/8 /19 /29 >> 195/8 /19 /29 >> 212/8 /19 /19 >> 213/8 /19 /19 >> 217/8 /20 /20 >How am I not correct if on the same RIPE document it says "Allocations or >assignments smaller than the default size have been made to users >requesting Provider Independent (PI) IPv4 address space." (did I see /29 >there above?). The longest prefixes have come from the oldest /8s: 193/8 and 194/7. In the other /8s we do not issue anything longer than a /19 or /20 (depending on the /8). The RIPE policy document "Provider Independent -vs- Provider Aggregatable Address Space" (ripe-127) states: Assignment criteria for both kinds of address space will be exactly identical w.r.t. the amount of address space assigned, the registration require- ments etc.. This also implies that assigning PI space prefixes longer than 24 bits is perfectly acceptable if the request does not merit 8 bits of address space to be assigned. [...] >But to be more to the point RIPE has a procedure in place on how LIR can >do micro-assignments (they call it Provider Independent Address Space): >http://www.ripe.net/training/lir/material/slides/page103.htm >http://www.ripe.net/training/lir/material/slides/page106.htm >By that procedure LIR can request PI space on behelf of the end-user and >then RIPE assigns that space to LIR and LIR to the end-user. Actually, the space would be assigned directly to the end user by the RIPE NCC. The LIR just makes the request on behalf of the end user. I hope this clarifies things for you. Kind regards, -- leo vegoda RIPE NCC Registration Services From jmcburnett at msmgmt.com Sat Mar 1 00:03:49 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Sat, 1 Mar 2003 00:03:49 -0500 Subject: [ppml] RIR shopping -- AND MORE Message-ID: <390E55B947E7C848898AEBB9E5077060750AD0@msmdcfs01.msmgmt.com> Folks, I hate to say it, but in today's business world if I were to do the ROI research on the cost of an IP space with a US ISP and put that against APIC ARIN and RIPE with the cost of meeting the other RIR requirement, and it was cheaper with less hassle than ARIN I would say bye bye ARIN.. SO I guess we, as ARIN members, need to pull out heads out of the sand and stop imitating an ostrich and get this right. If we can't stop nitpicking the policies and push forward, we may see other RIRs get the customers while ARIN falls behind... Then after saying this I have a flash back from an email someone else sent earlier.. They were discussing the fact that only a few of us even discuss these topics on this list and the real work happens at conference.. Well if that is the case- then let's just disband this list. I know ARIN has quite a few members.. how many receive this list? what is the %? I look at my ARIN folder and it shows less than 30 that comment on a regular basis.. With this last statement in mind, is it even worth our time to send 50 emails a day with only 6 people involved? anyway just my 10 cents worth, inflation you know... Jim Jim McBurnett Director of Information Technology Mid-South Management Company, Inc. > -----Original Message----- > From: Bill Woodcock [mailto:woody at pch.net] > Sent: Friday, February 28, 2003 11:27 PM > To: McBurnett, Jim > Cc: Ron da Silva; ppml at arin.net > Subject: Re: [ppml] RIR shopping??? > > > > If I disagree with the MicroAllocation policy as it > exists with ARIN and I want > > a CLASS C from APNIC or RIR, All I have to do is ask > APNIC or RIR? > > Even if I am in North America? > > Sure, if you're an APNIC or RIPE member, or qualify under one of the > policies which applies to non-members. You might want to get > an in-region > P.O. box or use a local office, but that's what people do, yes. > > > If that is the case, then why are we so picky over > some of the parts of 2002-7? > > That's what I've been asking. > > -Bill > > > From ahp at hilander.com Sat Mar 1 08:11:51 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Sat, 01 Mar 2003 06:11:51 -0700 Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: <390E55B947E7C848898AEBB9E5077060750AD0@msmdcfs01.msmgmt.com> References: <390E55B947E7C848898AEBB9E5077060750AD0@msmdcfs01.msmgmt.com> Message-ID: <1775736048.1046499111@macleod.hilander.com> --On Saturday, March 1, 2003 0:03 -0500 "McBurnett, Jim" wrote: > > If we can't stop nitpicking the policies and push forward, > we may see other RIRs get the customers while ARIN falls behind... We aren't in competition with the other RIRs. We also do not have to do anything just because the other RIRs do it. As I've said before, people will lie and cheat no matter what we do with our policies. We need to do what we think is best for the part of the world that ARIN serves. Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From william at elan.net Sat Mar 1 11:35:10 2003 From: william at elan.net (william at elan.net) Date: Sat, 1 Mar 2003 08:35:10 -0800 (PST) Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: <1775736048.1046499111@macleod.hilander.com> Message-ID: I think this is wrong to allow "RIR Shopping" at all, there is a reason why we have RIRs for particular major world region and it should stay this way, we should not be allowing companies to buy IP at one RIR and use it in completed different world order. Not only that but some applications on being able to tell where client is is coming from sometimes regions. I'm not really sure (yet) what policies (if any) RIRs should impliment to stop RIR shopping but I view it as really negative thing. And util now I did not know that RIR shopping was even allowed, I consult companies in different parts of the world and some companies are connecting to the networks present in both US and other regions, well when getting ips in other regions, ips were from block given from other RIR to that network and in US from ARIN to the network, this is for all networks I dealt with and I saw it as clear sign that networks obtain separate ip blocks when they expand to Europe and to Asia. That is the way its supposed to be I think, maybe only the actual core (routers) may use ips from the same RIRs if that is important for the network in the way its setup. On Sat, 1 Mar 2003, Alec H. Peterson wrote: > --On Saturday, March 1, 2003 0:03 -0500 "McBurnett, Jim" > wrote: > > > > > If we can't stop nitpicking the policies and push forward, > > we may see other RIRs get the customers while ARIN falls behind... > > We aren't in competition with the other RIRs. > > We also do not have to do anything just because the other RIRs do it. > > As I've said before, people will lie and cheat no matter what we do with > our policies. We need to do what we think is best for the part of the > world that ARIN serves. > > Alec > > -- > Alec H. Peterson -- ahp at hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com > From John.Sweeting at teleglobe.com Sat Mar 1 21:19:04 2003 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Sat, 1 Mar 2003 21:19:04 -0500 Subject: [ppml] RIR shopping -- AND MORE Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BEE1@usresms03.teleglobe.com> Why should a company with a global internet have to deal with more than one RIR? Do you realize the additional expense and drain on resources of dealing with 4 or more registries? I (personally speaking) do not think that there is any reason to pursue this line of reasoning, leave well enough alone. -----Original Message----- From: william at elan.net To: ppml at arin.net Sent: 3/1/03 11:35 AM Subject: RE: [ppml] RIR shopping -- AND MORE I think this is wrong to allow "RIR Shopping" at all, there is a reason why we have RIRs for particular major world region and it should stay this way, we should not be allowing companies to buy IP at one RIR and use it in completed different world order. Not only that but some applications on being able to tell where client is is coming from sometimes regions. I'm not really sure (yet) what policies (if any) RIRs should impliment to stop RIR shopping but I view it as really negative thing. And util now I did not know that RIR shopping was even allowed, I consult companies in different parts of the world and some companies are connecting to the networks present in both US and other regions, well when getting ips in other regions, ips were from block given from other RIR to that network and in US from ARIN to the network, this is for all networks I dealt with and I saw it as clear sign that networks obtain separate ip blocks when they expand to Europe and to Asia. That is the way its supposed to be I think, maybe only the actual core (routers) may use ips from the same RIRs if that is important for the network in the way its setup. On Sat, 1 Mar 2003, Alec H. Peterson wrote: > --On Saturday, March 1, 2003 0:03 -0500 "McBurnett, Jim" > wrote: > > > > > If we can't stop nitpicking the policies and push forward, > > we may see other RIRs get the customers while ARIN falls behind... > > We aren't in competition with the other RIRs. > > We also do not have to do anything just because the other RIRs do it. > > As I've said before, people will lie and cheat no matter what we do with > our policies. We need to do what we think is best for the part of the > world that ARIN serves. > > Alec > > -- > Alec H. Peterson -- ahp at hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com > From jlewis at lewis.org Sat Mar 1 21:37:36 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Sat, 1 Mar 2003 21:37:36 -0500 (EST) Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: <170E5E7779BCD3118C2A0008C7F40C1906E9BEE1@usresms03.teleglobe.com> Message-ID: On Sat, 1 Mar 2003, Sweeting, John wrote: > Why should a company with a global internet have to deal with more than one > RIR? Do you realize the additional expense and drain on resources of dealing > with 4 or more registries? I (personally speaking) do not think that there > is any reason to pursue this line of reasoning, leave well enough alone. That's different and the exception to the rule. Like (I'd guess) the majority of ARIN customers/members, Atlantic.Net is based in the US and at least at the moment does business only in the US. Should we be able to go RIR shopping and "buy space" from whichever RIR has the best prices and IP allocation policies (from our point of view obviously)? I think that's the question being asked. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From william at elan.net Sun Mar 2 11:34:44 2003 From: william at elan.net (william at elan.net) Date: Sun, 2 Mar 2003 08:34:44 -0800 (PST) Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: <170E5E7779BCD3118C2A0008C7F40C1906E9BEE1@usresms03.teleglobe.com> Message-ID: If you have money to pay for undersea fiber and to support what are probably several POPs in seversl countries, I don't think expense in ips is going be that significant in comparison to that. But to be more exact, if company has unified multi-region network, I think its ok for it to use ip block from only one RIR for its own infrastructure, but if the same company assigns or allocates ip blocks to customers in other regions, those ip blocks (for customer networks which are specific to only one region) should come from ip blocks issues by RIR in that region. If that is not done as described above and since there is general trend to globalize in service provider area (almost all large so-called tier-1s and many smaller networks operate in several regions and account for sometimes up to 50% of internet transit to those regions), we end up with large portions of internet blocks in other countries and regions using ip blocks from different RIR that you inevitably end up with situations where ip blocks are no longer viewed as specific to any RIR and people actually do begin to see RIRs as kind of paralled organizations in competition to each other. I think this is completely opposite to vision of to devide ip assignment and allocations on regional basis and created RIRs, its not for nothing that every RIR has list of countries it supports! I can also list several other reasons to keep regional ip blocks separate and not mix it all up, just don't have time for long email right now. P.S. And to my knowledge Teleglobe does have ip address blocks from ARIN and APNIC and assigns ips to customers in Asia from APNIC blocks and not from ARIN blocks just like I described above. So do other networks of global reach that I'v dealt with - such as Level3, Savvis, Worldcom, etc. On Sat, 1 Mar 2003, Sweeting, John wrote: > Why should a company with a global internet have to deal with more than one > RIR? Do you realize the additional expense and drain on resources of dealing > with 4 or more registries? I (personally speaking) do not think that there > is any reason to pursue this line of reasoning, leave well enough alone. > > > -----Original Message----- > From: william at elan.net > To: ppml at arin.net > Sent: 3/1/03 11:35 AM > Subject: RE: [ppml] RIR shopping -- AND MORE > > I think this is wrong to allow "RIR Shopping" at all, there is a reason > why we have RIRs for particular major world region and it should stay > this > way, we should not be allowing companies to buy IP at one RIR and use it > > in completed different world order. Not only that but some applications > on being able to tell where client is is coming from sometimes regions. > I'm not really sure (yet) what policies (if any) RIRs should impliment > to > stop RIR shopping but I view it as really negative thing. > > And util now I did not know that RIR shopping was even allowed, I > consult > companies in different parts of the world and some companies are > connecting to the networks present in both US and other regions, well > when getting ips in other regions, ips were from block given from other > RIR to that network and in US from ARIN to the network, this is for all > networks I dealt with and I saw it as clear sign that networks obtain > separate ip blocks when they expand to Europe and to Asia. That is the > way its supposed to be I think, maybe only the actual core (routers) may > > use ips from the same RIRs if that is important for the network in the > way its setup. > > On Sat, 1 Mar 2003, Alec H. Peterson wrote: > > > --On Saturday, March 1, 2003 0:03 -0500 "McBurnett, Jim" > > wrote: > > > > > > > > If we can't stop nitpicking the policies and push forward, > > > we may see other RIRs get the customers while ARIN falls behind... > > > > We aren't in competition with the other RIRs. > > > > We also do not have to do anything just because the other RIRs do it. > > > > As I've said before, people will lie and cheat no matter what we do > with > > our policies. We need to do what we think is best for the part of the > > > world that ARIN serves. > > > > Alec > > > > -- > > Alec H. Peterson -- ahp at hilander.com > > Chief Technology Officer > > Catbird Networks, http://www.catbird.com From jcurran at istaff.org Sun Mar 2 14:28:16 2003 From: jcurran at istaff.org (John Curran) Date: Sun, 2 Mar 2003 14:28:16 -0500 Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: <1775736048.1046499111@macleod.hilander.com> References: <390E55B947E7C848898AEBB9E5077060750AD0@msmdcfs01.msmgmt.com> <1775736048.1046499111@macleod.hilander.com> Message-ID: At 6:11 AM -0700 3/1/03, Alec H. Peterson wrote: >... >We aren't in competition with the other RIRs. > >We also do not have to do anything just because the other RIRs do it. > >As I've said before, people will lie and cheat no matter what we do with our policies. We need to do what we think is best for the part of the world that ARIN serves. I couldn't have said it better... we need to focus on what policies make sense for the region that is served by ARIN. The policy requirements of each region are understandably different, as the history of Internet deployment in each region is different. If we get into a situation where overall responsible stewardship of the address space is endangered due to chronic "RIR shopping", then that will be an issue raised with the other RIR's and the ASO AC. Personally, I've only heard a few anecdotal reports, so if people feel otherwise, let's bring it up for discussion in Memphis. /John From randy at psg.com Sun Mar 2 14:36:49 2003 From: randy at psg.com (Randy Bush) Date: Sun, 2 Mar 2003 11:36:49 -0800 Subject: [ppml] RIR shopping -- AND MORE References: <390E55B947E7C848898AEBB9E5077060750AD0@msmdcfs01.msmgmt.com> <1775736048.1046499111@macleod.hilander.com> Message-ID: it might be healthy if arin concentrated a bit less on the obsession of defending against liars and thought a bit more about the fact that, at least in my routing tables, this is the *global* internet. randy From jcurran at istaff.org Sun Mar 2 15:32:12 2003 From: jcurran at istaff.org (John Curran) Date: Sun, 2 Mar 2003 15:32:12 -0500 Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: References: <390E55B947E7C848898AEBB9E5077060750AD0@msmdcfs01.msmgmt.com> <1775736048.1046499111@macleod.hilander.com> Message-ID: At 11:36 AM -0800 3/2/03, Randy Bush wrote: >it might be healthy if arin concentrated a bit less on the obsession >of defending against liars and thought a bit more about the fact that, >at least in my routing tables, this is the *global* internet. Randy, I can't tell whether: 1) You think that "RIR shopping" is a concern in the global Internet, and ARIN should get more involved here; or 2) ARIN is dwelling too much on folks possibly gaming the system and this is a non-issue... Can you clarify? /John From randy at psg.com Sun Mar 2 15:36:59 2003 From: randy at psg.com (Randy Bush) Date: Sun, 2 Mar 2003 12:36:59 -0800 Subject: [ppml] RIR shopping -- AND MORE References: <390E55B947E7C848898AEBB9E5077060750AD0@msmdcfs01.msmgmt.com> <1775736048.1046499111@macleod.hilander.com> Message-ID: >> it might be healthy if arin concentrated a bit less on the obsession >> of defending against liars and thought a bit more about the fact that, >> at least in my routing tables, this is the *global* internet. > I can't tell whether: 1) You think that "RIR shopping" is a concern > in the global Internet, and ARIN should get more involved here; > or 2) ARIN is dwelling too much on folks possibly gaming the system > and this is a non-issue... Can you clarify? i think you (not sure about arin actually) pay too much attention to defending against all us nasty lying members. i think that address allocation policies affect the *global* routing tables, and inter-rir coordination on policy is very important. randy From jmcburnett at msmgmt.com Sun Mar 2 15:58:51 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Sun, 2 Mar 2003 15:58:51 -0500 Subject: [ppml] RIR shopping -- AND MORE Message-ID: <390E55B947E7C848898AEBB9E5077060750AD3@msmdcfs01.msmgmt.com> If yall don't mind: I would like to add: I think we are spending WAY too much time worring about the 10% gang. As a rule of thumb from a former profession we said that we always had 10% of miscreants, bad apples, birds and just down right undesireables. I think the I think with this said we should not allow our policy discussions to steer us in such a direction so that we spend 90% of OUR time aligning OUR policies to handle 10% of the members... To close: My whole point with RIR shopping is that we need to be aware of our policies in effect of the other RIR, and to put this on a forefront.. All of us in a budgetary "watch" responsible position, will watch for anything to cut $$.. And for the truth of the matter, I know of nothing that would prevent an American ISP from advertising an APNIC block... Soap box yielded... Jim > -----Original Message----- > From: John Curran [mailto:jcurran at istaff.org] > Sent: Sunday, March 02, 2003 3:32 PM > To: Randy Bush > Cc: ppml at arin.net > Subject: RE: [ppml] RIR shopping -- AND MORE > > > At 11:36 AM -0800 3/2/03, Randy Bush wrote: > >it might be healthy if arin concentrated a bit less on the obsession > >of defending against liars and thought a bit more about the > fact that, > >at least in my routing tables, this is the *global* internet. > > Randy, > > I can't tell whether: 1) You think that "RIR shopping" is a concern > in the global Internet, and ARIN should get more involved here; > or 2) ARIN is dwelling too much on folks possibly gaming the system > and this is a non-issue... Can you clarify? > > /John > > From John.Sweeting at teleglobe.com Sun Mar 2 19:27:15 2003 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Sun, 2 Mar 2003 19:27:15 -0500 Subject: [ppml] RIR shopping -- AND MORE Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BEE2@usresms03.teleglobe.com> Sorry but you are wrong about Teleglobe; we quit APNIC 5 months ago and do not use any more of their space. Also as I stated it was my personal views and not that of the company that I work for or as a member of the AC. Maybe in Memphis we (you and I) can sit down and have a real long discussion about the reality of life, business and the Internet but like you I do not have time for that long of an email. And by the way, your first remark is the very thinking that got most telecoms in financial trouble in the first place including Teleglobe. -----Original Message----- From: william at elan.net To: 'ppml at arin.net ' Sent: 3/2/03 11:34 AM Subject: RE: [ppml] RIR shopping -- AND MORE If you have money to pay for undersea fiber and to support what are probably several POPs in seversl countries, I don't think expense in ips is going be that significant in comparison to that. But to be more exact, if company has unified multi-region network, I think its ok for it to use ip block from only one RIR for its own infrastructure, but if the same company assigns or allocates ip blocks to customers in other regions, those ip blocks (for customer networks which are specific to only one region) should come from ip blocks issues by RIR in that region. If that is not done as described above and since there is general trend to globalize in service provider area (almost all large so-called tier-1s and many smaller networks operate in several regions and account for sometimes up to 50% of internet transit to those regions), we end up with large portions of internet blocks in other countries and regions using ip blocks from different RIR that you inevitably end up with situations where ip blocks are no longer viewed as specific to any RIR and people actually do begin to see RIRs as kind of paralled organizations in competition to each other. I think this is completely opposite to vision of to devide ip assignment and allocations on regional basis and created RIRs, its not for nothing that every RIR has list of countries it supports! I can also list several other reasons to keep regional ip blocks separate and not mix it all up, just don't have time for long email right now. P.S. And to my knowledge Teleglobe does have ip address blocks from ARIN and APNIC and assigns ips to customers in Asia from APNIC blocks and not from ARIN blocks just like I described above. So do other networks of global reach that I'v dealt with - such as Level3, Savvis, Worldcom, etc. On Sat, 1 Mar 2003, Sweeting, John wrote: > Why should a company with a global internet have to deal with more than one > RIR? Do you realize the additional expense and drain on resources of dealing > with 4 or more registries? I (personally speaking) do not think that there > is any reason to pursue this line of reasoning, leave well enough alone. > > > -----Original Message----- > From: william at elan.net > To: ppml at arin.net > Sent: 3/1/03 11:35 AM > Subject: RE: [ppml] RIR shopping -- AND MORE > > I think this is wrong to allow "RIR Shopping" at all, there is a reason > why we have RIRs for particular major world region and it should stay > this > way, we should not be allowing companies to buy IP at one RIR and use it > > in completed different world order. Not only that but some applications > on being able to tell where client is is coming from sometimes regions. > I'm not really sure (yet) what policies (if any) RIRs should impliment > to > stop RIR shopping but I view it as really negative thing. > > And util now I did not know that RIR shopping was even allowed, I > consult > companies in different parts of the world and some companies are > connecting to the networks present in both US and other regions, well > when getting ips in other regions, ips were from block given from other > RIR to that network and in US from ARIN to the network, this is for all > networks I dealt with and I saw it as clear sign that networks obtain > separate ip blocks when they expand to Europe and to Asia. That is the > way its supposed to be I think, maybe only the actual core (routers) may > > use ips from the same RIRs if that is important for the network in the > way its setup. > > On Sat, 1 Mar 2003, Alec H. Peterson wrote: > > > --On Saturday, March 1, 2003 0:03 -0500 "McBurnett, Jim" > > wrote: > > > > > > > > If we can't stop nitpicking the policies and push forward, > > > we may see other RIRs get the customers while ARIN falls behind... > > > > We aren't in competition with the other RIRs. > > > > We also do not have to do anything just because the other RIRs do it. > > > > As I've said before, people will lie and cheat no matter what we do > with > > our policies. We need to do what we think is best for the part of the > > > world that ARIN serves. > > > > Alec > > > > -- > > Alec H. Peterson -- ahp at hilander.com > > Chief Technology Officer > > Catbird Networks, http://www.catbird.com From Michael.Dillon at radianz.com Mon Mar 3 07:31:10 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 3 Mar 2003 12:31:10 +0000 Subject: [ppml] Leaders or followers (times 2) Message-ID: > Changing the wording just causes it to diverge from the other RIR's > policy, which defeats the entire purpose. Hmmm... so should ARIN only be following the lead of other RIRs or should ARIN try to set policy that is a good example for other RIRs to follow? > The fact that a few people continue to have objections which were raised > and dealt with to the satisfaction of the membership at the meeting > doesn't seem terribly pertinent to me. The ARIN policy process contains the following: The Advisory Council will consider the discussions and judge the level of consensus in the community in order to prepare a final proposal for consideration by the ARIN Board of Trustees. I take this to mean that the AC can write the proposal with any wording that they may choose, i.e. in "preparing" a final proposal, they don't have to just pass through wording from either the meetings or the list. --Michael Dillon From richardj at arin.net Mon Mar 3 08:42:46 2003 From: richardj at arin.net (Richard Jimmerson) Date: Mon, 3 Mar 2003 08:42:46 -0500 Subject: [ppml] Leaders or followers (times 2) In-Reply-To: Message-ID: <00df01c2e18a$c6ce4ae0$178888c0@Cobalt2> Hello Michael, > The ARIN policy process contains the following: > > The Advisory Council will consider the discussions and > judge the level of consensus in the community in order > to prepare a final proposal for consideration by the > ARIN Board of Trustees. > > I take this to mean that the AC can write the proposal with any > wording that they may choose, i.e. in "preparing" a final proposal, > they don't have to just pass through wording from either the meetings > or the list. It is possible the ARIN AC would judge the level of consensus that resulted from a policy proposal discussion and leave the original text as written by the author. It is also possible community discussion may yield cases where the ARIN AC would judge there is favorable consensus for a policy proposal with slight modifications to language. In either case, the paragraph that follows the one you have cited above requires that the final proposal be sent to the mailing list for a "Last-Call for Comments". The final proposal shall be posted on the ARIN web site on a publicly accessible page, and a "Last-Call for Comments" will be announced on ARIN members and public policy mailing lists for a discussion period of no less than ten (10) regular working days. This period can be extended if sufficient comments are made that warrant further discussion and consideration. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Michael.Dillon at radianz.com > Sent: Monday, March 03, 2003 7:31 AM > To: ppml at arin.net > Subject: [ppml] Leaders or followers (times 2) > > > > Changing the wording just causes it to diverge from the other RIR's > > policy, which defeats the entire purpose. > > Hmmm... so should ARIN only be following the lead of other > RIRs or should > ARIN try to set policy that is a good example for other RIRs > to follow? > > > The fact that a few people continue to have objections which were > > raised and dealt with to the satisfaction of the membership at the > > meeting doesn't seem terribly pertinent to me. > > The ARIN policy process contains the following: > > The Advisory Council will consider the discussions and > judge the level > > of consensus in the community in order to prepare a final > proposal for > > consideration by the ARIN Board of Trustees. > > I take this to mean that the AC can write the proposal with > any wording > that they may choose, i.e. in "preparing" a final proposal, > they don't > have to just pass through wording from either the meetings or > the list. > > --Michael Dillon > From billd at cait.wustl.edu Mon Mar 3 09:50:11 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Mon, 3 Mar 2003 08:50:11 -0600 Subject: [ppml] Leaders or followers (times 2) Message-ID: And furthermore, the next paragraph of the policy states: "Comments during this period will be collected by ARIN staff and included with the proposal when it is presented to the Board of Trustees for their consideration." Those last call comments are not meant to, nor will they, delay forever the process. They are a prescribed aspect of the vetting of the policy proposal. The ARIN staff forwards the last comments along with the AC's final proposal wording and its recommendation (for or against) to the BoT. Then, the BoT makes its decision to either return it to the AC for more analysis/consideration (and perhaps then to the open community) or to accept the recommendation as was submitted. Its not a perfect system but it is ARIN's system for making "consensus" policy...not "100% agreement" policy. If the policy proposal process takes too long in the judgement of some, or it is not inclusive enough, or too inclusive, or whatever the agrument against the process be, that too is a policy which is available for modification. To all those dissatisfied with the process.... please, make a proposal if you think you objection scales to that extent... we will then give due, if not overdue consideration to your proposal. Bill Darte ARIN Advisory Council > -----Original Message----- > From: Richard Jimmerson [mailto:richardj at arin.net] > Sent: Monday, March 03, 2003 7:43 AM > To: ppml at arin.net > Subject: RE: [ppml] Leaders or followers (times 2) > > > Hello Michael, > > > The ARIN policy process contains the following: > > > > The Advisory Council will consider the discussions and > > judge the level of consensus in the community in order > > to prepare a final proposal for consideration by the > > ARIN Board of Trustees. > > > > I take this to mean that the AC can write the proposal with any > > wording that they may choose, i.e. in "preparing" a final proposal, > > they don't have to just pass through wording from either > the meetings > > or the list. > > It is possible the ARIN AC would judge the level of consensus > that resulted from a policy proposal discussion and leave the > original text as written by the author. It is also possible > community discussion may yield cases where the ARIN AC would > judge there is favorable consensus for a policy proposal with > slight modifications to language. > > In either case, the paragraph that follows the one you have cited > above requires that the final proposal be sent to the mailing list > for a "Last-Call for Comments". > > The final proposal shall be posted on the ARIN web site on > a publicly accessible page, and a "Last-Call for Comments" > will be announced on ARIN members and public policy mailing > lists for a discussion period of no less than ten (10) regular > working days. This period can be extended if sufficient > comments are made that warrant further discussion and > consideration. > > Best Regards, > > Richard Jimmerson > Director of Operations > American Registry for Internet Numbers (ARIN) > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of Michael.Dillon at radianz.com > > Sent: Monday, March 03, 2003 7:31 AM > > To: ppml at arin.net > > Subject: [ppml] Leaders or followers (times 2) > > > > > > > Changing the wording just causes it to diverge from the > other RIR's > > > policy, which defeats the entire purpose. > > > > Hmmm... so should ARIN only be following the lead of other > > RIRs or should > > ARIN try to set policy that is a good example for other RIRs > > to follow? > > > > > The fact that a few people continue to have objections which were > > > raised and dealt with to the satisfaction of the > membership at the > > > meeting doesn't seem terribly pertinent to me. > > > > The ARIN policy process contains the following: > > > > The Advisory Council will consider the discussions and > > judge the level > > > > of consensus in the community in order to prepare a final > > proposal for > > > > consideration by the ARIN Board of Trustees. > > > > I take this to mean that the AC can write the proposal with > > any wording > > that they may choose, i.e. in "preparing" a final proposal, > > they don't > > have to just pass through wording from either the meetings or > > the list. > > > > --Michael Dillon > > > From william at elan.net Mon Mar 3 09:57:46 2003 From: william at elan.net (william at elan.net) Date: Mon, 3 Mar 2003 06:57:46 -0800 (PST) Subject: [ppml] Draft for proposal for Whois AUP Message-ID: I have draft read for my last proposal - this is to change current bulk whois data only AUP to general Whois AUP. It requires for all whois queries (no matter what protocol - which is meant to include rwhois, ldap, protocol developed by crisp WG or any other protocal that ARIN may want to use) to include a link to whois aup and for those that need access to entire data (including through ftp but also including other means such as cdrom, etc) to have to sign bulk whois aup agreement (as is done already) but does allow that once signed same access can be used more then one time with new agreement having to be signed after one month. The draft is available at: http://www.elan.net/~william/arin_proposal_whois_aup.htm Please comment what needs to be included in AUP, what needs to be changed in the draft, etc. etc. I'll submit this as actual proposal no later then Friday and if no substantial comments are received then on Wednesday. Here is a text version of the current draft: --------------------------------------------------------------------- This proposal changes current Bulk Whois Acceptable Use Policy to become general Whois Acceptable Use policy that would apply to all whois queries. In particular: 1. A new acceptable use policy called "Whois Acceptable Use Policy" is to be published on ARIN website as follows: "The ARIN Whois Data is for Internet operations and technical research purposes pertaining to Internet Operations only. It may not be used for advertising, direct marketing, marketing research or similar purposes. Use of ARIN whois date for these activities is explicitly forbidden. ARIN requests to be notified of any such activities or suspicions thereof. ARIN reserves the right to restrict access to the whois database in its sole discretion to ensure operational stability. ARIN may may restrict or terminate your access to the whois database for failure to abide by these terms of use." 2. Access to whois data with individual queries (such as by using whois protocol) must in the output either include entire 'ARIN Whois Acceptable Use Policy' in the comments or provide a one-line statement that data is provided and can only be used according to 'ARIN Whois Acceptable Use Policy' with a link to where the policy is published on ARIN website. 3. High frequency individual query access and access to either entire whois database or large portion of it must be provided with authentication to persons and organizations authorized by ARIN. These organizations must sign 'Acceptable Use Policy for Bulk Copies of ARIN Whois Data' agreement which shall include 'Whois Acceptable Use Policy' and additional statement that "Redistributing bulk ARIN Whois Data is explicitly forbidden. It is permissible to publish data on an individual query or small number of queries at a time basis as long as reasonable precautions are taken to prevent automated querying by database harvesters" Organizations that need access to ARIN whois data on regular basis maybe required to resubmit the agreement on monthly basis at which time authentication settings may need to be changed. From jcurran at istaff.org Mon Mar 3 19:12:36 2003 From: jcurran at istaff.org (John Curran) Date: Mon, 3 Mar 2003 19:12:36 -0500 Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: References: <390E55B947E7C848898AEBB9E5077060750AD0@msmdcfs01.msmgmt.com> <1775736048.1046499111@macleod.hilander.com> Message-ID: At 12:36 PM -0800 3/2/03, Randy Bush wrote: > > I can't tell whether: 1) You think that "RIR shopping" is a concern >> in the global Internet, and ARIN should get more involved here; >> or 2) ARIN is dwelling too much on folks possibly gaming the system >> and this is a non-issue... Can you clarify? > >i think you (not sure about arin actually) pay too much attention to >defending against all us nasty lying members. ... > Interesting... I've never voiced an opinion about the matter either way, other than to suggest that if folks thought there was an issue here, they ought to bring it up for discussion at the Memphis meeting. /John From david at iprg.nokia.com Mon Mar 3 19:35:47 2003 From: david at iprg.nokia.com (David Kessens) Date: Mon, 3 Mar 2003 16:35:47 -0800 Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: ; from jcurran@istaff.org on Sun, Mar 02, 2003 at 02:28:16PM -0500 References: <390E55B947E7C848898AEBB9E5077060750AD0@msmdcfs01.msmgmt.com> <1775736048.1046499111@macleod.hilander.com> Message-ID: <20030303163547.O30603@iprg.nokia.com> John, On Sun, Mar 02, 2003 at 02:28:16PM -0500, John Curran wrote: > > The policy requirements of each region are understandably different, > as the history of Internet deployment in each region is different. I would be really nice if somebody could point me to these 'different policy requirements'. We are all trying to connect to the same global Internet and I just really don't see any reasons why policies should be different. What we really need is a global policy platform. The current policy process doesn't scale and the real cause of different policies is lack of communication between the different regions. The problems that we have with certain policies are not at all unique to our region - having attended many of the different regions policy meetings, I see the same problems (and simular but not the same solutions) coming up in the different regions. In addition, it seems that some people think that more policies for all kind of special cases are going to make the allocation process more fair and equitable for all members. On the contrary: more policies only benefit the few privileged people who have too much time on their hands and manage to keep up with the latest policy of the day. David K. --- From jcurran at istaff.org Mon Mar 3 19:58:09 2003 From: jcurran at istaff.org (John Curran) Date: Mon, 3 Mar 2003 19:58:09 -0500 Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: <20030303163547.O30603@iprg.nokia.com> References: <390E55B947E7C848898AEBB9E5077060750AD0@msmdcfs01.msmgmt.com> <1775736048.1046499111@macleod.hilander.com> <20030303163547.O30603@iprg.nokia.com> Message-ID: At 4:35 PM -0800 3/3/03, David Kessens wrote: > >What we really need is a global policy platform. The current policy >process doesn't scale and the real cause of different policies is lack >of communication between the different regions. The problems that we >have with certain policies are not at all unique to our region - >having attended many of the different regions policy meetings, I see >the same problems (and simular but not the same solutions) coming up >in the different regions. I think we all see this happening, but it's hard keep things in sync between the regions when the members take different stands on how to solve the same problems. It's very common for RIPE or APNIC's policies on a given situation to come up during discussion at the members meeting, but that doesn't always lead to our members taking the same approach. If folks feel strongly about tighter inter-RIR coordination of policy formation, that would be a great item to raise in Memphis. If there's a consensus for tighter coupling with the other RIRs, I'm certain the ARIN AC would heed it. /John From ebohlin at UU.NET Mon Mar 3 20:43:23 2003 From: ebohlin at UU.NET (Einar Bohlin) Date: Mon, 3 Mar 2003 20:43:23 -0500 (EST) Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: Message-ID: RIR shopping? Check this out: The initial IP allocation policies for ARIN and APNIC both get you a /20 (see below for more info), but the requirements and what you have to do after you get the net are different. The fastest way to get your own IPs: ARIN - Be multihomed and using a /21 APNIC - Be using a /22 (or need one today) Assuming the ISP wants to renumber into their own nets, what renumbering are they faced with? best case typical worst case ARIN /21 /20 or more APNIC zero renumbering needed /22 Note that ARIN stipulates that the ISP needs to use the entire /20 in 3 months, APNIC only wants a /21 to be used within a year. If I were a new shopper with the ability to do so, I'd have to consider APNIC. IMHO ARIN's more strict policy is outdated; it applied to a time when registering IPs was fashionable. APNIC's policy is more reasonable. It would be great to be able to allocate IPs based on up to a year's utilization. Recently a downstream got a /23, then a follow up /22 and now wants more; those routes add up. Where is the harm if we'd initially allocated a larger range, corresponding to a longer timeframe of use. Regards, Einar Bohlin, IP Analyst IP Team - Ashburn Virginia - WorldCom Phone: 703 886-7362 (VNET 806-7362) email: einar.bohlin at wcom.com ARIN http://www.arin.net/policy/ipv4.html#ispinitial [/20] The efficient utilization of an entire previously allocated /20 from their upstream ISP. [or] Multi-homed organizations that have efficiently utilized a /21 may be allocated a /20. In order to receive an initial allocation from ARIN, multi-homed organizations must: Provide detailed information showing that a /20 will be utilized within three months. APNIC http://www.apnic.net/docs/policy/add-manage-policy.html 9.3 Criteria for initial allocation [/20] To be eligible to obtain an initial allocation, an LIR must: have used a /22 from their upstream provider or demonstrate an immediate need for a /22; have complied with applicable policies in managing all address space previously allocated to it; demonstrate a detailed plan for use of a /21 within a year; and commit to renumber from previously deployed space into the new address space within one year. 9.4 Criteria for subsequent allocations After the initial allocation to an LIR, all subsequent allocations will depend on the following: the LIR's verified usage rate (which is the rate at which the LIR made assignments and sub-allocations from relevant past allocations); their documented plans for address space; and their degree of compliance with APNIC policies with respect to relevant past allocations. Based on these factors, APNIC and NIRs will allocate enough address space to meet the LIR's estimated needs for a period up to one year. If APNIC or the NIR make an allocation based on a period of less than one year, then they must inform the LIR of the length of the period and the reasons for selecting it. From anne at apnic.net Mon Mar 3 21:57:40 2003 From: anne at apnic.net (Anne Lord) Date: Tue, 04 Mar 2003 12:57:40 +1000 Subject: [hm-staff] Re: [ppml] RIR shopping -- AND MORE In-Reply-To: References: Message-ID: <5.1.0.14.0.20030304123728.020f2008@imap.apnic.net> Einer, Just one clarification and one comment: At 08:43 PM 3/3/2003 -0500, Einar Bohlin wrote: >RIR shopping? Check this out: > >The initial IP allocation policies for ARIN and APNIC both >get you a /20 (see below for more info), but the >requirements and what you have to do after you >get the net are different. > >The fastest way to get your own IPs: >ARIN - Be multihomed and using a /21 >APNIC - Be using a /22 (or need one today) > >Assuming the ISP wants to renumber into their >own nets, what renumbering are they faced with? > > best case typical worst case >ARIN /21 /20 or more >APNIC zero renumbering needed /22 This is not quite correct. There is a renumbering requirement. The policy states: "To be eligible to obtain an initial allocation, an LIR must: - have used a /22 from their upstream provider or demonstrate an immediate need for a /22; - have complied with applicable policies in managing all address space previously allocated to it; - demonstrate a detailed plan for use of a /21 within a year; and - commit to renumber from previously deployed space into the new address space within one year" details are in: http://www.apnic.net/docs/policy/add-manage-policy.html#9.3 The reason that the criteria are slightly less restrictive in the APNIC region is in recognition of regional development. ie. the Internet is much less mature as an industry in many economies in the region and their market base is just much slower in gathering momentum. This was deemed important by the community and the policies reflect this. Hope this helps, regards, Anne ______________________________________________________ Anne Lord, Manager, Policy Liaison Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 ______________________________________________________ >Note that ARIN stipulates that the ISP needs to use the >entire /20 in 3 months, APNIC only wants a /21 to be used >within a year. > >If I were a new shopper with the ability to do so, >I'd have to consider APNIC. > >IMHO ARIN's more strict policy is outdated; it >applied to a time when registering IPs was fashionable. >APNIC's policy is more reasonable. > >It would be great to be able to allocate IPs based >on up to a year's utilization. Recently a downstream got >a /23, then a follow up /22 and now wants more; those routes >add up. Where is the harm if we'd initially allocated a larger >range, corresponding to a longer timeframe of use. > >Regards, > >Einar Bohlin, IP Analyst >IP Team - Ashburn Virginia - WorldCom >Phone: 703 886-7362 (VNET 806-7362) >email: einar.bohlin at wcom.com > > > > >ARIN http://www.arin.net/policy/ipv4.html#ispinitial [/20] > >The efficient utilization of an entire previously allocated /20 from their >upstream ISP. > >[or] > >Multi-homed organizations that have efficiently utilized a /21 may be >allocated a /20. In order to receive an initial allocation from ARIN, >multi-homed organizations must: > >Provide detailed information showing that a /20 will be utilized within >three months. > > > >APNIC http://www.apnic.net/docs/policy/add-manage-policy.html > >9.3 Criteria for initial allocation [/20] >To be eligible to obtain an initial allocation, an LIR must: > >have used a /22 from their upstream provider or demonstrate an immediate >need for a /22; >have complied with applicable policies in managing all address space >previously allocated to it; >demonstrate a detailed plan for use of a /21 within a year; and >commit to renumber from previously deployed space into the new address >space within one year. > >9.4 Criteria for subsequent allocations >After the initial allocation to an LIR, all subsequent allocations will >depend on the following: > >the LIR's verified usage rate (which is the rate at which the LIR made >assignments and sub-allocations from relevant past allocations); >their documented plans for address space; and >their degree of compliance with APNIC policies with respect to relevant >past allocations. >Based on these factors, APNIC and NIRs will allocate enough address space >to meet the LIR's estimated needs for a period up to one year. If APNIC or >the NIR make an allocation based on a period of less than one year, then >they must inform the LIR of the length of the period and the reasons for >selecting it. > > > >_______________________________________________ >Hostmaster-staff mailing list >Hostmaster-staff at apnic.net >http://mailman.apnic.net/mailman/listinfo/hostmaster-staff From plzak at arin.net Tue Mar 4 08:54:49 2003 From: plzak at arin.net (Ray Plzak) Date: Tue, 4 Mar 2003 08:54:49 -0500 Subject: [ppml] Re: common policy across RIRs In-Reply-To: <20030228192221.GD29457@aol.net> Message-ID: <00cb01c2e255$9f6a5a40$168888c0@arin.net> There is a common list to discuss v6 policy. This was the first attempt by the RIRs to coordinate a cross region region (common) policy. There is also a common list to discuss the replacement of RFC 2050. Ray > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Ron da Silva > Sent: Friday, February 28, 2003 2:22 PM > To: ppml at arin.net > Subject: [ppml] Re: common policy across RIRs > > > > Woodcock - Interesting. If we are looking to craft policies that > are uniform across RIRs, would it be best to have a forum to discuss > them jointly? That is, a policy that is worded by consensus in APNIC > might not necessarily capture concerns by ARIN. I don't think we > have a joint RIR ppml list to discuss common policy...but it might > be useful. Hmmm...? > > -ron > From billd at cait.wustl.edu Tue Mar 4 09:37:07 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 4 Mar 2003 08:37:07 -0600 Subject: [hm-staff] Re: [ppml] RIR shopping -- AND MORE Message-ID: I believe that there are differences within regions which suggest a need to differeniate policy and procedure. Anne's email illustrates this nicely. 'Suggestion' of need is not necessarily need itself, however. One might undertake painstaking effort to substantiate those needs. But would it be worth it? Cost-benefit is always an important element of assessment, but not the only one. Some may feel slighted by a given policy, especially when another RIR seems to have a relaxed rule-set. Others, who are not impinged, feel no pain an the point it mute to them. Such are the vagaries of every market, indeed wherever rules are applied. RIRs could align their policies precisely.... (recall the term painstaking from above). This effort may be 'worth it' for certain policy or for certain groups, and not for others. Who is to decide? Well, clearly in my mind, it is the stakeholders of each region. While I would assert that 'most' feel that to the extent 'reasonable', not 'possible', policy should be aligned. Where stakeholders, through defined policy proposal procedures, form differing consensus.....well, that is what must be done. Should those elected entities within the RIR evaluate the effect of such differences? Sure. Should the play devil's advocate and point out the potential side effects of differences? Sure. Should they advocate and demand precise alignment? No. IMO. We can tweak many aspects of the current practice of policy making and alignment, but I suggest that the process in not broken. To my way of thinking, policies are aligned across regions, but they are not always the same. Bill Darte ARIN Advisory Council > -----Original Message----- > From: Anne Lord [mailto:anne at apnic.net] > Sent: Monday, March 03, 2003 8:58 PM > To: Einar Bohlin > Cc: ppml at arin.net > Subject: Re: [hm-staff] Re: [ppml] RIR shopping -- AND MORE > > > > Einer, > > Just one clarification and one comment: > > At 08:43 PM 3/3/2003 -0500, Einar Bohlin wrote: > >RIR shopping? Check this out: > > > >The initial IP allocation policies for ARIN and APNIC both > >get you a /20 (see below for more info), but the > >requirements and what you have to do after you > >get the net are different. > > > >The fastest way to get your own IPs: > >ARIN - Be multihomed and using a /21 > >APNIC - Be using a /22 (or need one today) > > > >Assuming the ISP wants to renumber into their > >own nets, what renumbering are they faced with? > > > > best case typical worst case > >ARIN /21 /20 or more > >APNIC zero renumbering needed /22 > > This is not quite correct. There is a renumbering > requirement. The policy > states: > > "To be eligible to obtain an initial allocation, an LIR must: > > - have used a /22 from their upstream provider or demonstrate > an immediate > need for a > /22; > - have complied with applicable policies in managing all > address space > previously > allocated to it; > - demonstrate a detailed plan for use of a /21 within a year; and > - commit to renumber from previously deployed space into the > new address > space within > one year" > > details are in: > http://www.apnic.net/docs/policy/add-manage-policy.html#9.3 > > The reason that the criteria are slightly less restrictive in > the APNIC > region is in recognition of regional development. ie. the > Internet is much > less mature as an industry in many economies in the region > and their market > base is just much slower in gathering momentum. This was > deemed important > by the community and the policies reflect this. > > Hope this helps, > > regards, > > Anne > ______________________________________________________ > Anne Lord, Manager, Policy Liaison > Asia Pacific Network Information Centre phone: +61 7 3858 3100 > http://www.apnic.net > fax: +61 7 3858 > 3199 > ______________________________________________________ > > > >Note that ARIN stipulates that the ISP needs to use the > >entire /20 in 3 months, APNIC only wants a /21 to be used > >within a year. > > > >If I were a new shopper with the ability to do so, > >I'd have to consider APNIC. > > > >IMHO ARIN's more strict policy is outdated; it > >applied to a time when registering IPs was fashionable. > >APNIC's policy is more reasonable. > > > >It would be great to be able to allocate IPs based > >on up to a year's utilization. Recently a downstream got > >a /23, then a follow up /22 and now wants more; those routes > >add up. Where is the harm if we'd initially allocated a larger > >range, corresponding to a longer timeframe of use. > > > >Regards, > > > >Einar Bohlin, IP Analyst > >IP Team - Ashburn Virginia - WorldCom > >Phone: 703 886-7362 (VNET 806-7362) > >email: einar.bohlin at wcom.com > > > > > > > > > >ARIN http://www.arin.net/policy/ipv4.html#ispinitial [/20] > > > >The efficient utilization of an entire previously allocated > /20 from their > >upstream ISP. > > > >[or] > > > >Multi-homed organizations that have efficiently utilized a > /21 may be > >allocated a /20. In order to receive an initial allocation > from ARIN, > >multi-homed organizations must: > > > >Provide detailed information showing that a /20 will be > utilized within > >three months. > > > > > > > >APNIC http://www.apnic.net/docs/policy/add-manage-policy.html > > > >9.3 Criteria for initial allocation [/20] > >To be eligible to obtain an initial allocation, an LIR must: > > > >have used a /22 from their upstream provider or demonstrate > an immediate > >need for a /22; > >have complied with applicable policies in managing all address space > >previously allocated to it; > >demonstrate a detailed plan for use of a /21 within a year; and > >commit to renumber from previously deployed space into the > new address > >space within one year. > > > >9.4 Criteria for subsequent allocations > >After the initial allocation to an LIR, all subsequent > allocations will > >depend on the following: > > > >the LIR's verified usage rate (which is the rate at which > the LIR made > >assignments and sub-allocations from relevant past allocations); > >their documented plans for address space; and > >their degree of compliance with APNIC policies with respect > to relevant > >past allocations. > >Based on these factors, APNIC and NIRs will allocate enough > address space > >to meet the LIR's estimated needs for a period up to one > year. If APNIC or > >the NIR make an allocation based on a period of less than > one year, then > >they must inform the LIR of the length of the period and the > reasons for > >selecting it. > > > > > > > >_______________________________________________ > >Hostmaster-staff mailing list > >Hostmaster-staff at apnic.net > >http://mailman.apnic.net/mailman/listinfo/hostmaster-staff > From memsvcs at arin.net Tue Mar 4 10:16:25 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 4 Mar 2003 10:16:25 -0500 (EST) Subject: [ppml] ARIN Policy Proposals Message-ID: <200303041516.KAA12987@ops.arin.net> To All Interested Parties: ARIN will hold its next Public Policy Meeting in Memphis, Tennessee on April 7-8, 2003. Meeting and registration details can be found at: http://www.arin.net/ARIN-XI/index.html ARIN's Internet Resource Policy Evaluation Process specifies that policy proposals must be posted to the ARIN mailing lists at least 30 days prior to an ARIN meeting where they will be discussed. ARIN's Internet Resource Policy Evaluation Process is described at: http://www.arin.net/policy/ipep.html ARIN staff has received from various sources policy proposals to be discussed at the upcoming Public Policy Meeting. Each of these proposals will be released as a separate e-mail to the public policy mailing list over the next several days. The progress of each policy proposal will be tracked and documented at the following location. http://www.arin.net/policy/proposal_archive.html The entire Internet community is invited and encouraged to participate in these policy discussions. Your active participation in these discussions will help to form policies that are beneficial to all. Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Tue Mar 4 11:36:19 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 4 Mar 2003 11:36:19 -0500 (EST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <200303041636.LAA26902@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-1: Human Point of Contact 1. Statement of proposed Policy: ARIN shall require each ORG or other body receiving resources from ARIN to register at least one POC which is a human being. ARIN shall amend the registration services agreement to include this requirement and shall further require that each ORG or other body agree to keep such contact up to date within 10 days of any change. Further, at least one human contact shall be viewable, at least as a reference, on each resource record visible in the public WHOIS information. 2. Argument for the proposal and general discussion of the issue. Issue: Automated systems do fail. In a case where the only contact information available to resolve such a failure is the system which has failed, the problem becomes one which cannot be resolved. The ISPs which are most likely to take advantage of the ability to hide behind role accounts are the ones most likely to have issues which require human intervention. Argument in favor: When an automated system fails, it becomes important to be able to reach a human being capable of intervening or contacting an intervenor. It is OK if the POC information (address, phone number, etc.) is a work number, or NOC, or even a switchboard, as long as it is a point of contact which leads to a real person with some ability to close the loop. Problems: I understand the issue of hate mail, threats, and the general difficulty of dealing with irate complainers. However, in any business, there are risks. Being the human lightning rod for these complaints at a large provider is not a lot of fun, but it is a job which must be done. Nobody likes to clean the restroom. 3. Proposed timetable for implementation: Once this proposal is ratified, ARIN should update it's registration services agreement to reflect the new policy within 30 days. Existing ORG and other bodies should receive notification of the change and the requirement to comply during that same period. They should be required to comply within 90 days of the date the notification is sent to the existing ADMIN-C. After that time has elapsed, ARIN staff should be expected to investigate and take further appropriate action on any complaint received about lack of human contact in any resource record. Appropriate action is left to the discretion of the ARIN AC, but should include ARIN staff contacting the hidden human contacts to try and find resolution. From memsvcs at arin.net Tue Mar 4 12:43:18 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 4 Mar 2003 12:43:18 -0500 (EST) Subject: [ppml] Policy Proposal 2003-2: Network Abuse Message-ID: <200303041743.MAA08404@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-2: Network Abuse Proposal for a world wide IP Range Policy for fighting Network Abuse. 1. All networks should have valid owner name or Company name with a valid mailing address and phone number. Phone number and address doesn't need to be visible through the WHOIS Database, but the Regional Internet Registries [APNIC, ARIN, LACNIC, and RIPE NCC] should have that information. 2. All networks should [regardless of geographical location] provide a valid e-mail contact for network [NOC@] and abuse [Abuse@] contact. Make it standard. 3. Regional Internet Registries [APNIC, ARIN, LACNIC, and RIPE NCC] should set up a simple auto system that would periodically send an auto e-mail every quarter to all networks using their services to check reliability of contact information to help regulate distribution of IP Ranges and network security. Those networks would be responsible to reply back to the system within a set time period to confirm network contact. It could all be done with little or no staffing once set-up. 4. If an IP Range / Network or Dial-Up is found to have invalid contact information, address, phone #, e-mail address etc, Regional Internet Registries [APNIC, ARIN, LACNIC, and RIPE NCC] should try to contact then via e-mail first [which is already being done]. At that time if contact is not established via e-mail and returned Failure/Undeliverable, they should be contacted via phone or mail with the understanding that if they do not reply with in say 30 days their IP range will be terminated and no connections will be allowed in or out of their network until they comply to the terms of service. 5. All large networks and Dial-ups should have some type of security system or team that regulate the network to some level or extent. Whether it's a few people, a team of people or some type of software. Most do but not all. 6. All Network administrators responsible for reviewing network abuse reports sent about their end users, accused of malicious activity should be judge on the level of severity by the reported service used, not the number of access attempts to a network or end user. I say this because I have time and time again got replies back from networks stating, it was only one or two access attempts, we will warn them, regardless of what service they used to try to access, and then that same individual is right back at you. A Sub7 Trojan Horse is not a friendly thing, nor is it a mistake etc. I believe that the service greatly shows their intent, if your venerable it only takes one try regardless of service. If you break down someone's door on their home, it only takes once, the police don't tell the home owner, well he only broke your door down once, we will warn him, let us know if he breaks your door down again. 7. There should be some type of database that all IPS's / Dial-Ups use and could reference to check new users real names to determine whether new subscribers have a past history of network abuse and hacking. This database could be managed and updated, all ISP would add new names of users that we're found to be guilty of or had had their account terminated due to network abuse complaints etc. The dial-up provider could at that time at least be alerted to a possible situation. This would also make it difficult for hackers to jump from ISP to ISP. From memsvcs at arin.net Tue Mar 4 13:07:00 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 4 Mar 2003 13:07:00 -0500 (EST) Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy Message-ID: <200303041807.NAA12423@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-3: Residential Customer Privacy Privacy of Residential Customer Name and Address Information In WHOIS Policy Proposal Statement: ARIN guidelines presently state that privacy of an individual's residential address information may be protected in WHOIS by indicating "Private Residence". This policy proposal is intended to provide additional information privacy through omission of an individual's name from WHOIS, replacing their name with "Private Individual". The proposed policy would amend and modify the existing ARIN guideline, forming a new, permanent policy. Rationale and Justification: With the continued growth and popularity of DSL service, increasing numbers of individuals and small home-based businesses are taking advantage of this technology. Many of these customers require /29 or larger assignments to support small networks. Knowing that WHOIS is a public database, the majority of these customers have a viable concern regarding the publication of their name and address information in WHOIS. It is the responsibility of an ISP to support the needs of their customers, and protect customer privacy whenever possible. This policy specifically addresses the privacy issue on behalf of home/residential customers. The omission of personal name and address information from WHOIS is analogous to residential telephone service. When residential phone service is activated, the individual's name, address and phone number are listed in the telephone directory. The individual may, however, request an "unlisted" number, and their information is omitted from the directory. This policy proposes the "listing" of the IP subnet in WHOIS, but individual name and address information would be "unlisted". It is the responsibility of the ISP to maintain complete and accurate information regarding the customer's name, address, etc. This information would be made available to ARIN (if requested) for audit of netblock utilization in support of future allocations. In these difficult times, home security and privacy is on everyone's mind. As internet users, service providers and overseers, it is our combined responsibility to do whatever is necessary to ensure the safety, and protect the privacy of the internet community at large. From william at elan.net Tue Mar 4 14:27:49 2003 From: william at elan.net (william at elan.net) Date: Tue, 4 Mar 2003 11:27:49 -0800 (PST) Subject: [ppml] Draft for proposal for Whois AUP (fwd) Message-ID: I'v received permission from author of this email to post it on the mailing list. He has important comments regarding the proposal which I think must be mentioned on ppml. I'll see forward my response in next next email. ---------- Forwarded message ---------- Date: Mon, 03 Mar 2003 11:49:48 -0700 From: spammaster To: william at elan.net Subject: Re: [ppml] Draft for proposal for Whois AUP Please see comments below... -- Jeff SpamX support support at spamx.com { NoList(); NoSPAM(); } > From: william at elan.net > Date: Mon, 3 Mar 2003 06:57:46 -0800 (PST) > To: ppml at arin.net > Cc: dbwg at arin.net > Subject: [ppml] Draft for proposal for Whois AUP > > I have draft read for my last proposal - this is to change current bulk > whois data only AUP to general Whois AUP. It requires for all whois > queries (no matter what protocol - which is meant to include rwhois, ldap, > protocol developed by crisp WG or any other protocal that ARIN may want to > use) to include a link to whois aup and for those that need access to > entire data (including through ftp but also including other means such as > cdrom, etc) to have to sign bulk whois aup agreement (as is done already) > but does allow that once signed same access can be used more then one > time with new agreement having to be signed after one month. > > The draft is available at: > http://www.elan.net/~william/arin_proposal_whois_aup.htm > > Please comment what needs to be included in AUP, what needs to be changed > in the draft, etc. etc. I'll submit this as actual proposal no later then > Friday and if no substantial comments are received then on Wednesday. > > Here is a text version of the current draft: > --------------------------------------------------------------------- > > This proposal changes current Bulk Whois Acceptable Use Policy to become > general Whois Acceptable Use policy that would apply to all whois queries. > > In particular: > > 1. A new acceptable use policy called "Whois Acceptable Use Policy" is to > be published on ARIN website as follows: > > "The ARIN Whois Data is for Internet operations and technical research > purposes pertaining to Internet Operations only. It may not be used for > advertising, direct marketing, marketing research or similar purposes. Use > of ARIN whois date for these activities is explicitly forbidden. ARIN > requests to be notified > of any such activities or suspicions thereof. To this I can agree in principle however, the "suspicions thereof" part makes me rather nervous lest we enter another "McCarthy" era... > ARIN reserves the right to restrict access to the whois database in its > sole discretion to ensure operational stability. ARIN may may restrict or > terminate your access to the whois database for failure to abide by these > terms of use." Same as above. > > 2. Access to whois data with individual queries (such as by using whois > protocol) must in the output either include entire 'ARIN Whois Acceptable > Use Policy' in the comments Please put them at THE BOTTOM of the output > or provide a one-line statement that data is > provided and can only be used according to 'ARIN Whois Acceptable Use > Policy' with a link to where the policy is published on ARIN website. This would be more acceptable as the ENTIRE policy is going to chew up bandwidth and whois access needs to be relatively instantaneous in some cases - particularly mine as described in further detail below. > > 3. High frequency individual query access This needs to be defined in excruciating detail - I run an ANTI-spam program that accesses the arin database regularly [every 5 minutes is the default check interval, it only accesses arin data when spam is detected, however, there may be more than one spam during any given check as this junk seems to come in waves, as it were]. What you are saying, if implemented, may disable what I am trying to do which is to eliminate spam. My program uses arin data to determine contact addresses to which to email spam reports and does it on the inbound side to speed the user interface - Your proposal, in this particular regard, stands to eliminate my ability [my program's ability] to properly determine reporting addresses. I already implemented a caching feature in the software over a year ago to reduce the number of accesses to the various whois servers of which arin is one however, as spammers jump from IP to IP on a regular basis, there is NO caching scheme that can possibly guarantee the software will not be required to access whois data at some sort of the "high frequency" to which you allude. Check http://www.spamx.com for additional details on the software. > and access to either entire > whois database or large portion of it must be provided with authentication > to persons and organizations authorized by ARIN. These organizations JUST organizations or PERSONS as well!? If each and every PERSON who wishes to perform a whois query needs to SIGN some form of agreement the paperwork load will be indescribable. We cannot keep the Internet running with such draconian measures and let us NOT make arin and the other RIRs like the IRS in the U.S., please and thank you very much. > must > sign 'Acceptable Use Policy for Bulk Copies of ARIN Whois Data' agreement > which shall include 'Whois Acceptable Use Policy' and additional statement > that > > "Redistributing bulk ARIN Whois Data is explicitly forbidden. It is > permissible to publish data on an individual query or small number of > queries at a time basis as long as reasonable precautions are taken to > prevent automated querying by database harvesters" This requires some strict definition with regard to "automated querying". It is, at best, extremely problematic. > > Organizations that need access to ARIN whois data on regular basis maybe > required to resubmit the agreement on monthly basis at which time > authentication settings may need to be changed. Once again, just WHO is going to handle the paperwork and WHO is going to $PAY$ for it!? > Bear in mind as well that spammers also harvest email addresses from mailto: links on websites, make up addresses from domain names, get them from a number of other sources, don't care whether they bounce or not and this proposal will do little to stop any of that, little to stop spammers harvesting addresses from whois data and, most likely, do a great deal to eliminate legitimate use of whois data by the rest of us who are trying to use the Internet in a proper manner. How about we devote our energies in the spamfighting arena to raising the awareness level of ISPs to their open relays and, particularly, OPEN PROXIES, which have become so popular to the spammers recently? My program relies on access to whois data in order to do exactly that! Thanks for listening. From william at elan.net Tue Mar 4 14:36:28 2003 From: william at elan.net (william at elan.net) Date: Tue, 4 Mar 2003 11:36:28 -0800 (PST) Subject: [ppml] Draft for proposal for Whois AUP (fwd) Message-ID: My response to previously posted email. ---------- Forwarded message ---------- Date: Mon, 3 Mar 2003 09:32:08 -0800 (PST) From: william at elan.net To: spammaster Subject: Re: [ppml] Draft for proposal for Whois AUP This email went to me directly. Do you want me to post your comments on the email list and answer them there as well? I did think of most of what you said when creating this proposal, and as a matter of fact I also run whoius redirection service that does very frequent queries to ARIN and that is also used fairly often for anti-spam reports, so I'v pretty good idea what its all about. Everything else is inline: > > "The ARIN Whois Data is for Internet operations and technical research > > purposes pertaining to Internet Operations only. It may not be used for > > advertising, direct marketing, marketing research or similar purposes. Use > > of ARIN whois date for these activities is explicitly forbidden. ARIN > > requests to be notified > > of any such activities or suspicions thereof. > To this I can agree in principle however, the "suspicions thereof" part > makes me rather nervous lest we enter another "McCarthy" era... The above text was taken word-word from current ARIN bulk whois AUP. I have some suspicions about what you call "McCarthy" era, but did not think its that important to change currently accepted AUP. I did think its strange that AUP only applied to those who got arin database as a whole and nobody else could even find what it is. > > ARIN reserves the right to restrict access to the whois database in its > > sole discretion to ensure operational stability. ARIN may may restrict or > > terminate your access to the whois database for failure to abide by these > > terms of use." > > Same as above. This text was taken from Verisign AUP for .com/.net/.org registry. It does not represent anything different than what ARIN already does - they limit access when you query it too much. > > 2. Access to whois data with individual queries (such as by using whois > > protocol) must in the output either include entire 'ARIN Whois Acceptable > > Use Policy' in the comments > > Please put them at THE BOTTOM of the output The above was meant to be used for protocols other then whois where it has special field for sending out AUP comments as part of the output. For general whois maximum that ARIN community would accept is one line with a link to policy. This was already slightly discussed on last ARIN meeting where I first mentioned need for whois AUP. > > or provide a one-line statement that data is > > provided and can only be used according to 'ARIN Whois Acceptable Use > > Policy' with a link to where the policy is published on ARIN website. > > This would be more acceptable as the ENTIRE policy is going to chew up > bandwidth and whois access needs to be relatively instantaneous in some > cases - particularly mine as described in further detail below. See above. > > > > 3. High frequency individual query access > > This needs to be defined in excruciating detail - I run an ANTI-spam program > that accesses the arin database regularly [every 5 minutes is the default > check interval, it only accesses arin data when spam is detected, however, > there may be more than one spam during any given check as this junk seems to > come in waves, as it were]. What you are saying, if implemented, may > disable what I am trying to do which is to eliminate spam. My program uses > arin data to determine contact addresses to which to email spam reports and > does it on the inbound side to speed the user interface - Your proposal, in > this particular regard, stands to eliminate my ability [my program's > ability] to properly determine reporting addresses. I already implemented a > caching feature in the software over a year ago to reduce the number of > accesses to the various whois servers of which arin is one however, as > spammers jump from IP to IP on a regular basis, there is NO caching scheme > that can possibly guarantee the software will not be required to access > whois data at some sort of the "high frequency" to which you allude. Check > http://www.spamx.com for additional details on the software. Perhaps I should explain. What I meant is that if ARIN feels that access to their database from particular source is too often and they begin to put limits (and this happened to my service actually - before change to new ARIN database, old whois was slower and I was hitting their limits) and you do not like those limits and want unrestricted access, then you need to go to arin and sign AUP and you get unrestricted access same as you would if you were to get their entire database from time-time. One of the ideas is to try to move some of the services like yours or mine into working with ARIN and actually getting their entire database as bulk form, this is either on ARIN and puts less strain on their whois servers. This has not been popupar before because ARIN required to sign their agreement each time you want to get bulk copy of the database, so doing so on regular basis was impossible. > > and access to either entire > > whois database or large portion of it must be provided with authentication > > to persons and organizations authorized by ARIN. These organizations > > JUST organizations or PERSONS as well!? Good point. I'll modify the draft. > If each and every PERSON who wishes > to perform a whois query needs to SIGN some form of agreement the paperwork > load will be indescribable. We cannot keep the Internet running with such > draconian measures and let us NOT make arin and the other RIRs like the IRS > in the U.S., please and thank you very much. Only people who do queries so often that they hit ARIN's limits would be effected. See comments above. Everybody else is still bound by the AUP but need not sign it. > > must > > sign 'Acceptable Use Policy for Bulk Copies of ARIN Whois Data' agreement > > which shall include 'Whois Acceptable Use Policy' and additional statement > > that > > > > "Redistributing bulk ARIN Whois Data is explicitly forbidden. It is > > permissible to publish data on an individual query or small number of > > queries at a time basis as long as reasonable precautions are taken to > > prevent automated querying by database harvesters" > > This requires some strict definition with regard to "automated querying". > It is, at best, extremely problematic. The above text was taken word-word from ARIN bulk-whois agreement, so again its generally acceptable to current community. This text may not be perfect but idea is that you would use the same precautions as ARIN to prevent grabbing of entire database without agreeing on AUP. I also considered adding there that access to ARIN database on other website must be in accordance with ARIN AUP. I.E. If you have your own AUP it must be similar to ARIN's one and specific that use of information for marketing, etc is not allowed. > > Organizations that need access to ARIN whois data on regular basis maybe > > required to resubmit the agreement on monthly basis at which time > > authentication settings may need to be changed. > Once again, just WHO is going to handle the paperwork and WHO is going to > $PAY$ for it!? You're going to handle paperwork if you need unrestricted access. On ARIN side, it maybe more work for them, but I don't think expense is too high and will not be noticable compared to everything else they do. > Bear in mind as well that spammers also harvest email addresses from mailto: > links on websites, make up addresses from domain names, get them from a > number of other sources, don't care whether they bounce or not and this > proposal will do little to stop any of that, little to stop spammers > harvesting addresses from whois data and, most likely, do a great deal to > eliminate legitimate use of whois data by the rest of us who are trying to > use the Internet in a proper manner. I'm aware of all that. I'm also aware that there are spammers, that don't care about laws and they are "marketing organizations" that seems to operate on legitamete basis and would not violate AUP if it exists. And to this day, quite a number of these organizations, particular those targetting ISPs and selling lists of ISPs to vendors would go to ARIN, get the data (by single queries, but they could get entire database in 2-3 days) and then sell the info to a vendor. I'v directly correlated some calls from vendors with data published at ARIN. > How about we devote our energies in the spamfighting arena to raising the > awareness level of ISPs to their open relays and, particularly, OPEN > PROXIES, which have become so popular to the spammers recently? My program > relies on access to whois data in order to do exactly that! The above are really not things ARIN should or can do anything about. I would however suggest you join asrg at ietf.org email list which was just setup to discuss ways to stop spam, but that list is meant to work on technical solutions and your comment is more of operational one and would need to be discussed possibly at nanog or other lists that ISPs participate in. > Thanks for listening. Sure. I'm on so may anti-spam mailing list that I'v heard this all before. But this proposal is for ARIN and I have to think about what would be acceptable to ARIN community. -- William Leibzon Elan Communications Inc. william at elan.net From mury at goldengate.net Tue Mar 4 17:25:04 2003 From: mury at goldengate.net (Mury) Date: Tue, 4 Mar 2003 16:25:04 -0600 (CST) Subject: [ppml] Draft for proposal for Whois AUP (fwd) In-Reply-To: Message-ID: Too bad it's impractical to allow exceptions for frequent use. I certainly understand what the author is trying to accomplish, yet I see yours and other valid uses. It seems to me that despite all the evil that can be done with the information it's only asking for trouble to limit access to the data. I also see it as a losing cause trying to enforce an AUP on a regular basis. It certainly doesn't hurt to have one, but except in some rare cases where there are serious repeat offenders it's not going to accomplish much. Mury On Tue, 4 Mar 2003 william at elan.net wrote: > I'v received permission from author of this email to post it on the mailing > list. He has important comments regarding the proposal which I think must > be mentioned on ppml. I'll see forward my response in next next email. > > ---------- Forwarded message ---------- > Date: Mon, 03 Mar 2003 11:49:48 -0700 > From: spammaster > To: william at elan.net > Subject: Re: [ppml] Draft for proposal for Whois AUP > > Please see comments below... > -- > Jeff > SpamX support > support at spamx.com > > { > NoList(); > NoSPAM(); > } > > > > From: william at elan.net > > Date: Mon, 3 Mar 2003 06:57:46 -0800 (PST) > > To: ppml at arin.net > > Cc: dbwg at arin.net > > Subject: [ppml] Draft for proposal for Whois AUP > > > > I have draft read for my last proposal - this is to change current bulk > > whois data only AUP to general Whois AUP. It requires for all whois > > queries (no matter what protocol - which is meant to include rwhois, ldap, > > protocol developed by crisp WG or any other protocal that ARIN may want to > > use) to include a link to whois aup and for those that need access to > > entire data (including through ftp but also including other means such as > > cdrom, etc) to have to sign bulk whois aup agreement (as is done already) > > but does allow that once signed same access can be used more then one > > time with new agreement having to be signed after one month. > > > > The draft is available at: > > http://www.elan.net/~william/arin_proposal_whois_aup.htm > > > > Please comment what needs to be included in AUP, what needs to be changed > > in the draft, etc. etc. I'll submit this as actual proposal no later then > > Friday and if no substantial comments are received then on Wednesday. > > > > Here is a text version of the current draft: > > --------------------------------------------------------------------- > > > > This proposal changes current Bulk Whois Acceptable Use Policy to become > > general Whois Acceptable Use policy that would apply to all whois queries. > > > > In particular: > > > > 1. A new acceptable use policy called "Whois Acceptable Use Policy" is to > > be published on ARIN website as follows: > > > > "The ARIN Whois Data is for Internet operations and technical research > > purposes pertaining to Internet Operations only. It may not be used for > > advertising, direct marketing, marketing research or similar purposes. Use > > of ARIN whois date for these activities is explicitly forbidden. ARIN > > requests to be notified > > of any such activities or suspicions thereof. > To this I can agree in principle however, the "suspicions thereof" part > makes me rather nervous lest we enter another "McCarthy" era... > > > ARIN reserves the right to restrict access to the whois database in its > > sole discretion to ensure operational stability. ARIN may may restrict or > > terminate your access to the whois database for failure to abide by these > > terms of use." > > Same as above. > > > > > 2. Access to whois data with individual queries (such as by using whois > > protocol) must in the output either include entire 'ARIN Whois Acceptable > > Use Policy' in the comments > > Please put them at THE BOTTOM of the output > > > or provide a one-line statement that data is > > provided and can only be used according to 'ARIN Whois Acceptable Use > > Policy' with a link to where the policy is published on ARIN website. > > This would be more acceptable as the ENTIRE policy is going to chew up > bandwidth and whois access needs to be relatively instantaneous in some > cases - particularly mine as described in further detail below. > > > > > 3. High frequency individual query access > > This needs to be defined in excruciating detail - I run an ANTI-spam program > that accesses the arin database regularly [every 5 minutes is the default > check interval, it only accesses arin data when spam is detected, however, > there may be more than one spam during any given check as this junk seems to > come in waves, as it were]. What you are saying, if implemented, may > disable what I am trying to do which is to eliminate spam. My program uses > arin data to determine contact addresses to which to email spam reports and > does it on the inbound side to speed the user interface - Your proposal, in > this particular regard, stands to eliminate my ability [my program's > ability] to properly determine reporting addresses. I already implemented a > caching feature in the software over a year ago to reduce the number of > accesses to the various whois servers of which arin is one however, as > spammers jump from IP to IP on a regular basis, there is NO caching scheme > that can possibly guarantee the software will not be required to access > whois data at some sort of the "high frequency" to which you allude. Check > http://www.spamx.com for additional details on the software. > > > and access to either entire > > whois database or large portion of it must be provided with authentication > > to persons and organizations authorized by ARIN. These organizations > > JUST organizations or PERSONS as well!? If each and every PERSON who wishes > to perform a whois query needs to SIGN some form of agreement the paperwork > load will be indescribable. We cannot keep the Internet running with such > draconian measures and let us NOT make arin and the other RIRs like the IRS > in the U.S., please and thank you very much. > > > must > > sign 'Acceptable Use Policy for Bulk Copies of ARIN Whois Data' agreement > > which shall include 'Whois Acceptable Use Policy' and additional statement > > that > > > > "Redistributing bulk ARIN Whois Data is explicitly forbidden. It is > > permissible to publish data on an individual query or small number of > > queries at a time basis as long as reasonable precautions are taken to > > prevent automated querying by database harvesters" > > This requires some strict definition with regard to "automated querying". > It is, at best, extremely problematic. > > > > > Organizations that need access to ARIN whois data on regular basis maybe > > required to resubmit the agreement on monthly basis at which time > > authentication settings may need to be changed. > Once again, just WHO is going to handle the paperwork and WHO is going to > $PAY$ for it!? > > > > Bear in mind as well that spammers also harvest email addresses from mailto: > links on websites, make up addresses from domain names, get them from a > number of other sources, don't care whether they bounce or not and this > proposal will do little to stop any of that, little to stop spammers > harvesting addresses from whois data and, most likely, do a great deal to > eliminate legitimate use of whois data by the rest of us who are trying to > use the Internet in a proper manner. > > How about we devote our energies in the spamfighting arena to raising the > awareness level of ISPs to their open relays and, particularly, OPEN > PROXIES, which have become so popular to the spammers recently? My program > relies on access to whois data in order to do exactly that! > > Thanks for listening. > > From jsw at five-elements.com Tue Mar 4 17:43:52 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: 04 Mar 2003 17:43:52 -0500 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <200303041636.LAA26902@ops.arin.net> References: <200303041636.LAA26902@ops.arin.net> Message-ID: <1046817833.937.38.camel@intrepid> Comments below, much text removed to reduce length. On Tue, 2003-03-04 at 11:36, Member Services wrote: > Policy Proposal 2003-1: Human Point of Contact > > 3. Proposed timetable for implementation: > > Once this proposal is ratified, ARIN should update it's registration > services agreement to reflect the new policy within 30 days. Existing It took months for the ARIN staff to get the new templates worked out and usable. I have a hard time believing that this would be implemented well in a 30 day timeframe, as sad as that seems from the outside. > ORG and other bodies should receive notification of the change and the > requirement to comply during that same period. They should be required > to comply within 90 days of the date the notification is sent to the > existing ADMIN-C. > > After that time has elapsed, ARIN staff should be expected to investigate > and take further appropriate action on any complaint received about lack > of human contact in any resource record. > > Appropriate action is left to the discretion of the ARIN AC, but should > include ARIN staff contacting the hidden human contacts to try and find > resolution. Again, from my outsider's perspective, it seems like the ARIN does not have the necessary resources to perform its current duties, even with a budget excess in the millions of US Dollars. I assume this is due to an aversion to adding headcount with the assumption that registration needs will decrease as the economy slows and new IT spending decreases; or that management is simply incapable of growing beyond the current volume and complexity of operations no matter what resources are available. If either of my above assumptions are true, I doubt that any more ARIN human resources would be available to conduct these investigations. For that reason this proposal seems a bit far-fetched. -- Jeff S Wheeler From william at elan.net Tue Mar 4 16:32:08 2003 From: william at elan.net (william at elan.net) Date: Tue, 4 Mar 2003 13:32:08 -0800 (PST) Subject: [ppml] Draft for proposal for Whois AUP (fwd) In-Reply-To: Message-ID: > > Too bad it's impractical to allow exceptions for frequent use. I > certainly understand what the author is trying to accomplish, yet I see > yours and other valid uses. That is exactly what proposal is trying to address. The idea is to establish procedures to allow those wo do very frequent queries to be able to do it without limits (by signing bulk whois aup and then ARIN would setup special whois server for that "frequent" use and that special server would only answer queries from specific ips - so ip would server as authentication, plus ARIN would get good statistical data on what these queries are about and from which of the services run by others) or better yet to move them to just getting entire database as bulk on regular basis. I'll move to the latter category if I could get bulk whois data at least twice a week and did not have to sign a bulk whois agreement each time. > It seems to me that despite all the evil that can be done with the > information it's only asking for trouble to limit access to the data. Proposal does not put additional limits (other then use its if its against AUP) it lists what ARIN does already - that if load on ARIN's whois servers is too high, ARIN mayu refuse the queries. > I also see it as a losing cause trying to enforce an AUP on a regular > basis. It certainly doesn't hurt to have one, but except in some rare > cases where there are serious repeat offenders it's not going to > accomplish much. First of all I think that even if 10% of marketing is stopped by AUP its already is not a lost cause. And I think there is quite a bit more then 10% that would be accoplished. Email addresses are not taken from ARIN's whois quite as often as from regular domain whois or other places (this is based on amount of spam I receive), on the other hand they are used by ISP directed marketing a lot more often (because its easy to establish which contacts are for ISPs - those that are allocated and may have its own assignments), most companies involved in ISP marketing are not hit-run companies and would not intentionally violate an AUP if it existed. In addition to that some competitor ISPs are also known to have used ARIN's data to market their services to customers of ISP that may have problem in particular area or just when then establish a POP in new area and are trying to get new customers there; these kind of marketing would be stopped by AUP almost completely as these companies are ISPs, often members of ARIN and are least likely to want to violate its AUP. > Mury > > On Tue, 4 Mar 2003 william at elan.net wrote: > > > I'v received permission from author of this email to post it on the mailing > > list. He has important comments regarding the proposal which I think must > > be mentioned on ppml. I'll see forward my response in next next email. > > > > ---------- Forwarded message ---------- > > Date: Mon, 03 Mar 2003 11:49:48 -0700 > > From: spammaster > > To: william at elan.net > > Subject: Re: [ppml] Draft for proposal for Whois AUP > > > > Please see comments below... > > -- > > Jeff > > SpamX support > > support at spamx.com > > > > { > > NoList(); > > NoSPAM(); > > } > > > > > > > From: william at elan.net > > > Date: Mon, 3 Mar 2003 06:57:46 -0800 (PST) > > > To: ppml at arin.net > > > Cc: dbwg at arin.net > > > Subject: [ppml] Draft for proposal for Whois AUP > > > > > > I have draft read for my last proposal - this is to change current bulk > > > whois data only AUP to general Whois AUP. It requires for all whois > > > queries (no matter what protocol - which is meant to include rwhois, ldap, > > > protocol developed by crisp WG or any other protocal that ARIN may want to > > > use) to include a link to whois aup and for those that need access to > > > entire data (including through ftp but also including other means such as > > > cdrom, etc) to have to sign bulk whois aup agreement (as is done already) > > > but does allow that once signed same access can be used more then one > > > time with new agreement having to be signed after one month. > > > > > > The draft is available at: > > > http://www.elan.net/~william/arin_proposal_whois_aup.htm > > > > > > Please comment what needs to be included in AUP, what needs to be changed > > > in the draft, etc. etc. I'll submit this as actual proposal no later then > > > Friday and if no substantial comments are received then on Wednesday. > > > > > > Here is a text version of the current draft: > > > --------------------------------------------------------------------- > > > > > > This proposal changes current Bulk Whois Acceptable Use Policy to become > > > general Whois Acceptable Use policy that would apply to all whois queries. > > > > > > In particular: > > > > > > 1. A new acceptable use policy called "Whois Acceptable Use Policy" is to > > > be published on ARIN website as follows: > > > > > > "The ARIN Whois Data is for Internet operations and technical research > > > purposes pertaining to Internet Operations only. It may not be used for > > > advertising, direct marketing, marketing research or similar purposes. Use > > > of ARIN whois date for these activities is explicitly forbidden. ARIN > > > requests to be notified > > > of any such activities or suspicions thereof. > > To this I can agree in principle however, the "suspicions thereof" part > > makes me rather nervous lest we enter another "McCarthy" era... > > > > > ARIN reserves the right to restrict access to the whois database in its > > > sole discretion to ensure operational stability. ARIN may may restrict or > > > terminate your access to the whois database for failure to abide by these > > > terms of use." > > > > Same as above. > > > > > > > > 2. Access to whois data with individual queries (such as by using whois > > > protocol) must in the output either include entire 'ARIN Whois Acceptable > > > Use Policy' in the comments > > > > Please put them at THE BOTTOM of the output > > > > > or provide a one-line statement that data is > > > provided and can only be used according to 'ARIN Whois Acceptable Use > > > Policy' with a link to where the policy is published on ARIN website. > > > > This would be more acceptable as the ENTIRE policy is going to chew up > > bandwidth and whois access needs to be relatively instantaneous in some > > cases - particularly mine as described in further detail below. > > > > > > > > 3. High frequency individual query access > > > > This needs to be defined in excruciating detail - I run an ANTI-spam program > > that accesses the arin database regularly [every 5 minutes is the default > > check interval, it only accesses arin data when spam is detected, however, > > there may be more than one spam during any given check as this junk seems to > > come in waves, as it were]. What you are saying, if implemented, may > > disable what I am trying to do which is to eliminate spam. My program uses > > arin data to determine contact addresses to which to email spam reports and > > does it on the inbound side to speed the user interface - Your proposal, in > > this particular regard, stands to eliminate my ability [my program's > > ability] to properly determine reporting addresses. I already implemented a > > caching feature in the software over a year ago to reduce the number of > > accesses to the various whois servers of which arin is one however, as > > spammers jump from IP to IP on a regular basis, there is NO caching scheme > > that can possibly guarantee the software will not be required to access > > whois data at some sort of the "high frequency" to which you allude. Check > > http://www.spamx.com for additional details on the software. > > > > > and access to either entire > > > whois database or large portion of it must be provided with authentication > > > to persons and organizations authorized by ARIN. These organizations > > > > JUST organizations or PERSONS as well!? If each and every PERSON who wishes > > to perform a whois query needs to SIGN some form of agreement the paperwork > > load will be indescribable. We cannot keep the Internet running with such > > draconian measures and let us NOT make arin and the other RIRs like the IRS > > in the U.S., please and thank you very much. > > > > > must > > > sign 'Acceptable Use Policy for Bulk Copies of ARIN Whois Data' agreement > > > which shall include 'Whois Acceptable Use Policy' and additional statement > > > that > > > > > > "Redistributing bulk ARIN Whois Data is explicitly forbidden. It is > > > permissible to publish data on an individual query or small number of > > > queries at a time basis as long as reasonable precautions are taken to > > > prevent automated querying by database harvesters" > > > > This requires some strict definition with regard to "automated querying". > > It is, at best, extremely problematic. > > > > > > > > Organizations that need access to ARIN whois data on regular basis maybe > > > required to resubmit the agreement on monthly basis at which time > > > authentication settings may need to be changed. > > Once again, just WHO is going to handle the paperwork and WHO is going to > > $PAY$ for it!? > > > > > > > Bear in mind as well that spammers also harvest email addresses from mailto: > > links on websites, make up addresses from domain names, get them from a > > number of other sources, don't care whether they bounce or not and this > > proposal will do little to stop any of that, little to stop spammers > > harvesting addresses from whois data and, most likely, do a great deal to > > eliminate legitimate use of whois data by the rest of us who are trying to > > use the Internet in a proper manner. > > > > How about we devote our energies in the spamfighting arena to raising the > > awareness level of ISPs to their open relays and, particularly, OPEN > > PROXIES, which have become so popular to the spammers recently? My program > > relies on access to whois data in order to do exactly that! > > > > Thanks for listening. > > > > From ebohlin at UU.NET Tue Mar 4 19:59:48 2003 From: ebohlin at UU.NET (Einar Bohlin) Date: Tue, 4 Mar 2003 19:59:48 -0500 (EST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <200303041636.LAA26902@ops.arin.net> Message-ID: Hi, This post is for 2003-1 and 2003-2. Long ago there were host records with POCs. Then there were net records with POCs. Then ASN records with POCs. There's been a lot of traffic on queries of whois records, and making changes to POC records, etc., most of this stemming from spam and abuse complaints. ARIN has a gazillion records. Most of those records are nearly meaningless, like all of our /29s to DSL customers, which are there in whois entirely for utilization information. The key to all of this is that at any given time pick any IP address on the Internet and it is part of one Autonomous System. It follows that the only data for the purpose of contact information that matters in all of ARIN's whois is ASN records. Any organization that has registered an ASN with ARIN has an ORG record. ORG records have mandatory ADMIN and TECH POCs. There's also an optional ABUSE POC and a NOC POC. In the future the ADMIN may not be displayed, but there will still be a TECH POC. That TECH POC should be a role account because anybody who is running their own AS should have more than one person responsible for operations. To sum this up, IMHO to meet all contact information requirements for all ARIN nets, all that ARIN really has to do is try to make sure that TECH POC info for ORGs that have ASNs is up to date with phone, email, and street address. Regards, Einar Bohlin, IP Analyst IP Team - Ashburn Virginia - WorldCom Phone: 703 886-7362 (VNET 806-7362) email: einar.bohlin at wcom.com On Tue, 4 Mar 2003, Member Services wrote: > ARIN welcomes feedback and discussion about the following policy > proposal in the weeks leading to the ARIN Public Policy Meeting > in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback > received on the mailing list about this policy proposal will be > included in the discussions that will take place at the upcoming > Public Policy Meeting. > > This policy proposal discussion will take place on the ARIN Public > Policy Mailing List (ppml at arin.net). Subscription information is > available at http://www.arin.net/mailing_lists/index.html > > Richard Jimmerson > Director of Operations > American Registry for Internet Numbers (ARIN) > > ### * ### > > Policy Proposal 2003-1: Human Point of Contact > > 1. Statement of proposed Policy: > > ARIN shall require each ORG or other body receiving resources from > ARIN to register at least one POC which is a human being. ARIN shall > amend the registration services agreement to include this requirement > and shall further require that each ORG or other body agree to keep > such contact up to date within 10 days of any change. Further, at > least one human contact shall be viewable, at least as a reference, > on each resource record visible in the public WHOIS information. > > 2. Argument for the proposal and general discussion of the issue. > > Issue: > Automated systems do fail. In a case where the only contact > information available to resolve such a failure is the system > which has failed, the problem becomes one which cannot be > resolved. > > The ISPs which are most likely to take advantage of the ability > to hide behind role accounts are the ones most likely to have > issues which require human intervention. > > Argument in favor: > When an automated system fails, it becomes important to be able > to reach a human being capable of intervening or contacting > an intervenor. It is OK if the POC information (address, > phone number, etc.) is a work number, or NOC, or even a > switchboard, as long as it is a point of contact which leads > to a real person with some ability to close the loop. > > Problems: > I understand the issue of hate mail, threats, and the general > difficulty of dealing with irate complainers. However, in > any business, there are risks. Being the human lightning rod > for these complaints at a large provider is not a lot of fun, > but it is a job which must be done. Nobody likes to clean > the restroom. > > 3. Proposed timetable for implementation: > > Once this proposal is ratified, ARIN should update it's registration > services agreement to reflect the new policy within 30 days. Existing > ORG and other bodies should receive notification of the change and the > requirement to comply during that same period. They should be required > to comply within 90 days of the date the notification is sent to the > existing ADMIN-C. > > After that time has elapsed, ARIN staff should be expected to investigate > and take further appropriate action on any complaint received about lack > of human contact in any resource record. > > Appropriate action is left to the discretion of the ARIN AC, but should > include ARIN staff contacting the hidden human contacts to try and find > resolution. > > From owen at delong.com Tue Mar 4 20:07:06 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 04 Mar 2003 17:07:06 -0800 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <1046817833.937.38.camel@intrepid> References: <200303041636.LAA26902@ops.arin.net> <1046817833.937.38.camel@intrepid> Message-ID: <2147483647.1046797626@owen-delongs-computer.local> While I can accept that the implementation of the policy might fall short of it's ideal, I think that can be addressed through ARIN operations better than through policy. As such, I would appreciate your feedback if you have ways to improve the policy or make it more effective. I would also appreciate any feedback on ways the policy could become easier for ARIN to implement while still accomplishing it's stated goals. I'm not saying that your feedback below is invalid. Quite the contrary, it is likely to be exactly correct. However, I'd appreciate your assistance in turning it into positive action that can be taken to improve the process. Thanks, Owen --On Tuesday, March 4, 2003 17:43 -0500 Jeff S Wheeler wrote: > Comments below, much text removed to reduce length. > > On Tue, 2003-03-04 at 11:36, Member Services wrote: >> Policy Proposal 2003-1: Human Point of Contact >> >> 3. Proposed timetable for implementation: >> >> Once this proposal is ratified, ARIN should update it's registration >> services agreement to reflect the new policy within 30 days. Existing > It took months for the ARIN staff to get the new templates worked out > and usable. I have a hard time believing that this would be implemented > well in a 30 day timeframe, as sad as that seems from the outside. >> ORG and other bodies should receive notification of the change and the >> requirement to comply during that same period. They should be required >> to comply within 90 days of the date the notification is sent to the >> existing ADMIN-C. >> >> After that time has elapsed, ARIN staff should be expected to >> investigate and take further appropriate action on any complaint >> received about lack of human contact in any resource record. >> >> Appropriate action is left to the discretion of the ARIN AC, but should >> include ARIN staff contacting the hidden human contacts to try and find >> resolution. > Again, from my outsider's perspective, it seems like the ARIN does not > have the necessary resources to perform its current duties, even with a > budget excess in the millions of US Dollars. I assume this is due to an > aversion to adding headcount with the assumption that registration needs > will decrease as the economy slows and new IT spending decreases; or > that management is simply incapable of growing beyond the current volume > and complexity of operations no matter what resources are available. > > If either of my above assumptions are true, I doubt that any more ARIN > human resources would be available to conduct these investigations. For > that reason this proposal seems a bit far-fetched. > > -- > Jeff S Wheeler > > From owen at delong.com Tue Mar 4 20:06:49 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 04 Mar 2003 17:06:49 -0800 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <1046817833.937.38.camel@intrepid> References: <200303041636.LAA26902@ops.arin.net> <1046817833.937.38.camel@intrepid> Message-ID: <2147483647.1046797609@owen-delongs-computer.local> While I can accept that the implementation of the policy might fall short of it's ideal, I think that can be addressed through ARIN operations better than through policy. As such, I would appreciate your feedback if you have ways to improve the policy or make it more effective. I would also appreciate any feedback on ways the policy could become easier for ARIN to implement while still accomplishing it's stated goals. I'm not saying that your feedback below is invalid. Quite the contrary, it is likely to be exactly correct. However, I'd appreciate your assistance in turning it into positive action that can be taken to improve the process. Thanks, Owen --On Tuesday, March 4, 2003 17:43 -0500 Jeff S Wheeler wrote: > Comments below, much text removed to reduce length. > > On Tue, 2003-03-04 at 11:36, Member Services wrote: >> Policy Proposal 2003-1: Human Point of Contact >> >> 3. Proposed timetable for implementation: >> >> Once this proposal is ratified, ARIN should update it's registration >> services agreement to reflect the new policy within 30 days. Existing > It took months for the ARIN staff to get the new templates worked out > and usable. I have a hard time believing that this would be implemented > well in a 30 day timeframe, as sad as that seems from the outside. >> ORG and other bodies should receive notification of the change and the >> requirement to comply during that same period. They should be required >> to comply within 90 days of the date the notification is sent to the >> existing ADMIN-C. >> >> After that time has elapsed, ARIN staff should be expected to >> investigate and take further appropriate action on any complaint >> received about lack of human contact in any resource record. >> >> Appropriate action is left to the discretion of the ARIN AC, but should >> include ARIN staff contacting the hidden human contacts to try and find >> resolution. > Again, from my outsider's perspective, it seems like the ARIN does not > have the necessary resources to perform its current duties, even with a > budget excess in the millions of US Dollars. I assume this is due to an > aversion to adding headcount with the assumption that registration needs > will decrease as the economy slows and new IT spending decreases; or > that management is simply incapable of growing beyond the current volume > and complexity of operations no matter what resources are available. > > If either of my above assumptions are true, I doubt that any more ARIN > human resources would be available to conduct these investigations. For > that reason this proposal seems a bit far-fetched. > > -- > Jeff S Wheeler > > From owen at delong.com Tue Mar 4 20:18:49 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 04 Mar 2003 17:18:49 -0800 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <2147483647.1046798329@owen-delongs-computer.local> --On Tuesday, March 4, 2003 19:59 -0500 Einar Bohlin wrote: > Hi, > > This post is for 2003-1 and 2003-2. > > Long ago there were host records with POCs. > Then there were net records with POCs. > Then ASN records with POCs. > > There's been a lot of traffic on queries of > whois records, and making changes to POC records, > etc., most of this stemming from spam and abuse > complaints. > > ARIN has a gazillion records. Most of those records are > nearly meaningless, like all of our /29s to DSL customers, > which are there in whois entirely for utilization information. > While I would agree that the POC data on some of those records may not be meaningful, I would not agree that it should not be meaningful. Indeed, you should be registering information for utilization that leads to a contact who is responsible for the conduct eminating from that block. > The key to all of this is that at any given time pick any IP > address on the Internet and it is part of one Autonomous System. > It follows that the only data for the purpose of contact information > that matters in all of ARIN's whois is ASN records. > This is simply not always true. There are a number of cases where an IP address may be part of more than one ASN. There are also cases where many IPs may be part of an ASN, but the contact data for that ASN has very little to do with the daily operations of that IP block. For example, there are many IP ranges that are "part" of WorldCOM or C&W ASNs which belong to very large organizations which are customers of those providers. I suspect that C&W's contact data would not be terribly useful for resolving problems starting from one of their customers. Sure, if it's a small enough customer, they might turn them off eventually, if they confirm the abuse, and the customer doesn't resolve the problem. However, being able to contact the responsible contact for the block directly is a very desirable thing. As such, I cannot agree that the ASN POC is the only relevant POC. That, I believe, is why the ASN POC and the IP block POC records are maintained independently. > Any organization that has registered an ASN with ARIN > has an ORG record. ORG records have mandatory > ADMIN and TECH POCs. There's also an optional > ABUSE POC and a NOC POC. In the future the ADMIN may > not be displayed, but there will still be a TECH POC. > OK. > That TECH POC should be a role account > because anybody who is running their own AS > should have more than one person responsible for > operations. > While that is true, there should still be at least one POC which leads to a human being not an automated response system. This isn't so much intended to be about ROLE vs. INDIVIDUAL as to be about the ability to reach someone who can resolve the issue or find someone who can resolve the issue when the automated response system fails to create acceptable results (for whatever reason). > To sum this up, IMHO to meet all contact information requirements > for all ARIN nets, all that ARIN really has to do is try to make > sure that TECH POC info for ORGs that have ASNs is up to date > with phone, email, and street address. > OK... Your opinion is noted. I respectfully disagree as detailed above. I agree that the above would go a long way towards improving things, but if the phone number only leads to a voice-jail, and the email only leads to an autoresponder, and the street address turns out to be a mail drop, then what? Even if the street address is legitimate, it's not terribly useful if you are more than 1,000 miles away trying to resolve an ongoing abuse situation. Owen From jrace at attglobal.net Tue Mar 4 21:13:24 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 05 Mar 2003 09:13:24 +0700 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <200303050213.h252DfJW067592@smtp1.arin.net> On 04 Mar 2003 17:43:52 -0500, Jeff S Wheeler wrote: >Again, from my outsider's perspective, it seems like the ARIN does not >have the necessary resources to perform its current duties, even with a >budget excess in the millions of US Dollars. I assume this is due to an >aversion to adding headcount with the assumption that registration needs >will decrease as the economy slows and new IT spending decreases; or >that management is simply incapable of growing beyond the current volume >and complexity of operations no matter what resources are available. > >If either of my above assumptions are true, I doubt that any more ARIN >human resources would be available to conduct these investigations. For Another datapoint: my complaints to APNIC about phony/outdated/incomplete data have always received polite replies and followups. So it is organizationally possible to do. (They do not however follow up as a matter of policy failure to operate RFC-specified role accounts, a major point of contention.) It may be possible to state that ad interim ARIN must follow up all human-generated complaints, until mechanisms/budgets are in place for a wholesale standalone effort. Anything less than this, saying e.g. 'there is no money' is just dreaming on in the "let the victims pay" business model. Jeffrey Race From ras at e-gerbil.net Tue Mar 4 21:34:05 2003 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 4 Mar 2003 21:34:05 -0500 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <200303041636.LAA26902@ops.arin.net> References: <200303041636.LAA26902@ops.arin.net> Message-ID: <20030305023405.GH8839@overlord.e-gerbil.net> On Tue, Mar 04, 2003 at 11:36:19AM -0500, Member Services wrote: > Problems: > I understand the issue of hate mail, threats, and the general > difficulty of dealing with irate complainers. However, in > any business, there are risks. Being the human lightning rod > for these complaints at a large provider is not a lot of fun, > but it is a job which must be done. Nobody likes to clean > the restroom. That sounds like a volunteer to me... You're available 24/7 right? Let's get real here, that policy isn't just bad it's absurd. Role accounts exist for a reason, and 99% of the time it is to improve communications. I'd suggest that trying to solve the 1% of the cases where people are hiding behind roles by breaking the other 99% is not the way to go. I'd also suggest that it is a fallacy to project what you consider "reasonable" in your business onto others. For example, who is the 1 person that you would recommend to handle all of UUNet's issues? -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jrace at attglobal.net Tue Mar 4 22:07:21 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 05 Mar 2003 10:07:21 +0700 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <200303050307.h2537cJW068282@smtp1.arin.net> On Tue, 4 Mar 2003 21:34:05 -0500, Richard A Steenbergen wrote: > For example, who is the 1 >person that you would recommend to handle all of UUNet's issues? The Virginia Commonwealth Attorney by filing a criminal indictment against the management. Jeffrey Race From jmcburnett at msmgmt.com Tue Mar 4 22:08:06 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Tue, 4 Mar 2003 22:08:06 -0500 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <390E55B947E7C848898AEBB9E5077060750AE3@msmdcfs01.msmgmt.com> > That sounds like a volunteer to me... You're available 24/7 right? > > Let's get real here, that policy isn't just bad it's absurd. > Role accounts I remember a job I once had where when someone called and asked for Roger Williams, someone became Roger. HMMM- Should role accounts become no longer valid, I believe that many will find their own Roger. Sad to say, but I do not want my name plastered any more around the web than it already is. > exist for a reason, and 99% of the time it is to improve > communications. > I'd suggest that trying to solve the 1% of the cases where people are > hiding behind roles by breaking the other 99% is not the way to go. > > I'd also suggest that it is a fallacy to project what you consider > "reasonable" in your business onto others. For example, who is the 1 > person that you would recommend to handle all of UUNet's issues? Ah 1 person.. Sounds like Roger is in the bldg again... I think we can say Roger is a Role account, but only in fact not in Policy. This policy will never work. If the one is a tech and he/she will never be able to finish the task, if the one is in management and he/she will just delegate, and hence the one is no longer a one.... Either way, what happens when the one goes on vacation, gets sick etc, change the address for 1 day? anyway I think this policy is a little bit too strict. and I can't foresee it working... nor it being enforceable.. Is ARIN going to ask for a drivers license # for every new contact? I think this policy needs to meet another old friend, Davy Jones.. Jim > > -- > Richard A Steenbergen > http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 > 5ECA F8B1 2CBC) > From memsvcs at arin.net Wed Mar 5 08:54:51 2003 From: memsvcs at arin.net (Member Services) Date: Wed, 5 Mar 2003 08:54:51 -0500 (EST) Subject: [ppml] Policy Proposal 2003-4: IPv6 Policy Changes Message-ID: <200303051354.IAA14561@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-4: IPv6 Policy Changes The current IPv6 policies are described in the IPv6 Address Allocation and Assignment Policy document. http://www.arin.net/policy/ipv6_policy.html It is proposed the IPv6 policy document be updated to include the following language and that the changed document be adopted as policy. 5.1.1 [under d) add: Other organizations are defined as any customer of the LIR. No distinction will be made in terms of number of IP addresses required, even if that number is one. 5.8 Allocation for Early Adopters 5.8.1 Waiver of criteria listed in 5.1.1 (d) To promote the allocation of IPv6 space the requirement to make 200 /48 assignments within two years shall be waived for anyone requesting IPv6 space before Dec 31, 2004 or until this policy is amended. In the event that this policy is amended the existing IPv6 space holders shall not be subject to new or waived criteria for a period of 10 years from their initial allocation date. 5.8.2 Waiver of fees a) To promote the allocation of IPv6 space all IPv6 related fees shall be waived until Dec 31, 2006 for anyone requesting and receiving space before Dec 31, 2004. In the even that this policy is amended the existing IPv6 space holders shall under no circumstances be subject to waived or new fees until Dec 31, 2006. b) For billing purposes fees will be due according to normal ARIN billing policies on Jan 1, 2007. All early adopters will have the same billing date regardless of the date they received their allocation. 5.8.3 Micro Allocations a) To promote the allocation and deployment of IPv6 all the criteria in 5.1.1 shall be waived to those requesting a /48 micro allocation before Dec 31, 2004, or until this policy is changed. If this policy is changed, current space holders shall not be subject to any new or waived criteria. b) All fees shall be waived under the same rules listed in 5.8.2. c) Those receiving micro allocations shall not be allowed to make further allocations or assignments out of their /48. It is intended for their internal use only. d) When possible those receiving micro allocations shall return their allocation and receive a new /48 from their upstream provider (a LIR). This is requested in a good faith manner until Jan 1, 2007 at which time all micro allocations granted under these waived criteria must be returned. From lee.howard at wcom.com Wed Mar 5 10:52:43 2003 From: lee.howard at wcom.com (Lee Howard) Date: Wed, 5 Mar 2003 10:52:43 -0500 (EST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <20030305023405.GH8839@overlord.e-gerbil.net> Message-ID: Speaking as the Admin contact for UUNET, I can say that in the seven months I have been listed publically I have received thousands of spam messages (about 100-150 per day), a dozen threats, and maybe a couple hundred (about 10/week) spam or hacker/abuse/security reports. I reply politely to every one of the latter, explaining what information should be provided to whom (abuse-mail at wcom.com). Most of the abuse reports I get are sent to me instead of the Abuse POC. I have not seen any requests that I could handle other than referring to the existing POCs. I also read NANOG, where I often see requests for help of some kind from someone at UUNET, and I almost always direct those requests to the right place, or have someone call the queriant. Many other UUNET people do the same. None of these requests has ever been sent to the Admin POC of UUNET directly. If the entire Internet user community could be trained to not spam the Human POC, and to exhaust other POCs before trying the Human POC, I'd support this proposal. The proposal is based on an assumption that personal email addresses are more likely to elicit responses than role accounts. Lee On Tue, 4 Mar 2003, Richard A Steenbergen wrote: > Date: Tue, 04 Mar 2003 21:34:05 -0500 > From: Richard A Steenbergen > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2003-1: Human Point of Contact > > On Tue, Mar 04, 2003 at 11:36:19AM -0500, Member Services wrote: > > Problems: > > I understand the issue of hate mail, threats, and the general > > difficulty of dealing with irate complainers. However, in > > any business, there are risks. Being the human lightning rod > > for these complaints at a large provider is not a lot of fun, > > but it is a job which must be done. Nobody likes to clean > > the restroom. > > That sounds like a volunteer to me... You're available 24/7 right? > > Let's get real here, that policy isn't just bad it's absurd. Role accounts > exist for a reason, and 99% of the time it is to improve communications. > I'd suggest that trying to solve the 1% of the cases where people are > hiding behind roles by breaking the other 99% is not the way to go. > > I'd also suggest that it is a fallacy to project what you consider > "reasonable" in your business onto others. For example, who is the 1 > person that you would recommend to handle all of UUNet's issues? > > From mury at goldengate.net Wed Mar 5 12:08:32 2003 From: mury at goldengate.net (Mury) Date: Wed, 5 Mar 2003 11:08:32 -0600 (CST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <390E55B947E7C848898AEBB9E5077060750AE3@msmdcfs01.msmgmt.com> Message-ID: Just for the record when voting on this one, I echo these sentiments. I sure can't put my name on everything and I don't see anyone in my company being willing or able to fullfill this request. As someone mentioned earlier, role accounts exist for a reason. We do an excellent job of responding to any coorespondence this way. To put this task on a single person, even for a company our size, is asking us to no longer respond to people. Isn't it much like asking an ARIN employee to give out their email and phone to handle all new requests for IPs? I would venture to guess that ARIN thinks they are doing a much better job with their automated process than routing everything through a single employee. Why would it be any different for us? If things really break down and you can't get a role account to respond, then there are conventional methods available to you. Mury On Tue, 4 Mar 2003, McBurnett, Jim wrote: > > That sounds like a volunteer to me... You're available 24/7 right? > > > > Let's get real here, that policy isn't just bad it's absurd. > > Role accounts > > I remember a job I once had where when someone called and asked for > Roger Williams, someone became Roger. HMMM- > Should role accounts become no longer valid, I believe that many will > find their own Roger. Sad to say, but I do not want my name plastered any > more around the web than it already is. > > > > exist for a reason, and 99% of the time it is to improve > > communications. > > I'd suggest that trying to solve the 1% of the cases where people are > > hiding behind roles by breaking the other 99% is not the way to go. > > > > I'd also suggest that it is a fallacy to project what you consider > > "reasonable" in your business onto others. For example, who is the 1 > > person that you would recommend to handle all of UUNet's issues? > > Ah 1 person.. Sounds like Roger is in the bldg again... > I think we can say Roger is a Role account, but only in fact not in > Policy. > > This policy will never work. If the one is a tech and he/she will never > be able to finish the task, if the one is in management and he/she will just > delegate, and hence the one is no longer a one.... > > Either way, what happens when the one goes on vacation, gets sick etc, > change the address for 1 day? > > anyway I think this policy is a little bit too strict. > and I can't foresee it working... nor it being enforceable.. > Is ARIN going to ask for a drivers license # for every > new contact? > I think this policy needs to meet another old friend, Davy Jones.. > > Jim > > > > > -- > > Richard A Steenbergen > > http://www.e-gerbil.net/ras > > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 > > 5ECA F8B1 2CBC) > > > From marla_azinger at eli.net Wed Mar 5 12:18:52 2003 From: marla_azinger at eli.net (Marla Azinger) Date: Wed, 5 Mar 2003 09:18:52 -0800 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: Message-ID: <001201c2e33b$4baf23e0$770d1bac@eli.czn.com> Here Here! My thoughts exactly! The proposal is written well...but not such a good idea. Marla ELI IP Analyst -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Mury Sent: Wednesday, March 05, 2003 9:09 AM To: McBurnett, Jim Cc: Richard A Steenbergen; ppml at arin.net Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact Just for the record when voting on this one, I echo these sentiments. I sure can't put my name on everything and I don't see anyone in my company being willing or able to fullfill this request. As someone mentioned earlier, role accounts exist for a reason. We do an excellent job of responding to any coorespondence this way. To put this task on a single person, even for a company our size, is asking us to no longer respond to people. Isn't it much like asking an ARIN employee to give out their email and phone to handle all new requests for IPs? I would venture to guess that ARIN thinks they are doing a much better job with their automated process than routing everything through a single employee. Why would it be any different for us? If things really break down and you can't get a role account to respond, then there are conventional methods available to you. Mury On Tue, 4 Mar 2003, McBurnett, Jim wrote: > > That sounds like a volunteer to me... You're available 24/7 right? > > > > Let's get real here, that policy isn't just bad it's absurd. > > Role accounts > > I remember a job I once had where when someone called and asked for > Roger Williams, someone became Roger. HMMM- > Should role accounts become no longer valid, I believe that many will > find their own Roger. Sad to say, but I do not want my name plastered any > more around the web than it already is. > > > > exist for a reason, and 99% of the time it is to improve > > communications. > > I'd suggest that trying to solve the 1% of the cases where people are > > hiding behind roles by breaking the other 99% is not the way to go. > > > > I'd also suggest that it is a fallacy to project what you consider > > "reasonable" in your business onto others. For example, who is the 1 > > person that you would recommend to handle all of UUNet's issues? > > Ah 1 person.. Sounds like Roger is in the bldg again... > I think we can say Roger is a Role account, but only in fact not in > Policy. > > This policy will never work. If the one is a tech and he/she will never > be able to finish the task, if the one is in management and he/she will just > delegate, and hence the one is no longer a one.... > > Either way, what happens when the one goes on vacation, gets sick etc, > change the address for 1 day? > > anyway I think this policy is a little bit too strict. > and I can't foresee it working... nor it being enforceable.. > Is ARIN going to ask for a drivers license # for every > new contact? > I think this policy needs to meet another old friend, Davy Jones.. > > Jim > > > > > -- > > Richard A Steenbergen > > http://www.e-gerbil.net/ras > > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 > > 5ECA F8B1 2CBC) > > > From lee.howard at wcom.com Wed Mar 5 12:27:20 2003 From: lee.howard at wcom.com (Lee Howard) Date: Wed, 5 Mar 2003 12:27:20 -0500 (EST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <200303050307.h2537cJW068282@smtp1.arin.net> Message-ID: Please, sir, that was rude. Unless you mean to suggest that legal authorities should be listed on WHOIS records, it was also not helpful. Do you have anything to add regarding policy proopsal 2003-1: Human POC? Lee On Wed, 5 Mar 2003, Dr. Jeffrey Race wrote: > Date: Wed, 05 Mar 2003 10:07:21 +0700 > From: Dr. Jeffrey Race > To: "ppml at arin.net" > Subject: Re: [ppml] Policy Proposal 2003-1: Human Point of Contact > > On Tue, 4 Mar 2003 21:34:05 -0500, Richard A Steenbergen wrote: > > > For example, who is the 1 > >person that you would recommend to handle all of UUNet's issues? > > The Virginia Commonwealth Attorney by filing a criminal indictment > against the management. > > Jeffrey Race > From John.Sweeting at teleglobe.com Wed Mar 5 12:38:50 2003 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Wed, 5 Mar 2003 12:38:50 -0500 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BEEC@usresms03.teleglobe.com> Just want to point out that these policy proposals are submitted to ARIN from the public that they serve; they are not proposed by ARIN or their staff so please refrain from comments that suggest otherwise. Thank you. > -----Original Message----- > From: Mury [mailto:mury at goldengate.net] > Sent: Wednesday, March 05, 2003 12:09 PM > To: McBurnett, Jim > Cc: Richard A Steenbergen; ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > > > > Just for the record when voting on this one, I echo these > sentiments. I > sure can't put my name on everything and I don't see anyone > in my company > being willing or able to fullfill this request. > > As someone mentioned earlier, role accounts exist for a > reason. We do an > excellent job of responding to any coorespondence this way. > To put this > task on a single person, even for a company our size, is > asking us to no > longer respond to people. > > Isn't it much like asking an ARIN employee to give out their email and > phone to handle all new requests for IPs? > > I would venture to guess that ARIN thinks they are doing a > much better job > with their automated process than routing everything through a single > employee. Why would it be any different for us? > > If things really break down and you can't get a role account > to respond, > then there are conventional methods available to you. > > Mury > > On Tue, 4 Mar 2003, McBurnett, Jim wrote: > > > > That sounds like a volunteer to me... You're available 24/7 right? > > > > > > Let's get real here, that policy isn't just bad it's absurd. > > > Role accounts > > > > I remember a job I once had where when someone called and asked for > > Roger Williams, someone became Roger. HMMM- > > Should role accounts become no longer valid, I believe that > many will > > find their own Roger. Sad to say, but I do not want my name > plastered any > > more around the web than it already is. > > > > > > > exist for a reason, and 99% of the time it is to improve > > > communications. > > > I'd suggest that trying to solve the 1% of the cases > where people are > > > hiding behind roles by breaking the other 99% is not the > way to go. > > > > > > I'd also suggest that it is a fallacy to project what you consider > > > "reasonable" in your business onto others. For example, > who is the 1 > > > person that you would recommend to handle all of UUNet's issues? > > > > Ah 1 person.. Sounds like Roger is in the bldg again... > > I think we can say Roger is a Role account, but only in fact not in > > Policy. > > > > This policy will never work. If the one is a tech and > he/she will never > > be able to finish the task, if the one is in management and > he/she will just > > delegate, and hence the one is no longer a one.... > > > > Either way, what happens when the one goes on vacation, > gets sick etc, > > change the address for 1 day? > > > > anyway I think this policy is a little bit too strict. > > and I can't foresee it working... nor it being enforceable.. > > Is ARIN going to ask for a drivers license # for every > > new contact? > > I think this policy needs to meet another old friend, Davy Jones.. > > > > Jim > > > > > > > > -- > > > Richard A Steenbergen > > > http://www.e-gerbil.net/ras > > > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 > > > 5ECA F8B1 2CBC) > > > > > > From mury at goldengate.net Wed Mar 5 12:46:38 2003 From: mury at goldengate.net (Mury) Date: Wed, 5 Mar 2003 11:46:38 -0600 (CST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <170E5E7779BCD3118C2A0008C7F40C1906E9BEEC@usresms03.teleglobe.com> Message-ID: Whoa, What the heck are you talking about? In no way, shape, or form did I state that ARIN made this proposal, or did anything wrong. I merely made an example everyone on this list is familiar with. We are talking about things to do with ARIN right? I used the "fact" that ARIN is better served by a "role" account senario to make a point that we are too. Where is the harm in that? BTW, are you also telling me that ARIN staff, AC, and BOD cannot submit policy proposals? Not that I think I suggested in any manner that they have, but it would surprise me if they were not allowed to. Mury On Wed, 5 Mar 2003, Sweeting, John wrote: > Just want to point out that these policy proposals are submitted to ARIN > from the public that they serve; they are not proposed by ARIN or their > staff so please refrain from comments that suggest otherwise. Thank you. > > > -----Original Message----- > > From: Mury [mailto:mury at goldengate.net] > > Sent: Wednesday, March 05, 2003 12:09 PM > > To: McBurnett, Jim > > Cc: Richard A Steenbergen; ppml at arin.net > > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > > > > > > > > Just for the record when voting on this one, I echo these > > sentiments. I > > sure can't put my name on everything and I don't see anyone > > in my company > > being willing or able to fullfill this request. > > > > As someone mentioned earlier, role accounts exist for a > > reason. We do an > > excellent job of responding to any coorespondence this way. > > To put this > > task on a single person, even for a company our size, is > > asking us to no > > longer respond to people. > > > > Isn't it much like asking an ARIN employee to give out their email and > > phone to handle all new requests for IPs? > > > > I would venture to guess that ARIN thinks they are doing a > > much better job > > with their automated process than routing everything through a single > > employee. Why would it be any different for us? > > > > If things really break down and you can't get a role account > > to respond, > > then there are conventional methods available to you. > > > > Mury > > > > On Tue, 4 Mar 2003, McBurnett, Jim wrote: > > > > > > That sounds like a volunteer to me... You're available 24/7 right? > > > > > > > > Let's get real here, that policy isn't just bad it's absurd. > > > > Role accounts > > > > > > I remember a job I once had where when someone called and asked for > > > Roger Williams, someone became Roger. HMMM- > > > Should role accounts become no longer valid, I believe that > > many will > > > find their own Roger. Sad to say, but I do not want my name > > plastered any > > > more around the web than it already is. > > > > > > > > > > exist for a reason, and 99% of the time it is to improve > > > > communications. > > > > I'd suggest that trying to solve the 1% of the cases > > where people are > > > > hiding behind roles by breaking the other 99% is not the > > way to go. > > > > > > > > I'd also suggest that it is a fallacy to project what you consider > > > > "reasonable" in your business onto others. For example, > > who is the 1 > > > > person that you would recommend to handle all of UUNet's issues? > > > > > > Ah 1 person.. Sounds like Roger is in the bldg again... > > > I think we can say Roger is a Role account, but only in fact not in > > > Policy. > > > > > > This policy will never work. If the one is a tech and > > he/she will never > > > be able to finish the task, if the one is in management and > > he/she will just > > > delegate, and hence the one is no longer a one.... > > > > > > Either way, what happens when the one goes on vacation, > > gets sick etc, > > > change the address for 1 day? > > > > > > anyway I think this policy is a little bit too strict. > > > and I can't foresee it working... nor it being enforceable.. > > > Is ARIN going to ask for a drivers license # for every > > > new contact? > > > I think this policy needs to meet another old friend, Davy Jones.. > > > > > > Jim > > > > > > > > > > > -- > > > > Richard A Steenbergen > > > > http://www.e-gerbil.net/ras > > > > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 > > > > 5ECA F8B1 2CBC) > > > > > > > > > > From william at elan.net Wed Mar 5 11:07:34 2003 From: william at elan.net (william at elan.net) Date: Wed, 5 Mar 2003 08:07:34 -0800 (PST) Subject: [ppml] Displaying Rwhois information as separate field in whois output (fwd) Message-ID: I had written draft on rwhois issues, though this would probably not become a proposal (partially because only small part of it listed as #6 really needs to be a policy and my understanding is that somebody else is already working on such a proposal, but if it is not brought it, I'll send this as proposal or if you think it needs to be a proposal anyway, please send me a note). The draft is located at http://www.elan.net/~william/arin_proposal_rwhois_contact.htm The above is just one of the options available for rwhois and other options are available and will hopefully be discussed on DBWG, Please see below on more particular details. If you want to discuss this issues, please subscribe to dbwg mailing list. ---------- Forwarded message ---------- Date: Wed, 5 Mar 2003 07:55:50 -0800 (PST) From: william at elan.net To: dbwg at arin.net Subject: Displaying Rwhois information as separate field in whois output As some of you know ARIN setup "rwhois design group" in January to find ways to improve ISP-maintained reassigments which is currently done through rwhois. About 10 persons participated in that and problems and possible solutions were discussed. While no agreement on futher actions was reached, it did provide some important feedback to ARIN on what they could do and yesterday I was asked to write down futher on idea I had and ARIN has reported that it would not be too difficult to do (can be done in 60-90 days). I do want to mention thogh that while there were disagreements on several issues, there was also clear agreement on one particular issue - this is to FIX RWHOIS ROOT SERVER. While its not the kind of issue that can be put in the proposal, I'm hoping that since ARIN staff has listened to what has been discussed, they understand that this is something that everybody thinks must be done to improve rwhois. Now my original idea was as follows: > 4. Convert current comments into special reassigment contact and make it > easy for automated software to determine where to get rwhois information > as well as provide clear text indicating that reassigment info is coming > out of database not maintained by ARIN There are several ways to do it with various degree of complexity. One would be to simply add a "reassignment" field into either NETWORK or ORG and make modifications to ARIN whois server so it is displaying it as separate note regarding reassignments. I believe if its done this way, we may need to make an exception and allow "TECH" contact to be responsible for maintaining this particular field (especially for ORG). There is also somewhat of a problem as I see it that there is no way to do special reassignment-only comments (but we could add additional "reassignment comment" field as well) and these I think are important in many cases for example to advertise about custom schema or to tell non-technical viewers of whois how to find reassignment contact through web interface (in reality > 50% of those accessing ARIN data have no idea what rwhois is!). Another way is to do it as actual contact, which may require a little more time for ARIN to do and in the beginning (on actual conversion) may end up with multiple reassignment contacts in place where should have been only one (for networks that have many ip blocks with rwhois server reference) but hopefully this would be fixed by the ISP itself and extra contacts removed. For this option I actually create a proposal which is located at: http://www.elan.net/~william/arin_proposal_rwhois_contact.htm Except for part#6, this is mostly database-related and thus non-policy issue and does not necessarily need to be in a proposal (and for #6 somebody else may already be working on a similar proposal). So if you are an ISP that maintains rwhois, please think about what you think would be best way to do it (as listed above) and post your comments to this list or otherwise be ready to have it discussed on Memphis meeting. Below follows my actual proposal from url above in text format, it is more complicated that what ARIN itself would like to do, but I personally think this is better. ------------------------------------------------------------------------- Reassignment (Rwhois) Whois Contact Proposal This proposal is trying to better address an issue with ISP-maintained reassignment information (rwhois servers). Currently information on rwhois is displayed as comments in the whois and there are no standards on how these comments are entered which makes it difficult to futher parse the information. In addition it is often important to know who to contact regarding technical issues with ISP-maintained rwhois server and such information is difficult to obtain. There also no procedure that would allow for rwhois maintainer to modify information on rwhois and it can only be done through ISP main administrative contact which is sometimes an issue for large ISP with many ip blocks. So to address the above it is proposed that: 1. ARIN establish new "reassignment" contact. This contact should include same fields as other ARIN whois contacts and should be the contact of the person or technical group at the ISP that is responsible for maintaining rwhois server is other similar reassignment server. 2. In addition to standard whois fields, new contact should include additional special reassignment field which should provide URN to the server that provides futher reassignment information. An example of this would be: rwhois://rwhois.someisp.net:4321 3. Whois should display a note when reassignment contact is present that makes it clear that reassignment information is maintained by the ISP and can be found through its listed rwhois server or similar service. 4. ISP may also use optional comments fields to provide additional information such as information on additional features of its reassignment server or pointer to schema used. It is recommended that comments at least include URL with link to website which can provide reassignment information so that it can be used by those who do not have direct access to rwhois or other appropriate reassignment client program. 5. ARIN should attempt to convert all current rwhois comments into new reassignment contact. In this effort ARIN should contact all ISPs that have listed rwhois or other reassignment server in comments and try to obtain information on who is the correct contact responsible for maintaining such server. If ARIN is unable to get the exact information from the ISP, ARIN may substitute information from current technical or administrative contact when creating new reassignment contact. 6. In the future when ARIN receives reports of reassignment server not answering to queries, ARIN may do its own tests for at least a month with at least 10 non-sequential queries and if there higher then 75% failure rate, ARIN should attempt to contact person or group as listed in the reassignment contact (first by email and then by phone) and if no response is received, ARIN should attempt to contact technical contact listed for the ip block to try to find resolution to the problem. If ARIN is unable to make proper contact with ISP or find resolution to a problem, ARIN may add a comment to reassignment contact indicating that listed reassignment server is "lame" similar to the way this is done for lame DNS servers. From John.Sweeting at teleglobe.com Wed Mar 5 13:39:51 2003 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Wed, 5 Mar 2003 13:39:51 -0500 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BEED@usresms03.teleglobe.com> Great, thank you for the clarification. > -----Original Message----- > From: Mury [mailto:mury at goldengate.net] > Sent: Wednesday, March 05, 2003 12:47 PM > To: Sweeting, John > Cc: McBurnett, Jim; Richard A Steenbergen; ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > > > > Whoa, > > What the heck are you talking about? In no way, shape, or form did I > state that ARIN made this proposal, or did anything wrong. > > I merely made an example everyone on this list is familiar > with. We are > talking about things to do with ARIN right? > > I used the "fact" that ARIN is better served by a "role" > account senario > to make a point that we are too. Where is the harm in that? > > BTW, are you also telling me that ARIN staff, AC, and BOD > cannot submit > policy proposals? Not that I think I suggested in any manner > that they > have, but it would surprise me if they were not allowed to. > > Mury > > > On Wed, 5 Mar 2003, Sweeting, John wrote: > > > Just want to point out that these policy proposals are > submitted to ARIN > > from the public that they serve; they are not proposed by > ARIN or their > > staff so please refrain from comments that suggest > otherwise. Thank you. > > > > > -----Original Message----- > > > From: Mury [mailto:mury at goldengate.net] > > > Sent: Wednesday, March 05, 2003 12:09 PM > > > To: McBurnett, Jim > > > Cc: Richard A Steenbergen; ppml at arin.net > > > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > > > > > > > > > > > > Just for the record when voting on this one, I echo these > > > sentiments. I > > > sure can't put my name on everything and I don't see anyone > > > in my company > > > being willing or able to fullfill this request. > > > > > > As someone mentioned earlier, role accounts exist for a > > > reason. We do an > > > excellent job of responding to any coorespondence this way. > > > To put this > > > task on a single person, even for a company our size, is > > > asking us to no > > > longer respond to people. > > > > > > Isn't it much like asking an ARIN employee to give out > their email and > > > phone to handle all new requests for IPs? > > > > > > I would venture to guess that ARIN thinks they are doing a > > > much better job > > > with their automated process than routing everything > through a single > > > employee. Why would it be any different for us? > > > > > > If things really break down and you can't get a role account > > > to respond, > > > then there are conventional methods available to you. > > > > > > Mury > > > > > > On Tue, 4 Mar 2003, McBurnett, Jim wrote: > > > > > > > > That sounds like a volunteer to me... You're > available 24/7 right? > > > > > > > > > > Let's get real here, that policy isn't just bad it's absurd. > > > > > Role accounts > > > > > > > > I remember a job I once had where when someone called > and asked for > > > > Roger Williams, someone became Roger. HMMM- > > > > Should role accounts become no longer valid, I believe that > > > many will > > > > find their own Roger. Sad to say, but I do not want my name > > > plastered any > > > > more around the web than it already is. > > > > > > > > > > > > > exist for a reason, and 99% of the time it is to improve > > > > > communications. > > > > > I'd suggest that trying to solve the 1% of the cases > > > where people are > > > > > hiding behind roles by breaking the other 99% is not the > > > way to go. > > > > > > > > > > I'd also suggest that it is a fallacy to project what > you consider > > > > > "reasonable" in your business onto others. For example, > > > who is the 1 > > > > > person that you would recommend to handle all of > UUNet's issues? > > > > > > > > Ah 1 person.. Sounds like Roger is in the bldg again... > > > > I think we can say Roger is a Role account, but only in > fact not in > > > > Policy. > > > > > > > > This policy will never work. If the one is a tech and > > > he/she will never > > > > be able to finish the task, if the one is in management and > > > he/she will just > > > > delegate, and hence the one is no longer a one.... > > > > > > > > Either way, what happens when the one goes on vacation, > > > gets sick etc, > > > > change the address for 1 day? > > > > > > > > anyway I think this policy is a little bit too strict. > > > > and I can't foresee it working... nor it being enforceable.. > > > > Is ARIN going to ask for a drivers license # for every > > > > new contact? > > > > I think this policy needs to meet another old friend, > Davy Jones.. > > > > > > > > Jim > > > > > > > > > > > > > > -- > > > > > Richard A Steenbergen > > > > > http://www.e-gerbil.net/ras > > > > > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 > > > > > 5ECA F8B1 2CBC) > > > > > > > > > > > > > > > From mury at goldengate.net Wed Mar 5 13:42:55 2003 From: mury at goldengate.net (Mury) Date: Wed, 5 Mar 2003 12:42:55 -0600 (CST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <170E5E7779BCD3118C2A0008C7F40C1906E9BEED@usresms03.teleglobe.com> Message-ID: Cool ;) On Wed, 5 Mar 2003, Sweeting, John wrote: > Great, thank you for the clarification. > > > -----Original Message----- > > From: Mury [mailto:mury at goldengate.net] > > Sent: Wednesday, March 05, 2003 12:47 PM > > To: Sweeting, John > > Cc: McBurnett, Jim; Richard A Steenbergen; ppml at arin.net > > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > > > > > > > > Whoa, > > > > What the heck are you talking about? In no way, shape, or form did I > > state that ARIN made this proposal, or did anything wrong. > > > > I merely made an example everyone on this list is familiar > > with. We are > > talking about things to do with ARIN right? > > > > I used the "fact" that ARIN is better served by a "role" > > account senario > > to make a point that we are too. Where is the harm in that? > > > > BTW, are you also telling me that ARIN staff, AC, and BOD > > cannot submit > > policy proposals? Not that I think I suggested in any manner > > that they > > have, but it would surprise me if they were not allowed to. > > > > Mury > > > > > > On Wed, 5 Mar 2003, Sweeting, John wrote: > > > > > Just want to point out that these policy proposals are > > submitted to ARIN > > > from the public that they serve; they are not proposed by > > ARIN or their > > > staff so please refrain from comments that suggest > > otherwise. Thank you. > > > > > > > -----Original Message----- > > > > From: Mury [mailto:mury at goldengate.net] > > > > Sent: Wednesday, March 05, 2003 12:09 PM > > > > To: McBurnett, Jim > > > > Cc: Richard A Steenbergen; ppml at arin.net > > > > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > > > > > > > > > > > > > > > > Just for the record when voting on this one, I echo these > > > > sentiments. I > > > > sure can't put my name on everything and I don't see anyone > > > > in my company > > > > being willing or able to fullfill this request. > > > > > > > > As someone mentioned earlier, role accounts exist for a > > > > reason. We do an > > > > excellent job of responding to any coorespondence this way. > > > > To put this > > > > task on a single person, even for a company our size, is > > > > asking us to no > > > > longer respond to people. > > > > > > > > Isn't it much like asking an ARIN employee to give out > > their email and > > > > phone to handle all new requests for IPs? > > > > > > > > I would venture to guess that ARIN thinks they are doing a > > > > much better job > > > > with their automated process than routing everything > > through a single > > > > employee. Why would it be any different for us? > > > > > > > > If things really break down and you can't get a role account > > > > to respond, > > > > then there are conventional methods available to you. > > > > > > > > Mury > > > > > > > > On Tue, 4 Mar 2003, McBurnett, Jim wrote: > > > > > > > > > > That sounds like a volunteer to me... You're > > available 24/7 right? > > > > > > > > > > > > Let's get real here, that policy isn't just bad it's absurd. > > > > > > Role accounts > > > > > > > > > > I remember a job I once had where when someone called > > and asked for > > > > > Roger Williams, someone became Roger. HMMM- > > > > > Should role accounts become no longer valid, I believe that > > > > many will > > > > > find their own Roger. Sad to say, but I do not want my name > > > > plastered any > > > > > more around the web than it already is. > > > > > > > > > > > > > > > > exist for a reason, and 99% of the time it is to improve > > > > > > communications. > > > > > > I'd suggest that trying to solve the 1% of the cases > > > > where people are > > > > > > hiding behind roles by breaking the other 99% is not the > > > > way to go. > > > > > > > > > > > > I'd also suggest that it is a fallacy to project what > > you consider > > > > > > "reasonable" in your business onto others. For example, > > > > who is the 1 > > > > > > person that you would recommend to handle all of > > UUNet's issues? > > > > > > > > > > Ah 1 person.. Sounds like Roger is in the bldg again... > > > > > I think we can say Roger is a Role account, but only in > > fact not in > > > > > Policy. > > > > > > > > > > This policy will never work. If the one is a tech and > > > > he/she will never > > > > > be able to finish the task, if the one is in management and > > > > he/she will just > > > > > delegate, and hence the one is no longer a one.... > > > > > > > > > > Either way, what happens when the one goes on vacation, > > > > gets sick etc, > > > > > change the address for 1 day? > > > > > > > > > > anyway I think this policy is a little bit too strict. > > > > > and I can't foresee it working... nor it being enforceable.. > > > > > Is ARIN going to ask for a drivers license # for every > > > > > new contact? > > > > > I think this policy needs to meet another old friend, > > Davy Jones.. > > > > > > > > > > Jim > > > > > > > > > > > > > > > > > -- > > > > > > Richard A Steenbergen > > > > > > http://www.e-gerbil.net/ras > > > > > > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 > > > > > > 5ECA F8B1 2CBC) > > > > > > > > > > > > > > > > > > > > > From crain at iana.org Wed Mar 5 17:53:31 2003 From: crain at iana.org (John L Crain) Date: Wed, 5 Mar 2003 14:53:31 -0800 Subject: [ppml] IPv4 Update of address status Message-ID: <11218785552.20030305145331@iana.org> Dear Colleagues, As you may be aware the Regional Internet Registries have been active with the "Early Registrations Transfer [ERX] Project". As part of the preliminary investigations of this project and verification of the data by the IANA some /8s previously listed as "Various Registries" have now been designated as unused and as such will be listed in the IANA registries as "IANA Reserved". This update will take effect at http://www.iana.org/assignments/ipv4-address-space as of 23:59 UTC, 31 March 2003. The affected /8s will be listed as follows: 173/8 Apr 03 IANA - Reserved 174/8 Apr 03 IANA - Reserved 175/8 Apr 03 IANA - Reserved 176/8 Apr 03 IANA - Reserved 177/8 Apr 03 IANA - Reserved 178/8 Apr 03 IANA - Reserved 179/8 Apr 03 IANA - Reserved 180/8 Apr 03 IANA - Reserved 181/8 Apr 03 IANA - Reserved 182/8 Apr 03 IANA - Reserved 183/8 Apr 03 IANA - Reserved 184/8 Apr 03 IANA - Reserved 185/8 Apr 03 IANA - Reserved 186/8 Apr 03 IANA - Reserved 187/8 Apr 03 IANA - Reserved 189/8 Apr 03 IANA - Reserved 190/8 Apr 03 IANA - Reserved Comments can be sent to iana at iana.org. -- Best regards, John L. Crain mailto:crain at iana.org From owen at delong.com Wed Mar 5 00:14:08 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 04 Mar 2003 21:14:08 -0800 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <20030305023405.GH8839@overlord.e-gerbil.net> References: <200303041636.LAA26902@ops.arin.net> <20030305023405.GH8839@overlord.e-gerbil.net> Message-ID: <2147483647.1046812448@dhcp156-148.corp.tellme.com> I don't think you're understanding what I'm saying. This isn't really about ROLE vs. individual accounts. It's about having at least one POC that leads to a human being, not an autoresponder, and not a voice-jail. It's about being able to get things resolved. I will probably draft an amendment to the proposal to clarify this issue prior to the meeting and send it to PPML that allows for ROLE accounts as long as the ROLE account provides a phone number that is ANSWERED (at least during business hours local time to the published address) by a human being, and an email address which is READ by humans, and not /dev/null'ed by a broken autoresponder. I admit that the originally I was thinking that a human name was required for this, and the policy was written in that form. However, based on feedback I have received, I still think it's important to be able to reach an actual human, but I understand the desire to spread that workload and use role accounts. I think there are ways to accomodate this while still preserving the intent of the policy. What I am primarily trying to fix here is the situations where ROLE accounts are used and NO human is reachable under any circumstances. As to how people run their business, in any business, there are community standards to which every business is expected to conform. If you want to operate a business (or otherwise participate in) the Internet, there are community standards to which it is reasonable to expect you to conform. In this case, I propose that it is a reasonable community standard to expect people who run networks to be reachable in an effort to resolve problems being created by their networks. Owen --On Tuesday, March 4, 2003 21:34 -0500 Richard A Steenbergen wrote: > On Tue, Mar 04, 2003 at 11:36:19AM -0500, Member Services wrote: >> Problems: >> I understand the issue of hate mail, threats, and the general >> difficulty of dealing with irate complainers. However, in >> any business, there are risks. Being the human lightning rod >> for these complaints at a large provider is not a lot of fun, >> but it is a job which must be done. Nobody likes to clean >> the restroom. > > That sounds like a volunteer to me... You're available 24/7 right? > > Let's get real here, that policy isn't just bad it's absurd. Role accounts > exist for a reason, and 99% of the time it is to improve communications. > I'd suggest that trying to solve the 1% of the cases where people are > hiding behind roles by breaking the other 99% is not the way to go. > > I'd also suggest that it is a fallacy to project what you consider > "reasonable" in your business onto others. For example, who is the 1 > person that you would recommend to handle all of UUNet's issues? > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jrace at attglobal.net Thu Mar 6 02:18:09 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Thu, 06 Mar 2003 14:18:09 +0700 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <200303060718.h267IVJW004285@smtp1.arin.net> On Wed, 5 Mar 2003 12:27:20 -0500 (EST), Lee Howard wrote: >Please, sir, that was rude. Lee I apologize for offending you; I really thought I was bringing a little humorous cheer to our loving group. Guessed wrong . . . . Please observe that I said "management", not the toilers in the abuse department or others. The sad fact is that UUNet is one of the most unethical firms I have ever had the misfortune to deal with. There were ethical people there, and such may still exist, but the ones I personally knew are all gone. The senior management knowingly bought into the environmental polluter business model, still run the firm that way, and also (you may have noticed) were crooked businessmen, causing terrific damage to the US economy and to many who depended on the firm for their retirements. Read the sad truth at Jeffrey Race From lee.howard at wcom.com Thu Mar 6 10:29:46 2003 From: lee.howard at wcom.com (Lee Howard) Date: Thu, 6 Mar 2003 10:29:46 -0500 (EST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: Message-ID: I sense a little hostility here, but I'm not sure whether you're angry that we changed the email address of our Abuse POC, or something I said. I am trying to keep the conversation on track, as PPML is clearly the wrong forum to air grievances against any entity, personal or corporate (except ARIN, and maybe the ASO or ICANN in address-related ways). Are you proposing a policy that the Abuse POC email address must be abuse at domainname? While I recognize the usefulness of certain well-known email address, such as postmaster, hostmaster, webmaster, and root, I don't know that "abuse" has been established and accepted by the community. Is this in a Best Current Practices RFC? If this is your proposal, how do you propose to assign domain names to network assignments? If 172.16.0.0/16 is allocated to Acme Holdings, who operates under the domain name acme.com, acme.net, acme.com.ca, acmeholdings.com, and explodinganvil.mil, which domain will you require to be on the Abuse POC? As for the specific example you give below: I believe you will find that abuse at uu.net does work. Abuse-mail at uu.net was created so users could separate Usenet abuse (abuse-news at uu.net), ongoing intrusion attempts (security at uu.net), and spam (abuse-mail at uu.net). Having separate aliases allows us to direct the reported incident to the right people faster. I agree that users would only know about these if they did a WHOIS query or looked at our support page. So abuse at uu.net should still work, it just gets manually sorted, and therefore takes longer. As I'm sure you know, WorldCom bought MFS (which owned UUNET) at the end of 1996, which may explain why there is a transition from @uu.net aliases to @wcom.com aliases. I've said before that I don't mind people using UUNET or WorldCom as examples, positive or negative, in discussions on this list or at public meetings. My only request is that the example be used to support or argue ARIN-related matters, and not as venues to air grievances. If you have a beef with me or the company I work for, email me privately so the rest of the people on this list who are trying to get some work done don't have to be involved. Lee Howard Lee.Howard at wcom.com (703) 886-5231 Sr. Manager Internet Installations, WorldCom IP Policy and Allocations On Thu, 6 Mar 2003, JLS wrote: > Date: Thu, 06 Mar 2003 00:00:19 -0700 > From: JLS > To: Lee Howard > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2003-1: Human Point of Contact > > Seems a little STRANGE to me that "abuse-mail at wcom.com" should be the > contact for uunet - I would be thinking that, in adhering to the de facto > standard, the logical, sensible and practical address would be abuse at uu.net > instead of any inventive permutations of such reasonable and imminently > practical simplicity - can we please do away with the run amok "creativity" > on the part of those who are supposed to know what they are doing to make > things reasonably simple for the common person who, perhaps, does not have > the time, inclination or even the wherewithal to go digging around in the > whois world to find out just WHO to report abuse to - > or we just trying to play "hard to get to", here!? > Perhaps if UUNET had a STANDARD abuse address YOU would have never been put > in such a position as you were. Remember, the Internet does not have the > geographical limitations that other, older, forms of communication like > snail mail or pony express used to present and there is no reason that an > address like abuse at uu.net cannot be properly set to forward instantaneously > to any other address on the net so let's just please keep it as simple as it > can be, ok? > > Jeff S. > > > From: Lee Howard > > Date: Wed, 5 Mar 2003 10:52:43 -0500 (EST) > > To: Richard A Steenbergen > > Cc: ppml at arin.net > > Subject: Re: [ppml] Policy Proposal 2003-1: Human Point of Contact > > > > Speaking as the Admin contact for UUNET, I can say that in the seven > > months I have been listed publically I have received thousands of spam > > messages (about 100-150 per day), a dozen threats, and maybe a couple > > hundred (about 10/week) spam or hacker/abuse/security reports. I reply > > politely to every one of the latter, explaining what information should > > be provided to whom (abuse-mail at wcom.com). Most of the abuse reports > > I get are sent to me instead of the Abuse POC. > > > > I have not seen any requests that I could handle other than referring > > to the existing POCs. > > > > I also read NANOG, where I often see requests for help of some kind > > from someone at UUNET, and I almost always direct those requests to the > > right place, or have someone call the queriant. Many other UUNET people > > do the same. None of these requests has ever been sent to the Admin POC > > of UUNET directly. > > > > If the entire Internet user community could be trained to not spam the > > Human POC, and to exhaust other POCs before trying the Human POC, I'd > > support this proposal. The proposal is based on an assumption that > > personal email addresses are more likely to elicit responses than role > > accounts. > > > > Lee > > > > > > > > On Tue, 4 Mar 2003, Richard A Steenbergen wrote: > > > >> Date: Tue, 04 Mar 2003 21:34:05 -0500 > >> From: Richard A Steenbergen > >> To: ppml at arin.net > >> Subject: Re: [ppml] Policy Proposal 2003-1: Human Point of Contact > >> > >> On Tue, Mar 04, 2003 at 11:36:19AM -0500, Member Services wrote: > >>> Problems: > >>> I understand the issue of hate mail, threats, and the general > >>> difficulty of dealing with irate complainers. However, in > >>> any business, there are risks. Being the human lightning rod > >>> for these complaints at a large provider is not a lot of fun, > >>> but it is a job which must be done. Nobody likes to clean > >>> the restroom. > >> > >> That sounds like a volunteer to me... You're available 24/7 right? > >> > >> Let's get real here, that policy isn't just bad it's absurd. Role accounts > >> exist for a reason, and 99% of the time it is to improve communications. > >> I'd suggest that trying to solve the 1% of the cases where people are > >> hiding behind roles by breaking the other 99% is not the way to go. > >> > >> I'd also suggest that it is a fallacy to project what you consider > >> "reasonable" in your business onto others. For example, who is the 1 > >> person that you would recommend to handle all of UUNet's issues? > >> > >> > > > From jmcburnett at msmgmt.com Thu Mar 6 10:46:33 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Thu, 6 Mar 2003 10:46:33 -0500 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <390E55B947E7C848898AEBB9E5077060750AEF@msmdcfs01.msmgmt.com> Email snipped to limit length.. >Are you proposing a policy that the Abuse POC email address must be >abuse at domainname? While I recognize the usefulness of certain >well-known >email address, such as postmaster, hostmaster, webmaster, and root, I >don't know that "abuse" has been established and accepted by the >community. Is this in a Best Current Practices RFC? Take a look at: http://www.ietf.org/rfc/rfc2142.txt?number=2142 Also take a look at: http://www.rfc-ignorant.com/ > >If this is your proposal, how do you propose to assign domain names to >network assignments? If 172.16.0.0/16 is allocated to Acme Holdings, >who operates under the domain name acme.com, acme.net, acme.com.ca, >acmeholdings.com, and explodinganvil.mil, which domain will you require >to be on the Abuse POC? According to the RFC. Each Organization... If I recieve spam from any of those domains how am I to know they are linked? As I see it and as I implement it, I have 28 domain names tied to different business entities owned by our parent company- therefore IT has 28 * 8 mailboxes-- acutally they are just aliases... We own newspapers, and the average person, and even the above average person may not make the connections..... >As for the specific example you give below: >I believe you will find that abuse at uu.net does work. Abuse-mail at uu.net >was created so users could separate Usenet abuse (abuse-news at uu.net), >ongoing intrusion attempts (security at uu.net), and spam >(abuse-mail at uu.net). >Having separate aliases allows us to direct the reported incident to >the right people faster. I agree that users would only know >@uu.net aliases to @wcom.com aliases. Alias are fine as long as they still reach an action point.... I filter and redistribute all my stuff easily, and we are immensely smaller than the WCom's and the rest of the ISP backbone world..... Later, Jim From jmcburnett at msmgmt.com Thu Mar 6 11:13:29 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Thu, 6 Mar 2003 11:13:29 -0500 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <390E55B947E7C848898AEBB9E507706041E42F@msmdcfs01.msmgmt.com> >>As for the specific example you give below: >>I believe you will find that abuse at uu.net does work. >Abuse-mail at uu.net >>was created so users could separate Usenet abuse (abuse-news at uu.net), >>ongoing intrusion attempts (security at uu.net), and spam >>(abuse-mail at uu.net). >>Having separate aliases allows us to direct the reported incident to >>the right people faster. I agree that users would only know >>@uu.net aliases to @wcom.com aliases. >Alias are fine as long as they still reach an action point.... >I filter and redistribute all my stuff easily, and we are >immensely smaller >than the WCom's and the rest of the ISP backbone world..... > >Later, >Jim I just reread what I wrote: It should have said: I HAVE AN AUTOMATIC filter and redistribution system From memsvcs at arin.net Thu Mar 6 12:06:41 2003 From: memsvcs at arin.net (Member Services) Date: Thu, 6 Mar 2003 12:06:41 -0500 (EST) Subject: [ppml] Policy Proposal 2003-5: RWhois Server Use Requirements Message-ID: <200303061706.MAA21950@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-5: RWhois Server Use Requirements Background: RWhois was created in part to allow ISP's locally operate and control their own reassignment information. The purpose of placing this data in a RWhois server was two-fold: 1) Allow RIR staff to examine reassignment utilization 2) Allow access to the general public on reassignment information. Many ISPs have opted to use RWhois servers for their reassignment information over sending SWIPs to ARIN. But some of the ISP's who have selected to use RWhois servers for their reassignment information have not kept the servers operational 24x7, contents of the database up to-date, or are restricting access only to ARIN staff. This lack of a uniform set of operations of RWhois servers has resulted in confusion for end-users and ARIN staff. Policy Proposal: Therefore, it is proposed a set of minimal requirements of operating a RWhois server for those ISPs who decide to use RWhois to manage their IP reassignment information be established and enforced. The proposed minimal RWhois requirements are: The RWhois server must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The RWhois server must allow public access to reassignment information. The ISP may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts. The RWhois server must return reassignment information for the IP address queried. The RWhois server may follow the privacy protections for customers as described in the multi-homed policy. The RWhois server must give customer information as described in the multi-homed policy to ARIN staff. The RWhois server may return results for non-IP queries. The RWhois server must respond to a query with the minimal set of attributes per object as defined by ARIN staff. The RWhois server may include optional attributes per object that are defined by the operator. The RWhois server must return results that are up-to-date on reassignment information. From memsvcs at arin.net Thu Mar 6 12:25:03 2003 From: memsvcs at arin.net (Member Services) Date: Thu, 6 Mar 2003 12:25:03 -0500 (EST) Subject: [ppml] Policy Proposal 2003-6: Micro-Assignments with Sponsorship Message-ID: <200303061725.MAA25058@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-6: Micro-Assignments with Sponsorship Proposal for Micro-Assignments with Sponsorship from Subscriber Members Organization or individuals not meeting minimum criteria for end-user assignment as specified in ARIN end-user assignment policy may request IP space as end-user directly from ARIN if it has sponsorship of two or more ARIN subscriber members. To be a sponsor an ARIN member must have existing business relationship with the end-user and agree that: 1. It will act as first-level contact regarding IP requests by the end-user to ARIN and verify technical requirements for end-user according to ARIN policies 2. If in the future the business relationship is terminated, the sponsor will notify ARIN no longer then 30 days after such an event 3. In the event that a sponsor becomes aware that any information regarding IP block assigned under this policy is no longer valid, a sponsor must notify ARIN or verify that sponsored organization or individual has already made necessary updates to the information with ARIN. Information changes include all of the following: a. Changes in contact information such as physical address or email address b. Changes to the legal name of sponsored organization or individual c. Changes in the technical requirements that may make original request invalid or impact size of the required IP block End-users requesting IP block under this policy agree to the following: 1. If in the future a request is made to ARIN for additional IP block according to this or any other policy, end-user agrees that if the new request is approved it will renumber into new IP block in 6 months or less and then return the original block received under this policy. An exception is allowed when new IP block is requested under micro-allocation policy for exchange block or other critical infrastructure. 2. When end-user terminates relationship with one or more of its sponsors it must notify ARIN about this and in case there are less than two sponsors left, it must secure sponsorship of another ARIN member in 30 days or less. If the number of sponsors is less than two for period longer then 60 days, an end-user agrees that ARIN has the right to withdraw the assignment. 3. An end user is responsible with providing correct contact information to ARIN and in case of any changes such as change in legal name, physical or email address, it must contact ARIN and update the information. If ARIN becomes aware that information regarding end-user is incorrect it must contact end-user to request an updated information, assistance from sponsors maybe thought in such situations. If ARIN is unable to make proper contact with end user and the information in ARIN records remains incorrect for period of 60 days or more, ARIN has the right to withdraw the assignment. 4. An end-user is responsible with making regular yearly maintenance fee payments according to special micro-assignments schedule to be adapted by ARIN board of trustees. ARIN will provide a renewal invoice to last known mailing address and if the payment is not received 30 days after the due date, ARIN may contact all sponsors to verify correct billing information. In the event that ARIN is unable to make proper contact with end-user or when payment is still not received 90 days after the due date, ARIN has the right to withdraw the assignment. 5. When assignment has been withdrawn end-user agrees to make no further use of the IP block An assignment maybe withdrawn by ARIN if it meats the criteria specified #2, #3 or #4 above or if ARIN becomes aware that any information in the original request for assignment was incorrect and otherwise end-user would not have qualified for the assignment. In such cases: 1. ARIN must provide 30 day written notice to the last known mailing address and to all contact email addresses before withdrawing the assignment. 2. Under special circumstances an end-user may request postponement, which can be no longer then 12 months. All decisions on these requests are to be made by ARIN staff which may ask for assistance of board of advisors. In all circumstances the decisions by ARIN are final and may not be challenged by end-user by legal or any other means. 3. When an assignment is to be withdrawn, ARIN will provide a notice by both email and conventional mail to the sponsors and specify the reason for withdrawing the assignment and the date when it will be withdrawn. 4. When assignment is withdrawn, ARIN will change WHOIS information to specify that assignment is no longer valid and has been withdrawn. The WHOIS data as was last known regarding end-user and the assignment must be maintained for a period of at least 6 months. 5. An IP block assignment which was withdrawn may not be used for new assignments for at least 12 months. All assignments under this policy must be in according with guidelines listed in RFC2050, except where other ARIN policies may take precedence. In particular one of the following is required in order to qualify for the assignment: 1. Multihomed organizations may request a minimum assignment of /24 without any other justification OR 2. Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection. The basic criteria that must be met are: * 25% immediate utilization rate, and * 50% utilization rate within one year Before this policy is used a new maintenance fee schedule and other fees that are related to this policy must be adapted by the ARIN Board of Trustees. It is recommended that yearly maintenance fee schedule be scaled with 2-4 additional levels that the scale be in accordance with the size of IP block such that fee for /24 block is about 1/4 of the fee for /21 IP block. An additional one-time setup fee is also recommended to be equivalent to yearly maintenance fee. From memsvcs at arin.net Thu Mar 6 12:32:15 2003 From: memsvcs at arin.net (Member Services) Date: Thu, 6 Mar 2003 12:32:15 -0500 (EST) Subject: [ppml] Policy Proposal 2003-7: Announcement of New ARIN IPv4 Blocks Message-ID: <200303061732.MAA26419@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-7: Announcement of New ARIN IPv4 Blocks ARIN should make an effort to allocate and assign IP blocks so that allocations and assignments of the same size (such as micro-allocations, small, middle, large IP blocks) are made of the same /8 block as much as possible. In cases of allocations and assignments smaller then current minimum allocation size for ISP subscriber members (so called micro-allocations and micro- assignments), these allocations and assignments should be made from the IP block specifically reserved for micro-allocations and assignments. Minimum size allocations and assignments for each /8 block should be listed on the ARIN website and with additional information about the blocks where micro-allocation and assignments are made. ARIN should request new /8 blocks from IANA at least 6 months in advance of expected need and allow at least 4 months wait period between the time it received the block and first allocation or assignment that is made out of new /8. After IANA has made an assignment ARIN should provide information regarding new IP block and expected minimum allocations and assignments to be made out each /8 block ARIN has received to ARIN announcement mailing lists, network engineering mailing lists as well as send email to technical contacts for all ISP subscriber members and end-users regarding this new IANA assigned block. An additional announcement should be made one month or less prior to first assignment or allocation. If complaints are received by ARIN regarding routability problems with new IP block, ARIN may make additional announcements on mailing lists as needed and all complains received by ARIN regarding operational issues with new IP allocations and assignments should also be forwarded to proper regional mailing list (such as NANOG). When changes are made in the future regarding minimum allocation or assignments from any /8 block, additional announcement must be made at least 30 days prior to first smaller size assignment or allocation. From memsvcs at arin.net Thu Mar 6 12:39:42 2003 From: memsvcs at arin.net (Member Services) Date: Thu, 6 Mar 2003 12:39:42 -0500 (EST) Subject: [ppml] Policy Proposal 2003-8: End-User to Subscriber Member Status Change Message-ID: <200303061739.MAA27498@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-8: End-User to Subscriber Member Status Change An organization which previously received IP block(s) from ARIN as end-user may change its status and become subscriber member and keep existing IP block(s) as allocation from ARIN under the following conditions and procedures: 1. An organization has changed its business plan and new plans makes it necessary to sub-allocate parts of IP space to organization's customers. 2. ALL ARIN assigned IP blocks have to go through new audit and be justified under ISP initial address space request policy, except that - the organization must be at try to justify IP block allocation equivalent to what it has received as an assignment - If justified allocation size is smaller then current assignment(s), ARIN may require an organization to give up a part of its assignment before it can become a subscriber member - If justified allocation is larger or equal to the current minimum allocation for ISPs but existing assignment(s) were of smaller size, then organization may be allocated by ARIN one larger block equivalent to its requirements, in which case organization has 12 months to renumber and return previously assigned IP block(s) - For the justifications "internal use" as with end-user policies should be permitted but evidence (such as new business plan as in #1) must be shown that at least some IP space will be allocated to other organizations or assigned to end-users. 3. After the change organization may not apply for any additional IP blocks as end-user and must do it as ISP even for IP blocks intended primarily for internal use. 4. Organization maybe required to pay one-time fee to process this assignment->allocation change request and thereafter organization must pay for its IP blocks according to ISP subscriber member fee schedule. From lee.howard at wcom.com Thu Mar 6 12:45:51 2003 From: lee.howard at wcom.com (Lee Howard) Date: Thu, 6 Mar 2003 12:45:51 -0500 (EST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <390E55B947E7C848898AEBB9E5077060750AEF@msmdcfs01.msmgmt.com> Message-ID: On Thu, 6 Mar 2003, McBurnett, Jim wrote: > Date: Thu, 06 Mar 2003 10:46:33 -0500 > From: "McBurnett, Jim" > To: Lee Howard , JLS > Cc: ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > > Email snipped to limit length.. > Take a look at: http://www.ietf.org/rfc/rfc2142.txt?number=2142 > Also take a look at: http://www.rfc-ignorant.com/ Thank you for the reference. I personally disagree with rfc-ignorant on interpretation of some RFCs. > >If this is your proposal, how do you propose to assign domain names to > >network assignments? If 172.16.0.0/16 is allocated to Acme Holdings, > >who operates under the domain name acme.com, acme.net, acme.com.ca, > >acmeholdings.com, and explodinganvil.mil, which domain will you require > >to be on the Abuse POC? > > According to the RFC. Each Organization... > If I recieve spam from any of those domains how am I to know they are linked? Which WHOIS database are you using? If you get spam from bulkmailer at spam.net you can report it to abuse at spam.net without even looking it up. You can look in the headers and report it to every relay, and report it to abuse at everylistedrelay.com. Or you can try to pick an IP address, look up the ARIN record for that IP address, and report it to the Abuse POC given in ARIN's records. Only the latter case is on topic for ARIN PPML. Also, RFC2142 does not describe the possibility of multiple domains being associated with an IP address. If I assign a /24 to a customer who is a web hosting company, do you want the Abuse POC to be every domain name they host, one of their own domain names (.com or .net?) or one of my domain names? I'm not asking about the email address ABUSE at domain, which is described in the RFC, I'm asking about the Abuse POC given in ARIN's WHOIS database. > As I see it and as I implement it, I have 28 domain names tied to > different business entities owned by our parent company- therefore IT has > 28 * 8 mailboxes-- acutally they are just aliases... > We own newspapers, and the average person, and even the above average person > may not make the connections..... I have neither said nor implied that abuse@ any particular domain name is an invalid account. What I have said is that we have chosen to list a specific email address as the Abuse POC in ARIN's WHOIS. You can use abuse at whatever. I've listed the address I prefer you use, in the public WHOIS database that ARIN maintains. As far as I can tell, we are both a) RFC-compliant in this regard, and b) excercising our ability to list the most accurate contact in the Abuse POC records. In summary, I am asking if there is a proposal to require something more than reachability for the Abuse POC. If there is, I am asking for clarification, and whether this should be part of proposal 2003-1 or a separate proposal. If there is no such proposal, then there is no debate. > Later, > Jim I am only authoritative for IP addressing and WHOIS for UUNET and WorldCom Internet services. I am not authoritative for Abuse, Security, Support, NOC, or domain names, so I cannot discuss those areas, which are not related to ARIN Public Policy anyway. Thank you (in advance) for clarifying your position. Lee From woody at pch.net Thu Mar 6 12:49:35 2003 From: woody at pch.net (Bill Woodcock) Date: Thu, 6 Mar 2003 09:49:35 -0800 (PST) Subject: [ppml] Policy Proposal 2003-8: End-User to Subscriber Member Status Change In-Reply-To: <200303061739.MAA27498@ops.arin.net> Message-ID: > - the organization must be at try to justify IP block > allocation equivalent to what it has received as an > assignment This appears to have been mangled. -Bill From memsvcs at arin.net Thu Mar 6 12:47:15 2003 From: memsvcs at arin.net (Member Services) Date: Thu, 6 Mar 2003 12:47:15 -0500 (EST) Subject: [ppml] Policy Proposal 2003-9: WHOIS Acceptable Use Message-ID: <200303061747.MAA28873@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-9: WHOIS Acceptable Use This proposal changes current Bulk WHOIS Acceptable Use Policy to become general WHOIS Acceptable Use policy that would apply to all WHOIS queries. In particular: 1. A new acceptable use policy called "WHOIS Acceptable Use Policy" is to be published on ARIN website as follows: "The ARIN WHOIS Data is for Internet operations and technical research purposes pertaining to Internet Operations only. It may not be used for advertising, direct marketing, marketing research or similar purposes. Use of ARIN WHOIS data for these activities is explicitly forbidden. ARIN requests to be notified of any such activities or suspicions thereof. ARIN reserves the right to restrict access to the WHOIS database in its sole discretion to ensure operational stability. ARIN may restrict or terminate your access to the WHOIS database for failure to abide by these terms of use." 2. Access to WHOIS data with individual queries (such as by using WHOIS protocol) must in the output either include entire 'ARIN WHOIS Acceptable Use Policy' in the comments or provide a one-line statement that data is provided and can only be used according to 'ARIN WHOIS Acceptable Use Policy' with a link to where the policy is published on ARIN website. 3. High frequency individual query access and access to either entire WHOIS database or large portion of it must be provided with authentication to persons and organizations authorized by ARIN. These organizations must sign 'Acceptable Use Policy for Bulk Copies of ARIN WHOIS Data' agreement which shall include 'WHOIS Acceptable Use Policy' and additional statement that "Redistributing bulk ARIN WHOIS Data is explicitly forbidden. It is permissible to publish data on an individual query or small number of queries at a time basis as long as reasonable precautions are taken to prevent automated querying by database harvesters" Organizations that need access to ARIN WHOIS data on regular basis maybe required to resubmit the agreement on monthly basis at which time authentication settings may need to be changed. From memsvcs at arin.net Thu Mar 6 14:32:31 2003 From: memsvcs at arin.net (Member Services) Date: Thu, 6 Mar 2003 14:32:31 -0500 (EST) Subject: [ppml] Signing the Public DNS Root - Discussion at ARIN XI Message-ID: <200303061932.OAA18719@ops.arin.net> This message is not an ARIN policy proposal. This message is a request for feedback. This issue will be discussed at the upcoming ARIN XI meeting. An Internet-Draft has been written that proposes an interim scheme for signing the public DNS root. The current version of this Internet-Draft is: draft-ietf-dnsop-interim-signed-root-00.txt The full text of this Internet-Draft can be found at: http://www.ietf.org/ids.by.wg/dnsop.html In the Internet-Draft, a mechanism has been proposed for a first stage of a transition from a unsigned DNS root to a signed root, such that the data in the root zone is accompanied by DNSSEC signatures to allow validation. The process of doing this involves the use of a set of operator keys which are signed by one key signing key, sometimes referred to a "master key". It has been further proposed that these key signing keys be managed by the Regional Internet Registries (RIRs). The proposal states the requirements of the RIRs would be to: * establish a secure out-of-band communication path in collaboration with the signing operators which will be used for authenticated exchange of the unsigned keyset. * periodically generate strong keys using a good random number generator * manage their keys (i.e. use them for signing the operator keyset and keeping the private key appropriately secret) The author of this Internet-Draft will attend the upcoming ARIN XI meeting and will present the main points of the draft to meeting attendees. Question: Since this Internet-Draft suggests future action by the RIRs, the ARIN community should discuss this issue and provide feedback to the author. Therefore, the following question is asked: Is this a task that should be performed by ARIN? Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) From jmcburnett at msmgmt.com Thu Mar 6 14:46:38 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Thu, 6 Mar 2003 14:46:38 -0500 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <390E55B947E7C848898AEBB9E5077060750AF0@msmdcfs01.msmgmt.com> >> Take a look at: http://www.ietf.org/rfc/rfc2142.txt?number=2142 >> Also take a look at: http://www.rfc-ignorant.com/ > >Thank you for the reference. I personally disagree with rfc-ignorant >on interpretation of some RFCs. Yeah - they, as us all, differ.. I find it helpful sometimes when sending abuse complaints and get bounces... Makes a nice piece of news to send to an ISP that cares less about the rest of us. >Which WHOIS database are you using? If you get spam from >bulkmailer at spam.net you can report it to abuse at spam.net without even >looking it up. You can look in the headers and report it to every >relay, and report it to abuse at everylistedrelay.com. Or you can try to >pick an IP address, look up the ARIN record for that IP address, and >report it to the Abuse POC given in ARIN's records. Only the latter >case is on topic for ARIN PPML. The later PPML topic is the one that confuses me sometimes, and hence the RFC ignorant. A few ISP's I have been spammed from don't accept abuse@ secuirty@ etc.. And the ARIN POC is often inaccurate for the people on purpose. And as of late, many spammers are forging most of the header anyway.... >Also, RFC2142 does not describe the possibility of multiple domains >being associated with an IP address. If I assign a /24 to a customer >who is a web hosting company, do you want the Abuse POC to be every >domain name they host, one of their own domain names (.com or .net?) >or one of my domain names? I'm not asking about the email address >ABUSE at domain, which is described in the RFC, I'm asking about >the Abuse >POC given in ARIN's WHOIS database. Good Point.. I guess my answer is let's push the POC Policy to get the POC's to a higher level of accuracy... >I have neither said nor implied that abuse@ any particular domain name >is an invalid account. What I have said is that we have chosen to list >a specific email address as the Abuse POC in ARIN's WHOIS. You can use >abuse at whatever. I've listed the address I prefer you use, in >the public >WHOIS database that ARIN maintains. As far as I can tell, we are both >a) RFC-compliant in this regard, and b) excercising our >ability to list >the most accurate contact in the Abuse POC records. My apologies. I did not mean any implications... You did say something here I wish the community as a whole would adopt... "excercising our ability to list the most accurate contact" That is the whole problem.. I can't remember which "famed spammer" it was, but one spammer, his ISP and the every domain in relation has wrong WHOIS data.. Check out www.spamhaus.org > >In summary, I am asking if there is a proposal to require >something more >than reachability for the Abuse POC. If there is, I am asking for >clarification, and whether this should be part of proposal 2003-1 or a >separate proposal. If there is no such proposal, then there >is no debate. > Correction if there is no such proposal we need to create one... AND if it takes it, send the idea to the IETF.. Jim From lee.howard at wcom.com Thu Mar 6 15:39:56 2003 From: lee.howard at wcom.com (Lee Howard) Date: Thu, 6 Mar 2003 15:39:56 -0500 (EST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <390E55B947E7C848898AEBB9E5077060750AF0@msmdcfs01.msmgmt.com> Message-ID: On Thu, 6 Mar 2003, McBurnett, Jim wrote: > Date: Thu, 06 Mar 2003 14:46:38 -0500 > From: "McBurnett, Jim" > To: Lee Howard > Cc: ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > > > >pick an IP address, look up the ARIN record for that IP address, and > >report it to the Abuse POC given in ARIN's records. Only the latter > >case is on topic for ARIN PPML. > > The later PPML topic is the one that confuses me sometimes, and hence the > RFC ignorant. A few ISP's I have been spammed from > don't accept abuse@ secuirty@ etc.. And the ARIN POC is often inaccurate for > the people on purpose. And as of late, > many spammers are forging most of the header anyway.... Somewhat separate issues, still, I think. Enforcing ABUSE at domain isn't something I can imagine ARIN doing. Requiring valid POC information is the subject of a current policy proposal, 2003-2. > >or one of my domain names? I'm not asking about the email address > >ABUSE at domain, which is described in the RFC, I'm asking about > >the Abuse > >POC given in ARIN's WHOIS database. > > Good Point.. I guess my answer is let's push the POC Policy to get the POC's > to a higher level of accuracy... Excellent, I understand your position now. > >In summary, I am asking if there is a proposal to require > >something more > >than reachability for the Abuse POC. If there is, I am asking for > >clarification, and whether this should be part of proposal 2003-1 or a > >separate proposal. If there is no such proposal, then there > >is no debate. > > Correction if there is no such proposal we need to create one... > AND if it takes it, send the idea to the IETF.. Here's the text of 2003-2: http://www.arin.net/policy/2003_2.html Excerpt: 2. All networks should [regardless of geographical location] provide a valid e-mail contact for network [NOC@] and abuse [Abuse@] contact. Make it standard. It goes further to establish methods for verification and penalties for non-compliance. Are your concerns addressed by this policy proposal, or do you have a new policy to propose? > Jim Thank you for taking the time to discuss the policies. I must say that it's good to see so much participation on the list; it definitely helps clarify the proposals being considered at the meeting. Lee From william at elan.net Thu Mar 6 14:13:00 2003 From: william at elan.net (william at elan.net) Date: Thu, 6 Mar 2003 11:13:00 -0800 (PST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: Message-ID: I did not yet comments on 2003-1 and I'm not entirely made up my mind yet, but I have to say I'v not been conviced by either side and I see problems with it for both ISP that is listing its contacts and for community itself that wants to use the contact info: I. ISP 1. Some companies have charn with their employees changing quickly and some often change assignments/roles within companies, its easier to keep "role contact", its more up to date. 2. People do not like to be listed in public whois information because they inevitibly begin to get contacted for issues not related to do and called names, etc. 3. People do not like to be listed in public whois because that information is harvested by advertisers. II. Contact to ISP 1. If person is not available and its the only contact listed (as its the only contact required!), you have a real problem. 2. For emergency situation its a lot more important to reach ANYBODY in the say tech support or NOC then particular somebody. 3. Human contacts are not available 24/7, role contacts are sometimes (same as #2 really) I do think its important to keep correct reachable info for at least one contact and most likely both abuse and noc if they are listed (as is with 2003-2), though 2003-2 I'll not support in its current form - it goes way way too far on the abuse prevention (I guess I'm moderate...) and to actions ARIN can not do (like control over routing table). In all, human contact does not hurt, but only as option to be decided by ISP and not necessarily as the only option of contact. I think new redisign of the database, solves most of it allowing multiple contacts to be listed as ISP desires (instead of only one contact as it was before). And its my understand (please correct me if I'm wrong, I'v not see it yet in real whois output yet!) that you can have multiple TECH, ABUSE, NOC contacts for the same ORG or NET, allowing for both human and role contacts if ISP wants to do so. On Thu, 6 Mar 2003, Lee Howard wrote: > On Thu, 6 Mar 2003, McBurnett, Jim wrote: > > > Date: Thu, 06 Mar 2003 14:46:38 -0500 > > From: "McBurnett, Jim" > > To: Lee Howard > > Cc: ppml at arin.net > > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > > > > > > >pick an IP address, look up the ARIN record for that IP address, and > > >report it to the Abuse POC given in ARIN's records. Only the latter > > >case is on topic for ARIN PPML. > > > > The later PPML topic is the one that confuses me sometimes, and hence the > > RFC ignorant. A few ISP's I have been spammed from > > don't accept abuse@ secuirty@ etc.. And the ARIN POC is often inaccurate for > > the people on purpose. And as of late, > > many spammers are forging most of the header anyway.... > > Somewhat separate issues, still, I think. > Enforcing ABUSE at domain isn't something I can imagine ARIN doing. > Requiring valid POC information is the subject of a current policy > proposal, 2003-2. > > > >or one of my domain names? I'm not asking about the email address > > >ABUSE at domain, which is described in the RFC, I'm asking about > > >the Abuse > > >POC given in ARIN's WHOIS database. > > > > Good Point.. I guess my answer is let's push the POC Policy to get the POC's > > to a higher level of accuracy... > > Excellent, I understand your position now. > > > > >In summary, I am asking if there is a proposal to require > > >something more > > >than reachability for the Abuse POC. If there is, I am asking for > > >clarification, and whether this should be part of proposal 2003-1 or a > > >separate proposal. If there is no such proposal, then there > > >is no debate. > > > > Correction if there is no such proposal we need to create one... > > AND if it takes it, send the idea to the IETF.. > > Here's the text of 2003-2: > http://www.arin.net/policy/2003_2.html > Excerpt: > > 2. All networks should [regardless of geographical location] provide a > valid e-mail contact for network [NOC@] and abuse [Abuse@] contact. Make > it standard. > > It goes further to establish methods for verification and penalties for > non-compliance. Are your concerns addressed by this policy proposal, or > do you have a new policy to propose? > > > Jim > > Thank you for taking the time to discuss the policies. I must say that > it's good to see so much participation on the list; it definitely helps > clarify the proposals being considered at the meeting. > > > Lee > > From owen at delong.com Thu Mar 6 16:22:41 2003 From: owen at delong.com (Owen DeLong) Date: Thu, 06 Mar 2003 13:22:41 -0800 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: References: Message-ID: <2147483647.1046956961@imac-en0.delong.sj.ca.us> Thanks for your comments. I hope to publish an amended draft which should address most of your concerns. Please seem my inline comments below. --On Thursday, March 6, 2003 11:13 AM -0800 william at elan.net wrote: > I did not yet comments on 2003-1 and I'm not entirely made up my mind > yet, but I have to say I'v not been conviced by either side and I see > problems with it for both ISP that is listing its contacts and for > community itself that wants to use the contact info: > I. ISP > 1. Some companies have charn with their employees changing quickly > and some often change assignments/roles within companies, its easier > to keep "role contact", its more up to date. Agreed. This wasn't so much about having a specific human contact (at first I thought it was, but my position has changed some) as it is about having a contact which is: 1. A phone number that reaches a live human being capable of resolving problems or getting the caller to someone who can resolve their problem. Not an automaton or voice jail. The human should only be required to be reachable during normal business hours in the timezone applicable to the POC address on file, although 24x7 is strongly encouraged where practicable. and 2. An email address which, may send a receipt acknolwedgement automatically, but which maintains a committment that the received mail will be read by a human within 48 hours of receipt. > 2. People do not like to be listed in public whois information because > they inevitibly begin to get contacted for issues not related to > do and called names, etc. Agreed. > 3. People do not like to be listed in public whois because that > information is harvested by advertisers. > I have a little less sympathy here, as I think we should be working harder to prosecute this type of violation in the harvesting. > II. Contact to ISP > 1. If person is not available and its the only contact listed (as its > the only contact required!), you have a real problem. It is _NOT_ the only contact required. The standard requirements for Tech and Admin contacts remain. This contact could either be one of them, or could be an additional contact. The requirement is to list at least one admin or tech contact. I believe it is possible to list multiple contacts in any category. In the amended proposal, I will suggest the creation of a category of ABUSE contact, with the requirement that it be possible to: 1. List multiple ABUSE contacts 2. The contact should have a Comment Field which can be used to specify types of abuse handled by a particular contact. Further, at least one ABUSE contact should list a phone number which, during normal business hours in the timezone applicable to the address listed on said POC is answered by one or more live human beings capable of addressing network abuse. Further, that contact's Comment field should contain the phrase "Live Contact" followed by the hours in 24hr format with timezone, such as "Live Contact 0800-1700 US/Pacific Time". The timezone should be a POSIX timezone name. > 2. For emergency situation its a lot more important to reach ANYBODY in > the say tech support or NOC then particular somebody. Yes, and as such, it's important that at least one contact in the database allow you to do exactly that, rather than a voice jail or a bouncing auto- responder. > 3. Human contacts are not available 24/7, role contacts are sometimes > (same as #2 really) > Same answer as 2. > I do think its important to keep correct reachable info for at least one > contact and most likely both abuse and noc if they are listed (as is with > 2003-2), though 2003-2 I'll not support in its current form - it goes way > way too far on the abuse prevention (I guess I'm moderate...) and to > actions ARIN can not do (like control over routing table). > I agree. I like most of the intenet of 2003-2, but I think the majority of it is more of an IETF subject than an ARIN topic. However, as it relates to contacts, I'd like to find a common ground that allows Dr. Race and I to say there is a contact-related proposal we both support and feel addresses the issues within the scope of ARIN. > In all, human contact does not hurt, but only as option to be decided by > ISP and not necessarily as the only option of contact. I think new > redisign of the database, solves most of it allowing multiple contacts to > be listed as ISP desires (instead of only one contact as it was before). > And its my understand (please correct me if I'm wrong, I'v not see it > yet in real whois output yet!) that you can have multiple TECH, ABUSE, > NOC contacts for the same ORG or NET, allowing for both human and role > contacts if ISP wants to do so. > It was never intended as the only option of contact. It was intended to require that AT LEAST ONE POC be listed that is not handled through purely automatic means. (Who do you call when the automatic systems you call to report something broken are what's broken?) That is the primary intent behind this policy. I believe you are correct about the multiple contacts. That is why this policy was worded with "At least one" and not "The...". Thanks again, Owen > On Thu, 6 Mar 2003, Lee Howard wrote: > >> On Thu, 6 Mar 2003, McBurnett, Jim wrote: >> >> > Date: Thu, 06 Mar 2003 14:46:38 -0500 >> > From: "McBurnett, Jim" >> > To: Lee Howard >> > Cc: ppml at arin.net >> > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact >> > >> > >> > > pick an IP address, look up the ARIN record for that IP address, and >> > > report it to the Abuse POC given in ARIN's records. Only the latter >> > > case is on topic for ARIN PPML. >> > >> > The later PPML topic is the one that confuses me sometimes, and hence >> > the RFC ignorant. A few ISP's I have been spammed from >> > don't accept abuse@ secuirty@ etc.. And the ARIN POC is often >> > inaccurate for the people on >> > purpose. And as of late, many spammers are forging most of the header >> > anyway.... >> >> Somewhat separate issues, still, I think. >> Enforcing ABUSE at domain isn't something I can imagine ARIN doing. >> Requiring valid POC information is the subject of a current policy >> proposal, 2003-2. >> >> > > or one of my domain names? I'm not asking about the email address >> > > ABUSE at domain, which is described in the RFC, I'm asking about >> > > the Abuse >> > > POC given in ARIN's WHOIS database. >> > >> > Good Point.. I guess my answer is let's push the POC Policy to get the >> > POC's to a higher level of accuracy... >> >> Excellent, I understand your position now. >> >> >> > > In summary, I am asking if there is a proposal to require >> > > something more >> > > than reachability for the Abuse POC. If there is, I am asking for >> > > clarification, and whether this should be part of proposal 2003-1 or >> > > a separate proposal. If there is no such proposal, then there is >> > > no debate. >> > >> > Correction if there is no such proposal we need to create one... >> > AND if it takes it, send the idea to the IETF.. >> >> Here's the text of 2003-2: >> http://www.arin.net/policy/2003_2.html >> Excerpt: >> >> 2. All networks should [regardless of geographical location] provide a >> valid e-mail contact for network [NOC@] and abuse [Abuse@] contact. >> Make it standard. >> >> It goes further to establish methods for verification and penalties for >> non-compliance. Are your concerns addressed by this policy proposal, or >> do you have a new policy to propose? >> >> > Jim >> >> Thank you for taking the time to discuss the policies. I must say that >> it's good to see so much participation on the list; it definitely helps >> clarify the proposals being considered at the meeting. >> >> >> Lee >> >> > From william at elan.net Thu Mar 6 15:32:22 2003 From: william at elan.net (william at elan.net) Date: Thu, 6 Mar 2003 12:32:22 -0800 (PST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <2147483647.1046956961@imac-en0.delong.sj.ca.us> Message-ID: Ok, so to summarize you do not actually want human contact poc but want human reachable via poc information. This I'm not sure is really up to ARIN to tell their subscriber members how to setup their telephone system or email server (comes again as operational issue), nor does there seem to be clear way to test and punish if its not done so. Rather better would be to actually have policy that says they must have valid contact (i.e phone# and email are valid and ARIN can send email and get reply for example) and specify as recomendation that as an option it must be possible to talk to somebody on the phone or get human response (as recomendation it might well be ok). On Thu, 6 Mar 2003, Owen DeLong wrote: > Thanks for your comments. I hope to publish an amended draft which should > address most of your concerns. Please seem my inline comments below. > > > --On Thursday, March 6, 2003 11:13 AM -0800 william at elan.net wrote: > > > I did not yet comments on 2003-1 and I'm not entirely made up my mind > > yet, but I have to say I'v not been conviced by either side and I see > > problems with it for both ISP that is listing its contacts and for > > community itself that wants to use the contact info: > > I. ISP > > 1. Some companies have charn with their employees changing quickly > > and some often change assignments/roles within companies, its easier > > to keep "role contact", its more up to date. > > Agreed. This wasn't so much about having a specific human contact (at first > I thought it was, but my position has changed some) as it is about having > a contact which is: > 1. A phone number that reaches a live human being capable of > resolving problems or getting the caller to someone who can > resolve their problem. Not an automaton or voice jail. > The human should only be required to be reachable during > normal business hours in the timezone applicable to the POC > address on file, although 24x7 is strongly encouraged > where practicable. > > and > > 2. An email address which, may send a receipt acknolwedgement > automatically, but which maintains a committment that the > received mail will be read by a human within 48 hours of > receipt. > > > 2. People do not like to be listed in public whois information because > > they inevitibly begin to get contacted for issues not related to > > do and called names, etc. > > Agreed. > > > 3. People do not like to be listed in public whois because that > > information is harvested by advertisers. > > > > I have a little less sympathy here, as I think we should be working harder > to prosecute this type of violation in the harvesting. > > > II. Contact to ISP > > 1. If person is not available and its the only contact listed (as its > > the only contact required!), you have a real problem. > > It is _NOT_ the only contact required. The standard requirements for > Tech and Admin contacts remain. This contact could either be one of them, > or could be an additional contact. The requirement is to list at least > one admin or tech contact. I believe it is possible to list multiple > contacts in any category. In the amended proposal, I will suggest the > creation of a category of ABUSE contact, with the requirement that it > be possible to: > > 1. List multiple ABUSE contacts > 2. The contact should have a Comment Field which can be used > to specify types of abuse handled by a particular contact. > > Further, at least one ABUSE contact should list a phone number which, during > normal business hours in the timezone applicable to the address listed on > said POC is answered by one or more live human beings capable of addressing > network abuse. Further, that contact's Comment field should contain the > phrase "Live Contact" followed by the hours in 24hr format with timezone, > such as "Live Contact 0800-1700 US/Pacific Time". The timezone should > be a POSIX timezone name. > > > 2. For emergency situation its a lot more important to reach ANYBODY in > > the say tech support or NOC then particular somebody. > > Yes, and as such, it's important that at least one contact in the database > allow you to do exactly that, rather than a voice jail or a bouncing auto- > responder. > > > 3. Human contacts are not available 24/7, role contacts are sometimes > > (same as #2 really) > > > Same answer as 2. > > > I do think its important to keep correct reachable info for at least one > > contact and most likely both abuse and noc if they are listed (as is with > > 2003-2), though 2003-2 I'll not support in its current form - it goes way > > way too far on the abuse prevention (I guess I'm moderate...) and to > > actions ARIN can not do (like control over routing table). > > > I agree. I like most of the intenet of 2003-2, but I think the majority > of it is more of an IETF subject than an ARIN topic. However, as it relates > to contacts, I'd like to find a common ground that allows Dr. Race and I > to say there is a contact-related proposal we both support and feel > addresses > the issues within the scope of ARIN. > > > In all, human contact does not hurt, but only as option to be decided by > > ISP and not necessarily as the only option of contact. I think new > > redisign of the database, solves most of it allowing multiple contacts to > > be listed as ISP desires (instead of only one contact as it was before). > > And its my understand (please correct me if I'm wrong, I'v not see it > > yet in real whois output yet!) that you can have multiple TECH, ABUSE, > > NOC contacts for the same ORG or NET, allowing for both human and role > > contacts if ISP wants to do so. > > > It was never intended as the only option of contact. It was intended to > require that AT LEAST ONE POC be listed that is not handled through purely > automatic means. (Who do you call when the automatic systems you call to > report something broken are what's broken?) That is the primary intent > behind this policy. > > I believe you are correct about the multiple contacts. That is why this > policy was worded with "At least one" and not "The...". > > Thanks again, > > Owen > > > On Thu, 6 Mar 2003, Lee Howard wrote: > > > >> On Thu, 6 Mar 2003, McBurnett, Jim wrote: > >> > >> > Date: Thu, 06 Mar 2003 14:46:38 -0500 > >> > From: "McBurnett, Jim" > >> > To: Lee Howard > >> > Cc: ppml at arin.net > >> > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > >> > > >> > > >> > > pick an IP address, look up the ARIN record for that IP address, and > >> > > report it to the Abuse POC given in ARIN's records. Only the latter > >> > > case is on topic for ARIN PPML. > >> > > >> > The later PPML topic is the one that confuses me sometimes, and hence > >> > the RFC ignorant. A few ISP's I have been spammed from > >> > don't accept abuse@ secuirty@ etc.. And the ARIN POC is often > >> > inaccurate for the people on > >> > purpose. And as of late, many spammers are forging most of the header > >> > anyway.... > >> > >> Somewhat separate issues, still, I think. > >> Enforcing ABUSE at domain isn't something I can imagine ARIN doing. > >> Requiring valid POC information is the subject of a current policy > >> proposal, 2003-2. > >> > >> > > or one of my domain names? I'm not asking about the email address > >> > > ABUSE at domain, which is described in the RFC, I'm asking about > >> > > the Abuse > >> > > POC given in ARIN's WHOIS database. > >> > > >> > Good Point.. I guess my answer is let's push the POC Policy to get the > >> > POC's to a higher level of accuracy... > >> > >> Excellent, I understand your position now. > >> > >> > >> > > In summary, I am asking if there is a proposal to require > >> > > something more > >> > > than reachability for the Abuse POC. If there is, I am asking for > >> > > clarification, and whether this should be part of proposal 2003-1 or > >> > > a separate proposal. If there is no such proposal, then there is > >> > > no debate. > >> > > >> > Correction if there is no such proposal we need to create one... > >> > AND if it takes it, send the idea to the IETF.. > >> > >> Here's the text of 2003-2: > >> http://www.arin.net/policy/2003_2.html > >> Excerpt: > >> > >> 2. All networks should [regardless of geographical location] provide a > >> valid e-mail contact for network [NOC@] and abuse [Abuse@] contact. > >> Make it standard. > >> > >> It goes further to establish methods for verification and penalties for > >> non-compliance. Are your concerns addressed by this policy proposal, or > >> do you have a new policy to propose? > >> > >> > Jim > >> > >> Thank you for taking the time to discuss the policies. I must say that > >> it's good to see so much participation on the list; it definitely helps > >> clarify the proposals being considered at the meeting. > >> > >> > >> Lee > >> > >> > > From HRyu at norlight.com Thu Mar 6 17:49:13 2003 From: HRyu at norlight.com (Hyunseog Ryu) Date: Thu, 6 Mar 2003 16:49:13 -0600 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: Hi there, I missed some of emails regarding this thread because of my busy schedule. So if I say same thing which other people said already, please forgive me. ^.^ In my point, what will be the penalty for this policy? And how does ARIN check this policy implementation? Somebody from ARIN call POC every year - maybe renewal time for membership fee - to check whether ARIN members are following this or not? I believe this is a kind of ISP or Enterprise internal policy to keep their contact point as current as possible. I had some difficulty to reach somebody for ISP contact when I had some security issue or something like that. But if we do make policy for organization internal policy like this, we will have policy after policy, and without mechanism to check whether somebody is following this policy or not, I think this policy will be dead policy, and that's not a good practice for overall policy concept. If we have something like similar policy for yellow page or website contact information by FCC or some government agency for validation of contact point information, I may think this might be good policy. But I don't think this will be a good policy for everybody. Maintaining contact point to be reachable by ARIN Whois database will be ISP's or End-user's responsibility, not ARIN's. If we want to keep this as much as detailed, I believe it's enough to put "recommendation" in ARIN's template to state this. Hyun ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hyunseog Ryu / CCDA, MCSE, CCIE candidate(written test passed) Senior Network Engineer/Applications Engineering Norlight Telecommunications, Inc. 275 North Corporate Drive Brookfield, WI 53045-5818 Tel. +1.262.792.7965 Fax. +1.262.792.7733 email: hryu at norlight.com william at elan.net Sent by: To: Owen DeLong owner-ppml at arin.n cc: ppml at arin.net, (bcc: Hyunseog Ryu/Brookfield/Norlight) et Fax to: Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact 03/06/2003 02:32 PM Ok, so to summarize you do not actually want human contact poc but want human reachable via poc information. This I'm not sure is really up to ARIN to tell their subscriber members how to setup their telephone system or email server (comes again as operational issue), nor does there seem to be clear way to test and punish if its not done so. Rather better would be to actually have policy that says they must have valid contact (i.e phone# and email are valid and ARIN can send email and get reply for example) and specify as recomendation that as an option it must be possible to talk to somebody on the phone or get human response (as recomendation it might well be ok). On Thu, 6 Mar 2003, Owen DeLong wrote: > Thanks for your comments. I hope to publish an amended draft which should > address most of your concerns. Please seem my inline comments below. > > > --On Thursday, March 6, 2003 11:13 AM -0800 william at elan.net wrote: > > > I did not yet comments on 2003-1 and I'm not entirely made up my mind > > yet, but I have to say I'v not been conviced by either side and I see > > problems with it for both ISP that is listing its contacts and for > > community itself that wants to use the contact info: > > I. ISP > > 1. Some companies have charn with their employees changing quickly > > and some often change assignments/roles within companies, its easier > > to keep "role contact", its more up to date. > > Agreed. This wasn't so much about having a specific human contact (at first > I thought it was, but my position has changed some) as it is about having > a contact which is: > 1. A phone number that reaches a live human being capable of > resolving problems or getting the caller to someone who can > resolve their problem. Not an automaton or voice jail. > The human should only be required to be reachable during > normal business hours in the timezone applicable to the POC > address on file, although 24x7 is strongly encouraged > where practicable. > > and > > 2. An email address which, may send a receipt acknolwedgement > automatically, but which maintains a committment that the > received mail will be read by a human within 48 hours of > receipt. > > > 2. People do not like to be listed in public whois information because > > they inevitibly begin to get contacted for issues not related to > > do and called names, etc. > > Agreed. > > > 3. People do not like to be listed in public whois because that > > information is harvested by advertisers. > > > > I have a little less sympathy here, as I think we should be working harder > to prosecute this type of violation in the harvesting. > > > II. Contact to ISP > > 1. If person is not available and its the only contact listed (as its > > the only contact required!), you have a real problem. > > It is _NOT_ the only contact required. The standard requirements for > Tech and Admin contacts remain. This contact could either be one of them, > or could be an additional contact. The requirement is to list at least > one admin or tech contact. I believe it is possible to list multiple > contacts in any category. In the amended proposal, I will suggest the > creation of a category of ABUSE contact, with the requirement that it > be possible to: > > 1. List multiple ABUSE contacts > 2. The contact should have a Comment Field which can be used > to specify types of abuse handled by a particular contact. > > Further, at least one ABUSE contact should list a phone number which, during > normal business hours in the timezone applicable to the address listed on > said POC is answered by one or more live human beings capable of addressing > network abuse. Further, that contact's Comment field should contain the > phrase "Live Contact" followed by the hours in 24hr format with timezone, > such as "Live Contact 0800-1700 US/Pacific Time". The timezone should > be a POSIX timezone name. > > > 2. For emergency situation its a lot more important to reach ANYBODY in > > the say tech support or NOC then particular somebody. > > Yes, and as such, it's important that at least one contact in the database > allow you to do exactly that, rather than a voice jail or a bouncing auto- > responder. > > > 3. Human contacts are not available 24/7, role contacts are sometimes > > (same as #2 really) > > > Same answer as 2. > > > I do think its important to keep correct reachable info for at least one > > contact and most likely both abuse and noc if they are listed (as is with > > 2003-2), though 2003-2 I'll not support in its current form - it goes way > > way too far on the abuse prevention (I guess I'm moderate...) and to > > actions ARIN can not do (like control over routing table). > > > I agree. I like most of the intenet of 2003-2, but I think the majority > of it is more of an IETF subject than an ARIN topic. However, as it relates > to contacts, I'd like to find a common ground that allows Dr. Race and I > to say there is a contact-related proposal we both support and feel > addresses > the issues within the scope of ARIN. > > > In all, human contact does not hurt, but only as option to be decided by > > ISP and not necessarily as the only option of contact. I think new > > redisign of the database, solves most of it allowing multiple contacts to > > be listed as ISP desires (instead of only one contact as it was before). > > And its my understand (please correct me if I'm wrong, I'v not see it > > yet in real whois output yet!) that you can have multiple TECH, ABUSE, > > NOC contacts for the same ORG or NET, allowing for both human and role > > contacts if ISP wants to do so. > > > It was never intended as the only option of contact. It was intended to > require that AT LEAST ONE POC be listed that is not handled through purely > automatic means. (Who do you call when the automatic systems you call to > report something broken are what's broken?) That is the primary intent > behind this policy. > > I believe you are correct about the multiple contacts. That is why this > policy was worded with "At least one" and not "The...". > > Thanks again, > > Owen > > > On Thu, 6 Mar 2003, Lee Howard wrote: > > > >> On Thu, 6 Mar 2003, McBurnett, Jim wrote: > >> > >> > Date: Thu, 06 Mar 2003 14:46:38 -0500 > >> > From: "McBurnett, Jim" > >> > To: Lee Howard > >> > Cc: ppml at arin.net > >> > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > >> > > >> > > >> > > pick an IP address, look up the ARIN record for that IP address, and > >> > > report it to the Abuse POC given in ARIN's records. Only the latter > >> > > case is on topic for ARIN PPML. > >> > > >> > The later PPML topic is the one that confuses me sometimes, and hence > >> > the RFC ignorant. A few ISP's I have been spammed from > >> > don't accept abuse@ secuirty@ etc.. And the ARIN POC is often > >> > inaccurate for the people on > >> > purpose. And as of late, many spammers are forging most of the header > >> > anyway.... > >> > >> Somewhat separate issues, still, I think. > >> Enforcing ABUSE at domain isn't something I can imagine ARIN doing. > >> Requiring valid POC information is the subject of a current policy > >> proposal, 2003-2. > >> > >> > > or one of my domain names? I'm not asking about the email address > >> > > ABUSE at domain, which is described in the RFC, I'm asking about > >> > > the Abuse > >> > > POC given in ARIN's WHOIS database. > >> > > >> > Good Point.. I guess my answer is let's push the POC Policy to get the > >> > POC's to a higher level of accuracy... > >> > >> Excellent, I understand your position now. > >> > >> > >> > > In summary, I am asking if there is a proposal to require > >> > > something more > >> > > than reachability for the Abuse POC. If there is, I am asking for > >> > > clarification, and whether this should be part of proposal 2003-1 or > >> > > a separate proposal. If there is no such proposal, then there is > >> > > no debate. > >> > > >> > Correction if there is no such proposal we need to create one... > >> > AND if it takes it, send the idea to the IETF.. > >> > >> Here's the text of 2003-2: > >> http://www.arin.net/policy/2003_2.html > >> Excerpt: > >> > >> 2. All networks should [regardless of geographical location] provide a > >> valid e-mail contact for network [NOC@] and abuse [Abuse@] contact. > >> Make it standard. > >> > >> It goes further to establish methods for verification and penalties for > >> non-compliance. Are your concerns addressed by this policy proposal, or > >> do you have a new policy to propose? > >> > >> > Jim > >> > >> Thank you for taking the time to discuss the policies. I must say that > >> it's good to see so much participation on the list; it definitely helps > >> clarify the proposals being considered at the meeting. > >> > >> > >> Lee > >> > >> > > From william at elan.net Thu Mar 6 16:12:30 2003 From: william at elan.net (william at elan.net) Date: Thu, 6 Mar 2003 13:12:30 -0800 (PST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: Message-ID: That was exactly my concern as well. Its one thing to tell that contact is supposed to be valid (which is actually easy to check - invalid contact is the one where email bounces or phone# is disconnected) but its another to say how ISP should setup their phone system so you could reach somebody. This kind of thing can be a recommendation, but I do not see it as being a policy requirement. However the current policy proposal is actually valid - it requires human POC and ARIN does see a difference in ther database and on templates between human and role contacts. So this is possible to implement as a policy, I'm just not sure if its a good idea. On Thu, 6 Mar 2003, Hyunseog Ryu wrote: > > > > > > Hi there, > > I missed some of emails regarding this thread because of my busy schedule. > So if I say same thing which other people said already, please forgive me. > ^.^ > > In my point, what will be the penalty for this policy? > And how does ARIN check this policy implementation? > Somebody from ARIN call POC every year - maybe renewal time for membership > fee - to check whether ARIN members are following this or not? > I believe this is a kind of ISP or Enterprise internal policy to keep their > contact point as current as possible. > I had some difficulty to reach somebody for ISP contact when I had some > security issue or something like that. > But if we do make policy for organization internal policy like this, we > will have policy after policy, and without mechanism to check whether > somebody is following this policy or not, I think this policy will be dead > policy, and that's not a good practice for overall policy concept. > > If we have something like similar policy for yellow page or website contact > information by FCC or some government agency for validation of contact > point information, I may think this might be good policy. > But I don't think this will be a good policy for everybody. > > Maintaining contact point to be reachable by ARIN Whois database will be > ISP's or End-user's responsibility, not ARIN's. > If we want to keep this as much as detailed, I believe it's enough to put > "recommendation" in ARIN's template to state this. > > Hyun > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Hyunseog Ryu / CCDA, MCSE, CCIE candidate(written test passed) > Senior Network Engineer/Applications Engineering > Norlight Telecommunications, Inc. > 275 North Corporate Drive > Brookfield, WI 53045-5818 > Tel. +1.262.792.7965 > Fax. +1.262.792.7733 > email: hryu at norlight.com > > > > william at elan.net > Sent by: To: Owen DeLong > owner-ppml at arin.n cc: ppml at arin.net, (bcc: Hyunseog Ryu/Brookfield/Norlight) > et Fax to: > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > > 03/06/2003 02:32 > PM > > > > > > > Ok, so to summarize you do not actually want human contact poc but want > human reachable via poc information. This I'm not sure is really up to > ARIN to tell their subscriber members how to setup their telephone system > or email server (comes again as operational issue), nor does there seem to > be clear way to test and punish if its not done so. > > Rather better would be to actually have policy that says they must have > valid contact (i.e phone# and email are valid and ARIN can send email and > get reply for example) and specify as recomendation that as an option it > must be possible to talk to somebody on the phone or get human response > (as recomendation it might well be ok). > > On Thu, 6 Mar 2003, Owen DeLong wrote: > > > Thanks for your comments. I hope to publish an amended draft which > should > > address most of your concerns. Please seem my inline comments below. > > > > > > --On Thursday, March 6, 2003 11:13 AM -0800 william at elan.net wrote: > > > > > I did not yet comments on 2003-1 and I'm not entirely made up my mind > > > yet, but I have to say I'v not been conviced by either side and I see > > > problems with it for both ISP that is listing its contacts and for > > > community itself that wants to use the contact info: > > > I. ISP > > > 1. Some companies have charn with their employees changing quickly > > > and some often change assignments/roles within companies, its > easier > > > to keep "role contact", its more up to date. > > > > Agreed. This wasn't so much about having a specific human contact (at > first > > I thought it was, but my position has changed some) as it is about having > > a contact which is: > > 1. A phone number that reaches a live human being > capable of > > resolving problems or getting the caller to > someone who can > > resolve their problem. Not an automaton or voice > jail. > > The human should only be required to be reachable > during > > normal business hours in the timezone applicable > to the POC > > address on file, although 24x7 is strongly > encouraged > > where practicable. > > > > and > > > > 2. An email address which, may send a receipt > acknolwedgement > > automatically, but which maintains a committment > that the > > received mail will be read by a human within 48 > hours of > > receipt. > > > > > 2. People do not like to be listed in public whois information because > > > they inevitibly begin to get contacted for issues not related to > > > do and called names, etc. > > > > Agreed. > > > > > 3. People do not like to be listed in public whois because that > > > information is harvested by advertisers. > > > > > > > I have a little less sympathy here, as I think we should be working > harder > > to prosecute this type of violation in the harvesting. > > > > > II. Contact to ISP > > > 1. If person is not available and its the only contact listed (as its > > > the only contact required!), you have a real problem. > > > > It is _NOT_ the only contact required. The standard requirements for > > Tech and Admin contacts remain. This contact could either be one of > them, > > or could be an additional contact. The requirement is to list at least > > one admin or tech contact. I believe it is possible to list multiple > > contacts in any category. In the amended proposal, I will suggest the > > creation of a category of ABUSE contact, with the requirement that it > > be possible to: > > > > 1. List multiple ABUSE contacts > > 2. The contact should have a Comment Field which can > be used > > to specify types of abuse handled by a particular > contact. > > > > Further, at least one ABUSE contact should list a phone number which, > during > > normal business hours in the timezone applicable to the address listed on > > said POC is answered by one or more live human beings capable of > addressing > > network abuse. Further, that contact's Comment field should contain the > > phrase "Live Contact" followed by the hours in 24hr format with timezone, > > such as "Live Contact 0800-1700 US/Pacific Time". The timezone should > > be a POSIX timezone name. > > > > > 2. For emergency situation its a lot more important to reach ANYBODY > in > > > the say tech support or NOC then particular somebody. > > > > Yes, and as such, it's important that at least one contact in the > database > > allow you to do exactly that, rather than a voice jail or a bouncing > auto- > > responder. > > > > > 3. Human contacts are not available 24/7, role contacts are sometimes > > > (same as #2 really) > > > > > Same answer as 2. > > > > > I do think its important to keep correct reachable info for at least > one > > > contact and most likely both abuse and noc if they are listed (as is > with > > > 2003-2), though 2003-2 I'll not support in its current form - it goes > way > > > way too far on the abuse prevention (I guess I'm moderate...) and to > > > actions ARIN can not do (like control over routing table). > > > > > I agree. I like most of the intenet of 2003-2, but I think the majority > > of it is more of an IETF subject than an ARIN topic. However, as it > relates > > to contacts, I'd like to find a common ground that allows Dr. Race and I > > to say there is a contact-related proposal we both support and feel > > addresses > > the issues within the scope of ARIN. > > > > > In all, human contact does not hurt, but only as option to be decided > by > > > ISP and not necessarily as the only option of contact. I think new > > > redisign of the database, solves most of it allowing multiple contacts > to > > > be listed as ISP desires (instead of only one contact as it was > before). > > > And its my understand (please correct me if I'm wrong, I'v not see it > > > yet in real whois output yet!) that you can have multiple TECH, ABUSE, > > > NOC contacts for the same ORG or NET, allowing for both human and role > > > contacts if ISP wants to do so. > > > > > It was never intended as the only option of contact. It was intended to > > require that AT LEAST ONE POC be listed that is not handled through > purely > > automatic means. (Who do you call when the automatic systems you call to > > report something broken are what's broken?) That is the primary intent > > behind this policy. > > > > I believe you are correct about the multiple contacts. That is why this > > policy was worded with "At least one" and not "The...". > > > > Thanks again, > > > > Owen > > > > > On Thu, 6 Mar 2003, Lee Howard wrote: > > > > > >> On Thu, 6 Mar 2003, McBurnett, Jim wrote: > > >> > > >> > Date: Thu, 06 Mar 2003 14:46:38 -0500 > > >> > From: "McBurnett, Jim" > > >> > To: Lee Howard > > >> > Cc: ppml at arin.net > > >> > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact > > >> > > > >> > > > >> > > pick an IP address, look up the ARIN record for that IP address, > and > > >> > > report it to the Abuse POC given in ARIN's records. Only the > latter > > >> > > case is on topic for ARIN PPML. > > >> > > > >> > The later PPML topic is the one that confuses me sometimes, and > hence > > >> > the RFC ignorant. A few ISP's I have been spammed from > > >> > don't accept abuse@ secuirty@ etc.. And the ARIN POC is often > > >> > inaccurate for the people on > > >> > purpose. And as of late, many spammers are forging most of the > header > > >> > anyway.... > > >> > > >> Somewhat separate issues, still, I think. > > >> Enforcing ABUSE at domain isn't something I can imagine ARIN doing. > > >> Requiring valid POC information is the subject of a current policy > > >> proposal, 2003-2. > > >> > > >> > > or one of my domain names? I'm not asking about the email address > > >> > > ABUSE at domain, which is described in the RFC, I'm asking about > > >> > > the Abuse > > >> > > POC given in ARIN's WHOIS database. > > >> > > > >> > Good Point.. I guess my answer is let's push the POC Policy to get > the > > >> > POC's to a higher level of accuracy... > > >> > > >> Excellent, I understand your position now. > > >> > > >> > > >> > > In summary, I am asking if there is a proposal to require > > >> > > something more > > >> > > than reachability for the Abuse POC. If there is, I am asking for > > >> > > clarification, and whether this should be part of proposal 2003-1 > or > > >> > > a separate proposal. If there is no such proposal, then there is > > >> > > no debate. > > >> > > > >> > Correction if there is no such proposal we need to create one... > > >> > AND if it takes it, send the idea to the IETF.. > > >> > > >> Here's the text of 2003-2: > > >> http://www.arin.net/policy/2003_2.html > > >> Excerpt: > > >> > > >> 2. All networks should [regardless of geographical location] provide > a > > >> valid e-mail contact for network [NOC@] and abuse [Abuse@] contact. > > >> Make it standard. > > >> > > >> It goes further to establish methods for verification and penalties > for > > >> non-compliance. Are your concerns addressed by this policy proposal, > or > > >> do you have a new policy to propose? > > >> > > >> > Jim > > >> > > >> Thank you for taking the time to discuss the policies. I must say > that > > >> it's good to see so much participation on the list; it definitely > helps > > >> clarify the proposals being considered at the meeting. > > >> > > >> > > >> Lee > > >> > > >> > > > > From jmcburnett at msmgmt.com Thu Mar 6 19:23:15 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Thu, 6 Mar 2003 19:23:15 -0500 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <390E55B947E7C848898AEBB9E5077060750AF2@msmdcfs01.msmgmt.com> See Inline--- > Hi there, > > In my point, what will be the penalty for this policy? > And how does ARIN check this policy implementation? > Somebody from ARIN call POC every year - maybe renewal time > for membership > fee - to check whether ARIN members are following this or not? Suggestion: A new template that is parsed automatically at a complaint template. When this template is parsed the ARIN member can not renew if there has been a complaint or X number or complaints within the year, if this is made so they will fix it. To inform all of this setup the header response to a whois query like this: ==================== ARIN Policy 2003-1 outlines requirements that the POCs be up to date so that legitimate use of WHOIS data to reach an organization can occur in a timely and efficient manner. Should contact attempts be made to this organization via email result in SMTP bounces,non-delivery-reports, or if the organization is completely non-responsive after 72-96 hours please send the message or complaint to WHOISABUSE at arin.net as explained at http://policies.abuse.arin.net/templates/whoisabuse.html If telephone calls or faxes provide similiar problems identify this problem via the same template. ======================== Owen, Maybe this should be added??? > I believe this is a kind of ISP or Enterprise internal policy > to keep their > contact point as current as possible. Today, via their whois data, I was able to IMMEDIATELY contact someone when I got a high volume of the SLAMMER virus hitting one of my remote sites' firewall. If this company, was not responsible then what would do? contact their ISP and pray? I did before I called them, the ISP put me to voice mail jail. This is the point. We as an organization need a policy that says : Don't lie to me about contact info, give it to me or ............... As you put it, this is their responsibilty and we should let them handle it and we (ARIN) as an organization can not correct their lack of attention to WHOIS? If I was maintaining a database for customers, (HMM ARIN is..) I would want it to be correct. besides how does ARIN bill the customer.. There are more issues here than just a policy... > Maintaining contact point to be reachable by ARIN Whois > database will be > ISP's or End-user's responsibility, not ARIN's. > If we want to keep this as much as detailed, I believe it's > enough to put > "recommendation" in ARIN's template to state this. Following that assumption, should we assume that 90% will do what is right most of the time and not cause problems. While I have said you always have the 10% bad apple gang, in this realm I would not count the incorrect POCs as bad apples, but as ignorant apples... While I don't agree with all the policies listed here at the below website, I sure like a few of them. www.rfc-ignorant.com Snipped for length... Jim From jrace at attglobal.net Thu Mar 6 23:28:53 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Fri, 07 Mar 2003 11:28:53 +0700 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact Message-ID: <200303070429.h274TDJW038574@smtp1.arin.net> On Thu, 6 Mar 2003 16:49:13 -0600, Hyunseog Ryu wrote: >But if we do make policy for organization internal policy like this, we >will have policy after policy, and without mechanism to check whether >somebody is following this policy or not, I think this policy will be dead >policy, and that's not a good practice for overall policy concept. It can easily be automated and this has been covered earlier in the thread but you may have missed it as you said; I retain the posts if you wish me to resend. However the MAIN POINT is that the RIRs have to respond to complaints. Some now do, and some don't, and some respond to complaints about bad data but refuse to respond to complaints about enabled role accounts which fail to operate ("Mail to refused; mailbox is full"; retry postmaster, receive error "Mail to is refused; mailbox is full".) The thrust of the proposal is the operator most follow the rules detailing operational contact; if he doesn't follow the rules, he loses his IP address (eventually). It's common sense, really. If you are a parent you know how it works: "You were driving drunk last night; I am taking away the keys to the car." Jeffrey Race From Michael.Dillon at radianz.com Fri Mar 7 05:06:52 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 7 Mar 2003 10:06:52 +0000 Subject: [ppml] Policy Proposal 2003-5: RWhois Server Use Requirements Message-ID: > But some of the ISP's who > have selected to use RWhois servers for their reassignment information > have not kept the servers operational 24x7, contents of the database up > to-date, or are restricting access only to ARIN staff. This may well be true but trying to fix it by creating a policy is like trying to fix a gangrenous wound by using a sledgehammer. You may have some impact but it will not result in a healthy solution. The fact is that rwhois was a crude hack that should have only been temporary. There is only one source code implementation for an rwhois server and it is mostly undocumented. There is virtually no reason for anyone to spend time tinkering with an rwhois server once it is set up and running therefore there is no opportunity for people to develop expertise. As a result nobody trusts rwhois and that is one reason why it gets set up with ARIN-only access. Changing policy will not address the security issue. Virtually no-one outside of ARIN and a few old-time ISP folks make use of rwhois. Therefore there is little incentive to set it up as a publicly accessible service and that also is not something that can be changed by policy. Policies won't create a public demand for rwhois. On the other hand, there is a large and growing public demand for the type of information that is served up by rwhois. So there is good reason, outside of ARIN's need for data, to fix this situation. As I have said in the past, the solution lies in migrating away from the obsolete rwhois protocol and server towards the IETF standard directory service protocol, namely LDAP. I know that the CRISP working group http://www.ietf.org/html.charters/crisp-charter.html is also looking at developping a new protocol, IRIS, but I tend to take the pragmatic view that we in the ARIN community should not be reinventing wheels when a perfectly suitable wheel already exists that we can use. The rwhois schema can easily be translated into an LDAP schema and I suggest that ARIN should do this and publish it. ARIN should also set up an LDAP server using openLDAP http://www.openldap.org and serve up a copy of the existing whois data through that server. This is not rocket science and can leverage most of the technical work that was done in converting to the new database structure. LDAP is just a protocol for providing public access to a set of defined data that is usually stored and managed using other technology. ARIN should also accept LDAP v3 (referral LDAP) as a valid way for companies to supply addressing data as soon as they have published the LDAP/rwhois schema. And ARIN should also apply to the IANA for a port number assignment for LDAP used in this fashion so that we can easily transition by simply implementing an LDAP server on the same hardware as existing rwhois servers in a parallel fashion. None of this stuff needs any public policy setting although I think it would be healthy for a public discussion so that ARIN can see broad support for bring ARIN's external technical infrastructure up to modern standards. This includes getting rid of email templates and implementing web-based forms to replace them. --Michael Dillon From Michael.Dillon at radianz.com Fri Mar 7 05:20:58 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 7 Mar 2003 10:20:58 +0000 Subject: [ppml] Signing the Public DNS Root - Discussion at ARIN XI Message-ID: >:The proposal states the requirements of the RIRs would be to: > * establish a secure out-of-band communication path in > collaboration with the signing operators which will be used > for authenticated exchange of the unsigned keyset. > * periodically generate strong keys using a good random number > generator > * manage their keys (i.e. use them for signing the operator > keyset and keeping the private key appropriately secret) Sounds like another good reason for ARIN technical folks to get up to speed on running LDAP servers. > Is this a task that should be performed by ARIN? Definitely yes. When IPv6 is widely deployed there will be a lot less address allocation activity which will lead to the RIRs withering and dying (or consolidating into one global IR). Unless, of course, there are tasks that the RIRs can take on which are useful to the Internet community. Since the core function of an RIR is to provide a single authoritative source for bits of Internet infrastructure information, this task is 100% on target. IP addresses and AS numbers and DNS signing keys are all the same. They are all pieces of Internet infrastructure information that need to be available from an authoritative source. May I suggest, that in preparation for the Memphis meeting, ARIN management should give some thought towards a roadmap document for ARIN's future that incorporates various known events even if we don't know the timing. For instance DNSSEC is one, IPv6 is another. I would stretch this to include some sort of PKI as well as some sort of mail server authentication. This assumes that the day will come when there is widespread need for electronic signatures and therefore a need for some organization to manage the top levels of the authority hierarchy for these. And it also assumes that we will replace unsecured SMTP with an alternative email channel based on an authority hierarchy that provides a form of email callerID. This would require email servers to defer to an authoritative source, like ARIN, to authenticate other email servers. --Michael Dillon From spammaster at spamx.com Fri Mar 7 13:25:42 2003 From: spammaster at spamx.com (spammaster) Date: Fri, 07 Mar 2003 11:25:42 -0700 Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: <2147483647.1046956961@imac-en0.delong.sj.ca.us> Message-ID: > In the amended proposal, I will suggest the > creation of a category of ABUSE contact, with the requirement that it > be possible to: > > 1. List multiple ABUSE contacts > 2. The contact should have a Comment Field which can be used > to specify types of abuse handled by a particular contact. > > Further, at least one ABUSE contact should list a phone number which, during > normal business hours in the timezone applicable to the address listed on > said POC is answered by one or more live human beings capable of addressing > network abuse. Further, that contact's Comment field should contain the > phrase "Live Contact" followed by the hours in 24hr format with timezone, > such as "Live Contact 0800-1700 US/Pacific Time". The timezone should > be a POSIX timezone name. This is the best idea and one that, I believe addresses the primary concern of the entire proposal - It does not have to be a "human being's address" but one to which mail sent [particularly complaints of spamming] will be _read_ by a human being and within a short amount of time i.e. abuse at domain.tld and this, as some minimum, needs to be a requirement. There should also be a requirement that there shall be a working "abuse at domain.tld" address as is applied to the "postmaster" address specified by RFC822. From jlewis at lewis.org Fri Mar 7 14:16:05 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Fri, 7 Mar 2003 14:16:05 -0500 (EST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: Message-ID: > > Further, at least one ABUSE contact should list a phone number which, during > > normal business hours in the timezone applicable to the address listed on > > said POC is answered by one or more live human beings capable of addressing > > network abuse. Further, that contact's Comment field should contain the > > phrase "Live Contact" followed by the hours in 24hr format with timezone, > > such as "Live Contact 0800-1700 US/Pacific Time". The timezone should > > be a POSIX timezone name. That every network has a static schedule for when people are available for phone calls to handle abuse issues would be a bad assumption. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From william at elan.net Fri Mar 7 12:25:40 2003 From: william at elan.net (william at elan.net) Date: Fri, 7 Mar 2003 09:25:40 -0800 (PST) Subject: [ppml] Signing the Public DNS Root - Discussion at ARIN XI In-Reply-To: Message-ID: I agree what you say here about the future (except ipv6 - need for new ipv6 distribution would still exist even in far future) and what ARIN needs to do. But ARIN is generally slow, so lets just keep our focus and do dnssec for root first and then move to PKI next (which actually has been discussed slightly on San Francisco meeting a two year ago and in Las Vegas a year ago as well). In the end if we got all the things you mention (DnsSec, PKI, ipv6, LDAP CRISP) started by 2010, I'll actually be quite happy :) Oh, regarding LDAP, considering current arin situation, I'll try to do it all on my own and mirror ARIN data and provide it through CRISP (which is actually LDAP) protocol. I'll have presentation ready for next meeting after Memphis. If people like it, I'm sure we can encorage ARIN to do the same and in the end they will when CRISP begins to be deployed. On Fri, 7 Mar 2003 Michael.Dillon at radianz.com wrote: > >:The proposal states the requirements of the RIRs would be to: > > * establish a secure out-of-band communication path in > > collaboration with the signing operators which will be used > > for authenticated exchange of the unsigned keyset. > > * periodically generate strong keys using a good random number > > generator > > * manage their keys (i.e. use them for signing the operator > > keyset and keeping the private key appropriately secret) > > Sounds like another good reason for ARIN technical folks to get up to > speed on running LDAP servers. > > > Is this a task that should be performed by ARIN? > > Definitely yes. When IPv6 is widely deployed there will be a lot less > address allocation activity which will lead to the RIRs withering and > dying (or consolidating into one global IR). Unless, of course, there are > tasks that the RIRs can take on which are useful to the Internet > community. > > Since the core function of an RIR is to provide a single authoritative > source for bits of Internet infrastructure information, this task is 100% > on target. IP addresses and AS numbers and DNS signing keys are all the > same. They are all pieces of Internet infrastructure information that need > to be available from an authoritative source. > > May I suggest, that in preparation for the Memphis meeting, ARIN > management should give some thought towards a roadmap document for ARIN's > future that incorporates various known events even if we don't know the > timing. For instance DNSSEC is one, IPv6 is another. I would stretch this > to include some sort of PKI as well as some sort of mail server > authentication. This assumes that the day will come when there is > widespread need for electronic signatures and therefore a need for some > organization to manage the top levels of the authority hierarchy for > these. And it also assumes that we will replace unsecured SMTP with an > alternative email channel based on an authority hierarchy that provides a > form of email callerID. This would require email servers to defer to an > authoritative source, like ARIN, to authenticate other email servers. > > --Michael Dillon > From lee.howard at wcom.com Fri Mar 7 14:36:52 2003 From: lee.howard at wcom.com (Lee Howard) Date: Fri, 7 Mar 2003 14:36:52 -0500 (EST) Subject: [ppml] Policy Proposal 2003-1: Human Point of Contact In-Reply-To: Message-ID: I think this thread has already been ravelled, but . . . On Fri, 7 Mar 2003, JLS wrote: > Date: Fri, 07 Mar 2003 11:56:19 -0700 > From: JLS > To: Lee Howard > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2003-1: Human Point of Contact > [. . .] > > If this is your proposal, how do you propose to assign domain names to > > network assignments? If 172.16.0.0/16 is allocated to Acme Holdings, > > who operates under the domain name acme.com, acme.net, acme.com.ca, > > acmeholdings.com, and explodinganvil.mil, which domain will you require > > to be on the Abuse POC? > > When one looks up the domain assigned to the specific IP address in question > the proper TLD is returned and there needs to be the requirement that a > working abuse@ address be active for that domain. What do you mean "the domain assigned to the specific IP address"? abuse at in-addr.arpa. ? > Internal aliases are fine just as long as the individual who is more than > likely unaware of any ISPs internal aliasing scheme can reach the POC > through the standard abuse at domain.tld address. Fair enough. So an organization may list any address it wishes for its ARIN Abuse POC, but must have ABUSE at everydomain enabled as well. > > I've said before that I don't mind people using UUNET or WorldCom as > > examples, positive or negative, in discussions on this list or at public > > meetings. My only request is that the example be used to support or > > argue ARIN-related matters, and not as venues to air grievances. If > > you have a beef with me or the company I work for, email me privately > > so the rest of the people on this list who are trying to get some work > > done don't have to be involved. > > Specific examples often serve to illustrate the need for standardization. Agreed, and I'll leave it there. Lee From woody at pch.net Sun Mar 9 08:59:29 2003 From: woody at pch.net (Bill Woodcock) Date: Sun, 9 Mar 2003 05:59:29 -0800 (PST) Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: Message-ID: On Mon, 3 Mar 2003, John Curran wrote: > At 4:35 PM -0800 3/3/03, David Kessens wrote: > >What we really need is a global policy platform. The current policy > >process doesn't scale and the real cause of different policies is lack > >of communication between the different regions. The problems that we > >have with certain policies are not at all unique to our region - > >having attended many of the different regions policy meetings, I see > >the same problems (and simular but not the same solutions) coming up > >in the different regions. > I think we all see this happening, but it's hard keep things in sync between > the regions when the members take different stands on how to solve the > same problems. It's very common for RIPE or APNIC's policies on a given > situation to come up during discussion at the members meeting, but that > doesn't always lead to our members taking the same approach. > If folks feel strongly about tighter inter-RIR coordination of policy formation, > that would be a great item to raise in Memphis. If there's a consensus for > tighter coupling with the other RIRs, I'm certain the ARIN AC would heed it. David, I think you and I should do exactly as John suggests, and bring it up at the meeting. I think what I saw at the Las Vegas meeting was that the membership were happy to view harmonization as a strong criterion, but then everything went amok on the PPML list, where just a few people decided to second-guess the membership vote, and the process didn't take that possibility into account. I've talked with Scott about it, and he's said he'll attempt to address it in the process overhaul he's drafting. -Bill From woody at pch.net Sun Mar 9 09:08:22 2003 From: woody at pch.net (Bill Woodcock) Date: Sun, 9 Mar 2003 06:08:22 -0800 (PST) Subject: [ppml] RIR shopping -- AND MORE In-Reply-To: Message-ID: On Sun, 2 Mar 2003, Randy Bush wrote: > i think you (not sure about arin actually) pay too much attention to > defending against all us nasty lying members. i think that address > allocation policies affect the *global* routing tables, and inter-rir > coordination on policy is very important. I tend to agree, and tend to favor simplification, decriminalization, and harmonization, probably in that order. Simplification: I don't think that a profusion of very-specific rules which are intended to proscribe the behavior of both the members and the IP analysts actually benefit us. It's getting quite bad in both the ARIN and RIPE regions. Decriminalization: Any rules which most members have to circumvent, or which are unenforceable, probably shouldn't be on the books. There's no sense in having an organization of people who are united principally by their failure to abide by the rules of the organization. Harmonization: There are four, and Murphy willing, will be five RIRs. There is a growing class of operators who have to operate in all regions. If all of the RIRs run around creating wildly divergent policy, as has been happening lately, it becomes a terrible mess to manage. Since we have to abide by an RIR's subdelegation policies with respect to customers in that region, we now have to have divergent _internal_ policies with respect to otherwise-identical customers, or even with respect to _different offices of the same customer_. That's abhorrent. -Bill From Michael.Dillon at radianz.com Mon Mar 10 05:41:26 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 10 Mar 2003 10:41:26 +0000 Subject: [ppml] RIR shopping -- AND MORE Message-ID: > Simplification: I don't think that a profusion of very-specific rules > which are intended to proscribe the behavior of both the members and the > IP analysts actually benefit us. Say that again Bill!!! Loud and strong. 95% of the policy discussions have been about building complex processes to deal with some obscure issue without even addressing why we want to do it. We badly need to overhaul all of the ARIN policies to make them simple, clear, and relevant. This is especially important because there is no longer a common culture among the majority of network operators which means we can no longer leave things unsaid and just assume that they are "understood". --Michael Dillon From memsvcs at arin.net Mon Mar 10 10:43:52 2003 From: memsvcs at arin.net (Member Services) Date: Mon, 10 Mar 2003 10:43:52 -0500 (EST) Subject: [ppml] The last day to book hotel rooms for ARIN XI is Friday, March 14th. Message-ID: Time is running out! If you haven't registered for ARIN XI in Memphis, it's time to get involved. For those who have already registered, time is also running very short to book hotel rooms at our host hotel! The Peabody Memphis has a limited number of rooms reserved for our meeting. These rooms are being held until Friday, March 14th, so book now by calling the Peabody Memphis at 1-800-PEABODY. To register for ARIN XI, please visit our website: http://www.arin.net/ARIN-XI/index.html ARIN graciously thanks both NASA and Comcast for sponsoring portions of ARIN XI. As part of their sponsorship, NASA will be supplying the network connectivity, and will also be setting up and managing the wireless network. Comcast will be sponsoring this year's social event at BB King's, and sponsoring the audio-visual requirements in Memphis! We are still accepting sponsorship offers for the terminal room/learning center, as well as the continental breakfasts and lunches during the meeting. For more information about the meeting as well as sponsorship opportunities, contact Edward Pizzarello, ARIN Event Coordinator, at (703) 227-9878 or memsvcs at arin.net. ARIN Member Services From owen at delong.com Mon Mar 10 20:06:07 2003 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Mar 2003 17:06:07 -0800 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact In-Reply-To: <200303041636.LAA26902@ops.arin.net> References: <200303041636.LAA26902@ops.arin.net> Message-ID: <2147483647.1047315965@dhcp156-251.corp.tellme.com> There has been some good discussion and feedback in response to proposal 2003-1. As a result, I have pretty much rewritten the proposal. What little remains of the original proposal is prefixed with "> " quoting. Hopefully, this new version, which I offer as a proposed amendment, will address the original issue and most of the feedback I have received. I hope to further refine this so that we can go into the public policy meeting with rough consensus around a policy which will facilitate significant improvement around this issue. Owen > Policy Proposal 2003-1a: Required Performance of Abuse Contact > > 1. Statement of proposed Policy: > For the purposes of this policy, the following terms shall apply: ORG An organization or organizational unit which receives one or more resources from ARIN, whether by allocation or assignment. In either case, the ORG in question shall bear full responsibility under this policy for meeting the requirements thereof and bearing any consequences of failure to meet said responsibilities. This shall apply to the ORG to which ARIN directly allocated the resource, or to another ORG, which, has received from the previous ORG a transfer of the resources under ARIN's transfer policies. A simply SWIP of an assignment to an ORG which does not have a contractual relationship with ARIN shall not constitute such a transfer. MAINTAINER The appointed POC units which have authority and access to make changes to the ARIN held data regarding a resource owned by a particular ORG. POC A point of contact, whether human or role. ABUSE CONTACT This policy makes no effort to define Abuse. It is the opinion of the author of this policy that such a definition should come from the IETF and not from ARIN. It is the intent of this policy to set standards for the response required from an abuse contact without addressing the actions required by said contact. Again, it is the opinion of the author that said actions are outside of ARIN's scope and belong within the IETF. An ABUSE contact is a POC for an ORG which is associated with an ARIN issued resource as the POC responsible for addressing issues of abuse originating at or from the resource in question. RESOURCE In the case of ARIN, resources currently include ASNs and IPV4 and IPV6 address ranges which are allocated or assigned to registered ORGs. ASN An autonomous system number IPV4 Internet Protocol Version 4 IPV6 Internet Protocol Version 6 Proposed Policy For any given RESOURCE in the ARIN database, ARIN shall require at least one and allow multiple ABUSE CONTACTS to be listed. For at least one ABUSE CONTACT in each resource, ARIN shall require and maintain at least the following information: 1. Individual or Role 2. If Individual, full name 3. Address valid for Legal Service Must support physical delivery, registered mail, or both, and shall indicate which is acceptable. 4. Email Address. 5. A list of "normal business hours" specified in terms of the time zone applicable to the address in item 3 or in UTC, with an indication of whether DST should be considered. These hours should comprise at least 30 hours per week. 6. A phone number 7. A URL where the ORG maintains a web site listing it's ABUSE POLICIES. Each ORG shale be required to meet the following standards with respect to the performance and responsiveness of the required ABUSE CONTACT, and each ABUSE CONTACT which contains all of the data specified above. In cases where the language cannot be logically applied to a ROLE account, it shall mean all individuals assigned by the ORG in question to read the email or answer the phone calls to the addresses/numbers listed in the ABUSE CONTACT. 1. With the exception of sudden events of large call volume, shall staff adequately to have live humans answer calls to the listed abuse contact phone number during the hours indicated in the contact record. 2. Shall have a human being read and respond to abuse complaints received by email within 48 hours of receipt (for complaints received Sun-Thu), and, within 96 hours for complaints received Fri-Sat. 3. Shall be capable of taking action or immediately contacting a person capable of taking action to stop any reported abuse which is in violation of any of the following: A. Any definition of network abuse published by the IETF. (This shall not be construed to include any minor failure to comply with an RFC, but shall only apply to things the IETF has specifically defined as abuse). B. Any definition of network abuse determined by the ORG to be abuse in any of their own published AUPs. C. Any definition of network abuse which meets all of the following criteria: 1. Is defined as abuse in a policy published on the complaining networks ABUSE CONTACT URL. 2. Can be defined in terms that would allow most routers to block the abuse in question through the use of packet filters or other commonly available technology. (Commonly available technology for this purpose means a feature that is present and can be reasonably implemented in the majority of backbone router types in use on the Internet at the time of complaint.) 3. Is not a standard response to traffic being received from the complaining network. 4. Shall take appropriate action to stop abuse identified in the previous item as soon after receiving the complaint as practicable. 5. Shall respond to the complaint as soon as practicable with information on what actions are being taken to stop the abuse. Further, if an entity believes an ORG is not living up to the requirements set forth in this policy, they should be able to notify ARIN of the issue, including detailed documentation of the efforts made to contact the ORG and the results thereof. Any complaint received by ARIN which does not include the required information should receive only a form-reply from ARIN indicating what information is required to verify the complaint. In the event of a valid complaint, ARIN shall attempt to contact the ORG in question and notify them of the complaint. If ARIN is able to contact the ORG in question, ARIN should wait two weeks and contact the complainant. If the complainant is satisfied, no further action is required by ARIN. If the complainant is not satisfied, ARIN staff shall make a determination whether the complaint meets the definitions of abuse in 3 above. Further, the ARIN staff shall make a determination if the response and actions taken by the ORG in question meet the requirements of the policy. If the ARIN staff determines that the complaint meets the requirements and that the response of the ORG in question has not met the requirements of this policy, the ARIN staff shall inform the ORG of these facts, specifically indicating what additional response and/or action is necessary to comply. The ORG shall then have 5 business days or a longer reasonable time as determined by the ARIN staff to comply. If the ORG remains out of compliance, then the ARIN staff shall revoke each and every specific resource listed in the complaint and determined to be out of compliance with this policy. If a resource is revoked under this policy, it shall be referred to the ARIN ABUSE COUNCIL for final determination. The ORG in question shall have 30 days to present their side of the issue to the council in written form via email. The ORG in question may at any time prior to the 30 days indicate that they have submitted all desired information and terminate the 30 day period 24 hours after sending that email. After the 30 days has expired or the ORG has terminated the 30 day period as described, the ABUSE COUNCIL shall have 10 days to make a final determination on the revocation. The ABUSE COUNCIL may affirm the revocation, in which case, it becomes permanent. The ABUSE COUNCIL may overturn the revocation, in which case, the resources are to be immediately returned to the ORG in question. The ABUSE COUNCIL may decide to grant the ORG in question an extension for compliance. In that case, the council shall set a date by which the ORG must comply. The resource(s) will be immediately returned to the ORG in question. If, at the date in question, the ORG is determined by ARIN staff to still not be in compliance, the resources shall again be revoked. The ORG may again appeal this decision to the ABUSE COUNCIL as described. The ARIN BOARD shall nominate candidates to participate in the ABUSE COUNCIL. The ABUSE COUNCIL shall have 5 members. Each member shall be for a 2 year term. The first time, 3 members shall have 2 year terms, and 2 shall have 1 year terms. The ARIN BOARD shall nominate not less than two, nor more than three times the number of vacant seats. In the first election, the three candidates receiving the most votes shall be elected for 2 years. The community at large shall be allowed to vote, similar to the ASO AC election process. The election shall be conducted as a "Vote for no more than N" where N is the number of available seats (5 the first time, 2 the following year, 3 the year after, and so on). The ABUSE COUNCIL shall not be required to conduct physical meetings, and there shall be no compensation paid to the ABUSE COUNCIL by ARIN. If a complaint comes up against an ORG to which an ABUSE COUNCIL member has ties which could create a conflict of interest, then that members place on the ABUSE COUNCIL shall be filled by a member of the ARIN BOARD chosen at random with respect to that specific complaint. The ARIN BOARD shall serve as the ABUSE COUNCIL until such time as one can be elected. In no event shall there be less than 30 days from the public release of all candidates statements and nominations to the close of the voting. The ARIN BOARD shall set the annual election date, and shall nominate candidates each year at least 60 days prior to the election date. Voting shall be conducted for not less than 30 days leading up to the election date. The ABUSE COUNCIL changes shall take effect 5 days after the election date. > 2. Argument for the proposal and general discussion of the issue. > > Issue: When trying to resolve issues of abuse, three things are important: 1. Being able to pass the abuse information along to a meaningful contact at the originating ORG. 2. The originating ORG taking appropriate action to stop the abuse. 3. Meaningful contact from the originating ORG explaining what was done. Many ORGs today have built elaborate automated systems for handling abuse complaints. It is not uncommon for these systems to fail to meet items 1 and 2 above. It is almost unheard of for them to meet item 3. It is time for us to move the Internet beyond the idea that the victims of abuse should just have to accept those costs as part of being connected. The organizations where abuse originates must be required to address abuse originating from resources within their responsibility. > > Argument in favor: > When an automated system fails, it becomes important to be able > to reach a human being capable of intervening or contacting > an intervener. It is OK if the POC information (address, > phone number, etc.) is a work number, or NOC, or even a > switchboard, as long as it is a point of contact which leads > to a real person with some ability to close the loop. It does not have to lead to a specific real person, but it must be possible to engage human intervention through this process. > > Problems: Most of the objections to the original version of this policy represented the need for ROLE accounts and the desire not to release personal information. I think this amended proposal addresses both of those concerns. Other concerns raised were the definition of abuse. While this policy does not define abuse, I think it provides decent metrics for determining abuse through the IETF and through each networks AUP. Further, it shifts the definition of abuse to the perspective of the receiving network, allowing each network to define what traffic they are willing to accept in a public and accessible manner. Further, it avoids overly burdensome definitions of abuse by only requiring originating ISPs to take action to stop abuse if the policy defines abuse in terms which reasonably allow the ISP to configure that definition into their routers to prevent the origination of such abuse, and, then, only after the abuse has occurred and generated a complaint. > 3. Proposed timetable for implementation: > > Once this proposal is ratified, ARIN should update it's registration > services agreement to reflect the new policy within 30 days. Existing > ORG and other bodies should receive notification of the change and the > requirement to comply during that same period. They should be required > to comply within 90 days of the date the notification is sent to the > existing ADMIN-C. > > After that time has elapsed, ARIN staff should be expected to investigate > and take further appropriate action on any complaint received about lack > of appropriate ABUSE CONTACT(s) in any resource record. > > Appropriate action is left to the discretion of the ARIN AC, but should > include ARIN staff contacting the ORG in question by any means reasonably available to ARIN, and, possibly revoking resources found to be out of compliance. > From jmcburnett at msmgmt.com Mon Mar 10 20:24:18 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Mon, 10 Mar 2003 20:24:18 -0500 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact Message-ID: <390E55B947E7C848898AEBB9E507706041E48E@msmdcfs01.msmgmt.com> Ok - I think I like this as written.. BUT-- Am I understanding this correctly: SWIP Process and ORG-- If an organization has been SWIPd a Class C and their Upstreams allow them to use Private ASN for the advertising of said Class C- That ORG is not an ORG according to this Policy? I am not saying this happens, but unless ARIN directly gives the Resource to the user, does this apply to them? I am thinking of a SPAMMER in S Fla..... The IP block is not SWIPPED to them and they have no ASN and don't seem fit this... Not a problem for me.. I want to make sure we address ARIN Resposible ORGs and not every JOE.. (we just can't do that) Jim > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, March 10, 2003 8:06 PM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2003-1a: Required Performance of > Abuse Contact > > > There has been some good discussion and feedback in response > to proposal > 2003-1. > > As a result, I have pretty much rewritten the proposal. What > little remains > of the original proposal is prefixed with "> " quoting. > Hopefully, this new > version, which I offer as a proposed amendment, will address > the original > issue > and most of the feedback I have received. I hope to further > refine this so > that we can go into the public policy meeting with rough > consensus around > a policy which will facilitate significant improvement around > this issue. > > Owen > > > > Policy Proposal 2003-1a: Required Performance of Abuse Contact > > > > 1. Statement of proposed Policy: > > > For the purposes of this policy, the following terms shall apply: > > ORG An organization or organizational unit which receives > one or more > resources from ARIN, whether by allocation or > assignment. In either > case, the ORG in question shall bear full responsibility under > this policy for meeting the requirements thereof and bearing > any consequences of failure to meet said responsibilities. > > This shall apply to the ORG to which ARIN directly allocated the > resource, or to another ORG, which, has received from > the previous > ORG a transfer of the resources under ARIN's transfer policies. > A simply SWIP of an assignment to an ORG which does not have > a contractual relationship with ARIN shall not constitute such > a transfer. > > MAINTAINER > The appointed POC units which have authority and access to make > changes to the ARIN held data regarding a resource owned by a > particular ORG. > > POC A point of contact, whether human or role. > > ABUSE CONTACT > This policy makes no effort to define Abuse. It is the opinion > of the author of this policy that such a definition should come > from the IETF and not from ARIN. It is the intent of > this policy > to set standards for the response required from an abuse contact > without addressing the actions required by said contact. Again, > it is the opinion of the author that said actions are outside > of ARIN's scope and belong within the IETF. > > An ABUSE contact is a POC for an ORG which is associated with an > ARIN issued resource as the POC responsible for > addressing issues > of abuse originating at or from the resource in question. > > RESOURCE > In the case of ARIN, resources currently include ASNs and IPV4 > and IPV6 address ranges which are allocated or assigned to > registered ORGs. > > ASN An autonomous system number > > IPV4 Internet Protocol Version 4 > > IPV6 Internet Protocol Version 6 > > Proposed Policy > > For any given RESOURCE in the ARIN database, ARIN shall > require at least one > and allow multiple ABUSE CONTACTS to be listed. For at least > one ABUSE > CONTACT in each resource, ARIN shall require and maintain at least the > following information: > > 1. Individual or Role > > 2. If Individual, full name > > 3. Address valid for Legal Service > Must support physical delivery, registered > mail, or both, > and shall indicate which is acceptable. > > 4. Email Address. > > 5. A list of "normal business hours" specified in > terms of the > time zone applicable to the address in item 3 > or in UTC, with > an indication of whether DST should be > considered. These > hours should comprise at least 30 hours per week. > > 6. A phone number > > 7. A URL where the ORG maintains a web site > listing it's ABUSE > POLICIES. > > Each ORG shale be required to meet the following standards > with respect > to the performance and responsiveness of the required ABUSE CONTACT, > and each ABUSE CONTACT which contains all of the data specified above. > In cases where the language cannot be logically applied to a > ROLE account, > it shall mean all individuals assigned by the ORG in question > to read the > email or answer the phone calls to the addresses/numbers listed in the > ABUSE CONTACT. > > 1. With the exception of sudden events of large > call volume, > shall staff adequately to have live humans answer calls > to the listed abuse contact phone number during > the hours > indicated in the contact record. > > 2. Shall have a human being read and respond to > abuse complaints > received by email within 48 hours of receipt > (for complaints > received Sun-Thu), and, within 96 hours for complaints > received Fri-Sat. > > 3. Shall be capable of taking action or > immediately contacting > a person capable of taking action to stop any > reported abuse > which is in violation of any of the following: > > A. Any definition of network abuse published by the > IETF. (This shall not be construed to > include any > minor failure to comply with an RFC, > but shall only > apply to things the IETF has > specifically defined as > abuse). > > B. Any definition of network abuse > determined by the > ORG to be abuse in any of their own > published AUPs. > > C. Any definition of network abuse which > meets all of the > following criteria: > > 1. Is defined as abuse in a policy > published > on the complaining networks > ABUSE CONTACT > URL. > > 2. Can be defined in terms that > would allow most > routers to block the abuse in > question through > the use of packet filters or > other commonly > available technology. > > (Commonly available technology > for this purpose > means a feature that is present > and can be > reasonably implemented in the > majority of > backbone router types in use on > the Internet > at the time of complaint.) > > 3. Is not a standard response to > traffic being > received from the complaining network. > > 4. Shall take appropriate action to stop abuse identified > in the previous item as soon after receiving > the complaint > as practicable. > > 5. Shall respond to the complaint as soon as > practicable with information on what actions are > being taken to stop the abuse. > > Further, if an entity believes an ORG is not living up to the > requirements > set forth in this policy, they should be able to notify ARIN > of the issue, > including detailed documentation of the efforts made to > contact the ORG and > the results thereof. Any complaint received by ARIN which > does not include > the required information should receive only a form-reply from ARIN > indicating > what information is required to verify the complaint. > > In the event of a valid complaint, ARIN shall attempt to > contact the ORG > in question and notify them of the complaint. If ARIN is > able to contact > the ORG in question, ARIN should wait two weeks and contact > the complainant. > If the complainant is satisfied, no further action is > required by ARIN. > If the complainant is not satisfied, ARIN staff shall make a > determination > whether the complaint meets the definitions of abuse in 3 > above. Further, > the ARIN staff shall make a determination if the response and > actions taken > by the ORG in question meet the requirements of the policy. > If the ARIN > staff determines that the complaint meets the requirements > and that the > response of the ORG in question has not met the requirements > of this policy, > the ARIN staff shall inform the ORG of these facts, > specifically indicating > what additional response and/or action is necessary to > comply. The ORG > shall then have 5 business days or a longer reasonable time > as determined > by the ARIN staff to comply. If the ORG remains out of > compliance, then > the ARIN staff shall revoke each and every specific resource listed in > the complaint and determined to be out of compliance with this policy. > > If a resource is revoked under this policy, it shall be > referred to the > ARIN ABUSE COUNCIL for final determination. The ORG in question shall > have 30 days to present their side of the issue to the > council in written > form via email. The ORG in question may at any time prior to > the 30 days > indicate that they have submitted all desired information and > terminate > the 30 day period 24 hours after sending that email. After > the 30 days > has expired or the ORG has terminated the 30 day period as described, > the ABUSE COUNCIL shall have 10 days to make a final determination on > the revocation. The ABUSE COUNCIL may affirm the revocation, in which > case, it becomes permanent. The ABUSE COUNCIL may overturn the > revocation, in which case, the resources are to be > immediately returned > to the ORG in question. The ABUSE COUNCIL may decide to grant the > ORG in question an extension for compliance. In that case, > the council > shall set a date by which the ORG must comply. The resource(s) will > be immediately returned to the ORG in question. If, at the date in > question, the ORG is determined by ARIN staff to still not be in > compliance, the resources shall again be revoked. The ORG may again > appeal this decision to the ABUSE COUNCIL as described. > > > The ARIN BOARD shall nominate candidates to participate in the ABUSE > COUNCIL. > The ABUSE COUNCIL shall have 5 members. Each member shall be > for a 2 year > term. > The first time, 3 members shall have 2 year terms, and 2 > shall have 1 year > terms. The ARIN BOARD shall nominate not less than two, nor > more than three > times the number of vacant seats. In the first election, the three > candidates > receiving the most votes shall be elected for 2 years. The > community at > large > shall be allowed to vote, similar to the ASO AC election process. The > election shall be conducted as a "Vote for no more than N" > where N is the > number of available seats (5 the first time, 2 the following > year, 3 the > year after, and so on). The ABUSE COUNCIL shall not be > required to conduct > physical meetings, and there shall be no compensation paid to > the ABUSE > COUNCIL by ARIN. > > If a complaint comes up against an ORG to which an ABUSE > COUNCIL member has > ties which could create a conflict of interest, then that > members place > on the ABUSE COUNCIL shall be filled by a member of the ARIN > BOARD chosen > at random with respect to that specific complaint. > > > The ARIN BOARD shall serve as the ABUSE COUNCIL until such time as one > can be elected. In no event shall there be less than 30 days from the > public release of all candidates statements and nominations > to the close > of the voting. The ARIN BOARD shall set the annual election date, and > shall nominate candidates each year at least 60 days prior to > the election > date. Voting shall be conducted for not less than 30 days > leading up to > the election date. > > The ABUSE COUNCIL changes shall take effect 5 days after the > election date. > > > > 2. Argument for the proposal and general discussion of the issue. > > > > Issue: > When trying to resolve issues of abuse, three things are > important: > > 1. Being able to pass the abuse information along to a > meaningful contact at the originating ORG. > > 2. The originating ORG taking appropriate action to > stop the abuse. > > 3. Meaningful contact from the originating ORG explaining > what was done. > > Many ORGs today have built elaborate automated systems > for handling > abuse complaints. It is not uncommon for these systems > to fail to > meet items 1 and 2 above. It is almost unheard of for > them to meet > item 3. It is time for us to move the Internet beyond > the idea that > the victims of abuse should just have to accept those > costs as part > of being connected. The organizations where abuse > originates must > be required to address abuse originating from resources > within their > responsibility. > > > > > Argument in favor: > > When an automated system fails, it becomes > important to be able > > to reach a human being capable of intervening or contacting > > an intervener. It is OK if the POC information (address, > > phone number, etc.) is a work number, or NOC, or even a > > switchboard, as long as it is a point of contact which leads > > to a real person with some ability to close the > loop. It does > not have to lead to a specific real person, but it must > be possible > to engage human intervention through this process. > > > > Problems: > > Most of the objections to the original version of this policy > represented the need for ROLE accounts and the desire not to > release personal information. I think this amended proposal > addresses both of those concerns. Other concerns raised were > the definition of abuse. While this policy does not define > abuse, I think it provides decent metrics for determining abuse > through the IETF and through each networks AUP. Further, it > shifts the definition of abuse to the perspective of the > receiving network, allowing each network to define what traffic > they are willing to accept in a public and accessible manner. > Further, it avoids overly burdensome definitions of abuse by > only requiring originating ISPs to take action to stop abuse > if the policy defines abuse in terms which reasonably allow > the ISP to configure that definition into their routers to > prevent the origination of such abuse, and, then, only after > the abuse has occurred and generated a complaint. > > > > 3. Proposed timetable for implementation: > > > > Once this proposal is ratified, ARIN should update it's registration > > services agreement to reflect the new policy within 30 > days. Existing > > ORG and other bodies should receive notification of the > change and the > > requirement to comply during that same period. They should > be required > > to comply within 90 days of the date the notification is sent to the > > existing ADMIN-C. > > > > After that time has elapsed, ARIN staff should be expected > to investigate > > and take further appropriate action on any complaint > received about lack > > of appropriate ABUSE CONTACT(s) in any resource record. > > > > Appropriate action is left to the discretion of the ARIN > AC, but should > > include ARIN staff contacting the ORG in question by any > means reasonably > available to ARIN, and, possibly revoking resources found to be out of > compliance. > > > > > From mury at goldengate.net Mon Mar 10 20:35:12 2003 From: mury at goldengate.net (Mury) Date: Mon, 10 Mar 2003 19:35:12 -0600 (CST) Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact In-Reply-To: <2147483647.1047315965@dhcp156-251.corp.tellme.com> Message-ID: I haven't decided if I like this policy or not. I certainly appreciate what it is intending to accomplish, but with my indecision put aside one things bothers me more than other parts. If "RESOURCES" are revoked, how is ARIN going to handle those resources? Will they forever be kept on a list of "unusable" resources, thus allowing the offender in essence to continue using them. Or will they be recycled to a new member, possibly making that new member's life horrible if the offending member is still attempting to utilize those resources. I guess it gets down to the point that ARIN is basically a records keeping shop. They tell a new settler that they indeed own a parcel of land, but they can't keep the bandits away. Where is ARIN going to get its guns from? A group of backbone providers who agree to enforce ARIN's rulings? Lawyers? I'm not really expecting an answer. I'm really just wondering how effectively ARIN can revoke something. Mury On Mon, 10 Mar 2003, Owen DeLong wrote: > There has been some good discussion and feedback in response to proposal > 2003-1. > > As a result, I have pretty much rewritten the proposal. What little remains > of the original proposal is prefixed with "> " quoting. Hopefully, this new > version, which I offer as a proposed amendment, will address the original > issue > and most of the feedback I have received. I hope to further refine this so > that we can go into the public policy meeting with rough consensus around > a policy which will facilitate significant improvement around this issue. > > Owen > > > > Policy Proposal 2003-1a: Required Performance of Abuse Contact > > > > 1. Statement of proposed Policy: > > > For the purposes of this policy, the following terms shall apply: > > ORG An organization or organizational unit which receives one or more > resources from ARIN, whether by allocation or assignment. In either > case, the ORG in question shall bear full responsibility under > this policy for meeting the requirements thereof and bearing > any consequences of failure to meet said responsibilities. > > This shall apply to the ORG to which ARIN directly allocated the > resource, or to another ORG, which, has received from the previous > ORG a transfer of the resources under ARIN's transfer policies. > A simply SWIP of an assignment to an ORG which does not have > a contractual relationship with ARIN shall not constitute such > a transfer. > > MAINTAINER > The appointed POC units which have authority and access to make > changes to the ARIN held data regarding a resource owned by a > particular ORG. > > POC A point of contact, whether human or role. > > ABUSE CONTACT > This policy makes no effort to define Abuse. It is the opinion > of the author of this policy that such a definition should come > from the IETF and not from ARIN. It is the intent of this policy > to set standards for the response required from an abuse contact > without addressing the actions required by said contact. Again, > it is the opinion of the author that said actions are outside > of ARIN's scope and belong within the IETF. > > An ABUSE contact is a POC for an ORG which is associated with an > ARIN issued resource as the POC responsible for addressing issues > of abuse originating at or from the resource in question. > > RESOURCE > In the case of ARIN, resources currently include ASNs and IPV4 > and IPV6 address ranges which are allocated or assigned to > registered ORGs. > > ASN An autonomous system number > > IPV4 Internet Protocol Version 4 > > IPV6 Internet Protocol Version 6 > > Proposed Policy > > For any given RESOURCE in the ARIN database, ARIN shall require at least one > and allow multiple ABUSE CONTACTS to be listed. For at least one ABUSE > CONTACT in each resource, ARIN shall require and maintain at least the > following information: > > 1. Individual or Role > > 2. If Individual, full name > > 3. Address valid for Legal Service > Must support physical delivery, registered mail, or both, > and shall indicate which is acceptable. > > 4. Email Address. > > 5. A list of "normal business hours" specified in terms of the > time zone applicable to the address in item 3 or in UTC, with > an indication of whether DST should be considered. These > hours should comprise at least 30 hours per week. > > 6. A phone number > > 7. A URL where the ORG maintains a web site listing it's ABUSE > POLICIES. > > Each ORG shale be required to meet the following standards with respect > to the performance and responsiveness of the required ABUSE CONTACT, > and each ABUSE CONTACT which contains all of the data specified above. > In cases where the language cannot be logically applied to a ROLE account, > it shall mean all individuals assigned by the ORG in question to read the > email or answer the phone calls to the addresses/numbers listed in the > ABUSE CONTACT. > > 1. With the exception of sudden events of large call volume, > shall staff adequately to have live humans answer calls > to the listed abuse contact phone number during the hours > indicated in the contact record. > > 2. Shall have a human being read and respond to abuse complaints > received by email within 48 hours of receipt (for complaints > received Sun-Thu), and, within 96 hours for complaints > received Fri-Sat. > > 3. Shall be capable of taking action or immediately contacting > a person capable of taking action to stop any reported abuse > which is in violation of any of the following: > > A. Any definition of network abuse published by the > IETF. (This shall not be construed to include any > minor failure to comply with an RFC, but shall only > apply to things the IETF has specifically defined as > abuse). > > B. Any definition of network abuse determined by the > ORG to be abuse in any of their own published AUPs. > > C. Any definition of network abuse which meets all of the > following criteria: > > 1. Is defined as abuse in a policy published > on the complaining networks ABUSE CONTACT > URL. > > 2. Can be defined in terms that would allow most > routers to block the abuse in question through > the use of packet filters or other commonly > available technology. > > (Commonly available technology for this purpose > means a feature that is present and can be > reasonably implemented in the majority of > backbone router types in use on the Internet > at the time of complaint.) > > 3. Is not a standard response to traffic being > received from the complaining network. > > 4. Shall take appropriate action to stop abuse identified > in the previous item as soon after receiving the complaint > as practicable. > > 5. Shall respond to the complaint as soon as > practicable with information on what actions are > being taken to stop the abuse. > > Further, if an entity believes an ORG is not living up to the requirements > set forth in this policy, they should be able to notify ARIN of the issue, > including detailed documentation of the efforts made to contact the ORG and > the results thereof. Any complaint received by ARIN which does not include > the required information should receive only a form-reply from ARIN > indicating > what information is required to verify the complaint. > > In the event of a valid complaint, ARIN shall attempt to contact the ORG > in question and notify them of the complaint. If ARIN is able to contact > the ORG in question, ARIN should wait two weeks and contact the complainant. > If the complainant is satisfied, no further action is required by ARIN. > If the complainant is not satisfied, ARIN staff shall make a determination > whether the complaint meets the definitions of abuse in 3 above. Further, > the ARIN staff shall make a determination if the response and actions taken > by the ORG in question meet the requirements of the policy. If the ARIN > staff determines that the complaint meets the requirements and that the > response of the ORG in question has not met the requirements of this policy, > the ARIN staff shall inform the ORG of these facts, specifically indicating > what additional response and/or action is necessary to comply. The ORG > shall then have 5 business days or a longer reasonable time as determined > by the ARIN staff to comply. If the ORG remains out of compliance, then > the ARIN staff shall revoke each and every specific resource listed in > the complaint and determined to be out of compliance with this policy. > > If a resource is revoked under this policy, it shall be referred to the > ARIN ABUSE COUNCIL for final determination. The ORG in question shall > have 30 days to present their side of the issue to the council in written > form via email. The ORG in question may at any time prior to the 30 days > indicate that they have submitted all desired information and terminate > the 30 day period 24 hours after sending that email. After the 30 days > has expired or the ORG has terminated the 30 day period as described, > the ABUSE COUNCIL shall have 10 days to make a final determination on > the revocation. The ABUSE COUNCIL may affirm the revocation, in which > case, it becomes permanent. The ABUSE COUNCIL may overturn the > revocation, in which case, the resources are to be immediately returned > to the ORG in question. The ABUSE COUNCIL may decide to grant the > ORG in question an extension for compliance. In that case, the council > shall set a date by which the ORG must comply. The resource(s) will > be immediately returned to the ORG in question. If, at the date in > question, the ORG is determined by ARIN staff to still not be in > compliance, the resources shall again be revoked. The ORG may again > appeal this decision to the ABUSE COUNCIL as described. > > > The ARIN BOARD shall nominate candidates to participate in the ABUSE > COUNCIL. > The ABUSE COUNCIL shall have 5 members. Each member shall be for a 2 year > term. > The first time, 3 members shall have 2 year terms, and 2 shall have 1 year > terms. The ARIN BOARD shall nominate not less than two, nor more than three > times the number of vacant seats. In the first election, the three > candidates > receiving the most votes shall be elected for 2 years. The community at > large > shall be allowed to vote, similar to the ASO AC election process. The > election shall be conducted as a "Vote for no more than N" where N is the > number of available seats (5 the first time, 2 the following year, 3 the > year after, and so on). The ABUSE COUNCIL shall not be required to conduct > physical meetings, and there shall be no compensation paid to the ABUSE > COUNCIL by ARIN. > > If a complaint comes up against an ORG to which an ABUSE COUNCIL member has > ties which could create a conflict of interest, then that members place > on the ABUSE COUNCIL shall be filled by a member of the ARIN BOARD chosen > at random with respect to that specific complaint. > > > The ARIN BOARD shall serve as the ABUSE COUNCIL until such time as one > can be elected. In no event shall there be less than 30 days from the > public release of all candidates statements and nominations to the close > of the voting. The ARIN BOARD shall set the annual election date, and > shall nominate candidates each year at least 60 days prior to the election > date. Voting shall be conducted for not less than 30 days leading up to > the election date. > > The ABUSE COUNCIL changes shall take effect 5 days after the election date. > > > > 2. Argument for the proposal and general discussion of the issue. > > > > Issue: > When trying to resolve issues of abuse, three things are > important: > > 1. Being able to pass the abuse information along to a > meaningful contact at the originating ORG. > > 2. The originating ORG taking appropriate action to > stop the abuse. > > 3. Meaningful contact from the originating ORG explaining > what was done. > > Many ORGs today have built elaborate automated systems for handling > abuse complaints. It is not uncommon for these systems to fail to > meet items 1 and 2 above. It is almost unheard of for them to meet > item 3. It is time for us to move the Internet beyond the idea that > the victims of abuse should just have to accept those costs as part > of being connected. The organizations where abuse originates must > be required to address abuse originating from resources within their > responsibility. > > > > > Argument in favor: > > When an automated system fails, it becomes important to be able > > to reach a human being capable of intervening or contacting > > an intervener. It is OK if the POC information (address, > > phone number, etc.) is a work number, or NOC, or even a > > switchboard, as long as it is a point of contact which leads > > to a real person with some ability to close the loop. It does > not have to lead to a specific real person, but it must be possible > to engage human intervention through this process. > > > > Problems: > > Most of the objections to the original version of this policy > represented the need for ROLE accounts and the desire not to > release personal information. I think this amended proposal > addresses both of those concerns. Other concerns raised were > the definition of abuse. While this policy does not define > abuse, I think it provides decent metrics for determining abuse > through the IETF and through each networks AUP. Further, it > shifts the definition of abuse to the perspective of the > receiving network, allowing each network to define what traffic > they are willing to accept in a public and accessible manner. > Further, it avoids overly burdensome definitions of abuse by > only requiring originating ISPs to take action to stop abuse > if the policy defines abuse in terms which reasonably allow > the ISP to configure that definition into their routers to > prevent the origination of such abuse, and, then, only after > the abuse has occurred and generated a complaint. > > > > 3. Proposed timetable for implementation: > > > > Once this proposal is ratified, ARIN should update it's registration > > services agreement to reflect the new policy within 30 days. Existing > > ORG and other bodies should receive notification of the change and the > > requirement to comply during that same period. They should be required > > to comply within 90 days of the date the notification is sent to the > > existing ADMIN-C. > > > > After that time has elapsed, ARIN staff should be expected to investigate > > and take further appropriate action on any complaint received about lack > > of appropriate ABUSE CONTACT(s) in any resource record. > > > > Appropriate action is left to the discretion of the ARIN AC, but should > > include ARIN staff contacting the ORG in question by any means reasonably > available to ARIN, and, possibly revoking resources found to be out of > compliance. > > > > From Michael.Dillon at radianz.com Tue Mar 11 05:34:42 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 11 Mar 2003 10:34:42 +0000 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact Message-ID: >ABUSE CONTACT > This policy makes no effort to define Abuse. It is the opinion > of the author of this policy that such a definition should come > from the IETF and not from ARIN. It is the intent of this policy > to set standards for the response required from an abuse contact > without addressing the actions required by said contact. Again, > it is the opinion of the author that said actions are outside > of ARIN's scope and belong within the IETF. Don't back off so vigorously. Here's an attempt at some better wording: Given that the network is a shared resource, it is inevitable that some activities on the network will be viewed as network abuse by other users of the network. We make no attempt to define abuse here since that is better left to other forums. ARIN's only interest is to facilitate communication between the various parties who are using the network. To that end, this policy specifies the contact information that each organization MUST publish. I'm not sure whether I should have used the IETF form of "MUST" in that wording, especially since this isn't found in other ARIN policies. However, the idea of using specific wording to make it a very clear distinction between what is mandatory and what is recommended may be a good idea to adopt. Read RFC 2119 for more info. > 3. Address valid for Legal Service How about "Address to be used only to serve legal documents". > 5. A list of "normal business hours" specified in terms of the > time zone applicable to the address in item 3 or in UTC, with > an indication of whether DST should be considered. These > hours should comprise at least 30 hours per week. Too complicated. It should just indicate normal business hours in local time and identify the timezone offset from GTM. Assuming North American sites, everybody has a business day that overlaps everybody else at one end of the day or other, even the Aleutian islands (GMT -10 no DST) and Newfoundland (GMT -3.5 uses DST) make it just barely. But if you are thinking of the rest of the world, DST rules are not the same everywhere. In fact languages and legal systems are also different so let's not go there. > 6. A phone number Specify that this is a toll number. An 800 number that is usable in the USA cannot normally be used from within Canada and vice versa. And a regional network probably is only paying for a regional 800 number which means it won't work nationally. > 7. A URL where the ORG maintains a web site listing it's ABUSE > POLICIES. Sounding more like a job for LDAP every day... >Each ORG shale be required to meet the following standards with respect I think this whole section is outside of ARIN's mandate because it is defining how the members do business and therefore could be viewed as restraint of trade. >If a resource is revoked under this policy, it shall be referred to the >ARIN ABUSE COUNCIL for final determination. This costs money. Before going into great detail about how such a hypothetical function will operate you should get some consensus on whether or not such a function should exist. This also gets way out of scope of a policy for maintaining some contact info. If ARIN ever did create an ABUSE COUNCIL, I doubt it would happen like this. If there really is a need for such a council, it would be better to start a working group to do some investigations of the need, define the scope, and draft some guidelines for how the ABUSE COUNCIL would operate. Then, only if all of this was successful and met with broad support, would you get serious consideration from the ARIN board and AC. --Michael Dillon From jrace at attglobal.net Tue Mar 11 11:10:04 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Tue, 11 Mar 2003 23:10:04 +0700 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact Message-ID: <200303111610.h2BGAHJW028693@smtp1.arin.net> On Tue, 11 Mar 2003 10:34:42 +0000, Michael.Dillon at radianz.com wrote: >This costs money. Not much Before going into great detail about how such a >hypothetical function will operate you should get some consensus on >whether or not such a function should exist. It has to exist or the contact requirement becomes pointless because unenforceable (Human Behavior Studies 1) This also gets way out of >scope of a policy for maintaining some contact info. It is THE ESSENTIAL STEP for getting and maintaining contact info Jeffrey Race From marla_azinger at eli.net Tue Mar 11 11:55:08 2003 From: marla_azinger at eli.net (Azinger, Marla) Date: Tue, 11 Mar 2003 08:55:08 -0800 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact Message-ID: <5BD887EB4A582A439038636F7A93A5A745C351@wava00s2kexch01.eli.czn.com> Here are two more thoughts of my own that seem to go along the lines of this previouse response. 1. Address valid for Legal Service: I question whether any ARIN Proposal should start requiring "legal" delivery addresses. I question this because as we all know this is a "sue happy" world these days. This type of information could easily become more of an instigator for unneccessary legal work that will cost any company more money than it should. Plus, if someone really intends to sue a company or send legal notice of the type...they can get the needed information off of Government public records. I really question whether this is something ARIN policy should be dipping into. 2. If a resource is revoked under this policy, it shall be: I think revoking IP's could be a very costly endeaver for ARIN. If you were to revoke IP's from a company....that would effectively "restrict trade" and this alone would bring on "suing battles" between ARIN and the offending company. Do we really want to encourage such an event? Regard Marla Azinger ELI IP Analyst -----Original Message----- From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] Sent: Tuesday, March 11, 2003 2:35 AM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact >ABUSE CONTACT > This policy makes no effort to define Abuse. It is the opinion > of the author of this policy that such a definition should come > from the IETF and not from ARIN. It is the intent of this policy > to set standards for the response required from an abuse contact > without addressing the actions required by said contact. Again, > it is the opinion of the author that said actions are outside > of ARIN's scope and belong within the IETF. Don't back off so vigorously. Here's an attempt at some better wording: Given that the network is a shared resource, it is inevitable that some activities on the network will be viewed as network abuse by other users of the network. We make no attempt to define abuse here since that is better left to other forums. ARIN's only interest is to facilitate communication between the various parties who are using the network. To that end, this policy specifies the contact information that each organization MUST publish. I'm not sure whether I should have used the IETF form of "MUST" in that wording, especially since this isn't found in other ARIN policies. However, the idea of using specific wording to make it a very clear distinction between what is mandatory and what is recommended may be a good idea to adopt. Read RFC 2119 for more info. > 3. Address valid for Legal Service How about "Address to be used only to serve legal documents". > 5. A list of "normal business hours" specified in terms of the > time zone applicable to the address in item 3 or in UTC, with > an indication of whether DST should be considered. These > hours should comprise at least 30 hours per week. Too complicated. It should just indicate normal business hours in local time and identify the timezone offset from GTM. Assuming North American sites, everybody has a business day that overlaps everybody else at one end of the day or other, even the Aleutian islands (GMT -10 no DST) and Newfoundland (GMT -3.5 uses DST) make it just barely. But if you are thinking of the rest of the world, DST rules are not the same everywhere. In fact languages and legal systems are also different so let's not go there. > 6. A phone number Specify that this is a toll number. An 800 number that is usable in the USA cannot normally be used from within Canada and vice versa. And a regional network probably is only paying for a regional 800 number which means it won't work nationally. > 7. A URL where the ORG maintains a web site listing it's ABUSE > POLICIES. Sounding more like a job for LDAP every day... >Each ORG shale be required to meet the following standards with respect I think this whole section is outside of ARIN's mandate because it is defining how the members do business and therefore could be viewed as restraint of trade. >If a resource is revoked under this policy, it shall be referred to the >ARIN ABUSE COUNCIL for final determination. This costs money. Before going into great detail about how such a hypothetical function will operate you should get some consensus on whether or not such a function should exist. This also gets way out of scope of a policy for maintaining some contact info. If ARIN ever did create an ABUSE COUNCIL, I doubt it would happen like this. If there really is a need for such a council, it would be better to start a working group to do some investigations of the need, define the scope, and draft some guidelines for how the ABUSE COUNCIL would operate. Then, only if all of this was successful and met with broad support, would you get serious consideration from the ARIN board and AC. --Michael Dillon From owen at delong.com Tue Mar 11 12:14:46 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Mar 2003 09:14:46 -0800 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact In-Reply-To: References: Message-ID: <2147483647.1047374086@imac-en0.delong.sj.ca.us> > Don't back off so vigorously. Here's an attempt at some better wording: > > Given that the network is a shared resource, it is inevitable that some > activities on the network will be viewed as network abuse by other users > of the network. We make no attempt to define abuse here since that is > better left to other forums. ARIN's only interest is to facilitate > communication between the various parties who are using the network. To > that end, this policy specifies the contact information that each > organization MUST publish. > I like this exactly as you have phrased it. I will substitute the paragraph in my draft. Thanks!!! >> 3. Address valid for Legal Service > > How about "Address to be used only to serve legal documents". > I think it is acceptable (although unlikely) for someone to submit other abuse contact efforts via postal mail to this address prior to litigation. As such, I don't think the address should be listed as only for legal service. However, I do think it is important that the address _CAN_ be used for legal service. >> 5. A list of "normal business hours" > specified in terms of the >> time zone applicable to the address in > item 3 or in UTC, with >> an indication of whether DST should be > considered. These >> hours should comprise at least 30 hours > per week. > > Too complicated. It should just indicate normal business hours in local > time and identify the timezone offset from GTM. Assuming North American > sites, everybody has a business day that overlaps everybody else at one > end of the day or other, even the Aleutian islands (GMT -10 no DST) and > Newfoundland (GMT -3.5 uses DST) make it just barely. But if you are > thinking of the rest of the world, DST rules are not the same everywhere. > In fact languages and legal systems are also different so let's not go > there. > I think that some providers might prefer to publish their hours in UTC, and I want to allow for that. (GMT and UTC are not actually identical, BTW, and UTC is probably what you intend above). > >> 6. A phone number > > Specify that this is a toll number. An 800 number that is usable in the > USA cannot normally be used from within Canada and vice versa. And a > regional network probably is only paying for a regional 800 number which > means it won't work nationally. > OK...How about: 6. A globally reachable telephone number >> 7. A URL where the ORG maintains a web site > listing it's ABUSE >> POLICIES. > > Sounding more like a job for LDAP every day... > Let's _PLEASE_ not go there. (I'm in the middle of my own LDAP nightmares on a different project right now). > >> Each ORG shale be required to meet the following standards with respect > > I think this whole section is outside of ARIN's mandate because it is > defining how the members do business and therefore could be viewed as > restraint of trade. > Nope. It is setting up a contractual requirement like many other contracts in business. The ORG is receiving a resource controlled and allocated by ARIN, and, in exchange, they are agreeing to meet the terms and conditions of this contract as long as they continue to retain and/or use that resource. >> If a resource is revoked under this policy, it shall be referred to the >> ARIN ABUSE COUNCIL for final determination. > > This costs money. Before going into great detail about how such a > hypothetical function will operate you should get some consensus on > whether or not such a function should exist. This also gets way out of > scope of a policy for maintaining some contact info. > Again, I disagree. First, the contact policy simply doesn't mean anything without the ability to revoke the resource as a result of a material breach. Second, I, for one, am uncomfortable with making the ARIN staff judge, jury, and executioner on this issue. (As much for what it would do to the staff as for the other obvious reasons). As such, I think having a clearly defined appellate process in the policy is important. As to the cost, you have five uncompensated volunteers who conduct their business (which should, realistically be a very light workload) via email. How many appealed revocations are you expecting in given year? I would expect it to be a relatively small number. If it is not, then, perhaps, we need to look at the cost issue and find other ways of dealing with the appellate process. However, I don't think this will actually be an issue. > If ARIN ever did create an ABUSE COUNCIL, I doubt it would happen like > this. If there really is a need for such a council, it would be better to > start a working group to do some investigations of the need, define the > scope, and draft some guidelines for how the ABUSE COUNCIL would operate. > Then, only if all of this was successful and met with broad support, > would you get serious consideration from the ARIN board and AC. > I think you are applying more scope to the ABUSE COUNCIL that I attempted to define in the document. The sole and only role of the ABUSE COUNCIL would be to provide an appellate to a revocation made by the ARIN staff as a result of this policy. As such, the creation of the council is within the scope of this document (although, perhaps the name is implying a broader scope than intended and I should consider renaming it). The council does not define abuse, set policy, or create any sort of rules. They simply examine revocations made by the staff and any additional evidence presented by the offending ORG and make a ruling to support, deny, or delay the revocation. Owen > --Michael Dillon > > From owen at delong.com Tue Mar 11 12:37:23 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Mar 2003 09:37:23 -0800 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact In-Reply-To: <5BD887EB4A582A439038636F7A93A5A745C351@wava00s2kexch01.eli.czn.com> References: <5BD887EB4A582A439038636F7A93A5A745C351@wava00s2kexch01.eli.czn. com> Message-ID: <2147483647.1047375443@imac-en0.delong.sj.ca.us> --On Tuesday, March 11, 2003 8:55 AM -0800 "Azinger, Marla" wrote: > Here are two more thoughts of my own that seem to go along the lines of > this previouse response. > > 1. Address valid for Legal Service: I question whether any ARIN Proposal > should start requiring "legal" delivery addresses. I question this > because as we all know this is a "sue happy" world these days. This type > of information could easily become more of an instigator for unneccessary > legal work that will cost any company more money than it should. Plus, > if someone really intends to sue a company or send legal notice of the > type...they can get the needed information off of Government public > records. I really question whether this is something ARIN policy should > be dipping into. > I can see both sides of this issue. We'll see how people view it at the meeting. I could live with valid postal address, but, for now, I think I'll leave it as is unless I get more feedback. > 2. If a resource is revoked under this policy, it shall be: I think > revoking IP's could be a very costly endeaver for ARIN. If you were to > revoke IP's from a company....that would effectively "restrict trade" and > this alone would bring on "suing battles" between ARIN and the offending > company. Do we really want to encourage such an event? > Not at all. This would be incorporated into the ARIN services agreement as a material requirement of the contract. ARIN provides resource allocation, and the receiver agrees to meet the required conditions or risk having the resource revoked. This is fairly standard in business contracts. If side B makes a material breach of the contract, side A is free to stop providing what they have agreed to provide. It's not restraint of trade, it's contract enforcement. Since side B will have agreed to the contract, side B will have very little grounds for suing side A because side A did what they said when side B violated the contract. Further, I don't think we can afford to avoid developing community standards solely on the basis that we are afraid of being sued. That is a slippery slope, indeed. Owen > Regard > Marla Azinger > ELI IP Analyst > > > -----Original Message----- > From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] > Sent: Tuesday, March 11, 2003 2:35 AM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2003-1a: Required Performance of > Abuse Contact > > >> ABUSE CONTACT >> This policy makes no effort to define Abuse. It is the > opinion >> of the author of this policy that such a definition > should come >> from the IETF and not from ARIN. It is the intent of > this policy >> to set standards for the response required from an abuse > contact >> without addressing the actions required by said contact. > Again, >> it is the opinion of the author that said actions are > outside >> of ARIN's scope and belong within the IETF. > > Don't back off so vigorously. Here's an attempt at some better wording: > > Given that the network is a shared resource, it is inevitable that some > activities on the network will be viewed as network abuse by other users > of the network. We make no attempt to define abuse here since that is > better left to other forums. ARIN's only interest is to facilitate > communication between the various parties who are using the network. To > that end, this policy specifies the contact information that each > organization MUST publish. > > I'm not sure whether I should have used the IETF form of "MUST" in that > wording, especially since this isn't found in other ARIN policies. > However, the idea of using specific wording to make it a very clear > distinction between what is mandatory and what is recommended may be a > good idea to adopt. Read RFC 2119 for more info. > >> 3. Address valid for Legal Service > > How about "Address to be used only to serve legal documents". > >> 5. A list of "normal business hours" > specified in terms of the >> time zone applicable to the address in > item 3 or in UTC, with >> an indication of whether DST should be > considered. These >> hours should comprise at least 30 hours > per week. > > Too complicated. It should just indicate normal business hours in local > time and identify the timezone offset from GTM. Assuming North American > sites, everybody has a business day that overlaps everybody else at one > end of the day or other, even the Aleutian islands (GMT -10 no DST) and > Newfoundland (GMT -3.5 uses DST) make it just barely. But if you are > thinking of the rest of the world, DST rules are not the same everywhere. > In fact languages and legal systems are also different so let's not go > there. > > >> 6. A phone number > > Specify that this is a toll number. An 800 number that is usable in the > USA cannot normally be used from within Canada and vice versa. And a > regional network probably is only paying for a regional 800 number which > means it won't work nationally. > >> 7. A URL where the ORG maintains a web site > listing it's ABUSE >> POLICIES. > > Sounding more like a job for LDAP every day... > > >> Each ORG shale be required to meet the following standards with respect > > I think this whole section is outside of ARIN's mandate because it is > defining how the members do business and therefore could be viewed as > restraint of trade. > >> If a resource is revoked under this policy, it shall be referred to the >> ARIN ABUSE COUNCIL for final determination. > > This costs money. Before going into great detail about how such a > hypothetical function will operate you should get some consensus on > whether or not such a function should exist. This also gets way out of > scope of a policy for maintaining some contact info. > > If ARIN ever did create an ABUSE COUNCIL, I doubt it would happen like > this. If there really is a need for such a council, it would be better to > start a working group to do some investigations of the need, define the > scope, and draft some guidelines for how the ABUSE COUNCIL would operate. > Then, only if all of this was successful and met with broad support, > would you get serious consideration from the ARIN board and AC. > > --Michael Dillon > From john at chagres.net Tue Mar 11 14:38:51 2003 From: john at chagres.net (John M. Brown) Date: Tue, 11 Mar 2003 12:38:51 -0700 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact In-Reply-To: <2147483647.1047375443@imac-en0.delong.sj.ca.us> Message-ID: <000b01c2e805$d7cc5bd0$f9ecdfd8@laptoy> Hmmm, so how does ARIN keep a IPv4 /32 from being used on the global internet ??? Last I looked, ARIN has NO control, as repeatedly stated it has NO control, and does NOT WANT CONTROL over the global internet routing table. Oh, wait, we can have them publish a database of "revoked" space and then other service providers can build filters based on that revoked space database. Two phrases come to mind. Not Scaleable. Error Prone. Folks, you are attempting to use the RIR's as the Police.Net thats not their role. They have no statutory authority to be the Police.Net. Thats what the FBI, State AG's office and other places are for. We all bitch about how can't keep things updated properly, take to long to remove fixed IP blocks, etc. Do you REALLY think a RIR can do the job better ?? I certainly dont, and dont even want them to think they can, or to try. Its *NOT* their job. Their JOB is simple. Allocate resources in a equal and fair manner, make sure there aren't duplicate allocations, and report to ICANN and IETF if they see things that might exhaust the resources they are allocating. Respectfully, John Brown > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Owen DeLong > Sent: Tuesday, March 11, 2003 10:37 AM > To: Azinger, Marla; ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2003-1a: Required > Performance of Abuse Contact > > > > > --On Tuesday, March 11, 2003 8:55 AM -0800 "Azinger, Marla" > wrote: > > > Here are two more thoughts of my own that seem to go along > the lines > > of this previouse response. > > > > 1. Address valid for Legal Service: I question whether any ARIN > > Proposal should start requiring "legal" delivery addresses. I > > question this because as we all know this is a "sue happy" > world these > > days. This type of information could easily become more of an > > instigator for unneccessary legal work that will cost any > company more > > money than it should. Plus, if someone really intends to sue a > > company or send legal notice of the type...they can get the needed > > information off of Government public records. I really question > > whether this is something ARIN policy should be dipping into. > > > I can see both sides of this issue. We'll see how people > view it at the meeting. I could live with valid postal > address, but, for now, I think I'll leave it as is unless I > get more feedback. > > > 2. If a resource is revoked under this policy, it shall > be: I think > > revoking IP's could be a very costly endeaver for ARIN. If > you were > > to revoke IP's from a company....that would effectively "restrict > > trade" and this alone would bring on "suing battles" > between ARIN and > > the offending company. Do we really want to encourage such > an event? > > > Not at all. This would be incorporated into the ARIN > services agreement as a material requirement of the contract. > ARIN provides resource allocation, and the receiver agrees > to meet the required conditions or risk having the resource > revoked. This is fairly standard in business contracts. If > side B makes a material breach of the contract, side A is > free to stop providing what they have agreed to provide. > It's not restraint of trade, it's > contract > enforcement. Since side B will have agreed to the contract, > side B will > have > very little grounds for suing side A because side A did what > they said when side B violated the contract. > > Further, I don't think we can afford to avoid developing > community standards solely on the basis that we are afraid of > being sued. That is a slippery slope, indeed. > > Owen > > > Regard > > Marla Azinger > > ELI IP Analyst > > > > > > -----Original Message----- > > From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] > > Sent: Tuesday, March 11, 2003 2:35 AM > > To: ppml at arin.net > > Subject: Re: [ppml] Policy Proposal 2003-1a: Required > Performance of > > Abuse Contact > > > > > >> ABUSE CONTACT > >> This policy makes no effort to define Abuse. It is > >> the > > opinion > >> of the author of this policy that such a definition > > should come > >> from the IETF and not from ARIN. It is the > intent of > > this policy > >> to set standards for the response required from an > >> abuse > > contact > >> without addressing the actions required by said > >> contact. > > Again, > >> it is the opinion of the author that said > actions are > > outside > >> of ARIN's scope and belong within the IETF. > > > > Don't back off so vigorously. Here's an attempt at some better > > wording: > > > > Given that the network is a shared resource, it is inevitable that > > some activities on the network will be viewed as network abuse by > > other users of the network. We make no attempt to define abuse here > > since that is better left to other forums. ARIN's only > interest is to > > facilitate communication between the various parties who > are using the > > network. To that end, this policy specifies the contact information > > that each organization MUST publish. > > > > I'm not sure whether I should have used the IETF form of "MUST" in > > that wording, especially since this isn't found in other ARIN > > policies. However, the idea of using specific wording to make it a > > very clear distinction between what is mandatory and what is > > recommended may be a good idea to adopt. Read RFC 2119 for > more info. > > > >> 3. Address valid for Legal Service > > > > How about "Address to be used only to serve legal documents". > > > >> 5. A list of "normal business hours" > > specified in terms of the > >> time zone applicable to the > address in > > item 3 or in UTC, with > >> an indication of whether > DST should be > > considered. These > >> hours should comprise at least 30 > >> hours > > per week. > > > > Too complicated. It should just indicate normal business hours in > > local time and identify the timezone offset from GTM. > Assuming North > > American sites, everybody has a business day that overlaps > everybody > > else at one end of the day or other, even the Aleutian islands (GMT > > -10 no DST) and Newfoundland (GMT -3.5 uses DST) make it > just barely. > > But if you are thinking of the rest of the world, DST rules are not > > the same everywhere. In fact languages and legal systems are also > > different so let's not go there. > > > > > >> 6. A phone number > > > > Specify that this is a toll number. An 800 number that is usable in > > the USA cannot normally be used from within Canada and vice > versa. And > > a regional network probably is only paying for a regional > 800 number > > which means it won't work nationally. > > > >> 7. A URL where the ORG > maintains a web site > > listing it's ABUSE > >> POLICIES. > > > > Sounding more like a job for LDAP every day... > > > > > >> Each ORG shale be required to meet the following standards with > >> respect > > > > I think this whole section is outside of ARIN's mandate > because it is > > defining how the members do business and therefore could be > viewed as > > restraint of trade. > > > >> If a resource is revoked under this policy, it shall be > referred to > >> the ARIN ABUSE COUNCIL for final determination. > > > > This costs money. Before going into great detail about how such a > > hypothetical function will operate you should get some consensus on > > whether or not such a function should exist. This also gets > way out of > > scope of a policy for maintaining some contact info. > > > > If ARIN ever did create an ABUSE COUNCIL, I doubt it would > happen like > > this. If there really is a need for such a council, it > would be better > > to start a working group to do some investigations of the > need, define > > the scope, and draft some guidelines for how the ABUSE > COUNCIL would > > operate. Then, only if all of this was successful and met > with broad > > support, would you get serious consideration from the ARIN > board and > > AC. > > > > --Michael Dillon > > > > From jrace at attglobal.net Tue Mar 11 20:24:24 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 12 Mar 2003 08:24:24 +0700 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact Message-ID: <200303120124.h2C1OXJW048907@smtp1.arin.net> On Tue, 11 Mar 2003 12:38:51 -0700, John M. Brown wrote: >Do you REALLY think a RIR can do the job better ?? I certainly >dont, and dont even want them to think they can, or to try. > >Its *NOT* their job. I believe the thrust of the proposal is that the system is now broken because it is no one's job to enforce discipline, and therefore someone must be assigned the job. The lesson from the way the rest of society works is that the body which allocates the resources withdraws them if they are not used according to the allocation agreement. Some (small) amount of resources must be devoted to the discipline mechanism. If it is known that discipline will be fast and ruthless, practically no resources need be devoted because no one will dare to violate the allocation agreements. At the beginning you have to execute a very few offenders 'pour encourager les autres'. Viewing the big picture, I believe we can reasonably conclude that whatever resources the RIRs devote to discipline will be repaid hundreds, thousands or millions of times in reduced costs to the Internet as a whole. We can also conclude that unless a discipline mechanism is adopted, problems of viruses, trojans, spam and ddos will continue to multiply, as they are now. The rising numbers for all of these metrics show the system as now operated is broken. Jeffrey Race From mury at goldengate.net Wed Mar 12 03:02:01 2003 From: mury at goldengate.net (Mury) Date: Wed, 12 Mar 2003 02:02:01 -0600 (CST) Subject: [ppml] 2003-1a: Required Performance of Abuse Contact: Good - ARIN Should Not Define Abuse or Mediate Disputes In-Reply-To: <200303120124.h2C1OXJW048907@smtp1.arin.net> Message-ID: I've been thinking about this since the revised policy proposal came out. I wasn't sure how I felt about it at first, but I've come to this conclusion. 1) The part that deals with required and *usable* abuse contacts is a good one. 2) The part that attempts to deal with revocation of IP space due to abuse is bad. I don't think it is practical nor desirable for ARIN to try to attempt to settle abuse situations. That really should be left up to a court. Even if ARIN did attempt to deal with severe abuse situations it would probably end up in court any way. However, it makes complete sense for ARIN to "revoke" IP space for not having accurate and usable points of contact listed. If an abused party is able to contact the IP space holder by the abuse contacts listed, ARIN has fulfilled it's role. At that point the abused party can discuss the situation with the offending party and take it to court if they need to. If the abused party is unable to contact the offending party using the abuse contact information listed they can ask ARIN to intercede. If ARIN is also unable to contact the IP space holder, ARIN will revoke the IP space. I think the main crux of the original policy was to require a real response from abuse contacts. This is good. To define the grey lines of abuse and mediate disputes should not be ARIN's responsibility. Mury On Wed, 12 Mar 2003, Dr. Jeffrey Race wrote: > On Tue, 11 Mar 2003 12:38:51 -0700, John M. Brown wrote: > > >Do you REALLY think a RIR can do the job better ?? I certainly > >dont, and dont even want them to think they can, or to try. > > > >Its *NOT* their job. > > I believe the thrust of the proposal is that the system is now > broken because it is no one's job to enforce discipline, and > therefore someone must be assigned the job. The lesson from > the way the rest of society works is that the body which allocates > the resources withdraws them if they are not used according to > the allocation agreement. Some (small) amount of resources > must be devoted to the discipline mechanism. If it is known > that discipline will be fast and ruthless, practically no > resources need be devoted because no one will dare to violate > the allocation agreements. At the beginning you have to execute > a very few offenders 'pour encourager les autres'. > > Viewing the big picture, I believe we can reasonably conclude > that whatever resources the RIRs devote to discipline will be > repaid hundreds, thousands or millions of times in reduced > costs to the Internet as a whole. We can also conclude that > unless a discipline mechanism is adopted, problems of viruses, > trojans, spam and ddos will continue to multiply, as they are > now. The rising numbers for all of these metrics show the system as > now operated is broken. > > Jeffrey Race > > > From john at chagres.net Wed Mar 12 04:07:22 2003 From: john at chagres.net (John M. Brown) Date: Wed, 12 Mar 2003 02:07:22 -0700 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact In-Reply-To: <200303120124.h2C1OXJW048907@smtp1.arin.net> Message-ID: <000001c2e876$cd66da50$7d7ba8c0@laptoy> Yes the system is broken. Service providers need to start filtering on the edge of their networks to prevent bad packets from entering their networks. Socially SPAM needs to be addressed in a manner that allows people(natural or otherwise) to affect self-help and be provided the tools to take legal action against the spammers. Much like the TCPA does with junk-fax. You don't see the "phone company" revoking a phone line because its been used for sending junk faxes. When service providers like Sprint (AS 1239) and UUNET (AS 701) actually apply ingres filtering in such a manner that we no longer see RFC-1918 packets on edge transit links, then we will be getting someplace. Oh BTW filters on a Sprint Ingress link show: rt01#sh access-list as1239-in Extended IP access list as1239-in (Compiled) deny ip 10.0.0.0 0.255.255.255 any (618129 matches) deny ip 172.16.0.0 0.15.255.255 any (254224 matches) deny ip 192.168.0.0 0.0.255.255 any (488749 matches) deny ip 169.254.0.0 0.0.255.255 any (716 matches) This is during a 24 hour window, on ONE customer DS3 interface. Wonder what the aggregate count would be across their entire net. (Prolly less than a OC12 worth of traffic) (ARIN, RIPE, APNIC Please revoke their AS, all their routes from the internet because they allow spoofed packets to enter their networks) This is clearly ABUSE as the IETF has specified that IP packets labled with these integers (RFC-1918) MUST NOT be routed to the global Internet. So "We can conclude" that Sprint is abusing a majority of its customers with low volume DDOS by allowing these packets to exist.... May I ask, who is going to Pay Sprint to place these filters on every edge router in their global network??? May I ask, who is going to revoke AS 1239 and remove its ability to be used in the global BGP routing tables ?? I think, speaking for our client, that should that happen the org that causes this problem (in this case ARIN) would be facing legal action for interfering with interstate commerce and for possible RICO, anti-trust practices, and interfering with contractual relations that it is not a party to. Bluntly, this is a bad idea and deserves a red t-shirt. And for the record. Our client thinks Sprint runs a pretty darn good network. We only used their name and stats as a way of putting reality to this proposal. Msg to ARIN AC and BOT. Please spend your time on something like say, IPv6 and making those resources more available to people that want to start using them. john brown > We can also conclude that > unless a discipline mechanism is adopted, problems of > viruses, trojans, spam and ddos will continue to multiply, as > they are now. The rising numbers for all of these metrics > show the system as now operated is broken. > > Jeffrey Race > > > From jmcburnett at msmgmt.com Wed Mar 12 06:29:49 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 12 Mar 2003 06:29:49 -0500 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact Message-ID: <390E55B947E7C848898AEBB9E507706041E4B2@msmdcfs01.msmgmt.com> JOhn, I don't see it quite that way... Unless Sprint is using RFC1918 address in it's network infrastructure, why not just use Null routing? 1 instace takes care of the whole network... And if it is redistributed via iBGP then no need for a blue gazillin of ACLs.. Anyway, Jim > -----Original Message----- > From: John M. Brown [mailto:john at chagres.net] > Sent: Wednesday, March 12, 2003 4:07 AM > To: 'Dr. Jeffrey Race'; ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2003-1a: Required Performance of > Abuse Contact > > > Yes the system is broken. Service providers need to start > filtering on the edge of their networks to prevent bad packets > from entering their networks. > > Socially SPAM needs to be addressed in a manner that allows > people(natural or otherwise) to affect self-help and be provided > the tools to take legal action against the spammers. Much like > the TCPA does with junk-fax. You don't see the "phone company" > revoking a phone line because its been used for sending junk > faxes. > > > When service providers like Sprint (AS 1239) and UUNET (AS 701) > actually apply ingres filtering in such a manner that we no > longer see RFC-1918 packets on edge transit links, then we > will be getting someplace. > > Oh BTW filters on a Sprint Ingress link show: > > rt01#sh access-list as1239-in > Extended IP access list as1239-in (Compiled) > deny ip 10.0.0.0 0.255.255.255 any (618129 matches) > deny ip 172.16.0.0 0.15.255.255 any (254224 matches) > deny ip 192.168.0.0 0.0.255.255 any (488749 matches) > deny ip 169.254.0.0 0.0.255.255 any (716 matches) > > This is during a 24 hour window, on ONE customer DS3 interface. > Wonder what the aggregate count would be across their entire net. > (Prolly less than a OC12 worth of traffic) > > (ARIN, RIPE, APNIC Please revoke their AS, all their routes > from the internet because they allow spoofed packets to > enter their networks) > > This is clearly ABUSE as the IETF has specified that IP packets > labled with these integers (RFC-1918) MUST NOT be routed to the > global Internet. > > > So "We can conclude" that Sprint is abusing a majority of its > customers > with low volume DDOS by allowing these packets to exist.... > > May I ask, who is going to Pay Sprint to place these filters on > every edge router in their global network??? > > May I ask, who is going to revoke AS 1239 and remove its ability to > be used in the global BGP routing tables ?? I think, speaking > for our client, that should that happen the org that causes this > problem (in this case ARIN) would be facing legal action for > interfering with interstate commerce and for possible RICO, > anti-trust practices, and interfering with contractual relations > that it is not a party to. > > Bluntly, this is a bad idea and deserves a red t-shirt. > > And for the record. Our client thinks Sprint runs a pretty > darn good network. We only used their name and stats as a way > of putting reality to this proposal. > > > Msg to ARIN AC and BOT. Please spend your time on something like > say, IPv6 and making those resources more available to people that > want to start using them. > > john brown > > > > We can also conclude that > > unless a discipline mechanism is adopted, problems of > > viruses, trojans, spam and ddos will continue to multiply, as > > they are now. The rising numbers for all of these metrics > > show the system as now operated is broken. > > > > Jeffrey Race > > > > > > > > From john at chagres.net Wed Mar 12 10:52:02 2003 From: john at chagres.net (John M. Brown) Date: Wed, 12 Mar 2003 08:52:02 -0700 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact Message-ID: <000101c2e8af$533d1cb0$7d7ba8c0@laptoy> forgive me if I seem nieve.... packet enters NSP's network, SRC_IP is 192.168.1.1 DST_IP is 209.152.187.30 router looks for a route to the DST_IP and fwds the packet out the appropriate interface. otherwords, Routers look at DST IP when making fwd'ing decisions, NOT SRC ip. hence a ip route 192.168.0.0/16 null0 15 would do nothing for this packet, since its the SRC that is spoofed. Null routing would drop the reply packet that 209.152.187.30 generates and sends back in response. But in general that is already done because 192.168.1.1 isn't in 209.152.187.30's next hop routers table. Ergo, you have to filter based on the SRC_IP at the ingress to the network. If I missed some new cisco or juniper feature that now causes a router to forward based on SRC_IP, other than URPF thingy. > -----Original Message----- > From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] > Sent: Wednesday, March 12, 2003 4:30 AM > To: john at chagres.net; Dr. Jeffrey Race; ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2003-1a: Required > Performance of Abuse Contact > > > JOhn, > I don't see it quite that way... > Unless Sprint is using RFC1918 address in it's network > infrastructure, why not just use Null routing? 1 instace > takes care of the whole network... And if it is redistributed > via iBGP then no need for a blue gazillin of ACLs.. > > Anyway, > Jim > > > > > > -----Original Message----- > > From: John M. Brown [mailto:john at chagres.net] > > Sent: Wednesday, March 12, 2003 4:07 AM > > To: 'Dr. Jeffrey Race'; ppml at arin.net > > Subject: RE: [ppml] Policy Proposal 2003-1a: Required > Performance of > > Abuse Contact > > > > > > Yes the system is broken. Service providers need to start > filtering > > on the edge of their networks to prevent bad packets from entering > > their networks. > > > > Socially SPAM needs to be addressed in a manner that allows > > people(natural or otherwise) to affect self-help and be > provided the > > tools to take legal action against the spammers. Much like > the TCPA > > does with junk-fax. You don't see the "phone company" revoking a > > phone line because its been used for sending junk faxes. > > > > > > When service providers like Sprint (AS 1239) and UUNET (AS 701) > > actually apply ingres filtering in such a manner that we no > longer see > > RFC-1918 packets on edge transit links, then we will be getting > > someplace. > > > > Oh BTW filters on a Sprint Ingress link show: > > > > rt01#sh access-list as1239-in > > Extended IP access list as1239-in (Compiled) > > deny ip 10.0.0.0 0.255.255.255 any (618129 matches) > > deny ip 172.16.0.0 0.15.255.255 any (254224 matches) > > deny ip 192.168.0.0 0.0.255.255 any (488749 matches) > > deny ip 169.254.0.0 0.0.255.255 any (716 matches) > > > > This is during a 24 hour window, on ONE customer DS3 > interface. Wonder > > what the aggregate count would be across their entire net. (Prolly > > less than a OC12 worth of traffic) > > > > (ARIN, RIPE, APNIC Please revoke their AS, all their routes from the > > internet because they allow spoofed packets to enter their networks) > > > > This is clearly ABUSE as the IETF has specified that IP > packets labled > > with these integers (RFC-1918) MUST NOT be routed to the global > > Internet. > > > > > > So "We can conclude" that Sprint is abusing a majority of its > > customers with low volume DDOS by allowing these packets to > > exist.... > > > > May I ask, who is going to Pay Sprint to place these filters on > > every edge router in their global network??? > > > > May I ask, who is going to revoke AS 1239 and remove its ability to > > be used in the global BGP routing tables ?? I think, speaking > > for our client, that should that happen the org that causes this > > problem (in this case ARIN) would be facing legal action for > > interfering with interstate commerce and for possible RICO, > anti-trust > > practices, and interfering with contractual relations that > it is not a > > party to. > > > > Bluntly, this is a bad idea and deserves a red t-shirt. > > > > And for the record. Our client thinks Sprint runs a pretty > darn good > > network. We only used their name and stats as a way of putting > > reality to this proposal. > > > > > > Msg to ARIN AC and BOT. Please spend your time on > something like say, > > IPv6 and making those resources more available to people > that want to > > start using them. > > > > john brown > > > > > > > We can also conclude that > > > unless a discipline mechanism is adopted, problems of viruses, > > > trojans, spam and ddos will continue to multiply, as they are now. > > > The rising numbers for all of these metrics show the system as now > > > operated is broken. > > > > > > Jeffrey Race > > > > > > > > > > > > > > From owen at delong.com Wed Mar 12 13:16:01 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Mar 2003 10:16:01 -0800 Subject: [ppml] 2003-1a: Required Performance of Abuse Contact: Good - ARIN Should Not Define Abuse or Mediate Disputes In-Reply-To: References: Message-ID: <2147483647.1047464161@imac-en0.delong.sj.ca.us> > I've been thinking about this since the revised policy proposal came out. > I wasn't sure how I felt about it at first, but I've come to this > conclusion. > > 1) The part that deals with required and *usable* abuse contacts is a good > one. > Thanks! > 2) The part that attempts to deal with revocation of IP space due to abuse > is bad. > Hmmm... If the first part of your statement were true, I'd be forced to agree with the second part, too. However, it was not my intent for the policy to deal with revocation due to abuse. it was my intent to provide for revocation due to lack of response to an abuse complaint. There is little point to requiring a usable abuse contact without this. Afterall, what happens if the abuse contact is unusable? The stuff about defining abuse was intended to prevent ARIN getting swamped with complaints about unreachable or unresponsive abuse contacts in the absence of any abuse, and, to prevent providers from getting swamped with "abuse contact tests" in the absence of abuse. I think the policy will be significantly less effective without an ability for ARIN to revoke resources due to failure to comply with the policy. The defined steps for ARIN to take were intended to specify that ARIN would not simply revoke space due to a third-party complaint without first verifying that the ABUSE contact was, indeed, "unusable". As such, I think my intent was to specify a system for doing exactly what you say makes sense below. If the wording in my proposal doesn't meet that need, I'd certainly appreciate your assistance in improving it. > I don't think it is practical nor desirable for ARIN to try to attempt to > settle abuse situations. That really should be left up to a court. Even > if ARIN did attempt to deal with severe abuse situations it would probably > end up in court any way. > Agreed. I don't want ARIN settling abuse complaints. I do think ARIN has a role facilitating communications between the two ORGs in question (victim and alleged abuser) and in making sure that both ORGs have up to date usable contact information. If the parties in question cannot agree, then the matter must be referred to the court. ARINs involvement should end when one party responds to the other. Perhaps the confusion comes from my use of the term adequate response. An adequate response to abuse does not mean that the alleged abusive action must terminate for purposes of this policy (I'll clarify this with another amendment). What it means is that an actual person at the alleged abuser ORG has reviewed the complaint and informed the complainant of what actions they intend to take with respect to this abuse. An autoresponder, auto- attendent, or other automoton which simply spouts "It is our policy not to address your concerns" or some functional equivalant is _NOT_ an adequate response. It will take me some time to develop the wording to define that in policy terms, and I'd certainly welcome any suggestions. > However, it makes complete sense for ARIN to "revoke" IP space for not > having accurate and usable points of contact listed. > That _WAS_ the intenet of the policy. > If an abused party is able to contact the IP space holder by the abuse > contacts listed, ARIN has fulfilled it's role. At that point the abused > party can discuss the situation with the offending party and take it to > court if they need to. > Yes. However, I wanted to go a little further and require that the alleged abuser actually RESPOND to the abused party. Afterall, absent that, you could maintain a voice mailbox pointed at /dev/null. Technically, since I phoned that box and left a message on /dev/null, I contacted the alleged abuser. Personally, I don't think that constitutes a valid, usable abuse contact. However, requiring a response was, in my opinion, the end of ARINs role. Anything further belongs between the parties and/or the court(s). > If the abused party is unable to contact the offending party using the > abuse contact information listed they can ask ARIN to intercede. If ARIN > is also unable to contact the IP space holder, ARIN will revoke the IP > space. > Right. I think we're in relatively complete agreement. However, the crux of the perceived disagreement seems to come from lack of clarity on what constitutes contact. I attempted to define the requirements in terms of bidirectional communication. If you simply use the term contact, then it leaves a lot of legal wiggle-room for the /dev/null approach I described above. > I think the main crux of the original policy was to require a real > response from abuse contacts. This is good. To define the grey lines of > abuse and mediate disputes should not be ARIN's responsibility. > I absolutely agree. However, I didn't want ARIN to have to chase a bunch of "This guy is unresponsive even though he hasn't done anything wrong." complaints. That's why I specifically tried to avoid defining abuse, but still support the following possible constraints on the policy: 1. Any definition of abuse which may come from IETF in the future (there are efforts underway on this). and/or 2. A published AUP from the complainants network which is defined in terms that should allow the alleged abusing network to prevent violations relatively easily. The intent of this was to keep ARIN _OUT_ of the defining abuse business and to give ARIN a way to avoid resources chasing complaints about non-abusing networks. I will reiterate that I welcome any suggested wording changes to bring this more in line with our mutual intent. Thanks for your feedback! Owen > On Wed, 12 Mar 2003, Dr. Jeffrey Race wrote: > >> On Tue, 11 Mar 2003 12:38:51 -0700, John M. Brown wrote: >> >> > Do you REALLY think a RIR can do the job better ?? I certainly >> > dont, and dont even want them to think they can, or to try. >> > >> > Its *NOT* their job. >> >> I believe the thrust of the proposal is that the system is now >> broken because it is no one's job to enforce discipline, and >> therefore someone must be assigned the job. The lesson from >> the way the rest of society works is that the body which allocates >> the resources withdraws them if they are not used according to >> the allocation agreement. Some (small) amount of resources >> must be devoted to the discipline mechanism. If it is known >> that discipline will be fast and ruthless, practically no >> resources need be devoted because no one will dare to violate >> the allocation agreements. At the beginning you have to execute >> a very few offenders 'pour encourager les autres'. >> >> Viewing the big picture, I believe we can reasonably conclude >> that whatever resources the RIRs devote to discipline will be >> repaid hundreds, thousands or millions of times in reduced >> costs to the Internet as a whole. We can also conclude that >> unless a discipline mechanism is adopted, problems of viruses, >> trojans, spam and ddos will continue to multiply, as they are >> now. The rising numbers for all of these metrics show the system as >> now operated is broken. >> >> Jeffrey Race >> >> >> > > > From owen at delong.com Wed Mar 12 13:21:03 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Mar 2003 10:21:03 -0800 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact In-Reply-To: <000001c2e876$cd66da50$7d7ba8c0@laptoy> References: <000001c2e876$cd66da50$7d7ba8c0@laptoy> Message-ID: <2147483647.1047464463@imac-en0.delong.sj.ca.us> John, You're missing the point of the policy. The policy does not allow ARIN to revoke SPRINTs AS or IPs because they are conducting this abuse. If SPRINT's contact were unreachable or did not respond to complaints about this issue, then ARIN could revoke the IPs. The policy deliberately avoids addressing abuse and is strictly intended to force the requirement that the ORGs accept and respond to abuse complaints. It deliberately avoids defining what that response must be. I'm not overly impressed with SPRINT's network, but, I do think, that in spite of their continued abuse, their abuse department does provide an adequate response to meet the terms of this policy. As such, thank you for that reality. I hope it will allow you to see the reality of why this policy is a good idea and how it was intended to address exactly the concerns you have raised! Owen --On Wednesday, March 12, 2003 2:07 AM -0700 "John M. Brown" wrote: > Yes the system is broken. Service providers need to start > filtering on the edge of their networks to prevent bad packets > from entering their networks. > > Socially SPAM needs to be addressed in a manner that allows > people(natural or otherwise) to affect self-help and be provided > the tools to take legal action against the spammers. Much like > the TCPA does with junk-fax. You don't see the "phone company" > revoking a phone line because its been used for sending junk > faxes. > > > When service providers like Sprint (AS 1239) and UUNET (AS 701) > actually apply ingres filtering in such a manner that we no > longer see RFC-1918 packets on edge transit links, then we > will be getting someplace. > > Oh BTW filters on a Sprint Ingress link show: > > rt01#sh access-list as1239-in > Extended IP access list as1239-in (Compiled) > deny ip 10.0.0.0 0.255.255.255 any (618129 matches) > deny ip 172.16.0.0 0.15.255.255 any (254224 matches) > deny ip 192.168.0.0 0.0.255.255 any (488749 matches) > deny ip 169.254.0.0 0.0.255.255 any (716 matches) > > This is during a 24 hour window, on ONE customer DS3 interface. > Wonder what the aggregate count would be across their entire net. > (Prolly less than a OC12 worth of traffic) > > (ARIN, RIPE, APNIC Please revoke their AS, all their routes > from the internet because they allow spoofed packets to > enter their networks) > > This is clearly ABUSE as the IETF has specified that IP packets > labled with these integers (RFC-1918) MUST NOT be routed to the > global Internet. > > > So "We can conclude" that Sprint is abusing a majority of its customers > with low volume DDOS by allowing these packets to exist.... > > May I ask, who is going to Pay Sprint to place these filters on > every edge router in their global network??? > > May I ask, who is going to revoke AS 1239 and remove its ability to > be used in the global BGP routing tables ?? I think, speaking > for our client, that should that happen the org that causes this > problem (in this case ARIN) would be facing legal action for > interfering with interstate commerce and for possible RICO, > anti-trust practices, and interfering with contractual relations > that it is not a party to. > > Bluntly, this is a bad idea and deserves a red t-shirt. > > And for the record. Our client thinks Sprint runs a pretty > darn good network. We only used their name and stats as a way > of putting reality to this proposal. > > > Msg to ARIN AC and BOT. Please spend your time on something like > say, IPv6 and making those resources more available to people that > want to start using them. > > john brown > > >> We can also conclude that >> unless a discipline mechanism is adopted, problems of >> viruses, trojans, spam and ddos will continue to multiply, as >> they are now. The rising numbers for all of these metrics >> show the system as now operated is broken. >> >> Jeffrey Race >> >> >> > From owen at delong.com Wed Mar 12 13:44:43 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Mar 2003 10:44:43 -0800 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact In-Reply-To: <000101c2e8af$533d1cb0$7d7ba8c0@laptoy> References: <000101c2e8af$533d1cb0$7d7ba8c0@laptoy> Message-ID: <2147483647.1047465883@imac-en0.delong.sj.ca.us> --On Wednesday, March 12, 2003 8:52 AM -0700 "John M. Brown" wrote: > forgive me if I seem nieve.... > That's OK, John, we forgive you :-) (Sorry, John, couldn't resist) > packet enters NSP's network, > SRC_IP is 192.168.1.1 > DST_IP is 209.152.187.30 > > router looks for a route to the DST_IP and fwds > the packet out the appropriate interface. > Um, yeah. > otherwords, Routers look at DST IP when making > fwd'ing decisions, NOT SRC ip. > Absent policy routing or URPF, that's true. > hence a ip route 192.168.0.0/16 null0 15 would > do nothing for this packet, since its the SRC > that is spoofed. > Right. > Null routing would drop the reply packet that 209.152.187.30 > generates and sends back in response. But in general > that is already done because 192.168.1.1 isn't in > 209.152.187.30's next hop routers table. > Um only if the router doesn't have a default route, which, in my experience, would not be the majority of routers on the internet. Most routers in my experience, especially the ones suffering from out-of-date bogon filters, tend to be in the DEFAULT zone, not the DEFAULT-FREE zone. > > Ergo, you have to filter based on the SRC_IP at the > ingress to the network. > That would be nice. If you have a way to get routers to dynamically update their SRC_IP ingress filters based on some form of distribution protocol, I'm all ears. I didn't say I solved the whole problem (in fact, I'm pretty sure I said I didn't). However, I think I solved _PART_ of the problem. > If I missed some new cisco or juniper feature that > now causes a router to forward based on SRC_IP, other > than URPF thingy. > Nope... The URPF thingy goes a long way on solving the other half if we implement my half, though. Owen > >> -----Original Message----- >> From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] >> Sent: Wednesday, March 12, 2003 4:30 AM >> To: john at chagres.net; Dr. Jeffrey Race; ppml at arin.net >> Subject: RE: [ppml] Policy Proposal 2003-1a: Required >> Performance of Abuse Contact >> >> >> JOhn, >> I don't see it quite that way... >> Unless Sprint is using RFC1918 address in it's network >> infrastructure, why not just use Null routing? 1 instace >> takes care of the whole network... And if it is redistributed >> via iBGP then no need for a blue gazillin of ACLs.. >> >> Anyway, >> Jim >> >> >> >> >> > -----Original Message----- >> > From: John M. Brown [mailto:john at chagres.net] >> > Sent: Wednesday, March 12, 2003 4:07 AM >> > To: 'Dr. Jeffrey Race'; ppml at arin.net >> > Subject: RE: [ppml] Policy Proposal 2003-1a: Required >> Performance of >> > Abuse Contact >> > >> > >> > Yes the system is broken. Service providers need to start >> filtering >> > on the edge of their networks to prevent bad packets from entering >> > their networks. >> > >> > Socially SPAM needs to be addressed in a manner that allows >> > people(natural or otherwise) to affect self-help and be >> provided the >> > tools to take legal action against the spammers. Much like >> the TCPA >> > does with junk-fax. You don't see the "phone company" revoking a >> > phone line because its been used for sending junk faxes. >> > >> > >> > When service providers like Sprint (AS 1239) and UUNET (AS 701) >> > actually apply ingres filtering in such a manner that we no >> longer see >> > RFC-1918 packets on edge transit links, then we will be getting >> > someplace. >> > >> > Oh BTW filters on a Sprint Ingress link show: >> > >> > rt01#sh access-list as1239-in >> > Extended IP access list as1239-in (Compiled) >> > deny ip 10.0.0.0 0.255.255.255 any (618129 matches) >> > deny ip 172.16.0.0 0.15.255.255 any (254224 matches) >> > deny ip 192.168.0.0 0.0.255.255 any (488749 matches) >> > deny ip 169.254.0.0 0.0.255.255 any (716 matches) >> > >> > This is during a 24 hour window, on ONE customer DS3 >> interface. Wonder >> > what the aggregate count would be across their entire net. (Prolly >> > less than a OC12 worth of traffic) >> > >> > (ARIN, RIPE, APNIC Please revoke their AS, all their routes from the > >> > internet because they allow spoofed packets to enter their networks) >> > >> > This is clearly ABUSE as the IETF has specified that IP >> packets labled >> > with these integers (RFC-1918) MUST NOT be routed to the global >> > Internet. >> > >> > >> > So "We can conclude" that Sprint is abusing a majority of its >> > customers with low volume DDOS by allowing these packets to >> > exist.... >> > >> > May I ask, who is going to Pay Sprint to place these filters on >> > every edge router in their global network??? >> > >> > May I ask, who is going to revoke AS 1239 and remove its ability to >> > be used in the global BGP routing tables ?? I think, speaking >> > for our client, that should that happen the org that causes this >> > problem (in this case ARIN) would be facing legal action for >> > interfering with interstate commerce and for possible RICO, >> anti-trust >> > practices, and interfering with contractual relations that >> it is not a >> > party to. >> > >> > Bluntly, this is a bad idea and deserves a red t-shirt. >> > >> > And for the record. Our client thinks Sprint runs a pretty >> darn good >> > network. We only used their name and stats as a way of putting >> > reality to this proposal. >> > >> > >> > Msg to ARIN AC and BOT. Please spend your time on >> something like say, >> > IPv6 and making those resources more available to people >> that want to >> > start using them. >> > >> > john brown >> > >> > >> > > We can also conclude that >> > > unless a discipline mechanism is adopted, problems of viruses, >> > > trojans, spam and ddos will continue to multiply, as they are now. > >> > > The rising numbers for all of these metrics show the system as now > >> > > operated is broken. >> > > >> > > Jeffrey Race >> > > >> > > >> > > >> > >> > >> > From mury at goldengate.net Wed Mar 12 14:05:17 2003 From: mury at goldengate.net (Mury) Date: Wed, 12 Mar 2003 13:05:17 -0600 (CST) Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact In-Reply-To: <2147483647.1047465883@imac-en0.delong.sj.ca.us> Message-ID: I'm hestitant to add some input since this seems off topic, but using Null routes on a network as big as Sprint's good be bad. Yes, it would stop TCP traffic with one entry, however... Null routing TCP traffic can create types of syn-flood DOS attacks. The sending system keeps initiating the connection and the receiving machine keeps acking and leaving the connection open. I watched this happen a couple weeks ago with a BSD box using a current version of sendmail. So, yes, despite server software changes 5 years ago this behavior will affect modern hardware and popular server software. Mury On Wed, 12 Mar 2003, Owen DeLong wrote: > > > --On Wednesday, March 12, 2003 8:52 AM -0700 "John M. Brown" > wrote: > > > forgive me if I seem nieve.... > > > That's OK, John, we forgive you :-) (Sorry, John, couldn't resist) > > > packet enters NSP's network, > > SRC_IP is 192.168.1.1 > > DST_IP is 209.152.187.30 > > > > router looks for a route to the DST_IP and fwds > > the packet out the appropriate interface. > > > Um, yeah. > > > otherwords, Routers look at DST IP when making > > fwd'ing decisions, NOT SRC ip. > > > Absent policy routing or URPF, that's true. > > > hence a ip route 192.168.0.0/16 null0 15 would > > do nothing for this packet, since its the SRC > > that is spoofed. > > > Right. > > > Null routing would drop the reply packet that 209.152.187.30 > > generates and sends back in response. But in general > > that is already done because 192.168.1.1 isn't in > > 209.152.187.30's next hop routers table. > > > Um only if the router doesn't have a default route, which, in my experience, > would not be the majority of routers on the internet. Most routers in my > experience, especially the ones suffering from out-of-date bogon filters, > tend to be in the DEFAULT zone, not the DEFAULT-FREE zone. > > > > > Ergo, you have to filter based on the SRC_IP at the > > ingress to the network. > > > That would be nice. If you have a way to get routers to dynamically update > their SRC_IP ingress filters based on some form of distribution protocol, > I'm all ears. I didn't say I solved the whole problem (in fact, I'm pretty > sure I said I didn't). However, I think I solved _PART_ of the problem. > > > If I missed some new cisco or juniper feature that > > now causes a router to forward based on SRC_IP, other > > than URPF thingy. > > > Nope... The URPF thingy goes a long way on solving the other half if we > implement my half, though. > > Owen > > > > >> -----Original Message----- > >> From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] > >> Sent: Wednesday, March 12, 2003 4:30 AM > >> To: john at chagres.net; Dr. Jeffrey Race; ppml at arin.net > >> Subject: RE: [ppml] Policy Proposal 2003-1a: Required > >> Performance of Abuse Contact > >> > >> > >> JOhn, > >> I don't see it quite that way... > >> Unless Sprint is using RFC1918 address in it's network > >> infrastructure, why not just use Null routing? 1 instace > >> takes care of the whole network... And if it is redistributed > >> via iBGP then no need for a blue gazillin of ACLs.. > >> > >> Anyway, > >> Jim > >> > >> > >> > >> > >> > -----Original Message----- > >> > From: John M. Brown [mailto:john at chagres.net] > >> > Sent: Wednesday, March 12, 2003 4:07 AM > >> > To: 'Dr. Jeffrey Race'; ppml at arin.net > >> > Subject: RE: [ppml] Policy Proposal 2003-1a: Required > >> Performance of > >> > Abuse Contact > >> > > >> > > >> > Yes the system is broken. Service providers need to start > >> filtering > >> > on the edge of their networks to prevent bad packets from entering > >> > their networks. > >> > > >> > Socially SPAM needs to be addressed in a manner that allows > >> > people(natural or otherwise) to affect self-help and be > >> provided the > >> > tools to take legal action against the spammers. Much like > >> the TCPA > >> > does with junk-fax. You don't see the "phone company" revoking a > >> > phone line because its been used for sending junk faxes. > >> > > >> > > >> > When service providers like Sprint (AS 1239) and UUNET (AS 701) > >> > actually apply ingres filtering in such a manner that we no > >> longer see > >> > RFC-1918 packets on edge transit links, then we will be getting > >> > someplace. > >> > > >> > Oh BTW filters on a Sprint Ingress link show: > >> > > >> > rt01#sh access-list as1239-in > >> > Extended IP access list as1239-in (Compiled) > >> > deny ip 10.0.0.0 0.255.255.255 any (618129 matches) > >> > deny ip 172.16.0.0 0.15.255.255 any (254224 matches) > >> > deny ip 192.168.0.0 0.0.255.255 any (488749 matches) > >> > deny ip 169.254.0.0 0.0.255.255 any (716 matches) > >> > > >> > This is during a 24 hour window, on ONE customer DS3 > >> interface. Wonder > >> > what the aggregate count would be across their entire net. (Prolly > >> > less than a OC12 worth of traffic) > >> > > >> > (ARIN, RIPE, APNIC Please revoke their AS, all their routes from the > > > >> > internet because they allow spoofed packets to enter their networks) > >> > > >> > This is clearly ABUSE as the IETF has specified that IP > >> packets labled > >> > with these integers (RFC-1918) MUST NOT be routed to the global > >> > Internet. > >> > > >> > > >> > So "We can conclude" that Sprint is abusing a majority of its > >> > customers with low volume DDOS by allowing these packets to > >> > exist.... > >> > > >> > May I ask, who is going to Pay Sprint to place these filters on > >> > every edge router in their global network??? > >> > > >> > May I ask, who is going to revoke AS 1239 and remove its ability to > >> > be used in the global BGP routing tables ?? I think, speaking > >> > for our client, that should that happen the org that causes this > >> > problem (in this case ARIN) would be facing legal action for > >> > interfering with interstate commerce and for possible RICO, > >> anti-trust > >> > practices, and interfering with contractual relations that > >> it is not a > >> > party to. > >> > > >> > Bluntly, this is a bad idea and deserves a red t-shirt. > >> > > >> > And for the record. Our client thinks Sprint runs a pretty > >> darn good > >> > network. We only used their name and stats as a way of putting > >> > reality to this proposal. > >> > > >> > > >> > Msg to ARIN AC and BOT. Please spend your time on > >> something like say, > >> > IPv6 and making those resources more available to people > >> that want to > >> > start using them. > >> > > >> > john brown > >> > > >> > > >> > > We can also conclude that > >> > > unless a discipline mechanism is adopted, problems of viruses, > >> > > trojans, spam and ddos will continue to multiply, as they are now. > > > >> > > The rising numbers for all of these metrics show the system as now > > > >> > > operated is broken. > >> > > > >> > > Jeffrey Race > >> > > > >> > > > >> > > > >> > > >> > > >> > > > > From ron at aol.net Thu Mar 13 15:26:19 2003 From: ron at aol.net (Ron da Silva) Date: Thu, 13 Mar 2003 15:26:19 -0500 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact In-Reply-To: <390E55B947E7C848898AEBB9E507706041E48E@msmdcfs01.msmgmt.com> References: <390E55B947E7C848898AEBB9E507706041E48E@msmdcfs01.msmgmt.com> Message-ID: <20030313202619.GP9541@aol.net> On Mon, Mar 10, 2003 at 08:24:18PM -0500, McBurnett, Jim wrote: > Ok - > I think I like this as written.. > BUT-- Am I understanding this correctly: > SWIP Process and ORG-- > If an organization has been SWIPd a Class C and their > Upstreams allow them to use Private ASN for the > advertising of said Class C- That ORG is not an ORG > according to this Policy? > I am not saying this happens, but unless ARIN directly gives > the Resource to the user, does this apply to them? > > I am thinking of a SPAMMER in S Fla..... The IP block is not SWIPPED to them > and they have no ASN and don't seem fit this... > > Not a problem for me.. I want to make sure we address ARIN Resposible ORGs and > not every JOE.. (we just can't do that) sounds like this proposal would ensure (in this case) that the upstream who provided space to the spammer in S Fl would be required to maintain responsive abuse contacts. -ron From ron at aol.net Thu Mar 13 15:30:50 2003 From: ron at aol.net (Ron da Silva) Date: Thu, 13 Mar 2003 15:30:50 -0500 Subject: [ppml] Policy Proposal 2003-1a: Required Performance of Abuse Contact In-Reply-To: <2147483647.1047315965@dhcp156-251.corp.tellme.com> References: <200303041636.LAA26902@ops.arin.net> <2147483647.1047315965@dhcp156-251.corp.tellme.com> Message-ID: <20030313203050.GQ9541@aol.net> On Mon, Mar 10, 2003 at 05:06:07PM -0800, Owen DeLong wrote: > > 2. Can be defined in terms that would allow most > routers to block the abuse in question through > the use of packet filters or other commonly available technology. > > (Commonly available technology for this purpose > means a feature that is present and can be > reasonably implemented in the majority of > backbone router types in use on the Internet > at the time of complaint.) Hmm...other devices or appliances besides 'routers' may facilitate this type of functionality. > ...After the 30 days > has expired or the ORG has terminated the 30 day period as described, > the ABUSE COUNCIL shall have 10 days to make a final determination on > the revocation... This would require the ABUCE COUNCIL to possibly convene every 10 days. If the number of appeals are low, this might be ok though and a non-issue. -ron From Scott.Whipple at cox.com Mon Mar 17 15:55:36 2003 From: Scott.Whipple at cox.com (Whipple, Scott (CCI-Atlanta)) Date: Mon, 17 Mar 2003 15:55:36 -0500 Subject: [ppml] RE: [arin-announce] Policy Proposal 2003-3: Residential Customer Privacy Message-ID: <4B8EA05057E49E4F940B74AC3AEC23F40BB771@CATL0MS03.corp.cox.com> Seeing that there has not been any traffic with this proposal, it would seem not to many people really care. What if we took this one a step further and did not show simple reassignments at all? ISP's would still be required to swip showing utilization, but the records would no longer show up in a whois query. If the ISP needed to see where their utilization statistics are they could send a message to hostmaster asking for a netinfo report. Simple reassignments have no DNS information or POC records associated with them, so if you are trying to trouble shoot a problem that happens to come from a range that has been assigned as a simple reassignment you still need to go to the upstream to get any information that may help. To clarify, there is no useful information that comes from a simple reassignment. What does everyone think? Scott -----Original Message----- From: Member Services [mailto:memsvcs at arin.net] Sent: Tuesday, March 04, 2003 1:07 PM To: arin-announce at arin.net; ppml at arin.net Subject: [arin-announce] Policy Proposal 2003-3: Residential Customer Privacy ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy Meeting in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback received on the mailing list about this policy proposal will be included in the discussions that will take place at the upcoming Public Policy Meeting. This policy proposal discussion will take place on the ARIN Public Policy Mailing List (ppml at arin.net). Subscription information is available at http://www.arin.net/mailing_lists/index.html Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-3: Residential Customer Privacy Privacy of Residential Customer Name and Address Information In WHOIS Policy Proposal Statement: ARIN guidelines presently state that privacy of an individual's residential address information may be protected in WHOIS by indicating "Private Residence". This policy proposal is intended to provide additional information privacy through omission of an individual's name from WHOIS, replacing their name with "Private Individual". The proposed policy would amend and modify the existing ARIN guideline, forming a new, permanent policy. Rationale and Justification: With the continued growth and popularity of DSL service, increasing numbers of individuals and small home-based businesses are taking advantage of this technology. Many of these customers require /29 or larger assignments to support small networks. Knowing that WHOIS is a public database, the majority of these customers have a viable concern regarding the publication of their name and address information in WHOIS. It is the responsibility of an ISP to support the needs of their customers, and protect customer privacy whenever possible. This policy specifically addresses the privacy issue on behalf of home/residential customers. The omission of personal name and address information from WHOIS is analogous to residential telephone service. When residential phone service is activated, the individual's name, address and phone number are listed in the telephone directory. The individual may, however, request an "unlisted" number, and their information is omitted from the directory. This policy proposes the "listing" of the IP subnet in WHOIS, but individual name and address information would be "unlisted". It is the responsibility of the ISP to maintain complete and accurate information regarding the customer's name, address, etc. This information would be made available to ARIN (if requested) for audit of netblock utilization in support of future allocations. In these difficult times, home security and privacy is on everyone's mind. As internet users, service providers and overseers, it is our combined responsibility to do whatever is necessary to ensure the safety, and protect the privacy of the internet community at large. From owen at delong.com Mon Mar 17 16:01:09 2003 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Mar 2003 13:01:09 -0800 Subject: [ppml] RE: [arin-announce] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: <4B8EA05057E49E4F940B74AC3AEC23F40BB771@CATL0MS03.corp.cox.com> References: <4B8EA05057E49E4F940B74AC3AEC23F40BB771@CATL0MS03.corp.cox.com> Message-ID: <2147483647.1047906069@imac-en0.delong.sj.ca.us> I would oppose the original proposal, although my energy has been focused on 2003-1a. I would certainly not take silence on 2003-3 as consent. Taking it the further step you mention is even worse. Owen --On Monday, March 17, 2003 3:55 PM -0500 "Whipple, Scott (CCI-Atlanta)" wrote: > Seeing that there has not been any traffic with this proposal, it would > seem not to many people really care. What if we took this one a step > further and did not show simple reassignments at all? ISP's would still > be required to swip showing utilization, but the records would no longer > show up in a whois query. If the ISP needed to see where their > utilization statistics are they could send a message to hostmaster asking > for a netinfo report. > > Simple reassignments have no DNS information or POC records associated > with them, so if you are trying to trouble shoot a problem that happens > to come from a range that has been assigned as a simple reassignment you > still need to go to the upstream to get any information that may help. > To clarify, there is no useful information that comes from a simple > reassignment. > > What does everyone think? > > Scott > > -----Original Message----- > From: Member Services [mailto:memsvcs at arin.net] > Sent: Tuesday, March 04, 2003 1:07 PM > To: arin-announce at arin.net; ppml at arin.net > Subject: [arin-announce] Policy Proposal 2003-3: Residential Customer > Privacy > > > ARIN welcomes feedback and discussion about the following policy > proposal in the weeks leading to the ARIN Public Policy Meeting > in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback > received on the mailing list about this policy proposal will be > included in the discussions that will take place at the upcoming > Public Policy Meeting. > > This policy proposal discussion will take place on the ARIN Public > Policy Mailing List (ppml at arin.net). Subscription information is > available at http://www.arin.net/mailing_lists/index.html > > Richard Jimmerson > Director of Operations > American Registry for Internet Numbers (ARIN) > >### * ### > > Policy Proposal 2003-3: Residential Customer Privacy > > Privacy of Residential Customer > Name and Address Information > In WHOIS > > Policy Proposal Statement: > > ARIN guidelines presently state that privacy of an individual's > residential address information may be protected in WHOIS by > indicating "Private Residence". This policy proposal is intended > to provide additional information privacy through omission of an > individual's name from WHOIS, replacing their name with > "Private Individual". > > The proposed policy would amend and modify the existing ARIN > guideline, forming a new, permanent policy. > > Rationale and Justification: > > With the continued growth and popularity of DSL service, increasing > numbers of individuals and small home-based businesses are taking > advantage of this technology. Many of these customers require /29 > or larger assignments to support small networks. Knowing that WHOIS > is a public database, the majority of these customers have a viable > concern regarding the publication of their name and address information > in WHOIS. It is the responsibility of an ISP to support the needs of > their customers, and protect customer privacy whenever possible. This > policy specifically addresses the privacy issue on behalf of > home/residential customers. > > The omission of personal name and address information from WHOIS is > analogous to residential telephone service. When residential phone > service is activated, the individual's name, address and phone number > are listed in the telephone directory. The individual may, however, > request an "unlisted" number, and their information is omitted from the > directory. This policy proposes the "listing" of the IP subnet in WHOIS, > but individual name and address information would be "unlisted". > > It is the responsibility of the ISP to maintain complete and accurate > information regarding the customer's name, address, etc. This > information would be made available to ARIN (if requested) for audit > of netblock utilization in support of future allocations. > > In these difficult times, home security and privacy is on everyone's > mind. As internet users, service providers and overseers, it is our > combined responsibility to do whatever is necessary to ensure the > safety, and protect the privacy of the internet community at large. > From ebohlin at UU.NET Mon Mar 17 16:56:11 2003 From: ebohlin at UU.NET (Einar Bohlin) Date: Mon, 17 Mar 2003 16:56:11 -0500 (EST) Subject: [ppml] RE: [arin-announce] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: <4B8EA05057E49E4F940B74AC3AEC23F40BB771@CATL0MS03.corp.cox.com> Message-ID: The two parts of a reassignment are contact information and utilization information. Even though ISPs seem to be taking over the contact part, the utilization information is still valuable. The simple reassignment is nice to have so customers can look up and confirm their own networks. And even when you have your own database, whois lookups are good now and then as a sanity check. Personally I don't like the Private Individual proposal. I believe it's enough that we're already able to list Private Residence (and you don't have to list a phone or email). Also, simple reassignments are used for more than just individuals, they need to have the organization info and be seen. Regards, Einar Bohlin, IP Analyst IP Team - Ashburn Virginia - WorldCom Phone: 703 886-7362 (VNET 806-7362) email: einar.bohlin at wcom.com On Mon, 17 Mar 2003, Whipple, Scott (CCI-Atlanta) wrote: > Seeing that there has not been any traffic with this proposal, it would seem not to many people really care. What if we took this one a step further and did not show simple reassignments at all? ISP's would still be required to swip showing utilization, but the records would no longer show up in a whois query. If the ISP needed to see where their utilization statistics are they could send a message to hostmaster asking for a netinfo report. > > Simple reassignments have no DNS information or POC records associated with them, so if you are trying to trouble shoot a problem that happens to come from a range that has been assigned as a simple reassignment you still need to go to the upstream to get any information that may help. To clarify, there is no useful information that comes from a simple reassignment. > > What does everyone think? > > Scott > > -----Original Message----- > From: Member Services [mailto:memsvcs at arin.net] > Sent: Tuesday, March 04, 2003 1:07 PM > To: arin-announce at arin.net; ppml at arin.net > Subject: [arin-announce] Policy Proposal 2003-3: Residential Customer > Privacy > > > ARIN welcomes feedback and discussion about the following policy > proposal in the weeks leading to the ARIN Public Policy Meeting > in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback > received on the mailing list about this policy proposal will be > included in the discussions that will take place at the upcoming > Public Policy Meeting. > > This policy proposal discussion will take place on the ARIN Public > Policy Mailing List (ppml at arin.net). Subscription information is > available at http://www.arin.net/mailing_lists/index.html > > Richard Jimmerson > Director of Operations > American Registry for Internet Numbers (ARIN) > > ### * ### > > Policy Proposal 2003-3: Residential Customer Privacy > > Privacy of Residential Customer > Name and Address Information > In WHOIS > > Policy Proposal Statement: > > ARIN guidelines presently state that privacy of an individual's > residential address information may be protected in WHOIS by > indicating "Private Residence". This policy proposal is intended > to provide additional information privacy through omission of an > individual's name from WHOIS, replacing their name with > "Private Individual". > > The proposed policy would amend and modify the existing ARIN > guideline, forming a new, permanent policy. > > Rationale and Justification: > > With the continued growth and popularity of DSL service, increasing > numbers of individuals and small home-based businesses are taking > advantage of this technology. Many of these customers require /29 > or larger assignments to support small networks. Knowing that WHOIS > is a public database, the majority of these customers have a viable > concern regarding the publication of their name and address information > in WHOIS. It is the responsibility of an ISP to support the needs of > their customers, and protect customer privacy whenever possible. This > policy specifically addresses the privacy issue on behalf of > home/residential customers. > > The omission of personal name and address information from WHOIS is > analogous to residential telephone service. When residential phone > service is activated, the individual's name, address and phone number > are listed in the telephone directory. The individual may, however, > request an "unlisted" number, and their information is omitted from the > directory. This policy proposes the "listing" of the IP subnet in WHOIS, > but individual name and address information would be "unlisted". > > It is the responsibility of the ISP to maintain complete and accurate > information regarding the customer's name, address, etc. This > information would be made available to ARIN (if requested) for audit > of netblock utilization in support of future allocations. > > In these difficult times, home security and privacy is on everyone's mind. > As internet users, service providers and overseers, it is our combined > responsibility to do whatever is necessary to ensure the safety, and > protect the privacy of the internet community at large. > > From jlewis at lewis.org Mon Mar 17 23:51:52 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Mon, 17 Mar 2003 23:51:52 -0500 (EST) Subject: [ppml] RE: [arin-announce] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: <4B8EA05057E49E4F940B74AC3AEC23F40BB771@CATL0MS03.corp.cox.com> Message-ID: On Mon, 17 Mar 2003, Whipple, Scott (CCI-Atlanta) wrote: > Seeing that there has not been any traffic with this proposal, it would > seem not to many people really care. What if we took this one a step > further and did not show simple reassignments at all? ISP's would still > be required to swip showing utilization, but the records would no longer > show up in a whois query. If the ISP needed to see where their The anti-spam community would not appreciate that. Simple reassignments are at least a publicly visible demarcation of IP blocks...making it possible for those who would choose to, to block an entire block with minimal collateral damage. IMO, making simple reassignments invisible would be a bad idea. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Michael.Dillon at radianz.com Tue Mar 18 05:40:54 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 18 Mar 2003 10:40:54 +0000 Subject: [ppml] RE: [arin-announce] Policy Proposal 2003-3: Residential Customer Privacy Message-ID: >Personally I don't like the Private Individual proposal. I don't like it either. It's another example of bad policy that is too detailed and therefore misses solving the problem. The fact is that some organizations or individuals who receive IP addresses, either don't want to publish contact information or else they are clueless in some way so there is no point in publishing contact information. Therefore, a reasonable policy would state something like this: There MUST be contact information published for all IP address sub-allocations and assignments. The contact information MAY belong to the upstream organization rather than the address user but it MUST lead to people who can deal with issues such as network abuse. See how simple things could be. We want contact information that is accurate and is usable because it leads to people who can take action. Sometimes the address user can meet the need for such contact info but other times the ISP is the only one who can meet these needs. If an ISP has a large organization as a customer using a /20 of IP address space, they can still hide the identity of this organization and keep everybody happy as long as the ISP themselves will act as the contact point. The only area of possible concern is that ARIN may wish to see the full identity in order to audit address usage. If we would only get rid of this antique technology of SWIP and whois and rwhois then this would not be a problem. LDAP allows secure access and it allows one to define that only certain users can see certain info. Therefore it is simplicity for an ISP to run an LDAP server that provides public access to public info and lets ARIN people, under NDA, have a peek at more detail. Of course, if we don't want to use modern technology like LDAP, we can still meet the ARIN requirement by sending them some kind of files or databases anytime they do an audit. But that's a process problem and I don't think we need policy to solve it. P.S. I think the best use of the upcoming meeting is not to discuss the policies on the table. Rather, I believe it would be more fruitful to discuss some draft policies that can be discussed over the next few months and then voted on at the next meeting. There seems to be some interest right now in policy revision, but I believe it would be a mistake to rush in and make policy in the disorganized fashion currently in use. From ppml at rsuc.gweep.net Tue Mar 18 06:01:04 2003 From: ppml at rsuc.gweep.net (Joe Provo) Date: Tue, 18 Mar 2003 06:01:04 -0500 Subject: [ppml] RE: [arin-announce] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: References: Message-ID: <20030318110103.GA2046@gweep.net> On Tue, Mar 18, 2003 at 10:40:54AM +0000, Michael.Dillon at radianz.com wrote: > >Personally I don't like the Private Individual proposal. > > I don't like it either. It's another example of bad policy that is too > detailed and therefore misses solving the problem. The fact is that some > organizations or individuals who receive IP addresses, either don't want > to publish contact information or else they are clueless in some way so > there is no point in publishing contact information. Therefore, a > reasonable policy would state something like this: > > There MUST be contact information published for all IP address > sub-allocations and assignments. > The contact information MAY belong to the upstream organization rather > than the address user > but it MUST lead to people who can deal with issues such as network > abuse. Personally, I find it sad that there is some innate expectation that people have some 'right' to chunks of address space and can hide from the responsibility. The 'residential telephone listing' is bogus as the security concerns for IP are wildly different; resources can and are abused by 'action at a distance' which is not possible in the circuit-switched world. All that said, M Dillon's simplification above would satisfy me, and I expect many of the accountability-minded. [snip technology gripes] The tools can and will change over time. It muddies the issue to chase a particular technology of the day (or yesterday) as a solution when the solution lies in the process and data held. Cheers, Joe -- ppml at rsuc.gweep.net RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From db6906 at sbc.com Tue Mar 18 11:48:50 2003 From: db6906 at sbc.com (BARGER, DAVE (SBIS)) Date: Tue, 18 Mar 2003 10:48:50 -0600 Subject: [ppml] RE: [arin-announce] Policy Proposal 2003-3: Residentia l Customer Privacy Message-ID: <6CE0DC2F2ED2B94F80357B939C56740107D6C397@sbis0.sbcis.sbc.com> The intention of this proposal is simply to protect individual's desire to remain anonymous, and protect their personal privacy. It is not intended to address a specific technology - DSL is used in this context simply to illustrate by example the type of customer requesting further need for privacy. With that said, the simple reassignments represented by this slice of the user community are only a portion of all simple reassignments. Corporate (non-residential) businesses would still be expected to fully disclose information, and that information would be published in Whois. I agree with Michael Dillion in that there must be published information and contacts for a real person/team that is accountable - teams that deal with network and abuse issues. But if the ISP has detailed POC information in Whois, wouldn't that be sufficient (just a click away in the net handle link)? Dave Barger Senior Technical Director Network Engineering IP Management SBC Internet Services 214-495-2098 (office) 877-514-7507 (pager) -----Original Message----- From: Joe Provo [mailto:ppml at rsuc.gweep.net] Sent: Tuesday, March 18, 2003 5:01 AM To: ppml at arin.net Subject: Re: [ppml] RE: [arin-announce] Policy Proposal 2003-3: Residential Customer Privacy On Tue, Mar 18, 2003 at 10:40:54AM +0000, Michael.Dillon at radianz.com wrote: > >Personally I don't like the Private Individual proposal. > > I don't like it either. It's another example of bad policy that is too > detailed and therefore misses solving the problem. The fact is that some > organizations or individuals who receive IP addresses, either don't want > to publish contact information or else they are clueless in some way so > there is no point in publishing contact information. Therefore, a > reasonable policy would state something like this: > > There MUST be contact information published for all IP address > sub-allocations and assignments. > The contact information MAY belong to the upstream organization rather > than the address user > but it MUST lead to people who can deal with issues such as network > abuse. Personally, I find it sad that there is some innate expectation that people have some 'right' to chunks of address space and can hide from the responsibility. The 'residential telephone listing' is bogus as the security concerns for IP are wildly different; resources can and are abused by 'action at a distance' which is not possible in the circuit-switched world. All that said, M Dillon's simplification above would satisfy me, and I expect many of the accountability-minded. [snip technology gripes] The tools can and will change over time. It muddies the issue to chase a particular technology of the day (or yesterday) as a solution when the solution lies in the process and data held. Cheers, Joe -- ppml at rsuc.gweep.net RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From memsvcs at arin.net Tue Mar 18 17:15:24 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 18 Mar 2003 17:15:24 -0500 (EST) Subject: [ppml] ARIN XI Meeting Agenda and Registration Message-ID: ARIN XI in Memphis, TN is fast approaching! The expanded agenda has just been posted to the meeting web page. View the agenda and register for the meeting at the following url: http://www.arin.net/ARIN-XI/index.html Our host hotel, The Peabody, has informed us they have a limited amount of rooms still available at the $170 rate for Sunday, April 6th through Wednesday, April 9th. These rooms are available on a first-come, first-served basis. If you still need a room, please call The Peabody directly at 901-529-4000 for reservations. If you have questions regarding ARIN XI, please feel free to contact Edward Pizzarello, ARIN Event Coordinator, at 703-227-9878, or via e-mail at pizza at arin.net. ARIN Member Services =================================================================== email memsvcs at ARIN.NET ftp ftp.arin.net whois whois.arin.net website http://www.arin.net =================================================================== From memsvcs at arin.net Wed Mar 19 10:35:17 2003 From: memsvcs at arin.net (Member Services) Date: Wed, 19 Mar 2003 10:35:17 -0500 (EST) Subject: [ppml] Annual Maintenance Fees Message-ID: <200303191535.KAA00770@ops.arin.net> At the ARIN X Public Policy Meeting held in Eugene, Oregon, October 30-31, 2002, a discussion about adjusting maintenance fees was held. There was general agreement amongst the attendees that the maintenance fees needed adjustment. The minutes of the ARIN X Public Policy Meeting are available at http://www.arin.net/policy/pol_min.html. At its January 10, 2003 meeting, the ARIN Board of Trustees discussed the issue of adjusting maintenance fees. It was the sense of the Board that since there was community support at the ARIN Public Policy Meeting to adjust the fees, the Board would adopt the fee change, and it could be further discussed at the ARIN meeting in April in Memphis, TN. The minutes of the ARIN Board of Trustees meeting are available at http://www.arin.net/library/minutes/bot/bot2003_0110.html. Beginning July 1, 2003, the annual maintenance fee will be $100. In cases where a single organization has more than one registration record in the ARIN database that is normally charged annual maintenance fees, only a single consolidated maintenance fee of $100 will be invoiced. Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Fri Mar 21 11:27:01 2003 From: memsvcs at arin.net (Member Services) Date: Fri, 21 Mar 2003 11:27:01 -0500 (EST) Subject: [ppml] ARIN Policy Proposals Message-ID: <200303211627.LAA29406@ops.arin.net> ARIN will hold its next Public Policy Meeting in Memphis, Tennessee on April 7-8, 2003. Meeting and registration details can be found at: http://www.arin.net/ARIN-XI/index.html Policy discussions that will take place at this meeting are identified on the meeting agenda available at the URL listed below. Discussions will be centered around policy proposals just recently introduced to the public policy mailing list in 2003, and those carried over from the previous public policy meeting. New messages will be posted to this list for the policy proposals carried over from the last meeting to encourage further discussion. http://www.arin.net/ARIN-XI/agenda.html Leading up to the meeting, the policy proposals are open for discussion on this mailing list. Each of the policy proposals have been posted to this mailing list as an independent thread to facilitate discussion. A summary of the active policy proposals under discussion is available at: http://www.arin.net/policy/proposal_archive.html The entire Internet community is invited and encouraged to participate in these policy discussions. Your active participation in these discussions is vital to the process and will help to form policies that are beneficial to all. Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Fri Mar 21 11:33:46 2003 From: memsvcs at arin.net (Member Services) Date: Fri, 21 Mar 2003 11:33:46 -0500 (EST) Subject: [ppml] 2002-2: Experimental Internet Resource Allocations Message-ID: <200303211633.LAA00860@ops.arin.net> This policy proposal is being re-posted to the public policy mailing list to encourage continued discussion. This policy proposal was previously discussed on this mailing list and at the ARIN X Public Policy Meeting. Following previous discussions on this mailing list and at the ARIN X Public Policy Meeting, it has been determined consensus to pass this proposal as a new policy has not yet been achieved. Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2002-2: Experimental Internet Resource Allocations There have been a number of experimental address allocations undertaken in the Internet over the past decade. These experimental address allocations have been made by the IANA in coordination with standards bodies, such as the IETF, on an ad hoc basis. There is currently no systematic means of receiving other Numbering Resources on a temporary basis as part of a recognised experiment in Internet technology deployment. The following policy is proposed: The RIRs will allocate Numbering Resources to entities requiring temporary Numbering Resources for a fixed period of time under the terms of recognised experimental activity. The following criteria for this policy are proposed: 1. Public Disclosure of Experimental Requests The organisation requesting the resources will have to detail what experimental work they are going to carry out. Such detail can usually be made either: * by submitting a proposal that references a current IETF Experimental RFC (Detail Two), or * by submitting an 'experiment proposal' detailing what resources are required, and what activities will be carried out (Detail Three). Such experimental proposals will, in the normal course of events be made public upon acceptance of the proposal by an RIR. Consideration will be given to non-disclosure constraints, but this is anticipated to be a prohibitive constraint upon the use of public Numbering Resources, even in an experimental context. The RIR will not allocate resources if the entire research experiment cannot be publicly disclosed as per Details Two and Three following. 2. Resource Coordination with Standards Development Bodies The IETF from time to time describes experimental activities and associated requirements for resources that will be required by participants in the experiment. It is considered as being acceptable for the organisation to reference a current Experimental RFC and indicate the organisation's participation in the experiment. Organisations such as the IETF, who describe experimental activities as part of their standards development process, need to consider the associated Numbering Resource requirements with any proposed experiment, and under this proposal will need to liaise with the RIRs as part of the process of publishing a draft as an experimental RFC. 3. Resource Coordination with Independent Experiments For experimental proposals not covered by Detail Two, the RIR will require the experiment's aims and objectives to be published in a publicly accessible document. The RIRs have a strong preference for the use of an Experimental RFC published through the IETF, but will accept other publication mechanisms where the experiment's objectives and practices are publicly and openly available free of charges and free of any constraints of disclosure. The RIRs would also normally require that the experiment's outcomes be published in an openly and freely available document, again free of charges and free of any constraints of disclosure. 4. Resource Allocation Term and Renewal The Numbering Resources are allocated on a lease/license basis for a period of one year. The allocation can be renewed on application to the issuing RIR providing information as per in Detail One. The identity and details of the applicant and the allocated Numbering Resources will be published under the conditions of the RIR's normal publication policy (for example, listed as a temporary allocation in the RIR's database). 5. Single Resource Allocation per Experiment The RIR will make one-off allocations only, on an annual basis. Additional allocations outside the annual cycle will not be made unless justified by a subsequent complete application. It's important for the requesting organisation to ensure they have sufficient resources requested as part of their initial application for the proposed experimental use. 6. Resource Allocation Fees Each RIR may charge an administration fee to cover each allocation made of these experimental resources. This fee simply covers registration and maintenance, rather than the full allocation process for standard RIR members. This administration fee should be as low as possible as these requests do not have to undergo the same evaluation process as those requested in the normal policy environment. 7. Resource Allocation Size The Numbering Resources requested come from the global Internet Resource space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing RIR minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organisation requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, they should include in their research proposal why this is required. 8. Commercial Use Prohibited If there is any evidence that the temporary resource is being used for commercial purposes, or is being used for any activities not documented in the original experiment description provided to the RIR, the issuing RIR reserves the right to immediately withdraw the resource and reassign it to the free pool. 9. Resource Request Appeal or Arbitration The RIRs should be in a position to assess and comment on the objectives of the experiment with regard to the requested amount of Numbering Resources. The issuing RIR should be able to modify the requested allocation as appropriate, and in agreement with the proposer. In the event that the proposed modifications are not acceptable, the requesting organization may request an appeal or arbitration using the normal procedures of the RIR. In this case, the original standards body that endorsed the experimental action may be requested to provide additional information regarding the experiment and its objectives to assist in the resolution of the appeal. From memsvcs at arin.net Fri Mar 21 11:38:51 2003 From: memsvcs at arin.net (Member Services) Date: Fri, 21 Mar 2003 11:38:51 -0500 (EST) Subject: [ppml] 2002-3: Micro-Assignments for Multihomed Networks Message-ID: <200303211638.LAA01775@ops.arin.net> This policy proposal is being re-posted to the public policy mailing list to encourage continued discussion. This policy proposal was previously discussed on this mailing list and at the ARIN X Public Policy Meeting. Following previous discussions on this mailing list and at the ARIN X Public Policy Meeting, it has been determined consensus to pass this proposal as a new policy has not yet been achieved. The authors have modified the text to clarify the intent and purpose of the proposal. Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks Modify Policy: End User Assignments Old text: The minimum block of IP address space assigned by ARIN is a /20. If assignments smaller than /20 are needed, end-users should contact their upstream provider. New text: If an end-user is not multi-homed, the minimum block of IP address space assigned by ARIN is a /20. If assignments smaller than /20 are needed, end-users should contact their upstream provider. If an end-user is multi-homed, and has an ARIN assigned ASN, the minimum block of IP address space assigned by ARIN is a /22. If assignments smaller than a /22 are needed, end users should contact their upstream provider. Problem Summary: Many end-user organizations are choosing to multi-home for reliability reasons. At the same time, many are using technologies such as NAT, or load balancers that reduce the need for external IP space. These groups are forced today to take one of two actions: 1) Use IP space from one of their upstreams on both connections. This can lead to load balancing issues, and also makes the end-user more dependent on the ISP who assigned the space. The ISP's business problems, for instance could force downtime and/or renumbering. 2) "Waste" address space (often by not using the technologies that conserve it) in order to qualify for a /20 under the current policy. In order to allow people to both conserve address space, and reap the benefits of multi-homing the minimum size assignment for those who do multi-home should be made smaller. From forrest at almighty.c64.org Fri Mar 21 12:01:25 2003 From: forrest at almighty.c64.org (Forrest) Date: Fri, 21 Mar 2003 11:01:25 -0600 (CST) Subject: [ppml] 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: <200303211638.LAA01775@ops.arin.net> Message-ID: On Fri, 21 Mar 2003, Member Services wrote: > New text: > If an end-user is not multi-homed, the minimum block of IP > address space assigned by ARIN is a /20. If assignments > smaller than /20 are needed, end-users should contact their > upstream provider. > > If an end-user is multi-homed, and has an ARIN assigned > ASN, the minimum block of IP address space assigned by > ARIN is a /22. If assignments smaller than a /22 are > needed, end users should contact their upstream provider. I'm not sure I see the point in reducing the minimum allocation from /20 to /22. Are people going to come back 3 years from now and want the proposal changed again to make the minimum /24? One of the arguments for changing the minimum allocation is that people currently lie about their needs and uses in order to qualify for a /20. I think with this proposal, people that could get by with a /24 are going to find creative ways to waste addresses to qualify for a /22. Whether someone receives a /24 or a /22, its only one added prefix to the global routing tables, so why not give people what they REALLY need and conserve IP space. I strongly feel there needs to be a mechanism added that enables IP space to be reclaimed if an organization ceases to be multihomed. Is it possible for someone to tack on all of the discussion from 2002-7 onto this proposal. No need to rehash everything that's already been said. Forrest > > Problem Summary: > Many end-user organizations are choosing to multi-home > for reliability reasons. At the same time, many are > using technologies such as NAT, or load balancers that > reduce the need for external IP space. These groups > are forced today to take one of two actions: > > 1) Use IP space from one of their upstreams on both > connections. This can lead to load balancing > issues, and also makes the end-user more dependent > on the ISP who assigned the space. The ISP's > business problems, for instance could force downtime > and/or renumbering. > > 2) "Waste" address space (often by not using the > technologies that conserve it) in order to qualify > for a /20 under the current policy. > > In order to allow people to both conserve address > space, and reap the benefits of multi-homing the > minimum size assignment for those who do multi-home > should be made smaller. > From memsvcs at arin.net Fri Mar 21 12:05:35 2003 From: memsvcs at arin.net (Member Services) Date: Fri, 21 Mar 2003 12:05:35 -0500 (EST) Subject: [ppml] 2002-5: Amnesty Requests Message-ID: <200303211705.MAA07234@ops.arin.net> This policy proposal is being re-posted to the public policy mailing list to encourage continued discussion. This policy proposal was previously discussed on this mailing list and at the ARIN X Public Policy Meeting. Following previous discussions on this mailing list and at the ARIN X Public Policy Meeting, it has been determined consensus to pass this proposal as a new policy has not yet been achieved. Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2002-5: Amnesty Requests If an organization, whether a member or non-member, ISP or end-user, relinquishes a larger block of portable address space to ARIN, they shall be allowed to receive a smaller block, /24 or shorter, in exchange. The organization will not be required to justify their use of the new, smaller block. The organization must return the block to be exchanged within 12 months. ARIN staff shall, at their discretion, determine whether the smaller replacement block shall be a subnet of the returned block, or a block allocated from some different range. If any of the relinquished blocks had associated maintenance fees, then the new block will be subject to the appropriate fees for that block size. Likewise those without maintenance fees shall remain so. From memsvcs at arin.net Fri Mar 21 12:06:45 2003 From: memsvcs at arin.net (Member Services) Date: Fri, 21 Mar 2003 12:06:45 -0500 (EST) Subject: [ppml] 2002-6: Aggregation Requests Message-ID: <200303211706.MAA07404@ops.arin.net> This policy proposal is being re-posted to the public policy mailing list to encourage continued discussion. This policy proposal was previously discussed on this mailing list and at the ARIN X Public Policy Meeting. Following previous discussions on this mailing list and at the ARIN X Public Policy Meeting, it has been determined consensus to pass this proposal as a new policy has not yet been achieved. Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2002-6: Aggregation Requests If an organization, whether a member or non-member, ISP or end-user, relinquishes a group of portable, non-aggregatable address blocks to ARIN, they shall be allowed to receive a block in exchange, /24 or shorter, but no more than the shortest block that could contain all of the returned blocks. Exchanged space shall be returned within 12 months. For example, if an organization relinquished three /24s, they should be allowed to take either a /24, a /23, or a /22 in exchange. If all of the previous address blocks were maintained in the ARIN database without maintenance fees, the replacement space shall be as well, but if any one of the returned blocks had associated maintenance fees, then the replacement block shall also be subject to maintenance fees. From richardj at arin.net Fri Mar 21 12:12:12 2003 From: richardj at arin.net (Richard Jimmerson) Date: Fri, 21 Mar 2003 12:12:12 -0500 Subject: [ppml] 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: Message-ID: <006f01c2efcd$04853c90$258888c0@arin.net> Hello Forrest, > Is it possible for someone to tack on all of the discussion > from 2002-7 onto this proposal. No need to rehash everything > that's already been said. Because of the similarities between 2002-3 and 2002-7, the discussion that has taken place on this list for 2002-7 will be included in the discussion summary for 2002-3 at the upcoming ARIN XI public policy meeting. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Forrest > Sent: Friday, March 21, 2003 12:01 PM > To: ppml at arin.net > Subject: Re: [ppml] 2002-3: Micro-Assignments for Multihomed Networks > > > > On Fri, 21 Mar 2003, Member Services wrote: > > > New text: > > If an end-user is not multi-homed, the minimum block of IP > > address space assigned by ARIN is a /20. If assignments > > smaller than /20 are needed, end-users should contact their > > upstream provider. > > > > If an end-user is multi-homed, and has an ARIN assigned > > ASN, the minimum block of IP address space assigned by > > ARIN is a /22. If assignments smaller than a /22 are > > needed, end users should contact their upstream provider. > > > > I'm not sure I see the point in reducing the minimum > allocation from /20 > to /22. Are people going to come back 3 years from now and want the > proposal changed again to make the minimum /24? One of the > arguments for > changing the minimum allocation is that people currently lie > about their > needs and uses in order to qualify for a /20. I think with > this proposal, > people that could get by with a /24 are going to find > creative ways to > waste addresses to qualify for a /22. Whether someone > receives a /24 or a > /22, its only one added prefix to the global routing tables, > so why not > give people what they REALLY need and conserve IP space. > > I strongly feel there needs to be a mechanism added that > enables IP space > to be reclaimed if an organization ceases to be multihomed. > > Is it possible for someone to tack on all of the discussion > from 2002-7 > onto this proposal. No need to rehash everything that's already been > said. > > Forrest > > > > > > Problem Summary: > > Many end-user organizations are choosing to multi-home > > for reliability reasons. At the same time, many are > > using technologies such as NAT, or load balancers that > > reduce the need for external IP space. These groups > > are forced today to take one of two actions: > > > > 1) Use IP space from one of their upstreams on both > > connections. This can lead to load balancing > > issues, and also makes the end-user more dependent > > on the ISP who assigned the space. The ISP's > > business problems, for instance could force downtime > > and/or renumbering. > > > > 2) "Waste" address space (often by not using the > > technologies that conserve it) in order to qualify > > for a /20 under the current policy. > > > > In order to allow people to both conserve address > > space, and reap the benefits of multi-homing the > > minimum size assignment for those who do multi-home > > should be made smaller. > > > From forrest at almighty.c64.org Fri Mar 21 12:23:57 2003 From: forrest at almighty.c64.org (Forrest) Date: Fri, 21 Mar 2003 11:23:57 -0600 (CST) Subject: [ppml] 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: <006f01c2efcd$04853c90$258888c0@arin.net> Message-ID: Hi Richard, thanks for the info, could the discussion from 2002-7 also get included with proposal 2003-6? That proposal also relates to Micro-Assignments and I think the discussion is relevant to that proposal as well. Forrest On Fri, 21 Mar 2003, Richard Jimmerson wrote: > Hello Forrest, > > > Is it possible for someone to tack on all of the discussion > > from 2002-7 onto this proposal. No need to rehash everything > > that's already been said. > > Because of the similarities between 2002-3 and 2002-7, > the discussion that has taken place on this list for 2002-7 > will be included in the discussion summary for 2002-3 at the > upcoming ARIN XI public policy meeting. > > Best Regards, > > Richard Jimmerson > Director of Operations > American Registry for Internet Numbers (ARIN) > From richardj at arin.net Fri Mar 21 12:35:48 2003 From: richardj at arin.net (Richard Jimmerson) Date: Fri, 21 Mar 2003 12:35:48 -0500 Subject: [ppml] 2002-3: Micro-Assignments for Multihomed Networks In-Reply-To: Message-ID: <007001c2efd0$4fa75e80$258888c0@arin.net> Hello Forrest, > Hi Richard, thanks for the info, could the discussion from > 2002-7 also get included with proposal 2003-6? That proposal > also relates to Micro-Assignments and I think the discussion > is relevant to that proposal as well. Yes, some of the discussion for 2002-7 can be included in the discussion summary for 2003-6. Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Forrest > Sent: Friday, March 21, 2003 12:24 PM > To: ppml at arin.net > Subject: RE: [ppml] 2002-3: Micro-Assignments for Multihomed Networks > > > > Hi Richard, thanks for the info, could the discussion from > 2002-7 also get > included with proposal 2003-6? That proposal also relates to > Micro-Assignments and I think the discussion is relevant to > that proposal > as well. > > Forrest > > > On Fri, 21 Mar 2003, Richard Jimmerson wrote: > > > Hello Forrest, > > > > > Is it possible for someone to tack on all of the discussion > > > from 2002-7 onto this proposal. No need to rehash everything > > > that's already been said. > > > > Because of the similarities between 2002-3 and 2002-7, > > the discussion that has taken place on this list for 2002-7 will be > > included in the discussion summary for 2002-3 at the > upcoming ARIN XI > > public policy meeting. > > > > Best Regards, > > > > Richard Jimmerson > > Director of Operations > > American Registry for Internet Numbers (ARIN) > > > > > > From Michael.Dillon at radianz.com Mon Mar 24 09:25:05 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 24 Mar 2003 14:25:05 +0000 Subject: [ppml] Blacklist, whitelist, DUL question Message-ID: I know that there are various address range blacklists that identify SPAM sources and that some people have whitelists of mail servers known to be clean. In both cases, these lists are making a somewhat moralistic statement about the address range. Then there is the DUL which does not make a moralistic statement but merely identifies addresses used for dialup Internet connections. Does anyone know of a list that identifies address ranges in which there are no mail servers? In other words, the range in question is used for network infrastructure or perhaps used for customers who have agreed not to set up Internet accessible mail servers in the range. I have some address ranges that should never contain mail servers which I would like to place in such a list so that people can reject email containing these addresses but I do not want these ranges to be part of a blacklist because of the taint associated with it. Ideally, the list would also be used to filter spam complaints as well so that if someone does receive SPAM containing a forged Received header then they will not send a complaint to the abuse address for these blocks. ------------------------------------------------------- Michael Dillon Network Product Engineering, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From jrace at attglobal.net Mon Mar 24 10:08:30 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Mon, 24 Mar 2003 22:08:30 +0700 Subject: [ppml] Blacklist, whitelist, DUL question Message-ID: <200303241508.h2OF8h34080208@smtp1.arin.net> On Mon, 24 Mar 2003 14:25:05 +0000, Michael.Dillon at radianz.com wrote: >Does anyone know of a list that identifies address ranges in which there >are no mail servers? I believe this is being discussed in a thread on Spam-L. You may wish to repost there Jeffrey Race From memsvcs at arin.net Tue Mar 25 15:09:12 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 25 Mar 2003 15:09:12 -0500 (EST) Subject: [ppml] Be a Part of ARIN XI, April 6-9 in Memphis Message-ID: There is still time to make plans to attend ARIN's Public Policy and Members meeting at the Peabody Hotel in Memphis, Tennessee beginning Sunday afternoon, April 6. Remember, all ARIN member organizations may send two representatives at no cost. Links to the agenda, registration and hotel information can be found at: http://www.arin.net/ARIN-XI/index.html With over a dozen policy proposals on the agenda, there is certain to be at least one issue discussed that could impact your business. If you can't make it to Memphis, use the public policy mailing list, ppml at arin.net, to register your opinion concerning any of the proposals. You can subscribe to this public list at: http://ww1.arin.net/mailing_lists/index.html We look forward to seeing many of you in April. ARIN Member Services =================================================================== email memsvcs at ARIN.NET ftp ftp.arin.net whois whois.arin.net website http://www.arin.net =================================================================== From owen at delong.com Tue Mar 25 17:51:15 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Mar 2003 14:51:15 -0800 Subject: [ppml] Policy Porposal 2003-1b In-Reply-To: <2147483647.1047315965@dhcp156-251.corp.tellme.com> References: <200303041636.LAA26902@ops.arin.net> <2147483647.1047315965@dhcp156-251.corp.tellme.com> Message-ID: <2147483647.1048603875@dhcp156-237.corp.tellme.com> OK... I've received some really good feedback on 2003-1a. Almost all the feedback I have received on this version has been positive. The negative feedback falls into three categories... 1. They seem to support what I intended the policy to say, but they didn't think the policy said it. Usually this was a perception that the policy put ARIN in the position of judging abuse and revoking resources for abuse. I don't think that's appropriate, nor do I think anyone has come up with a sufficiently concrete definition of abuse to make that feasible. I attempted to put some guidelines in for a relatively restrictive definition of abuse to prevent ARIN from revoking resources if abuse was _NOT_ present. Further, even if a network is abusing, if they are providing a valid and usable abuse contact which is reachable, ARIN's job is over, and the resolution of any dispute should be up to the respective network owners. ARIN's role ends with facilitating the communication between the parties. 2. They seem to support the requirements, but they don't think ARIN should be allowed to revoke resources and they don't feel that any enforcement provisions should be made. Frankly, in my opinion, without enforcement provisions, this policy won't accomplish much. As such, I will keep the provisions in, and if someone wants to bring an amendment to remove them to a vote at the policy meeting, that's fine. Otherwise, we'll agree to disagree and leave the decision to a vote. 3. They believe this policy will create legal expenses beyond ARIN's capabilities and that the ARIN board will have to reject the enforcement provisions of this policy to avoid legal complications. I haven't been able to get any advice from ARIN on that issue, but I hope something will be forthcoming soon. It is my hope that since ARIN will only be revoking resources as a result of failure to meet a contractual obligation to keep current functional contact information available, the anticipated legal hassles would be minimal. I am hoping that ARIN's legal staff and board will concur. That having been said, below is the revised 2003-1b to attempt to clarify the issues raised by groups 1 and 3. I hope that the people in group 2 will realize that all I am attempting to enforce is a requirement for responsive abuse contacts and come to support that. I will be at the meeting in Memphis. In order to provide people a fair opportunity to review the policy prior to the meeting, this will be the last revision. This version will be presented at the meeting. (I may make syntactic or typographical corrections prior to the meeting if they come to my attention). There seems to be pretty good consensus around 2003-1a, and this only represents minor changes to that version. I received approximately three times as many positive comments as I did negative comments. Of the negative comments, 2/3's of them fell into group 1. Only one person fell into group 3. There were two people in group 2. >> Came from 2003-1 > Came from 2003-1a New for 2003-1b >> > Policy Proposal 2003-1a: Required Performance of Abuse Contact >> >> 1. Statement of proposed Policy: >> > For the purposes of this policy, the following terms shall apply: > > ORG An organization or organizational unit which receives one or more > resources from ARIN, whether by allocation or assignment. In either > case, the ORG in question shall bear full responsibility under > this policy for meeting the requirements thereof and bearing > any consequences of failure to meet said responsibilities. > > This shall apply to the ORG to which ARIN directly allocated the > resource, or to another ORG, which, has received from the previous > ORG a transfer of the resources under ARIN's transfer policies. > A simply SWIP of an assignment to an ORG which does not have > a contractual relationship with ARIN shall not constitute such > a transfer. > > MAINTAINER > The appointed POC units which have authority and access to make > changes to the ARIN held data regarding a resource owned by a > particular ORG. > > POC A point of contact, whether human or role. > > ABUSE CONTACT > This policy makes no effort to define Abuse. It is the opinion > of the author of this policy that such a definition should come > from the IETF and not from ARIN. It is the intent of this policy > to set standards for the response required from an abuse contact > without addressing the actions required by said contact. Again, > it is the opinion of the author that said actions are outside > of ARIN's scope and belong within the IETF. > > An ABUSE contact is a POC for an ORG which is associated with an > ARIN issued resource as the POC responsible for addressing issues > of abuse originating at or from the resource in question. > > RESOURCE > In the case of ARIN, resources currently include ASNs and IPv4 > and IPv6 address ranges which are allocated or assigned to > registered ORGs. > > ASN An autonomous system number > > IPv4 Internet Protocol Version 4 > > IPv6 Internet Protocol Version 6 > > Proposed Policy > > For any given RESOURCE in the ARIN database, ARIN shall require at least > one and allow multiple ABUSE CONTACTS to be listed. For at least one > ABUSE CONTACT in each resource, ARIN shall require and maintain at least > the following information: > > 1. Individual or Role > > 2. If Individual, full name > > 3. Address valid for Legal Service > Must support physical delivery, registered mail, or both, > and shall indicate which is acceptable. > > 4. Email Address. > > 5. A list of "normal business hours" specified in terms of the > time zone applicable to the address in item 3 or in UTC, with > an indication of whether DST should be considered. These > hours should comprise at least 30 hours per week. > > 6. A phone number > > 7. A URL where the ORG maintains a web site listing it's ABUSE > POLICIES. > > Each ORG shall be required to meet the following standards with respect > to the performance and responsiveness of the required ABUSE CONTACT, > and each ABUSE CONTACT which contains all of the data specified above. > In cases where the language cannot be logically applied to a ROLE account, > it shall mean all individuals assigned by the ORG in question to read the > email or answer the phone calls to the addresses/numbers listed in the > ABUSE CONTACT. > > 1. With the exception of sudden events of large call volume, > shall staff adequately to have live humans answer calls > to the listed abuse contact phone number during the hours > indicated in the contact record. > > 2. Shall have a human being read and respond to abuse complaints > received by email within 48 hours of receipt (for complaints > received Sun-Thu), and, within 96 hours for complaints > received Fri-Sat. > > 3. Shall be capable of taking action or immediately contacting > a person capable of taking action to stop any reported abuse > which is in violation of any of the following: > > A. Any definition of network abuse published by the > IETF. (This shall not be construed to include any > minor failure to comply with an RFC, but shall only > apply to things the IETF has specifically defined as > abuse). > > B. Any definition of network abuse determined by the > ORG to be abuse in any of their own published AUPs. > > C. Any definition of network abuse which meets all of the > following criteria: > > 1. Is defined as abuse in a policy published > on the complaining networks ABUSE CONTACT > URL. > > 2. Can be defined in terms that would allow most > routers to block the abuse in question through > the use of packet filters or other commonly > available technology. > > (Commonly available technology for this purpose > means a feature that is present and can be > reasonably implemented in the majority of > backbone router types in use on the Internet > at the time of complaint.) > > 3. Is not a standard response to traffic being > received from the complaining network. > It should be noted that this requirement is for the capability to take action to be present. It does not require the individual in question to take the desired action. That matter is between the parties. The ARIN agreement requires the contact to be available to respond. > 4. Shall respond to the complaint as soon as > practicable with information on what actions are > being taken to stop the abuse. > > Further, if an entity believes an ORG is not living up to the requirements > set forth in this policy, they should be able to notify ARIN of the issue, > including detailed documentation of the efforts made to contact the ORG > and the results thereof. Any complaint received by ARIN which does not > include the required information should receive only a form-reply from > ARIN indicating what information is required to verify the complaint. > > In the event of a valid complaint, ARIN shall attempt to contact the ORG > in question and notify them of the complaint. If ARIN is able to contact > the ORG in question, ARIN should wait two weeks and contact the > complainant. If the complainant is satisfied, no further action is > required by ARIN. If the complainant is not satisfied, ARIN staff shall > make a determination whether the complaint meets the definitions of abuse > in 3 above. Further, the ARIN staff shall make a determination if the > response and actions taken by the ORG in question meet the requirements > of the policy. > If the ARIN staff determines that the complaint meets the > requirements and that the response of the ORG in question has not met the > requirements of this policy, the ARIN staff shall inform the ORG of these > facts, specifically indicating what additional response and/or action is > necessary to comply. The ORG shall then have 5 business days or a longer > reasonable time as determined by the ARIN staff to comply. If the ORG > remains out of compliance, then the ARIN staff shall revoke each and > every specific resource listed in the complaint and determined to be out > of compliance with this policy. > > If a resource is revoked under this policy, it shall be referred to the > ARIN ABUSE COUNCIL for final determination. The ORG in question shall > have 30 days to present their side of the issue to the council in written > form via email. The ORG in question may at any time prior to the 30 days > indicate that they have submitted all desired information and terminate > the 30 day period 24 hours after sending that email. After the 30 days > has expired or the ORG has terminated the 30 day period as described, > the ABUSE COUNCIL shall have 10 days to make a final determination on > the revocation. The ABUSE COUNCIL may affirm the revocation, in which > case, it becomes permanent. The ABUSE COUNCIL may overturn the > revocation, in which case, the resources are to be immediately returned > to the ORG in question. The ABUSE COUNCIL may decide to grant the > ORG in question an extension for compliance. In that case, the council > shall set a date by which the ORG must comply. The resource(s) will > be immediately returned to the ORG in question. If, at the date in > question, the ORG is determined by ARIN staff to still not be in > compliance, the resources shall again be revoked. The ORG may again > appeal this decision to the ABUSE COUNCIL as described. > > The ARIN BOARD shall nominate candidates to participate in the ABUSE > COUNCIL. The ABUSE COUNCIL shall have 5 members. Each member shall be > for a 2 year term. The first time, 3 members shall have 2 year terms, and > 2 shall have 1 year terms. The ARIN BOARD shall nominate not less than > two, nor more than three times the number of vacant seats. In the first > election, the three candidates receiving the most votes shall be elected > for 2 years. The community at large shall be allowed to vote, similar to > the ASO AC election process. The election shall be conducted as a "Vote > for no more than N" where N is the number of available seats (5 the first > time, 2 the following year, 3 the year after, and so on). The ABUSE > COUNCIL shall not be required to conduct physical meetings, and there > shall be no compensation paid to the ABUSE COUNCIL by ARIN. > > If a complaint comes up against an ORG to which an ABUSE COUNCIL member > has ties which could create a conflict of interest, then that members > place on the ABUSE COUNCIL shall be filled by a member of the ARIN BOARD > chosen at random with respect to that specific complaint. > > The ARIN BOARD shall serve as the ABUSE COUNCIL until such time as one > can be elected. In no event shall there be less than 30 days from the > public release of all candidates statements and nominations to the close > of the voting. The ARIN BOARD shall set the annual election date, and > shall nominate candidates each year at least 60 days prior to the election > date. Voting shall be conducted for not less than 30 days leading up to > the election date. > > The ABUSE COUNCIL changes shall take effect 5 days after the election > date. > > >> 2. Argument for the proposal and general discussion of the issue. >> >> Issue: > When trying to resolve issues of abuse, three things are > important: > > 1. Being able to pass the abuse information along to a > meaningful contact at the originating ORG. > > 2. The originating ORG taking appropriate action to > stop the abuse. > > 3. Meaningful contact from the originating ORG explaining > what was done. > > Many ORGs today have built elaborate automated systems for handling > abuse complaints. It is not uncommon for these systems to fail to > meet items 1 and 2 above. It is almost unheard of for them to meet > item 3. It is time for us to move the Internet beyond the idea that > the victims of abuse should just have to accept those costs as part > of being connected. The organizations where abuse originates must > be required to address abuse originating from resources within their > responsibility. This policy primarily addresses items 1 and 3. It is limited in it's ability to meet item 2 by the following factors: + No clear definition of what constitutes abuse. Although there is some definition included in this policy, that is intended to be overly vague and should only be used to exclude acts which are _NOT_ abuse from triggering revocation. + No policy or guidance from IETF or ICANN on abuse + The registries have not been assigned an abuse-related role other than the maintenance of contact information for resources they allocate. + Significant additional controversy in the community regarding the definition of abuse and who determines the definition of abuse. As such, this policy attempts to make a strong first step by addressing items 1 and 3 as completely as possible, facilitating a better effort towards item 2 by the parties involved. > >> >> Argument in favor: >> When an automated system fails, it becomes important to be able >> to reach a human being capable of intervening or contacting >> an intervener. It is OK if the POC information (address, >> phone number, etc.) is a work number, or NOC, or even a >> switchboard, as long as it is a point of contact which leads >> to a real person with some ability to close the loop. It does > not have to lead to a specific real person, but it must be possible > to engage human intervention through this process. >> >> Problems: > > Most of the objections to the original version of this policy > represented the need for ROLE accounts and the desire not to > release personal information. I think this amended proposal > addresses both of those concerns. Other concerns raised were > the definition of abuse. While this policy does not define > abuse, I think it provides decent metrics for determining abuse > through the IETF and through each networks AUP. Further, it > shifts the definition of abuse to the perspective of the > receiving network, allowing each network to define what traffic > they are willing to accept in a public and accessible manner. > Further, it avoids overly burdensome definitions of abuse by > only requiring originating ISPs to take action to stop abuse > if the policy defines abuse in terms which reasonably allow > the ISP to configure that definition into their routers to > prevent the origination of such abuse, and, then, only after > the abuse has occurred and generated a complaint. Additionally, it avoids taking any action based on abuse. It requires both abuse and a failure to meet a contractual obligation to maintain valid abuse contacts in order for an ORG to have their resources revoked. Hopefully this provides a balanced approach to requiring valid contact information. Given valid contact information, the parties involved should be able to resolve abuse situations in good faith. In any case, the RIRs role is limited to facilitating the contact and they have no involvement in the actual determination of abuse or it's resolution. > > >> 3. Proposed timetable for implementation: >> >> Once this proposal is ratified, ARIN should update it's registration >> services agreement to reflect the new policy within 30 days. Existing >> ORG and other bodies should receive notification of the change and the >> requirement to comply during that same period. They should be required >> to comply within 90 days of the date the notification is sent to the >> existing ADMIN-C. >> >> After that time has elapsed, ARIN staff should be expected to investigate >> and take further appropriate action on any complaint received about lack >> of appropriate ABUSE CONTACT(s) in any resource record. >> >> Appropriate action is left to the discretion of the ARIN AC, but should >> include ARIN staff contacting the ORG in question by any means reasonably > available to ARIN, and, possibly revoking resources found to be out of > compliance. > >> From memsvcs at arin.net Wed Mar 26 16:13:23 2003 From: memsvcs at arin.net (Member Services) Date: Wed, 26 Mar 2003 16:13:23 -0500 (EST) Subject: [ppml] ARIN Web-based Templates Available Message-ID: Web-based versions of the ISP Network Request and AS Number Request templates are now available. Links to these two new templates are available at http://www.arin.net/library/index.html. Using the web-based templates: --Enter all registration and justification information in the appropriate data fields --Provide your e-mail address when prompted --Hit submit button --Conduct final review of template when it is e-mailed back to you --To complete the request process, an authoritative POC must send the template to hostmaster at arin.net Please contact the Registration Services Help Desk if you have any questions, or if you experience any difficulty in completing or submitting the templates. Registration Services Department American Registry for Internet Numbers From memsvcs at arin.net Wed Mar 26 16:25:25 2003 From: memsvcs at arin.net (Member Services) Date: Wed, 26 Mar 2003 16:25:25 -0500 (EST) Subject: [ppml] Opening Mailing List to the Public Message-ID: Beginning March 28, 2003, the ARIN Announce Mailing List (arin-announce at arin.net) will be open to the general public. Any interested person may join ARIN Announce and receive e-mails. However, only ARIN staff can broadcast information to this List. All announcements relating to ARIN meetings, elections, and activities will be made through ARIN Announce and may be posted on the website. We will continue to send notification of policy discussions to both ARIN Announce and the Public Policy Mailing List (ppml at arin.net), where all policy discussions take place. In opening ARIN Announce to the public, duplicate announcements concerning events and elections will no longer be sent to the PPML. Anyone interested in information about ARIN events should join arin-announce at arin.net. Subscription instructions are available at: http://www.arin.net/mailing_lists/index.html Member Services Department American Registry for Internet Numbers(ARIN) From Michael.Dillon at radianz.com Thu Mar 27 09:13:25 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 27 Mar 2003 14:13:25 +0000 Subject: [ppml] Efficient allocation? What's that? Message-ID: In some internal discussions I've been asked to demonstrate what is the official method for calculating address utilization rates. The discussion arose because different people have different ideas of what is a "used" IP address. I though it would be simple enough to find a public document that would backup the method that I'm using to calculate this, but I was wrong. Apparently, there is nothing on the ARIN website nor in any of the RFCs that defines when an IP address is "used" for the purposes of calculating the usage rate. If there really is a need to continue minimizing waste of IPv4 addresses, then I would think that now would be a good time to tighten up definitions. There is less than 40% of the IPv4 address space left. If IPv4 addresses really are valuable then it won't be long before we start to see hoarding behavior which will lead to premature exhaustion of the space. Having clear and unambiguous definitions of things like "used" and "justified" will help prevent hoarding. On the other hand, some people, including me, don't care whether or not the IPv4 space runs out in the next 3 to 5 years. It wouldn't be a catastrophe because we do have tools like IPv6 and NAT and MPLS to keep on running the net. I think we should now be loosening the rules of IPv4 allocation in various ways because we no longer need to fear the day when they are all gone. However, there is still a need to provide clear definitions for things like "used" and "justified". Rather than leaving the vagueness in, define them in a way that is simple to administer. In fact, there are two kinds of usage rate to calculate. One is for an assignment where you probably want to count the number of device interfaces configured as "used". But at the allocation and sub-allocation level, you probably want to count an entire justified assignment as "used" because that's easy to administer. Am I making sense with this? --Michael Dillon From jeroen at unfix.org Thu Mar 27 11:29:16 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 27 Mar 2003 17:29:16 +0100 Subject: [ppml] Efficient allocation? What's that? In-Reply-To: Message-ID: <000f01c2f47e$046eebb0$210d640a@unfix.org> Michael.Dillon at radianz.com wrote: > In some internal discussions I've been asked to demonstrate > what is the official method for calculating address utilization rates. What about RFC 1715 and RFC 3194 ? RFC3194: The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio. This document provides an update on the "H ratio" defined in RFC 1715. It defines a new ratio which the authors claim is easier to understand. Though this is assignment and not allocation. Greets, Jeroen From jmcburnett at msmgmt.com Mon Mar 31 15:18:57 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Mon, 31 Mar 2003 15:18:57 -0500 Subject: [ppml] BOGUS- ARIN WHOIS? Message-ID: <390E55B947E7C848898AEBB9E507706041E5C8@msmdcfs01.msmgmt.com> Okay, I got bit.. I did a whois for an IP address that came up Central Telephone company Lincoln, NE. 151.213.99.122 And I got a name, email address etc.. Due to the reason I looked it up- which is another topic totally- I immediately called this contact. Which was disconnected.. Then I discovered, oh this is ALLTEL now. I hope we can get the proposal passed and force the updating of the WHOIS.. But in the interim is there any kind of existing policy to reports bad WHOIS to ARIN? Thanks, Jim From richardj at arin.net Mon Mar 31 15:57:12 2003 From: richardj at arin.net (Richard Jimmerson) Date: Mon, 31 Mar 2003 15:57:12 -0500 Subject: [ppml] BOGUS- ARIN WHOIS? In-Reply-To: <390E55B947E7C848898AEBB9E507706041E5C8@msmdcfs01.msmgmt.com> Message-ID: <009101c2f7c8$1a0e4d60$1c8888c0@arin.net> Hello Jim, > is there any kind of existing policy to reports bad > WHOIS to ARIN? You can send email to hostmaster at arin.net. ARIN staff will research reports of out-of-date information and take appropriate action. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of McBurnett, Jim > Sent: Monday, March 31, 2003 3:19 PM > To: ppml at arin.net > Subject: [ppml] BOGUS- ARIN WHOIS? > > > Okay, > I got bit.. > I did a whois for an IP address that came up Central > Telephone company Lincoln, NE. > 151.213.99.122 > And I got a name, email address etc.. > Due to the reason I looked it up- which is another topic totally- > I immediately called this contact. > Which was disconnected.. Then I discovered, oh this is ALLTEL now. > > I hope we can get the proposal passed and force the updating of > the WHOIS.. But in the interim is there any kind of existing > policy to reports bad WHOIS to ARIN? > > Thanks, > Jim > From Jack.W.Parks at alltel.com Mon Mar 31 17:03:01 2003 From: Jack.W.Parks at alltel.com (Jack.W.Parks at alltel.com) Date: Mon, 31 Mar 2003 16:03:01 -0600 Subject: [ppml] BOGUS- ARIN WHOIS? Message-ID: Thanks for bringing this up! We have been trying to correct this discrepancy for months, however, we are deadlocked with ARIN for resolving this issue. I know this could rat hole rather rapidly and is OT. Ticket # ARIN-20021211.474 If you need any questions answered, you may forward questions about this block to ipadmin at alltel.net or abuse at alltel.net. Thanks, Jack W. Parks IV Sr. Network Engineer ALLTEL Communications jack.w.parks at alltel.com Work: 501-905-5961 Cell: 501-680-3341 -----Original Message----- From: Richard Jimmerson [mailto:richardj at arin.net] Sent: Monday, March 31, 2003 2:57 PM To: ppml at arin.net Subject: RE: [ppml] BOGUS- ARIN WHOIS? Hello Jim, > is there any kind of existing policy to reports bad > WHOIS to ARIN? You can send email to hostmaster at arin.net. ARIN staff will research reports of out-of-date information and take appropriate action. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of McBurnett, Jim > Sent: Monday, March 31, 2003 3:19 PM > To: ppml at arin.net > Subject: [ppml] BOGUS- ARIN WHOIS? > > > Okay, > I got bit.. > I did a whois for an IP address that came up Central > Telephone company Lincoln, NE. > 151.213.99.122 > And I got a name, email address etc.. > Due to the reason I looked it up- which is another topic totally- > I immediately called this contact. > Which was disconnected.. Then I discovered, oh this is ALLTEL now. > > I hope we can get the proposal passed and force the updating of > the WHOIS.. But in the interim is there any kind of existing > policy to reports bad WHOIS to ARIN? > > Thanks, > Jim >