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. Dave Trickett BTnet
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
Hi,
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.
I think that really makes sense. Just another suggestion (from what I experienced in my environment): Would it be possible to treat/convert inetnum: 193.0.0.221 to inetnum: 193.0.0.221 - 193.0.0.221 (the 'single host') ? lG uk -- ------------------------------------------------------------------------ Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network Security Universitaetsstrasse 7, 1010 Wien, Austria ------------------------------------------------------------------------ eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 Hotline: security.zid@univie.ac.at Fax: (+43 1) 4277 / 9140 ------------------------------------------------------------------------ GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8
participants (3)
-
ipmaster＠bt.com -
Shane Kerr -
Ulrich Kiermayr