Re: [db-wg] [routing-wg] Need for "import-via:" and "export-via:" attributes in AUT-NUM object
Dear people, On Thu, Oct 24, 2013 at 03:05:21PM +0200, Denis Walker wrote:
During the RIPE 67 Meeting in Athens last week, there was some discussion about the introduction of new "via" attributes to the AUT-NUM object.
This issue has been discussed on both the Database and Routing Working Group mailing lists and at RIPE 67 in both Database and Routing sessions. Overall there was support for it on the Database Working Group list. On the routing-wg@ mailinglist one comment was made, also in support of the introduction of these attributes. The software is ready to be deployed, but the RIPE NCC needs someone to say 'yes, go ahead' if there is consensus. Does anyone have a problem with moving forward towards deployment? Bullet point pitch: - The change is backwards compatible with older RPSL parsers. - The new attributes are completely optional. - This change adds advanced functionality that will especially benefit route server operators and participants. Kind regards, Job
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks,
Bullet point pitch:
- The change is backwards compatible with older RPSL parsers. - The new attributes are completely optional. - This change adds advanced functionality that will especially benefit route server operators and participants.
Can I encourage those that have an opinion about this to voice it? The NCC would like some confirmation from the community that there is some demand to implement this (and no objection to doing it). Job: What are the plans for advancing the I-D? Cheers, Rob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKWMREACgkQF83fs8P8zalu1ACgwlCUB8Jc23I0LtvZR6cgW1m2 87oAn0omzasDIhWxX23uvwaBPSUel3OV =QExP -----END PGP SIGNATURE-----
On Wed, Nov 27, 2013 at 05:51:13PM +0000, Rob Evans wrote:
Job: What are the plans for advancing the I-D?
I will continue to improve the wording and examples based on feedback, and eventually produce a top-notch RFC. It is not entirely clear at this stage in which working group this document the can be discussed and worked upon, the original RPS working group has been concluded. It is possible an individual submission will be appropriate. Kind regards, Job
On 27/11/2013 17:51, Rob Evans wrote:
- The change is backwards compatible with older RPSL parsers. - The new attributes are completely optional. - This change adds advanced functionality that will especially benefit route server operators and participants.
Can I encourage those that have an opinion about this to voice it? The NCC would like some confirmation from the community that there is some demand to implement this (and no objection to doing it).
I don't object to this change, and possibly a good purpose will be served by having it although I don't plan to use it. By way of historical context, this syntax was previously implemented about 15 years ago using the rs-in: and rs-out: statements for the routing arbiter project. These parameters were lost in the mists of time, but you can still find traces of them here and there, e.g.
http://www.nanog.org/mailinglist/mailarchives/old_archive/1999-10/msg00429.h...
My main concern about the changes is that they unearth a more fundamental problem with rpsl, namely that it is not possible to extend the language without creating a new incompatible statement fork with duplicated syntax. Probably this can be handled relatively efficiently by the back-end code but from the point of view of language design, it's ugly. Nick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi db-wg and routing-wg,
Can I encourage those that have an opinion about this to voice it? The NCC would like some confirmation from the community that there is some demand to implement this (and no objection to doing it).
The only feedback since that message has been from Nick who, if I may summarise, said that he didn't object, it may serve some use, but this creates an ugly (but inevitable) fork in RPSL. There was mild support before RIPE 67, and the NCC have asked if we can now declare consensus and move on. My interpretation is "yes." Cheers, Rob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKp2GQACgkQF83fs8P8zalp7wCfbMI6Cr1/kIZ+u1ZvTERaVjha BJkAn3x+GTjxrq9EE3AZvzPnlkt5ceJz =MEex -----END PGP SIGNATURE-----
On Thu, Dec 12, 2013 at 03:38:12PM +0000, Rob Evans wrote:
Can I encourage those that have an opinion about this to voice it? The NCC would like some confirmation from the community that there is some demand to implement this (and no objection to doing it).
The only feedback since that message has been from Nick who, if I may summarise, said that he didn't object, it may serve some use, but this creates an ugly (but inevitable) fork in RPSL.
If this change anything: I do not object. :) Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
participants (4)
-
Job Snijders -
Nick Hilliard -
Piotr Strzyzewski -
Rob Evans