I ended up finding a good way of traking internal use rather unintentinally. Our internal IP database shoots off a SWIP everytime you make an allocation or an assignment; filling in all the proper fields. To differentiate types of internal networks I make separate customers, say "ELI - Dialup", "ELI - Backbone", etc. These customers have a flag set that means they don't do resale, so they are end assignments. A swip gets generated, but I can also use our database to generate the appropriate sections for the http://www.arin.net/templates/isptemplate.txt form. Generating these by hand would be quite a lot of work, but verifying an already created list is much easier. --Ben Kirkpatrick On Tue, 10 Nov 1998, Steven J. Sobol wrote: )On Tue, Nov 10, 1998 at 03:36:53PM -0600, Phil Howard wrote: ) )NACS is going to need a new /19 pretty soon. But we have 13 Class C's )used for things like dialups, servers, web virtual hosts, etc. So how can )we explain our need for more addresses when much of our current /19 may appear )to be unused, since it isn't SWIP'd? ) )> When I do hand out real /30's, what I have done so far is send in an "aggregate )> SWIP" simply stating that the space is for /30's. At least something is on )> record for it. And this may be totally satisfactory. ) )How do we record this for /24's which we use for internal purposes? ) )> So how would you feel if the requirement to send in SWIP data was lifted so )> that only those networks allocated for resale, or otherwise have a specific )> and different point of contact, need to be SWIPped? Keep in mind this would )> mean that I would probably have about 4 or 5 of them, total. ) )This is one possible solution.