[dbwg] Simple Reassignment POC

[Derek J. Balling]

I'll chime in that I've had a discussion with Ginny over the last 48  
hours, and we would kick around possible solutions to the problem.

My concern is that there could potentially be a lot of network traffic  
(two, three, four recursive calls for deeply nested subassignments),  
requiring the WHOIS client to try to intelligently parse the output and  
make successive calls to the database as needed.

One solution I proposed was for non-POC subassignments, perhaps the  
whois server could do that recursion behind the scenes and include the  
(parent,grandparent,etc)'s POC info as appropriate.

Minimizes network traffic, minimizes calls to the DB, and requires less  
"intelligence" in the client and/or end-user of whois.

D



On Wednesday, February 12, 2003, at 11:55 AM, Einar Bohlin wrote:

> Hi,
>
> Was there some other reason they picked on you?
> You're not the only one using simples.
>
> We should discuss this, sure.  But not not in the
> context of these list creators who can change
> their requirements any time they want.
>
> By definition the POC info for a simple
> reassignment is the parent block info.
> Yes, one has to make two whois queries
> to get that info.
>
> As a matter of fact there is a thread in which
> the rfc ignorant people addressed a smiliar issue.
> And they went with two whois lookups being okay. This
> is the same thing.
>
> Where does adding to the output stop?  It
> could get extreme.  Somebody with a list might
> want every IP query to include full registry
> info and info for IANA and/or ICANN.
>
> Finally, in RFC 2050 it says the
> registries determine what comprises
> reassignment information.  And since ARIN
> allows reassign simple records, then
> simple reassignments are RFC compliant.
>
> Regards,
>
> Einar Bohlin, IP Analyst
> IP Team - Ashburn Virginia - WorldCom
> Phone: 703 886-7362 (VNET 806-7362)
> email: einar.bohlin at wcom.com
>
>
>
> Here's the post:
>
> http://lists.megacity.org/pipermail/rfci-discuss/2002-October/ 
> 001096.html
>
> *********************************************
>
> [RFCI-Discuss] ipwhois: ARIN's nonexistent postal addresses
> Derek J. Balling rfci-discuss at lists.megacity.org
> Mon, 7 Oct 2002 18:15:50 -0400
>
> Previous message: [RFCI-Discuss] ipwhois: ARIN's nonexistent postal  
> addresses
> Next message: [RFCI-Discuss] ipwhois: ARIN's nonexistent postal  
> addresses
> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>
> ----------------------------------------------------------------------- 
> ---------
>
> On Monday, October 7, 2002, at 05:24  PM, Will Aoki wrote:
>> A whois on the OrgID will show postal addresses. I didn't find any
>> telephone numbers on the OrgIDs that I checked, although the contact
>> handles I checked have phone numbers.
>>
>> Unless the RFCs are interpreted to require address data to be returned
>> in the first whois query, instead of needing another query to an orgid
>> handle, ARIN seems no more or less compliant than it was before.
>
> Thanks for digging deeper. You're right (and I don't necessarily have a
> problem with the way ARIN is doing it, now that I see how they've
> implemented it).
>
> D
>
> *********************************************
>
>
>
>
> On Wed, 12 Feb 2003, Whipple, Scott (CCI-Atlanta) wrote:
>
>> I would like to propose a slight change to the way simple  
>> reassignments are displayed in ARIN's whois.  I recently had some of  
>> our IPs listed in a black list database (ipwhois.rfc-ignorant.org).   
>> The reason that I received was that the simple reassignments in ARINs  
>> database do not have POC information.  I didn't believe this was a  
>> legitimate reason to have the IPs listed because the POC information  
>> on the parent is responsible for the simple reassignment, but this  
>> was the reason given to me.  I explained to them that this was not a  
>> requirement of ARIN and that the POCs on the parent block is actually  
>> who maintains the reassignments.  The only way to fix this problem  
>> was to change all my simple reassignments into detailed >> reassignments.
>>
>> What I would like to propose is that when a simple reassignment is  
>> submitted the POC information listed on the parent block be imported  
>> to the simple reassignment.  So, when a query is done on a simple  
>> reassignment you will get the POC information that is responsible for  
>> the network.  The POC information that is actually displayed is the  
>> same as the parent but you do get a POC without having to do two  
>> queries.
>>
>> Is there anyone out there that has had this type of problem?  Does  
>> anyone see value in making this change?
>>
>> Scott
>>
>