SWIP netblocks

[Linda]

Yes it is based on a previous relationships as well as language.  I was merely
replying to your statement that many blocks were not swip(ed) on the bit boundary
and in this case it was ARIN not SCSI that stored .254 in the db.  I was not sure
if this was an exception to the rule or if ARIN has done this on other swip
information?  In the future as you stated below this will not be an issue.

Linda

ginny listman wrote:

> In the future, child/parent relationship will be tracked by a separate
> table, not by the size of the network.  Therefore once we convert the
> database, you may (we will) change COTAS to 255.  My question to you, and
> the others, is how frequently do you allocate the entire netblock?  Why
> wouldn't COTA go directly to UUNET, if the are getting the same size of
> allocation that SCSI is getting?  Is this based on previous relationships
> and/or possible language?
>
> Ginny
>
> On Wed, 3 Jan 2001, Linda wrote:
>
> > Satellite Communications (NETBLK-UU-63-65-12) UU-63-65-12
> >                                                           63.65.12.0 -
> > 63.65.12.255
> >      Cotas LTDA. (NETBLK-SCSI-COTAS-2) SCSI-COTAS-2       63.65.12.0 -
> > 63.65.12.254
> >
> > We have one /24 that was allocated by UUNET to SCSI, who allocated it to
> > COTAS.  Our swip template was submitted with .0 to .255, and COTAS's was also
> > submitted with a .0 to .255.  I called the ARIN help desk regarding this
> > matter and I was told that the only way to correctly show the parent child
> > relationship was if the child was listed in the database as .254.  The
> > database was changed by ARIN because after we allocated the /24 to COTAS the
> > db initially listed the order as UUNET to COTAS to SCSI.
> >
> > Linda
> >
> > ginny listman wrote:
> >
> > > In reviewing what is currently stored in the database, there are a number
> > > of SWIPed netblocks that are not on the bit boundary.  For example,
> > > instead of SWIPing 0 to 255, an entire /24, 1 to 254 was SWIPed.  In the
> > > future, we will be operating in a cidr world, including displaying cidr
> > > blocks in whois.  For a block that is 1 to 254, the display will include 2
> > > /32, 2 /31, 2 /30, 2 /29, 2 /28, 2 /27, and 2 /26.  It would be a whole
> > > lot cleaner to display 1 /24.
> > >
> > > How do people feel about enforcing allocations/assignments based on a
> > > single cidr block?  I could see an occasion where someone may want to
> > > assign 2-4 cidr blocks at a single time, but can we enforce, or strongly
> > > encouraging, a policy like this?  SWIP on the bit boundary.
> > >
> > > Ginny
> >