AW: [db-wg] Slash notation

Hi Shane,

it would be nice if you can reimplement the slash notation again.
A support of /32's will cover Ulrichs host adresses.

thank you
Martin

----------------------------
Martin VYSKOCIL
Telekom Austria AG
Broadband Networks & Services

Tel.: +43 59059 1 43429
FAX: +43 59059 1 43492
mailto:mvyskocil at highway.telekom.at


> -----Ursprüngliche Nachricht-----
> Von: db-wg-admin at ripe.net [mailto:db-wg-admin at ripe.net]Im Auftrag von
> ipmaster at bt.com
> Gesendet: Mittwoch, 21. Mai 2003 18:04
> An: shane at ripe.net
> Cc: db-wg at ripe.net
> Betreff: RE: [db-wg] Slash notation
>
>
> Shane,
> sounds good to me !!
> Thanx
> Dave Trickett
> BTnet
>
> -----Original Message-----
> From: Shane Kerr [mailto:shane at ripe.net]
> Sent: 21 May 2003 16:56
> To: IPMASTER G
> Cc: db-wg at ripe.net
> Subject: Re: [db-wg] Slash notation
>
>
> On 2003-05-21 16:26:43 +0100, ipmaster at bt.com wrote:
> > Hi
> >
> > Quick question:-)
> > We used to be able to update (via email) the Database with new
> > inetnums using slash notation. Since the introduction of RPSL, this
> > facility has been lost, would it be possible to re-introduce it?
> > I can see the benefits of using the long hand version if I am
> > updating with a /27 and a /28, such as (*.*.*.64 - *.*.*.111).
> > But for Inetnums that fall on the bit boundary would not make sense
> > to enable the slash?
> > If I update a route object I can still use the slash notation.
>
> Short answer:
>
> When version 3 of the Database software was designed, one of the
> principles used was to not change user data as it was submitted.  This
> included the transformation you defined.
>
> The easiest solution would be to convert the CIDR to ranges, as you
> suggest, so:
>
> inetnum: 193.0.0.0/20
>
> Would become:
>
> ***Warning: inetnum '193.0.0.0/20' converted to '193.0.0.0 - 193.0.7.255'
>
> inetnum: 193.0.0.0 - 193.0.7.255
>    .
>    .
>    .
>
> If this makes sense, we'll include this change shortly.
>
>
>
> Explaination (for the curious):
>
> The reason that these types of modifications were avoided in the
> original design is because RPSL allows a number of formats that can
> make the changes difficult.  For example:
>
> inetnum:
>    # this
> +# is a valid
>      # inetnum attribute
>                                 193.0.0.0
> +                                -
>         # heck, you can even put a comment here
>  193.0.7.255
> + # and at the end too
>
>
> Modifying this kind of attribute can be problematic, because the
> value is split across many lines, and has comments in the middle.
>
> However, with your suggestion it would be possible to do something
> like converting:
>
> inetnum:
>    # this
> +# is a valid
>      # inetnum attribute
>                                 193.0.0.0/21
> + # but still parsable!
>
> Into the following:
>
> inetnum:
>    # this
> +# is a valid
>      # inetnum attribute
>                                 193.0.0.0 - 193.0.7.255
> + # but still parsable!
>
>
> Since the CIDR-notation is "atomic", we don't have to worry about
> values split across lines or with comments inside.
>
> Note that comments and split lines in the primary attributes are very,
> very rare, but it is technically possible for any user that wishes to
> do so.
>
> --
> Shane Kerr
> RIPE NCC
>