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@highway.telekom.at
-----Ursprüngliche Nachricht----- Von: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net]Im Auftrag von ipmaster@bt.com Gesendet: Mittwoch, 21. Mai 2003 18:04 An: shane@ripe.net Cc: db-wg@ripe.net Betreff: RE: [db-wg] Slash notation
Shane, sounds good to me !! Thanx Dave Trickett BTnet
-----Original Message----- From: Shane Kerr [mailto:shane@ripe.net] Sent: 21 May 2003 16:56 To: IPMASTER G Cc: db-wg@ripe.net Subject: Re: [db-wg] Slash notation
On 2003-05-21 16:26:43 +0100, ipmaster@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