[arin-ppml] ARIN-PPML Digest, Vol 56, Issue 18
Rudolph Daniel
rudi.daniel at gmail.com
Wed Feb 3 11:45:42 EST 2010
My take on this is not whether there is whois info or not. whois info is a
must have. And accurate whois information is important to ARIN.
The system we create for collecting that info is in question as is ...what
info. is available to whom. Where a reallocation has an isp (for eg) as a
contact because the isp agrees to be, my thinking is that ARIN needs to have
all the info. on the reallocation and in many cases, the information
available to the public is not as detailed as the info. which is available
to ARIN.
We also need to decide on the level of accuracy required for ARIN records
and that ultimately determines what we put in place. I think I'm getting
the view that the current whois database is a little way off the required
standard?? And there would seem to be much use of the or maybe abuse of the
current system as suggested by the 2006 audit.
RD
> Message: 5
> Date: Wed, 3 Feb 2010 08:06:33 +0300
> From: McTim <dogwallah at gmail.com>
> To: Chris Grundemann <cgrundemann at gmail.com>
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
> Message-ID:
> <f65fb55e1002022106x7ef97a7dk32cce362b3a98af7 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Feb 2, 2010 at 11:05 PM, Chris Grundemann <cgrundemann at gmail.com>
> wrote:
> <snip>
> >
> > +1
> >
> > whois must contain valid contact information for the person/entity
> > directly responsible for the host(s) using a given IP. I oppose this
> > and any other policy which undermines this fundamental requirement.
>
> +1
>
> --
> Cheers,
>
> McTim
> "A name indicates what we seek. An address indicates where it is. A
> route indicates how we get there." Jon Postel
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 2 Feb 2010 23:16:41 -0800
> From: "George Bonser" <gbonser at seven.com>
> To: "William Herrin" <bill at herrin.us>, <ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
> Message-ID:
> <5A6D953473350C4B9995546AFE9939EE081F75AA at RWC-EX1.corp.seven.com>
> Content-Type: text/plain; charset="us-ascii"
>
> > Perhaps a *fair* solution is that ISPs who would rather suffer
> > penetrating annual audits purchased by ARIN at the ISP's expense can
> > forgo publishing customer information via SWIP while those who place
> > their information in the public's hands remain relieved of that
> > burden.
> >
> > Regards,
> > Bill Herrin
>
> For me the judgment call seems fairly simple.
>
> >From the standpoint of someone who isn't a commercial ISP
>
> what benefit does this proposal offer me?
> What is the value of that benefit?
>
> What is the benefit to the community at large of the proposal?
> What is the value of that benefit?
>
> What is the cost to the community of the proposal?
>
> What is the cost to me of the proposal?
>
>
> And then the question of whether to support it or not is weighed. I
> keep coming up with little/no benefit, high cost.
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 3 Feb 2010 01:54:03 -0600
> From: James Hess <mysidia at gmail.com>
> To: Scott Leibrand <scottleibrand at gmail.com>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Petition Underway - Policy Proposal
> 95:CustomerConfidentiality - Time Sensitive
> Message-ID: <6eb799ab1002022354q29e029i6d89302cb15022b at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Feb 2, 2010 at 9:28 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
> > On 2/2/2010 7:00 PM, George Bonser wrote:
> > If I, as a colo provider, didn't SWIP customers like this their entire
> /29,
> > I may not be able to meet 80% utilization thresholds. ?For purposes of
> > calculating utilization, however, the /29 is considered 100% utilized as
>
> It's possible to keep record of utilization using the form in sec.
> 4.2.3.7.5 of the NRPM without SWIPing -- where a full /29 block
> is not re-assigned.
>
> SWIPs submitted to ARIN are not (or should not) be your only
> records or way of keeping proper information about re-assignments for
> justifying additional allocation requests, since most ISPs and
> end-users will have some allocations or assignments of blocks smaller
> than /29.
> e,g it might look like
>
> City Which IP Addresses Assigned No. of Internal Machines
> Purpose:
> (CITY) *192.0.0.0 1
> Collocated
> 192.0.0.1
> (Customer
> 192.0.0.2
> Name) -
> 192.0.0.3
> 4 customer IPs
> 192.0.0.4
> 4 provider
> 192.0.0.5
> IPs
> 192.0.0.6
> *192.0.0.7
>
> So, you have 4 IPs that are part of the service provider's
> network 192.0.0.0 and 192.0.0.7 broadcast addresses required for
> your router, plus your 2 router IPs for their servers to use as
> gateway. Then 4 customer IPs, for their server.
>
> It may be more convenient to just SWIP the entire /29, provider IPs and
> all..
> but then again, this will show the customer as 'responsible' for
> some collocation provider router IPs then, which might be
> undesirable.
>
>
> In this case... you have 100% utilized the /29.
> You assigned 4 IPs to your equipment, and you delegated an address
> block equivalent in allocation size of a /30 to the user (probably
> 192.0.0.3 to 6).
>
> The end-user's network block is smaller than a /29, so no SWIP
> would be required under NRPM 4.2.3.7.2.
>
> Your router on your premises... and your inefficiency.
> Now if you peered with a customer router over a /30, and forwarded a
> /29, that would indicate reassignment of a full /29.
>
>
> --
> -J
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 56, Issue 18
> *****************************************
>
--
Rudi Daniel
e Business Consultant
http://www.svgpso.org
http://oecstimes.wordpress.com
“The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts.” - Bertrand
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100203/2ec3dd01/attachment.htm>
More information about the ARIN-PPML
mailing list