draft-blunk-rpslng-05.txt has been submitted
The draft is available at www.radb.net/rpslng-05.html. The structured syntax has been updated to reflect comments by Cengiz and Mark. Note that the optional afi field is now outside the brackets in refine and except expressions. I believe this is simpler and more intuitive. We may wish to simplify further and only allow an initial afi specification on policy expressions (similar to the optional protocol fields). However, I don't have a strong opinion on this. -Larry
Larry J. Blunk wrote:
The draft is available at www.radb.net/rpslng-05.html. The structured syntax has been updated to reflect comments by Cengiz and Mark. Note that the optional afi field is now outside the brackets in refine and except expressions. I believe this is simpler and more intuitive. We may wish to simplify further and only allow an initial afi specification on policy expressions (similar to the optional protocol fields). However, I don't have a strong opinion on this.
Can we also "fix" community_elm so that you can use wildcards, or preferably regular expressions, on each side of the ":". For example, it would be useful to be able to delete(7575:*) rather than have to list them, although delete(7575:[1-9][0-9]{3}) would be better. Mark.
On Thursday 13 May 2004 20:46, Mark Prior wrote:
Larry J. Blunk wrote:
The draft is available at www.radb.net/rpslng-05.html. The structured syntax has been updated to reflect comments by Cengiz and Mark. Note that the optional afi field is now outside the brackets in refine and except expressions. I believe this is simpler and more intuitive. We may wish to simplify further and only allow an initial afi specification on policy expressions (similar to the optional protocol fields). However, I don't have a strong opinion on this.
Can we also "fix" community_elm so that you can use wildcards, or preferably regular expressions, on each side of the ":". For example, it would be useful to be able to delete(7575:*) rather than have to list them, although delete(7575:[1-9][0-9]{3}) would be better.
Mark.
Unfortunately, the dictionary "typedef" support seems a bit too limited to extend community_elm like this. Do you have any proposed text for the draft? It seems like a new "community_exp" pre-defined type would need to be added to the dictionary. The support for "<num>:<num>" syntax to express "integers" is already a bit of a hack added for communities. Speaking of communities, should the RFC3765 "NOPEER" community be added to the well-known community enum list? -Larry
I'd like to issue a last call to the list for draft-blunk-rpslng-05.txt prior to going to the IESG. Mark, it seems the extensions to community_elm are sufficiently complex and outside the scope of this draft that they should not be included. However, I'd appreciate hearing feedback from others (some text would be nice as well) about whether or not they think this is important enough to hold up the draft for inclusion. -Larry Larry J. Blunk wrote:
On Thursday 13 May 2004 20:46, Mark Prior wrote:
Larry J. Blunk wrote:
The draft is available at www.radb.net/rpslng-05.html. The structured syntax has been updated to reflect comments by Cengiz and Mark. Note that the optional afi field is now outside the brackets in refine and except expressions. I believe this is simpler and more intuitive. We may wish to simplify further and only allow an initial afi specification on policy expressions (similar to the optional protocol fields). However, I don't have a strong opinion on this.
Can we also "fix" community_elm so that you can use wildcards, or preferably regular expressions, on each side of the ":". For example, it would be useful to be able to delete(7575:*) rather than have to list them, although delete(7575:[1-9][0-9]{3}) would be better.
Mark.
Unfortunately, the dictionary "typedef" support seems a bit too limited to extend community_elm like this. Do you have any proposed text for the draft? It seems like a new "community_exp" pre-defined type would need to be added to the dictionary. The support for "<num>:<num>" syntax to express "integers" is already a bit of a hack added for communities.
Speaking of communities, should the RFC3765 "NOPEER" community be added to the well-known community enum list?
-Larry
Hi all, On 2004-05-24 14:35:40 -0400, Larry Blunk wrote:
I'd like to issue a last call to the list for draft-blunk-rpslng-05.txt prior to going to the IESG.
I'd say let's go ahead.
Mark, it seems the extensions to community_elm are sufficiently complex and outside the scope of this draft that they should not be included.
I agree that this is outside the scope of this effort. Even if there are many other things that can be fixed or improved in RPSL RFC, they will take considerable time. Regards, -engin
However, I'd appreciate hearing feedback from others (some text would be nice as well) about whether or not they think this is important enough to hold up the draft for inclusion.
-Larry
Larry J. Blunk wrote:
On Thursday 13 May 2004 20:46, Mark Prior wrote:
Larry J. Blunk wrote:
The draft is available at www.radb.net/rpslng-05.html. The structured syntax has been updated to reflect comments by Cengiz and Mark. Note that the optional afi field is now outside the brackets in refine and except expressions. I believe this is simpler and more intuitive. We may wish to simplify further and only allow an initial afi specification on policy expressions (similar to the optional protocol fields). However, I don't have a strong opinion on this.
Can we also "fix" community_elm so that you can use wildcards, or preferably regular expressions, on each side of the ":". For example, it would be useful to be able to delete(7575:*) rather than have to list them, although delete(7575:[1-9][0-9]{3}) would be better.
Mark.
Unfortunately, the dictionary "typedef" support seems a bit too limited to extend community_elm like this. Do you have any proposed text for the draft? It seems like a new "community_exp" pre-defined type would need to be added to the dictionary. The support for "<num>:<num>" syntax to express "integers" is already a bit of a hack added for communities.
Speaking of communities, should the RFC3765 "NOPEER" community be added to the well-known community enum list?
-Larry
-- Engin Gunduz RIPE NCC Software Engineering Department
Short version: Let's ship it! Long version: I think the current version is Good Enough, and it's high time we get this out as an RFC, so that the routing registries implement it and we (ISPs that have peerings other than IPv4 unicast) can use it. Personally I'm not convinced that the current defaulting semantics in the "mp-..." attributes are optimal, but they seem to be close to the best compromise that we can achieve. My reservation is that we default mp-... without "afi" qualifier to default to exactly the four AFI/SAFIs of ipv4.unicast, ipv4.multicast, ipv6.unicast, ipv6.multicast, and this set of four AFI/SAFIs doesn't seem to be guaranteed future-proof. But I don't care, I don't think I'll be using the defaults anyway (look at AS559 in the RIPE test whois registry at rpslng.ripe.net, port 53001, for how I intend to use RPSLng). By the time people will want different defaults - either because IPv4 or IPv6 or multicast (re-)become exotic, or something else becomes widespread - we simply won't be able to seamlessly change those defaults. But probably by that time it will be a good idea to base the routing registry on something completely different anyway. A unified grammar (maybe even in RFC2234-compatible ABNF!) would be great, but let's leave this for a future RFC that replaces both RFC 2622 and the RPSLng RFC. Regards, -- Simon.
Simon Leinen wrote:
Short version: Let's ship it!
I'd like this out as well - I want to get on with getting the New Zealand IXes using RPSL based configuration for the IPv6 route servers and I want to be able to point to a standard so I can start persuading the particpants to do the right thing with IPv6 from day one. I may then even persuade them of the value for IPv4.
On Sat, 29 May 2004, Simon Leinen wrote:
Short version: Let's ship it!
Long version:
I think the current version is Good Enough, and it's high time we get this out as an RFC, so that the routing registries implement it and we (ISPs that have peerings other than IPv4 unicast) can use it.
Personally I'm not convinced that the current defaulting semantics in the "mp-..." attributes are optimal, but they seem to be close to the best compromise that we can achieve. My reservation is that we default mp-... without "afi" qualifier to default to exactly the four AFI/SAFIs of ipv4.unicast, ipv4.multicast, ipv6.unicast, ipv6.multicast, and this set of four AFI/SAFIs doesn't seem to be guaranteed future-proof. But I don't care, I don't think I'll be using the defaults anyway (look at AS559 in the RIPE test whois registry at rpslng.ripe.net, port 53001, for how I intend to use RPSLng). By the time people will want different defaults - either because IPv4 or IPv6 or multicast (re-)become exotic, or something else becomes widespread - we simply won't be able to seamlessly change those defaults. But probably by that time it will be a good idea to base the routing registry on something completely different anyway.
A unified grammar (maybe even in RFC2234-compatible ABNF!) would be great, but let's leave this for a future RFC that replaces both RFC 2622 and the RPSLng RFC.
Regards, -- Simon.
Hello, I strongly agree with Simon. This is already suitable enough to be taken to the next step (the deployment that will enable non-v4-unicast-only ISPs to express their own routing policies). Regards, ./Carlos -------------- IPv6 -> http://www.ip6.fccn.pt Wide Area Network Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (135072/470), naming (millions) and... people!"
participants (7)
-
Andy Linton -
Carlos Friacas -
Engin Gunduz -
Larry Blunk -
Larry J. Blunk
-
Mark Prior -
Simon Leinen