I thought folks in this forum might be interested in possibly replying to the matter in this note from ppml, and got the author's permission to forward it to this list. I'm trying to set the Mail-Followup-To header on this note to the ppml@arin.net list, not sure if I'm getting it right, but I think it would be appropriate if any replies were directed to the ppml list, as that's what ARIN is watching for this solicitation of public comment. ----- Forwarded message from ginny listman <ginny@arin.net> ----- From: ginny listman <ginny@arin.net> Subject: Just to clarify Date: Thu, 4 Jan 2001 08:20:07 -0500 (EST) To: ppml@arin.net Hi, my name is Ginny Listman. As of early December, I am the new Director of Engineering here at ARIN. In a meeting yesterday, to discuss database changes, the following policy issue came up. Apparently, there have been some upstream ISPs that have assigned some networks via SWIP, where later the downstream comes back saying it should have been an allocation, ie they want a maintainer id so they can assign/allocate further on down. In most cases, RSG has been granting the downstream's wish, creating the maintainer id, allowing them to further assign/allocate. Many times, it is just a minor error in the SWIP template, and shouldn't be a big deal. However, would there ever be a situation where the upstream would not want the downstream to be assigning/allocating? Should ARIN be responsible for notifying the upstream? We have be processing these request because we do not want to delay the downstream's business. Do we need a written policy to define how we should be processing such a request? ----- End forwarded message ----- I believe this matter is on-topic for nanog; if I'm mistaken my apologies, and please do let me know. Note that this forwarding to nanog is my fault and not the fault of the original author. -Bennett
Hi, my name is Ginny Listman. As of early December, I am the new Director of Engineering here at ARIN. In a meeting yesterday, to discuss database changes, the following policy issue came up.
Apparently, there have been some upstream ISPs that have assigned some networks via SWIP, where later the downstream comes back saying it should have been an allocation, ie they want a maintainer id so they can assign/allocate further on down.
In most cases, RSG has been granting the downstream's wish, creating the maintainer id, allowing them to further assign/allocate.
Many times, it is just a minor error in the SWIP template, and shouldn't be a big deal. However, would there ever be a situation where the upstream would not want the downstream to be assigning/allocating? Should ARIN be responsible for notifying the upstream? We have be processing these request because we do not want to delay the downstream's business. Do we need a written policy to define how we should be processing such a request?
The upstream might not be all that fond of its customer reselling service, and this may be taken into consideration by their contract, but the downstream is going to dole out the space regardless of their ability to SWIP subassignments. I would think that it's in ARIN's interest to foster the maintenance of as accurate a database as possible, and leave quarrels over type of service between a provider and its customers to the provider and its customers. It's not the RIR's responsibility to enforce contract terms between an ISP and its downstreams. Some mechanism should be provided for the maintainer of a block (either directly obtained from ARIN or from an upstream via SWIP) to list all allocations, assignments, suballocations, and subassignments so that he or she can enforce contracts appropriately. I'm personally glad that ARIN changes the status of blocks from assigned to allocated and performs other active maintenance upon request. It's been of direct value to me when upstreams do the wrong thing and assign instead of allocate or set the wrong maintainer ID on an allocation. These are usually misunderstandings, and getting them straigtened out would take weeks if done through the provider. All of that said, this can be taken to the logical extreme and the distinction between allocations and assignments can be eliminated altogether, and provider/maintainer IDs can be replaced purely with ARIN handles. Finally, the ability to submit assignment and allocation information via rwhois seems like a license for inconsistency. Rwhois was a great idea that never took off. It would be interesting if this information could be provided by splintering off a new DNS class (or at least some new RR types.) Has anyone ever considered this? Mark
Finally, the ability to submit assignment and allocation information via rwhois seems like a license for inconsistency. Rwhois was a great idea that never took off. It would be interesting if this information could be provided by splintering off a new DNS class (or at least some new RR types.) Has anyone ever considered this?
Mark
rWhois is still a great idea, however the learning curve is a bit steep. It is possible to dump RPSL data into the DNS and use the inverse tree to track assignments & allocations. It can even be used to track prefered announcing parties. (being able to track proxy aggregations fairly easily.) Varients on these types of proposals were made in the old RIDEwg in the IETF (prox 2 years ago) and there was a NANOG presentation on using the data in the DNS to authenticate routing announcements. Twas a bit extreme. That said, I'll posit that the adoption rate of new DNS code is fairly slow (based on 3 years of study) and so even if some goofy new class or RR type is promoted, it would not get deployed anytime soon. --bill
bmanning@vacation.karoshi.com wrote:
Finally, the ability to submit assignment and allocation information via rwhois seems like a license for inconsistency. Rwhois was a great idea that never took off. It would be interesting if this information could be provided by splintering off a new DNS class (or at least some new RR types.) Has anyone ever considered this?
Mark
That said, I'll posit that the adoption rate of new DNS code is fairly slow (based on 3 years of study) and so even if some goofy new class or RR type is promoted, it would not get deployed anytime soon.
All of this stuff (global WHOIS included) really needs to go into LDAP, using standardized schemas for the relevant data. Obviously the schema is job #1. All of the [g/cc]TLD databases and numbering authoritites really should have made this a collective priority a couple of years ago. Note that putting the data into LDAP doesn't preclude WHOIS clients from talking to a WHOIS server which proxies the LDAP data. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
said ldap server should be publicly accessible.... ----- Original Message ----- From: "Eric A. Hall" <ehall@ehsco.com> To: <bmanning@vacation.karoshi.com> Cc: "Mark Mentovai" <mark-list@mentovai.com>; <ppml@arin.net>; "Bennett Todd" <bet@rahul.net>; <nanog@merit.edu>; <ginny@arin.net> Sent: Thursday, January 04, 2001 2:53 PM Subject: Re: fwd ppml: ARIN asking about SWIP procedures
bmanning@vacation.karoshi.com wrote:
Finally, the ability to submit assignment and allocation information via rwhois seems like a license for inconsistency. Rwhois was a great idea that never took off. It would be interesting if this information could be provided by splintering off a new DNS class (or at least some new RR types.) Has anyone ever considered this?
Mark
That said, I'll posit that the adoption rate of new DNS code is fairly slow (based on 3 years of study) and so even if some goofy new class or RR type is promoted, it would not get deployed anytime soon.
All of this stuff (global WHOIS included) really needs to go into LDAP, using standardized schemas for the relevant data. Obviously the schema is job #1. All of the [g/cc]TLD databases and numbering authoritites really should have made this a collective priority a couple of years ago.
Note that putting the data into LDAP doesn't preclude WHOIS clients from talking to a WHOIS server which proxies the LDAP data.
-- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
That said, I'll posit that the adoption rate of new DNS code is fairly slow (based on 3 years of study) and so even if some goofy new class or RR type is promoted, it would not get deployed anytime soon.
All of this stuff (global WHOIS included) really needs to go into LDAP, using standardized schemas for the relevant data. Obviously the schema is job #1. All of the [g/cc]TLD databases and numbering authoritites really should have made this a collective priority a couple of years ago.
Note that putting the data into LDAP doesn't preclude WHOIS clients from talking to a WHOIS server which proxies the LDAP data.
-- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
LDAP might just have a chance. But it looks alot like the x500 stuff from the last decade. I remain unconvinced. --bill
I earlier forwarded the question from ARIN soliciting feedback on a question; they just announced the resolution of the question on the ppml list, and I got permission to forward their note to this forum. As before, if you disapprove of the cross-list forwarding please complain to me directly as this is solely my fault, and if you wish to discuss the topic of the posting I've tried to set the Mail-Followup-To header to direct discussions to the ppml list. -Bennett
participants (5)
-
Bennett Todd
-
bmanning@vacation.karoshi.com
-
Dana Hudes
-
Eric A. Hall
-
Mark Mentovai