From rps-admin@ietf.org Fri Jan 2 03:29:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22523 for ; Fri, 2 Jan 2004 03:29:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcKg2-0006g4-TT; Fri, 02 Jan 2004 03:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcKfE-0006fB-8e for rps@optimus.ietf.org; Fri, 02 Jan 2004 03:28:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22504 for ; Fri, 2 Jan 2004 03:28:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcKfB-0003EW-00 for rps@ietf.org; Fri, 02 Jan 2004 03:28:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcKde-0003Ah-00 for rps@ietf.org; Fri, 02 Jan 2004 03:26:38 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcKby-000361-00 for rps@ietf.org; Fri, 02 Jan 2004 03:24:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i028OKr09658; Fri, 2 Jan 2004 10:24:20 +0200 From: Pekka Savola To: rps@ietf.org cc: rpslng@ripe.net Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 2 Jan 2004 10:24:20 +0200 (EET) Hi, (I tailed down the Cc: list..) On Sat, 27 Dec 2003, Randy Bush wrote: > > OK, I now found that the doc did have an IETF Last Call > > in late August/Early Sept. > > and there were technical objections which have not been addressed Thanks, Randy, for reminding about that. Based on some off-list discussion, the technical objections being referred to are the comments from Mark Prior on the list, one of them copied below. I'll try to summarize the loooo-ong thread somehow. Mark believes that the current RPSLng proposition unnecessarily adds complexity to the operators' use of the language, as e.g. IPv4 and IPv6 addresses, peerings, etc. could all be facilitated by redefining the current attributes etc. -- and whichever would be returned could be evaluated based on the context. As the number of operators using the language is extremely high (and we'd like it to be higher :-) compared to the registry/tool implementations, Mark argues that optimizing for the simplicity to the operators is the most important goal. Curtis objects to this mainly based on the fact that this would break the backward compatibility for the clients which do not expect to receive IPv6 data back from their queries. This could be easily fixed e.g. in tools like IRRToolSet, but that there are a probably a number of hacks built on top of perl, telnetting to port 43, or whatever, which might not be equally fortunate. Workarounds to this seem to be adding some kind of version negotiation or inclusion to the whois protocol (in the future, maybe using CRISP), so that only the clients who signal "yes, I can process IPv6 records!" would activate the IPv6 context processing. This could also be passed to the whois server with an option, like '--use-rpslng' or '-6'. Or maybe the client would state which records it wants to get, e.g. '-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or something, for "NEW", otherwise only v4 would be returned :) for both). At least RIPE database allows the use of '-Vxxx' verstion string to tell about the version of the client software. The exact details of how this method would work out would need to be fleshed out. Any takers? Personally, when I was trying to form an opinion on this subject, I found myself thinking that Mark's proposal addresses only IPv4/IPv6 case. It doesn't seem to address how one could specify different unicast/multicast policies, or how to specify different v4/v6 policies. This is also one goal of RPSLng.. even though the major operators who do have multicast or v6 often want their policies to be the same. How would this work out if a "more intelligence" model was adopted? (I'm personally a bit unsure whether a "more intelligence in the tools" -model would or would not make sense at this point, but I think I can see both sides of the argument..) Could we get some form of discussion and maybe consensus on what would seem to be the right way forward? :-) =========== Date: Tue, 23 Sep 2003 09:00:06 +0930 From: Mark Prior To: curtis@fictitious.org Cc: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard Curtis Villamizar wrote: > How is RPSLng not a superset of RPSL? Nothing has been removed from > RPSL. Superset is probably not the best word to describe what I want. > The issue is just how do you make transition easiest, supporting older > RPSL only clients. If you just extend import rather than rename it > mp-import and extend it, then old RPSL only clients will consider you > autnum broken. If you include mp-import but forget to reflect you > IPv4 policy in plain import then the old RPSL client will pick up a > subset of you policy. > > In either case, extending import, or adding mp-import and putting the > extensions there, it would make for a smoother transition if the > server code could recognize old clients and feed them with objects > translated into plain RPSL. I think I have been consistent in wanting the smarts to be in the software and not the language. I would prefer to overload the syntax then create new syntax and let the software work out what is required. We don't use different syntax in computer languages when we want to operate on integers rather than reals so why make the distinction in RPSL? If we have a route object that has a IPv6 address in it surely the software can work out if it wants it or not given it's current context? I know you (and others :-) keep on about the old clients but we have left them behind once before in the transition from RIPE 181 to RPSL so do it again but this time lets leave some mechanism behind so that when we need (RPSLng)ng we don't go through this pain yet again. Saying it's not part of the language is a pathetic excuse in my book for not fixing it. If we need a "shim" document to describe the interaction between a server and a client then lets do it. It would make the client software writers life a lot easier if there weren't (at least) 3 server interaction languages to deal with. Mark. ========== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Fri Jan 2 03:32:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22600 for ; Fri, 2 Jan 2004 03:32:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcKiw-00071S-71 for rps-archive@odin.ietf.org; Fri, 02 Jan 2004 03:32:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i028W1eh026987 for rps-archive@odin.ietf.org; Fri, 2 Jan 2004 03:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcKiv-00071C-K8 for rps-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 03:32:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22578 for ; Fri, 2 Jan 2004 03:31:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcKit-0003Ma-00 for rps-web-archive@ietf.org; Fri, 02 Jan 2004 03:31:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcKh8-0003Iz-00 for rps-web-archive@ietf.org; Fri, 02 Jan 2004 03:30:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcKgF-0003GJ-00 for rps-web-archive@ietf.org; Fri, 02 Jan 2004 03:29:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcKg2-0006g4-TT; Fri, 02 Jan 2004 03:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcKfE-0006fB-8e for rps@optimus.ietf.org; Fri, 02 Jan 2004 03:28:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22504 for ; Fri, 2 Jan 2004 03:28:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcKfB-0003EW-00 for rps@ietf.org; Fri, 02 Jan 2004 03:28:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcKde-0003Ah-00 for rps@ietf.org; Fri, 02 Jan 2004 03:26:38 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcKby-000361-00 for rps@ietf.org; Fri, 02 Jan 2004 03:24:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i028OKr09658; Fri, 2 Jan 2004 10:24:20 +0200 From: Pekka Savola To: rps@ietf.org cc: rpslng@ripe.net Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 2 Jan 2004 10:24:20 +0200 (EET) Hi, (I tailed down the Cc: list..) On Sat, 27 Dec 2003, Randy Bush wrote: > > OK, I now found that the doc did have an IETF Last Call > > in late August/Early Sept. > > and there were technical objections which have not been addressed Thanks, Randy, for reminding about that. Based on some off-list discussion, the technical objections being referred to are the comments from Mark Prior on the list, one of them copied below. I'll try to summarize the loooo-ong thread somehow. Mark believes that the current RPSLng proposition unnecessarily adds complexity to the operators' use of the language, as e.g. IPv4 and IPv6 addresses, peerings, etc. could all be facilitated by redefining the current attributes etc. -- and whichever would be returned could be evaluated based on the context. As the number of operators using the language is extremely high (and we'd like it to be higher :-) compared to the registry/tool implementations, Mark argues that optimizing for the simplicity to the operators is the most important goal. Curtis objects to this mainly based on the fact that this would break the backward compatibility for the clients which do not expect to receive IPv6 data back from their queries. This could be easily fixed e.g. in tools like IRRToolSet, but that there are a probably a number of hacks built on top of perl, telnetting to port 43, or whatever, which might not be equally fortunate. Workarounds to this seem to be adding some kind of version negotiation or inclusion to the whois protocol (in the future, maybe using CRISP), so that only the clients who signal "yes, I can process IPv6 records!" would activate the IPv6 context processing. This could also be passed to the whois server with an option, like '--use-rpslng' or '-6'. Or maybe the client would state which records it wants to get, e.g. '-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or something, for "NEW", otherwise only v4 would be returned :) for both). At least RIPE database allows the use of '-Vxxx' verstion string to tell about the version of the client software. The exact details of how this method would work out would need to be fleshed out. Any takers? Personally, when I was trying to form an opinion on this subject, I found myself thinking that Mark's proposal addresses only IPv4/IPv6 case. It doesn't seem to address how one could specify different unicast/multicast policies, or how to specify different v4/v6 policies. This is also one goal of RPSLng.. even though the major operators who do have multicast or v6 often want their policies to be the same. How would this work out if a "more intelligence" model was adopted? (I'm personally a bit unsure whether a "more intelligence in the tools" -model would or would not make sense at this point, but I think I can see both sides of the argument..) Could we get some form of discussion and maybe consensus on what would seem to be the right way forward? :-) =========== Date: Tue, 23 Sep 2003 09:00:06 +0930 From: Mark Prior To: curtis@fictitious.org Cc: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, rps@ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard Curtis Villamizar wrote: > How is RPSLng not a superset of RPSL? Nothing has been removed from > RPSL. Superset is probably not the best word to describe what I want. > The issue is just how do you make transition easiest, supporting older > RPSL only clients. If you just extend import rather than rename it > mp-import and extend it, then old RPSL only clients will consider you > autnum broken. If you include mp-import but forget to reflect you > IPv4 policy in plain import then the old RPSL client will pick up a > subset of you policy. > > In either case, extending import, or adding mp-import and putting the > extensions there, it would make for a smoother transition if the > server code could recognize old clients and feed them with objects > translated into plain RPSL. I think I have been consistent in wanting the smarts to be in the software and not the language. I would prefer to overload the syntax then create new syntax and let the software work out what is required. We don't use different syntax in computer languages when we want to operate on integers rather than reals so why make the distinction in RPSL? If we have a route object that has a IPv6 address in it surely the software can work out if it wants it or not given it's current context? I know you (and others :-) keep on about the old clients but we have left them behind once before in the transition from RIPE 181 to RPSL so do it again but this time lets leave some mechanism behind so that when we need (RPSLng)ng we don't go through this pain yet again. Saying it's not part of the language is a pathetic excuse in my book for not fixing it. If we need a "shim" document to describe the interaction between a server and a client then lets do it. It would make the client software writers life a lot easier if there weren't (at least) 3 server interaction languages to deal with. Mark. ========== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Fri Jan 2 03:52:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23105 for ; Fri, 2 Jan 2004 03:52:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcL2G-0007ok-I3; Fri, 02 Jan 2004 03:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcL2E-0007oW-7G for rps@optimus.ietf.org; Fri, 02 Jan 2004 03:51:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23073 for ; Fri, 2 Jan 2004 03:51:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcL2B-0003zC-00 for rps@ietf.org; Fri, 02 Jan 2004 03:51:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcL0H-0003w0-00 for rps@ietf.org; Fri, 02 Jan 2004 03:50:00 -0500 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1AcKyY-0003rP-00 for rps@ietf.org; Fri, 02 Jan 2004 03:48:10 -0500 Received: from mrp.net (CPE-144-137-220-76.sa.bigpond.net.au [144.137.220.76]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id i028lPFk013636 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Fri, 2 Jan 2004 19:17:29 +1030 (CST) (envelope-from mrp@mrp.net) Message-ID: <3FF5301D.5000701@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: rps@ietf.org, rpslng@ripe.net Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Jan 2004 19:17:25 +1030 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > I'll try to summarize the loooo-ong thread somehow. Mark believes > that the current RPSLng proposition unnecessarily adds complexity to > the operators' use of the language, as e.g. IPv4 and IPv6 addresses, > peerings, etc. could all be facilitated by redefining the current > attributes etc. -- and whichever would be returned could be evaluated > based on the context. As the number of operators using the language > is extremely high (and we'd like it to be higher :-) compared to the > registry/tool implementations, Mark argues that optimizing for the > simplicity to the operators is the most important goal. That pretty much summarises my position. I will also comment that when we migrated from RIPE-181 to RPSL we also had a backward compatibility problem but that didn't seem to be a problem back then so I don't see why it's now suddenly a problem. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Fri Jan 2 03:56:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23221 for ; Fri, 2 Jan 2004 03:56:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcL64-0007uV-Pq for rps-archive@odin.ietf.org; Fri, 02 Jan 2004 03:55:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i028tuio030408 for rps-archive@odin.ietf.org; Fri, 2 Jan 2004 03:55:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcL64-0007uN-FQ for rps-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 03:55:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23198 for ; Fri, 2 Jan 2004 03:55:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcL61-000470-00 for rps-web-archive@ietf.org; Fri, 02 Jan 2004 03:55:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcL4L-00043Y-00 for rps-web-archive@ietf.org; Fri, 02 Jan 2004 03:54:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcL2K-0003zo-00 for rps-web-archive@ietf.org; Fri, 02 Jan 2004 03:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcL2G-0007ok-I3; Fri, 02 Jan 2004 03:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcL2E-0007oW-7G for rps@optimus.ietf.org; Fri, 02 Jan 2004 03:51:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23073 for ; Fri, 2 Jan 2004 03:51:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcL2B-0003zC-00 for rps@ietf.org; Fri, 02 Jan 2004 03:51:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcL0H-0003w0-00 for rps@ietf.org; Fri, 02 Jan 2004 03:50:00 -0500 Received: from suzuka.mrp.net ([150.101.71.129]) by ietf-mx with esmtp (Exim 4.12) id 1AcKyY-0003rP-00 for rps@ietf.org; Fri, 02 Jan 2004 03:48:10 -0500 Received: from mrp.net (CPE-144-137-220-76.sa.bigpond.net.au [144.137.220.76]) (authenticated (0 bits)) by suzuka.mrp.net (8.12.10/8.12.10) with ESMTP id i028lPFk013636 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Fri, 2 Jan 2004 19:17:29 +1030 (CST) (envelope-from mrp@mrp.net) Message-ID: <3FF5301D.5000701@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: rps@ietf.org, rpslng@ripe.net Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Jan 2004 19:17:25 +1030 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > I'll try to summarize the loooo-ong thread somehow. Mark believes > that the current RPSLng proposition unnecessarily adds complexity to > the operators' use of the language, as e.g. IPv4 and IPv6 addresses, > peerings, etc. could all be facilitated by redefining the current > attributes etc. -- and whichever would be returned could be evaluated > based on the context. As the number of operators using the language > is extremely high (and we'd like it to be higher :-) compared to the > registry/tool implementations, Mark argues that optimizing for the > simplicity to the operators is the most important goal. That pretty much summarises my position. I will also comment that when we migrated from RIPE-181 to RPSL we also had a backward compatibility problem but that didn't seem to be a problem back then so I don't see why it's now suddenly a problem. Mark. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Fri Jan 2 23:50:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06727 for ; Fri, 2 Jan 2004 23:50:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acdig-0002om-53; Fri, 02 Jan 2004 23:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acdi2-0002m5-KM for rps@optimus.ietf.org; Fri, 02 Jan 2004 23:48:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06706 for ; Fri, 2 Jan 2004 23:48:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Acdhy-0007Wh-00 for rps@ietf.org; Fri, 02 Jan 2004 23:48:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Acdg4-0007TQ-00 for rps@ietf.org; Fri, 02 Jan 2004 23:46:20 -0500 Received: from [211.161.169.190] (helo=211.161.169.190) by ietf-mx with smtp (Exim 4.12) id 1Acdf5-0007Qa-00 for rps@ietf.org; Fri, 02 Jan 2004 23:45:20 -0500 From: 241485@aol.com X-Mailer: MIME::Lite 2.117 (F2.6; A1.44; B2.12; Q2.03) Reply-To: 241485@yahoo.com Organization: 1562909390 X-Priority: 3 (Normal) To: rps@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=25.4 required=5.0 tests=ADDR_NUMS_AT_BIGSITE, DATE_IN_FUTURE_12_24,FROM_ALL_NUMS,FROM_ENDS_IN_NUMS, FROM_NUM_AT_WEBMAIL,FROM_STARTS_WITH_NUMS,FROM_WEBMAIL_END_NUMS6, HTML_30_40,HTML_FONT_BIG,HTML_MESSAGE,IMPOTENCE,INCREASE_SEX, MIME_HTML_ONLY,MONEY_BACK,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, PENIS_ENLARGE2,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 2.1 FROM_WEBMAIL_END_NUMS6 From webmail service and address ends in numbers * 0.3 NO_REAL_NAME From: does not include a real name * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 1.1 FROM_NUM_AT_WEBMAIL From address is webmail, but starts with a number * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.7 ADDR_NUMS_AT_BIGSITE Uses an address with lots of numbers, at a big ISP * 1.6 FROM_STARTS_WITH_NUMS From: starts with nums * 0.6 PENIS_ENLARGE2 BODY: Information on getting larger penis/breasts * 4.2 IMPOTENCE BODY: Impotence cure * 1.9 INCREASE_SEX BODY: Talks about a bigger drive for sex * 4.3 MONEY_BACK BODY: Money back guarantee * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 2.0 DATE_IN_FUTURE_12_24 Date: is 12 to 24 hours after Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 FROM_ALL_NUMS From an address that is all numbers (non-phone) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id XAA06708 Subject: [Rps] (no subject) Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 03 Jan 2004 12:46:56 -0800 Content-Transfer-Encoding: quoted-printable
The Facts...


     Deep in Canada=92s b= arren North, lives an animal scientists believe to be the most prolific l= over in the entire animal kingdom. During the Fall rutting season, the ma= le Wapiti Elk (cervus elaphus) amasses a hormonal structure that allows h= im to experience multiple sexual orgasms within three minutes apart =96 a= nd up to 20 times per day!=20 Now imagine that you might safely infuse yourself with the hormones behin= d this incredibly virile creature's sexual abilities. You'd find yourself= in the enviable position of being known as "Super Sex Machine". You woul= d have amazing stamina. The ability to rapidly rejuvenate your erections.= Allowing you to please your lover over and over again, until she begs yo= u to stop.


Only Alpha Male Plus can give men multiple orgasms.

* Increase testosterone levels up to 500 percent
* Prevent premature ejaculation
* Enhance penis size up to 3 inches
* Maintain harder, stronger erections for hours
* Have amazing sex up to 20 times per day
* Improve sexual stamina dramatically
* Increase sexual self-confidence
* Satisfy yourself and your lover like never before
* 100 percent Safe To Take, With NO Side Effects
* Fast Priority USPS Shipping WorldWide
* Doctor Approved And Recommended
* 100 percent Money Back Guarantee
* FREE Bottle Of AlphaMale+ Worth Over $50
* FREE "Male Help E-Book" Worth Over $50


Continue... -> =20







Remove me from this list
_______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Fri Jan 2 23:50:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06820 for ; Fri, 2 Jan 2004 23:50:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acdk3-0002sa-Ig for rps-archive@odin.ietf.org; Fri, 02 Jan 2004 23:50:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i034oRxA011069 for rps-archive@odin.ietf.org; Fri, 2 Jan 2004 23:50:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acdk3-0002sS-6s for rps-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 23:50:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06816 for ; Fri, 2 Jan 2004 23:50:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Acdk0-0007cR-00 for rps-web-archive@ietf.org; Fri, 02 Jan 2004 23:50:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcdjF-0007YZ-00 for rps-web-archive@ietf.org; Fri, 02 Jan 2004 23:49:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acdig-0002om-53; Fri, 02 Jan 2004 23:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acdi2-0002m5-KM for rps@optimus.ietf.org; Fri, 02 Jan 2004 23:48:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06706 for ; Fri, 2 Jan 2004 23:48:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Acdhy-0007Wh-00 for rps@ietf.org; Fri, 02 Jan 2004 23:48:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Acdg4-0007TQ-00 for rps@ietf.org; Fri, 02 Jan 2004 23:46:20 -0500 Received: from [211.161.169.190] (helo=211.161.169.190) by ietf-mx with smtp (Exim 4.12) id 1Acdf5-0007Qa-00 for rps@ietf.org; Fri, 02 Jan 2004 23:45:20 -0500 From: 241485@aol.com X-Mailer: MIME::Lite 2.117 (F2.6; A1.44; B2.12; Q2.03) Reply-To: 241485@yahoo.com Organization: 1562909390 X-Priority: 3 (Normal) To: rps@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=25.4 required=5.0 tests=ADDR_NUMS_AT_BIGSITE, DATE_IN_FUTURE_12_24,FROM_ALL_NUMS,FROM_ENDS_IN_NUMS, FROM_NUM_AT_WEBMAIL,FROM_STARTS_WITH_NUMS,FROM_WEBMAIL_END_NUMS6, HTML_30_40,HTML_FONT_BIG,HTML_MESSAGE,IMPOTENCE,INCREASE_SEX, MIME_HTML_ONLY,MONEY_BACK,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, PENIS_ENLARGE2,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 2.1 FROM_WEBMAIL_END_NUMS6 From webmail service and address ends in numbers * 0.3 NO_REAL_NAME From: does not include a real name * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 1.1 FROM_NUM_AT_WEBMAIL From address is webmail, but starts with a number * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.7 ADDR_NUMS_AT_BIGSITE Uses an address with lots of numbers, at a big ISP * 1.6 FROM_STARTS_WITH_NUMS From: starts with nums * 0.6 PENIS_ENLARGE2 BODY: Information on getting larger penis/breasts * 4.2 IMPOTENCE BODY: Impotence cure * 1.9 INCREASE_SEX BODY: Talks about a bigger drive for sex * 4.3 MONEY_BACK BODY: Money back guarantee * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 2.0 DATE_IN_FUTURE_12_24 Date: is 12 to 24 hours after Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 FROM_ALL_NUMS From an address that is all numbers (non-phone) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id XAA06708 Subject: [Rps] (no subject) Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 03 Jan 2004 12:46:56 -0800 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable
The Facts...


     Deep in Canada=92s b= arren North, lives an animal scientists believe to be the most prolific l= over in the entire animal kingdom. During the Fall rutting season, the ma= le Wapiti Elk (cervus elaphus) amasses a hormonal structure that allows h= im to experience multiple sexual orgasms within three minutes apart =96 a= nd up to 20 times per day!=20 Now imagine that you might safely infuse yourself with the hormones behin= d this incredibly virile creature's sexual abilities. You'd find yourself= in the enviable position of being known as "Super Sex Machine". You woul= d have amazing stamina. The ability to rapidly rejuvenate your erections.= Allowing you to please your lover over and over again, until she begs yo= u to stop.


Only Alpha Male Plus can give men multiple orgasms.

* Increase testosterone levels up to 500 percent
* Prevent premature ejaculation
* Enhance penis size up to 3 inches
* Maintain harder, stronger erections for hours
* Have amazing sex up to 20 times per day
* Improve sexual stamina dramatically
* Increase sexual self-confidence
* Satisfy yourself and your lover like never before
* 100 percent Safe To Take, With NO Side Effects
* Fast Priority USPS Shipping WorldWide
* Doctor Approved And Recommended
* 100 percent Money Back Guarantee
* FREE Bottle Of AlphaMale+ Worth Over $50
* FREE "Male Help E-Book" Worth Over $50


Continue... -> =20







Remove me from this list
_______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Jan 13 11:21:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21761 for ; Tue, 13 Jan 2004 11:21:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRHs-0003JF-6I; Tue, 13 Jan 2004 11:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRHQ-0003Hn-44 for rps@optimus.ietf.org; Tue, 13 Jan 2004 11:20:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21721 for ; Tue, 13 Jan 2004 11:20:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgRHP-0001Io-00 for rps@ietf.org; Tue, 13 Jan 2004 11:20:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRFn-0001Eh-00 for rps@ietf.org; Tue, 13 Jan 2004 11:18:56 -0500 Received: from segue.merit.edu ([198.108.1.41]) by ietf-mx with esmtp (Exim 4.12) id 1AgREh-00018v-00 for rps@ietf.org; Tue, 13 Jan 2004 11:17:47 -0500 Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151]) by segue.merit.edu (Postfix) with ESMTP id 77EB55DDAF; Tue, 13 Jan 2004 11:17:46 -0500 (EST) Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] From: "Larry J. Blunk" To: Pekka Savola Cc: rps@ietf.org, rpslng@ripe.net In-Reply-To: References: Content-Type: text/plain Organization: Merit Network, Inc. Message-Id: <1074010929.3795.45.camel@ablate.merit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Jan 2004 11:22:09 -0500 Content-Transfer-Encoding: 7bit On Fri, 2004-01-02 at 03:24, Pekka Savola wrote: > Hi, > > (I tailed down the Cc: list..) > > On Sat, 27 Dec 2003, Randy Bush wrote: > > > OK, I now found that the doc did have an IETF Last Call > > > in late August/Early Sept. > > > > and there were technical objections which have not been addressed > > Thanks, Randy, for reminding about that. > > Based on some off-list discussion, the technical objections being > referred to are the comments from Mark Prior on the list, one of them > copied below. > > I'll try to summarize the loooo-ong thread somehow. Mark believes > that the current RPSLng proposition unnecessarily adds complexity to > the operators' use of the language, as e.g. IPv4 and IPv6 addresses, > peerings, etc. could all be facilitated by redefining the current > attributes etc. -- and whichever would be returned could be evaluated > based on the context. As the number of operators using the language > is extremely high (and we'd like it to be higher :-) compared to the > registry/tool implementations, Mark argues that optimizing for the > simplicity to the operators is the most important goal. > > Curtis objects to this mainly based on the fact that this would break > the backward compatibility for the clients which do not expect to > receive IPv6 data back from their queries. This could be easily fixed > e.g. in tools like IRRToolSet, but that there are a probably a number > of hacks built on top of perl, telnetting to port 43, or whatever, > which might not be equally fortunate. > > Workarounds to this seem to be adding some kind of version negotiation > or inclusion to the whois protocol (in the future, maybe using CRISP), > so that only the clients who signal "yes, I can process IPv6 records!" > would activate the IPv6 context processing. This could also be passed > to the whois server with an option, like '--use-rpslng' or '-6'. Or > maybe the client would state which records it wants to get, e.g. > '-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or > something, for "NEW", otherwise only v4 would be returned :) for > both). At least RIPE database allows the use of '-Vxxx' verstion > string to tell about the version of the client software. > > The exact details of how this method would work out would need to be > fleshed out. Any takers? I don't believe this would be particularly productive. These are implementation details which are really outside the scope of the RPSLng work. I don't see the objections to RPSLng as objective technical issues, but rather subjective preferences. > > Personally, when I was trying to form an opinion on this subject, I > found myself thinking that Mark's proposal addresses only IPv4/IPv6 > case. It doesn't seem to address how one could specify different > unicast/multicast policies, or how to specify different v4/v6 > policies. This is also one goal of RPSLng.. even though the major > operators who do have multicast or v6 often want their policies to be > the same. > > How would this work out if a "more intelligence" model was adopted? > > (I'm personally a bit unsure whether a "more intelligence in the > tools" -model would or would not make sense at this point, but I think > I can see both sides of the argument..) It is very difficult to judge the impact of such a model without having a complete census of the various tools in use by ISP's. For example, C&W has an extensive set of in-house developed tools which interact with IRR's. Is it fair to ask them to hack up their tools to fit this model? > > Could we get some form of discussion and maybe consensus on what would > seem to be the right way forward? :-) I think we have already reached the point of "rough" consensus. Again, I view the expressed objections as subjective preferences rather than solid technical beefs with the specification. Regards, Larry > > =========== > Date: Tue, 23 Sep 2003 09:00:06 +0930 > From: Mark Prior > To: curtis@fictitious.org > Cc: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, > rps@ietf.org > Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard > > Curtis Villamizar wrote: > > > How is RPSLng not a superset of RPSL? Nothing has been removed from > > RPSL. > > Superset is probably not the best word to describe what I want. > > > The issue is just how do you make transition easiest, supporting older > > RPSL only clients. If you just extend import rather than rename it > > mp-import and extend it, then old RPSL only clients will consider you > > autnum broken. If you include mp-import but forget to reflect you > > IPv4 policy in plain import then the old RPSL client will pick up a > > subset of you policy. > > > > In either case, extending import, or adding mp-import and putting the > > extensions there, it would make for a smoother transition if the > > server code could recognize old clients and feed them with objects > > translated into plain RPSL. > > I think I have been consistent in wanting the smarts to be in the > software and not the language. I would prefer to overload the syntax > then create new syntax and let the software work out what is required. > We don't use different syntax in computer languages when we want to > operate on integers rather than reals so why make the distinction in > RPSL? If we have a route object that has a IPv6 address in it surely the > software can work out if it wants it or not given it's current context? > > I know you (and others :-) keep on about the old clients but we have > left them behind once before in the transition from RIPE 181 to RPSL so > do it again but this time lets leave some mechanism behind so that when > we need (RPSLng)ng we don't go through this pain yet again. Saying it's > not part of the language is a pathetic excuse in my book for not fixing > it. If we need a "shim" document to describe the interaction between a > server and a client then lets do it. It would make the client software > writers life a lot easier if there weren't (at least) 3 server > interaction languages to deal with. > > Mark. > ========== _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Jan 13 11:24:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21946 for ; Tue, 13 Jan 2004 11:24:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRLB-0003ON-Cf for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 11:24:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DGOTtE013039 for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 11:24:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRLB-0003OE-7G for rps-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 11:24:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21917 for ; Tue, 13 Jan 2004 11:24:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgRLA-0001Sb-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 11:24:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRJL-0001OQ-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 11:22:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgRI4-0001KF-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 11:21:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRHs-0003JF-6I; Tue, 13 Jan 2004 11:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRHQ-0003Hn-44 for rps@optimus.ietf.org; Tue, 13 Jan 2004 11:20:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21721 for ; Tue, 13 Jan 2004 11:20:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgRHP-0001Io-00 for rps@ietf.org; Tue, 13 Jan 2004 11:20:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRFn-0001Eh-00 for rps@ietf.org; Tue, 13 Jan 2004 11:18:56 -0500 Received: from segue.merit.edu ([198.108.1.41]) by ietf-mx with esmtp (Exim 4.12) id 1AgREh-00018v-00 for rps@ietf.org; Tue, 13 Jan 2004 11:17:47 -0500 Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151]) by segue.merit.edu (Postfix) with ESMTP id 77EB55DDAF; Tue, 13 Jan 2004 11:17:46 -0500 (EST) Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] From: "Larry J. Blunk" To: Pekka Savola Cc: rps@ietf.org, rpslng@ripe.net In-Reply-To: References: Content-Type: text/plain Organization: Merit Network, Inc. Message-Id: <1074010929.3795.45.camel@ablate.merit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Jan 2004 11:22:09 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2004-01-02 at 03:24, Pekka Savola wrote: > Hi, > > (I tailed down the Cc: list..) > > On Sat, 27 Dec 2003, Randy Bush wrote: > > > OK, I now found that the doc did have an IETF Last Call > > > in late August/Early Sept. > > > > and there were technical objections which have not been addressed > > Thanks, Randy, for reminding about that. > > Based on some off-list discussion, the technical objections being > referred to are the comments from Mark Prior on the list, one of them > copied below. > > I'll try to summarize the loooo-ong thread somehow. Mark believes > that the current RPSLng proposition unnecessarily adds complexity to > the operators' use of the language, as e.g. IPv4 and IPv6 addresses, > peerings, etc. could all be facilitated by redefining the current > attributes etc. -- and whichever would be returned could be evaluated > based on the context. As the number of operators using the language > is extremely high (and we'd like it to be higher :-) compared to the > registry/tool implementations, Mark argues that optimizing for the > simplicity to the operators is the most important goal. > > Curtis objects to this mainly based on the fact that this would break > the backward compatibility for the clients which do not expect to > receive IPv6 data back from their queries. This could be easily fixed > e.g. in tools like IRRToolSet, but that there are a probably a number > of hacks built on top of perl, telnetting to port 43, or whatever, > which might not be equally fortunate. > > Workarounds to this seem to be adding some kind of version negotiation > or inclusion to the whois protocol (in the future, maybe using CRISP), > so that only the clients who signal "yes, I can process IPv6 records!" > would activate the IPv6 context processing. This could also be passed > to the whois server with an option, like '--use-rpslng' or '-6'. Or > maybe the client would state which records it wants to get, e.g. > '-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or > something, for "NEW", otherwise only v4 would be returned :) for > both). At least RIPE database allows the use of '-Vxxx' verstion > string to tell about the version of the client software. > > The exact details of how this method would work out would need to be > fleshed out. Any takers? I don't believe this would be particularly productive. These are implementation details which are really outside the scope of the RPSLng work. I don't see the objections to RPSLng as objective technical issues, but rather subjective preferences. > > Personally, when I was trying to form an opinion on this subject, I > found myself thinking that Mark's proposal addresses only IPv4/IPv6 > case. It doesn't seem to address how one could specify different > unicast/multicast policies, or how to specify different v4/v6 > policies. This is also one goal of RPSLng.. even though the major > operators who do have multicast or v6 often want their policies to be > the same. > > How would this work out if a "more intelligence" model was adopted? > > (I'm personally a bit unsure whether a "more intelligence in the > tools" -model would or would not make sense at this point, but I think > I can see both sides of the argument..) It is very difficult to judge the impact of such a model without having a complete census of the various tools in use by ISP's. For example, C&W has an extensive set of in-house developed tools which interact with IRR's. Is it fair to ask them to hack up their tools to fit this model? > > Could we get some form of discussion and maybe consensus on what would > seem to be the right way forward? :-) I think we have already reached the point of "rough" consensus. Again, I view the expressed objections as subjective preferences rather than solid technical beefs with the specification. Regards, Larry > > =========== > Date: Tue, 23 Sep 2003 09:00:06 +0930 > From: Mark Prior > To: curtis@fictitious.org > Cc: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, > rps@ietf.org > Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard > > Curtis Villamizar wrote: > > > How is RPSLng not a superset of RPSL? Nothing has been removed from > > RPSL. > > Superset is probably not the best word to describe what I want. > > > The issue is just how do you make transition easiest, supporting older > > RPSL only clients. If you just extend import rather than rename it > > mp-import and extend it, then old RPSL only clients will consider you > > autnum broken. If you include mp-import but forget to reflect you > > IPv4 policy in plain import then the old RPSL client will pick up a > > subset of you policy. > > > > In either case, extending import, or adding mp-import and putting the > > extensions there, it would make for a smoother transition if the > > server code could recognize old clients and feed them with objects > > translated into plain RPSL. > > I think I have been consistent in wanting the smarts to be in the > software and not the language. I would prefer to overload the syntax > then create new syntax and let the software work out what is required. > We don't use different syntax in computer languages when we want to > operate on integers rather than reals so why make the distinction in > RPSL? If we have a route object that has a IPv6 address in it surely the > software can work out if it wants it or not given it's current context? > > I know you (and others :-) keep on about the old clients but we have > left them behind once before in the transition from RIPE 181 to RPSL so > do it again but this time lets leave some mechanism behind so that when > we need (RPSLng)ng we don't go through this pain yet again. Saying it's > not part of the language is a pathetic excuse in my book for not fixing > it. If we need a "shim" document to describe the interaction between a > server and a client then lets do it. It would make the client software > writers life a lot easier if there weren't (at least) 3 server > interaction languages to deal with. > > Mark. > ========== _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Jan 13 11:33:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22634 for ; Tue, 13 Jan 2004 11:33:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRTQ-0003b1-Mo; Tue, 13 Jan 2004 11:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRTH-0003aO-QB for rps@optimus.ietf.org; Tue, 13 Jan 2004 11:32:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22605 for ; Tue, 13 Jan 2004 11:32:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgRTG-00028l-00 for rps@ietf.org; Tue, 13 Jan 2004 11:32:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRRl-00021H-00 for rps@ietf.org; Tue, 13 Jan 2004 11:31:18 -0500 Received: from ip166.usw253.dsl-acs2.sea.iinet.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 1AgRPz-0001qm-00 for rps@ietf.org; Tue, 13 Jan 2004 11:29:27 -0500 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgRPu-0002HL-Ti; Tue, 13 Jan 2004 08:29:23 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Larry J. Blunk" Cc: rps@ietf.org, rpslng@ripe.net Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] References: <1074010929.3795.45.camel@ablate.merit.edu> Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 08:29:23 -0800 Content-Transfer-Encoding: 7bit then let me register my support for the issues and approaches marc raises. perhaps the system is for the benefit of operations more than the ease of registries? randy _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Jan 13 11:37:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22908 for ; Tue, 13 Jan 2004 11:37:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRWv-0003gp-Qq for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 11:36:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DGabTK014177 for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 11:36:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRWv-0003ga-LJ for rps-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 11:36:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22830 for ; Tue, 13 Jan 2004 11:36:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgRWu-0002Of-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 11:36:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRV7-0002HG-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 11:34:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgRTR-0002AP-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 11:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRTQ-0003b1-Mo; Tue, 13 Jan 2004 11:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRTH-0003aO-QB for rps@optimus.ietf.org; Tue, 13 Jan 2004 11:32:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22605 for ; Tue, 13 Jan 2004 11:32:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgRTG-00028l-00 for rps@ietf.org; Tue, 13 Jan 2004 11:32:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRRl-00021H-00 for rps@ietf.org; Tue, 13 Jan 2004 11:31:18 -0500 Received: from ip166.usw253.dsl-acs2.sea.iinet.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 1AgRPz-0001qm-00 for rps@ietf.org; Tue, 13 Jan 2004 11:29:27 -0500 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgRPu-0002HL-Ti; Tue, 13 Jan 2004 08:29:23 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Larry J. Blunk" Cc: rps@ietf.org, rpslng@ripe.net Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] References: <1074010929.3795.45.camel@ablate.merit.edu> Message-Id: Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 08:29:23 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit then let me register my support for the issues and approaches marc raises. perhaps the system is for the benefit of operations more than the ease of registries? randy _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Jan 13 12:03:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25546 for ; Tue, 13 Jan 2004 12:03:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRwS-00053B-UH; Tue, 13 Jan 2004 12:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRwI-00051g-1b for rps@optimus.ietf.org; Tue, 13 Jan 2004 12:02:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25508 for ; Tue, 13 Jan 2004 12:02:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgRwG-0004vi-00 for rps@ietf.org; Tue, 13 Jan 2004 12:02:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRut-0004kQ-00 for rps@ietf.org; Tue, 13 Jan 2004 12:01:23 -0500 Received: from segue.merit.edu ([198.108.1.41]) by ietf-mx with esmtp (Exim 4.12) id 1AgRsd-0004P2-00 for rps@ietf.org; Tue, 13 Jan 2004 11:59:03 -0500 Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151]) by segue.merit.edu (Postfix) with ESMTP id DD0885DE6E; Tue, 13 Jan 2004 11:59:01 -0500 (EST) Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] From: "Larry J. Blunk" To: Randy Bush Cc: rps@ietf.org, rpslng@ripe.net In-Reply-To: References: <1074010929.3795.45.camel@ablate.merit.edu> Content-Type: text/plain Organization: Merit Network, Inc. Message-Id: <1074013404.3795.52.camel@ablate.merit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Jan 2004 12:03:24 -0500 Content-Transfer-Encoding: 7bit On Tue, 2004-01-13 at 11:29, Randy Bush wrote: > then let me register my support for the issues and approaches > marc raises. perhaps the system is for the benefit of operations > more than the ease of registries? > > randy > There are a number of operators that run their own registries (e.g. Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal about preserving the syntax of existing RPSL attributes. -Larry _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Jan 13 12:09:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25801 for ; Tue, 13 Jan 2004 12:09:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgS2G-0005VX-Qo; Tue, 13 Jan 2004 12:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgS1b-0005Uk-9K for rps@optimus.ietf.org; Tue, 13 Jan 2004 12:08:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25758 for ; Tue, 13 Jan 2004 12:08:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgS1Z-00058q-00 for rps@ietf.org; Tue, 13 Jan 2004 12:08:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRzs-00056y-00 for rps@ietf.org; Tue, 13 Jan 2004 12:06:33 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AgRyX-00053n-00 for rps@ietf.org; Tue, 13 Jan 2004 12:05:09 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i0DH3CRX053524; Tue, 13 Jan 2004 12:03:12 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200401131703.i0DH3CRX053524@workhorse.fictitious.org> To: "Larry J. Blunk" cc: Pekka Savola , rps@ietf.org, rpslng@ripe.net Reply-To: curtis@fictitious.org Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-reply-to: Your message of "13 Jan 2004 11:22:09 EST." <1074010929.3795.45.camel@ablate.merit.edu> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 12:03:12 -0500 In message <1074010929.3795.45.camel@ablate.merit.edu>, "Larry J. Blunk" writes : > On Fri, 2004-01-02 at 03:24, Pekka Savola wrote: > > Hi, > > > > (I tailed down the Cc: list..) > > > > On Sat, 27 Dec 2003, Randy Bush wrote: > > > > OK, I now found that the doc did have an IETF Last Call > > > > in late August/Early Sept. > > > > > > and there were technical objections which have not been addressed > > > > Thanks, Randy, for reminding about that. > > > > Based on some off-list discussion, the technical objections being > > referred to are the comments from Mark Prior on the list, one of them > > copied below. > > > > I'll try to summarize the loooo-ong thread somehow. Mark believes > > that the current RPSLng proposition unnecessarily adds complexity to > > the operators' use of the language, as e.g. IPv4 and IPv6 addresses, > > peerings, etc. could all be facilitated by redefining the current > > attributes etc. -- and whichever would be returned could be evaluated > > based on the context. As the number of operators using the language > > is extremely high (and we'd like it to be higher :-) compared to the > > registry/tool implementations, Mark argues that optimizing for the > > simplicity to the operators is the most important goal. > > > > Curtis objects to this mainly based on the fact that this would break > > the backward compatibility for the clients which do not expect to > > receive IPv6 data back from their queries. This could be easily fixed > > e.g. in tools like IRRToolSet, but that there are a probably a number > > of hacks built on top of perl, telnetting to port 43, or whatever, > > which might not be equally fortunate. > > > > Workarounds to this seem to be adding some kind of version negotiation > > or inclusion to the whois protocol (in the future, maybe using CRISP), > > so that only the clients who signal "yes, I can process IPv6 records!" > > would activate the IPv6 context processing. This could also be passed > > to the whois server with an option, like '--use-rpslng' or '-6'. Or > > maybe the client would state which records it wants to get, e.g. > > '-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or > > something, for "NEW", otherwise only v4 would be returned :) for > > both). At least RIPE database allows the use of '-Vxxx' verstion > > string to tell about the version of the client software. > > > > The exact details of how this method would work out would need to be > > fleshed out. Any takers? > > I don't believe this would be particularly productive. These > are implementation details which are really outside the scope of > the RPSLng work. I don't see the objections to RPSLng as objective > technical issues, but rather subjective preferences. I'll agree with that. So if any comments I made having to do with transition and backwards compatibility are holding this up, comments which I beleive I made as suggestions, then please consider those to be resolved issues. > > Personally, when I was trying to form an opinion on this subject, I > > found myself thinking that Mark's proposal addresses only IPv4/IPv6 > > case. It doesn't seem to address how one could specify different > > unicast/multicast policies, or how to specify different v4/v6 > > policies. This is also one goal of RPSLng.. even though the major > > operators who do have multicast or v6 often want their policies to be > > the same. > > > > How would this work out if a "more intelligence" model was adopted? > > > > (I'm personally a bit unsure whether a "more intelligence in the > > tools" -model would or would not make sense at this point, but I think > > I can see both sides of the argument..) > > It is very difficult to judge the impact of such a model without > having a complete census of the various tools in use by ISP's. For > example, C&W has an extensive set of in-house developed tools which > interact with IRR's. Is it fair to ask them to hack up their tools > to fit this model? > > > > > Could we get some form of discussion and maybe consensus on what would > > seem to be the right way forward? :-) > > I think we have already reached the point of "rough" consensus. > Again, I view the expressed objections as subjective preferences rather > than solid technical beefs with the specification. > > Regards, > Larry I agree here too. Perhaps Mark can tell us whether he has any specific suggestions for changing the language from what is currently proposed. Curtis > > =========== > > Date: Tue, 23 Sep 2003 09:00:06 +0930 > > From: Mark Prior > > To: curtis@fictitious.org > > Cc: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, > > rps@ietf.org > > Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard > > > > Curtis Villamizar wrote: > > > > > How is RPSLng not a superset of RPSL? Nothing has been removed from > > > RPSL. > > > > Superset is probably not the best word to describe what I want. > > > > > The issue is just how do you make transition easiest, supporting older > > > RPSL only clients. If you just extend import rather than rename it > > > mp-import and extend it, then old RPSL only clients will consider you > > > autnum broken. If you include mp-import but forget to reflect you > > > IPv4 policy in plain import then the old RPSL client will pick up a > > > subset of you policy. > > > > > > In either case, extending import, or adding mp-import and putting the > > > extensions there, it would make for a smoother transition if the > > > server code could recognize old clients and feed them with objects > > > translated into plain RPSL. > > > > I think I have been consistent in wanting the smarts to be in the > > software and not the language. I would prefer to overload the syntax > > then create new syntax and let the software work out what is required. > > We don't use different syntax in computer languages when we want to > > operate on integers rather than reals so why make the distinction in > > RPSL? If we have a route object that has a IPv6 address in it surely the > > software can work out if it wants it or not given it's current context? > > > > I know you (and others :-) keep on about the old clients but we have > > left them behind once before in the transition from RIPE 181 to RPSL so > > do it again but this time lets leave some mechanism behind so that when > > we need (RPSLng)ng we don't go through this pain yet again. Saying it's > > not part of the language is a pathetic excuse in my book for not fixing > > it. If we need a "shim" document to describe the interaction between a > > server and a client then lets do it. It would make the client software > > writers life a lot easier if there weren't (at least) 3 server > > interaction languages to deal with. > > > > Mark. > > ========== > > > _______________________________________________ > Rps mailing list > Rps@ietf.org > https://www1.ietf.org/mailman/listinfo/rps _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Jan 13 12:13:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26085 for ; Tue, 13 Jan 2004 12:13:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgS6b-0005bL-2F for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 12:13:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DHDTQh021528 for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 12:13:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgS6a-0005b9-Sb for rps-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 12:13:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25974 for ; Tue, 13 Jan 2004 12:13:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgS6Z-0005hj-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 12:13:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgS3b-0005FH-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 12:10:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AgS1c-000585-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 12:08:20 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AgRwa-0003gS-0Q for rps-web-archive@ietf.org; Tue, 13 Jan 2004 12:03:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRwS-00053B-UH; Tue, 13 Jan 2004 12:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRwI-00051g-1b for rps@optimus.ietf.org; Tue, 13 Jan 2004 12:02:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25508 for ; Tue, 13 Jan 2004 12:02:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgRwG-0004vi-00 for rps@ietf.org; Tue, 13 Jan 2004 12:02:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRut-0004kQ-00 for rps@ietf.org; Tue, 13 Jan 2004 12:01:23 -0500 Received: from segue.merit.edu ([198.108.1.41]) by ietf-mx with esmtp (Exim 4.12) id 1AgRsd-0004P2-00 for rps@ietf.org; Tue, 13 Jan 2004 11:59:03 -0500 Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151]) by segue.merit.edu (Postfix) with ESMTP id DD0885DE6E; Tue, 13 Jan 2004 11:59:01 -0500 (EST) Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] From: "Larry J. Blunk" To: Randy Bush Cc: rps@ietf.org, rpslng@ripe.net In-Reply-To: References: <1074010929.3795.45.camel@ablate.merit.edu> Content-Type: text/plain Organization: Merit Network, Inc. Message-Id: <1074013404.3795.52.camel@ablate.merit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Jan 2004 12:03:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2004-01-13 at 11:29, Randy Bush wrote: > then let me register my support for the issues and approaches > marc raises. perhaps the system is for the benefit of operations > more than the ease of registries? > > randy > There are a number of operators that run their own registries (e.g. Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal about preserving the syntax of existing RPSL attributes. -Larry _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Jan 13 12:16:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26596 for ; Tue, 13 Jan 2004 12:16:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgS8d-0005gd-4T for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 12:15:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DHFZXB021860 for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 12:15:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgS8d-0005gV-0L for rps-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 12:15:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26524 for ; Tue, 13 Jan 2004 12:15:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgS8b-0005zp-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 12:15:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgS6D-0005ey-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 12:13:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AgS2S-0005DX-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 12:09:12 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AgS2R-0004HP-R2 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 12:09:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgS2G-0005VX-Qo; Tue, 13 Jan 2004 12:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgS1b-0005Uk-9K for rps@optimus.ietf.org; Tue, 13 Jan 2004 12:08:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25758 for ; Tue, 13 Jan 2004 12:08:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgS1Z-00058q-00 for rps@ietf.org; Tue, 13 Jan 2004 12:08:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRzs-00056y-00 for rps@ietf.org; Tue, 13 Jan 2004 12:06:33 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AgRyX-00053n-00 for rps@ietf.org; Tue, 13 Jan 2004 12:05:09 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i0DH3CRX053524; Tue, 13 Jan 2004 12:03:12 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200401131703.i0DH3CRX053524@workhorse.fictitious.org> To: "Larry J. Blunk" cc: Pekka Savola , rps@ietf.org, rpslng@ripe.net Reply-To: curtis@fictitious.org Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-reply-to: Your message of "13 Jan 2004 11:22:09 EST." <1074010929.3795.45.camel@ablate.merit.edu> From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 12:03:12 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <1074010929.3795.45.camel@ablate.merit.edu>, "Larry J. Blunk" writes : > On Fri, 2004-01-02 at 03:24, Pekka Savola wrote: > > Hi, > > > > (I tailed down the Cc: list..) > > > > On Sat, 27 Dec 2003, Randy Bush wrote: > > > > OK, I now found that the doc did have an IETF Last Call > > > > in late August/Early Sept. > > > > > > and there were technical objections which have not been addressed > > > > Thanks, Randy, for reminding about that. > > > > Based on some off-list discussion, the technical objections being > > referred to are the comments from Mark Prior on the list, one of them > > copied below. > > > > I'll try to summarize the loooo-ong thread somehow. Mark believes > > that the current RPSLng proposition unnecessarily adds complexity to > > the operators' use of the language, as e.g. IPv4 and IPv6 addresses, > > peerings, etc. could all be facilitated by redefining the current > > attributes etc. -- and whichever would be returned could be evaluated > > based on the context. As the number of operators using the language > > is extremely high (and we'd like it to be higher :-) compared to the > > registry/tool implementations, Mark argues that optimizing for the > > simplicity to the operators is the most important goal. > > > > Curtis objects to this mainly based on the fact that this would break > > the backward compatibility for the clients which do not expect to > > receive IPv6 data back from their queries. This could be easily fixed > > e.g. in tools like IRRToolSet, but that there are a probably a number > > of hacks built on top of perl, telnetting to port 43, or whatever, > > which might not be equally fortunate. > > > > Workarounds to this seem to be adding some kind of version negotiation > > or inclusion to the whois protocol (in the future, maybe using CRISP), > > so that only the clients who signal "yes, I can process IPv6 records!" > > would activate the IPv6 context processing. This could also be passed > > to the whois server with an option, like '--use-rpslng' or '-6'. Or > > maybe the client would state which records it wants to get, e.g. > > '-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or > > something, for "NEW", otherwise only v4 would be returned :) for > > both). At least RIPE database allows the use of '-Vxxx' verstion > > string to tell about the version of the client software. > > > > The exact details of how this method would work out would need to be > > fleshed out. Any takers? > > I don't believe this would be particularly productive. These > are implementation details which are really outside the scope of > the RPSLng work. I don't see the objections to RPSLng as objective > technical issues, but rather subjective preferences. I'll agree with that. So if any comments I made having to do with transition and backwards compatibility are holding this up, comments which I beleive I made as suggestions, then please consider those to be resolved issues. > > Personally, when I was trying to form an opinion on this subject, I > > found myself thinking that Mark's proposal addresses only IPv4/IPv6 > > case. It doesn't seem to address how one could specify different > > unicast/multicast policies, or how to specify different v4/v6 > > policies. This is also one goal of RPSLng.. even though the major > > operators who do have multicast or v6 often want their policies to be > > the same. > > > > How would this work out if a "more intelligence" model was adopted? > > > > (I'm personally a bit unsure whether a "more intelligence in the > > tools" -model would or would not make sense at this point, but I think > > I can see both sides of the argument..) > > It is very difficult to judge the impact of such a model without > having a complete census of the various tools in use by ISP's. For > example, C&W has an extensive set of in-house developed tools which > interact with IRR's. Is it fair to ask them to hack up their tools > to fit this model? > > > > > Could we get some form of discussion and maybe consensus on what would > > seem to be the right way forward? :-) > > I think we have already reached the point of "rough" consensus. > Again, I view the expressed objections as subjective preferences rather > than solid technical beefs with the specification. > > Regards, > Larry I agree here too. Perhaps Mark can tell us whether he has any specific suggestions for changing the language from what is currently proposed. Curtis > > =========== > > Date: Tue, 23 Sep 2003 09:00:06 +0930 > > From: Mark Prior > > To: curtis@fictitious.org > > Cc: Pekka Savola , iesg@ietf.org, rpslng@ripe.net, > > rps@ietf.org > > Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard > > > > Curtis Villamizar wrote: > > > > > How is RPSLng not a superset of RPSL? Nothing has been removed from > > > RPSL. > > > > Superset is probably not the best word to describe what I want. > > > > > The issue is just how do you make transition easiest, supporting older > > > RPSL only clients. If you just extend import rather than rename it > > > mp-import and extend it, then old RPSL only clients will consider you > > > autnum broken. If you include mp-import but forget to reflect you > > > IPv4 policy in plain import then the old RPSL client will pick up a > > > subset of you policy. > > > > > > In either case, extending import, or adding mp-import and putting the > > > extensions there, it would make for a smoother transition if the > > > server code could recognize old clients and feed them with objects > > > translated into plain RPSL. > > > > I think I have been consistent in wanting the smarts to be in the > > software and not the language. I would prefer to overload the syntax > > then create new syntax and let the software work out what is required. > > We don't use different syntax in computer languages when we want to > > operate on integers rather than reals so why make the distinction in > > RPSL? If we have a route object that has a IPv6 address in it surely the > > software can work out if it wants it or not given it's current context? > > > > I know you (and others :-) keep on about the old clients but we have > > left them behind once before in the transition from RIPE 181 to RPSL so > > do it again but this time lets leave some mechanism behind so that when > > we need (RPSLng)ng we don't go through this pain yet again. Saying it's > > not part of the language is a pathetic excuse in my book for not fixing > > it. If we need a "shim" document to describe the interaction between a > > server and a client then lets do it. It would make the client software > > writers life a lot easier if there weren't (at least) 3 server > > interaction languages to deal with. > > > > Mark. > > ========== > > > _______________________________________________ > Rps mailing list > Rps@ietf.org > https://www1.ietf.org/mailman/listinfo/rps _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Jan 13 12:21:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26966 for ; Tue, 13 Jan 2004 12:21:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSDu-0005v3-W3; Tue, 13 Jan 2004 12:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSDV-0005tc-Em for rps@optimus.ietf.org; Tue, 13 Jan 2004 12:20:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26921 for ; Tue, 13 Jan 2004 12:20:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgSDU-0006NR-00 for rps@ietf.org; Tue, 13 Jan 2004 12:20:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgSBq-0006It-00 for rps@ietf.org; Tue, 13 Jan 2004 12:18:54 -0500 Received: from ip166.usw253.dsl-acs2.sea.iinet.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 1AgSAN-0006C4-00 for rps@ietf.org; Tue, 13 Jan 2004 12:17:24 -0500 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgSAN-0003cT-GG; Tue, 13 Jan 2004 09:17:23 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Larry J. Blunk" Cc: rps@ietf.org, rpslng@ripe.net Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] References: <1074010929.3795.45.camel@ablate.merit.edu> <1074013404.3795.52.camel@ablate.merit.edu> Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 09:17:23 -0800 Content-Transfer-Encoding: 7bit >> then let me register my support for the issues and approaches >> marc raises. perhaps the system is for the benefit of operations >> more than the ease of registries? > There are a number of operators that run their own registries (e.g. > Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal > about preserving the syntax of existing RPSL attributes. thanks for representing operations. but i are one. and i have a (small) registry. i want the operational fix, thanks. randy _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Jan 13 12:25:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27105 for ; Tue, 13 Jan 2004 12:25:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSHL-000610-W6 for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 12:24:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DHOZMc023116 for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 12:24:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSHL-00060i-Pv for rps-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 12:24:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27058 for ; Tue, 13 Jan 2004 12:24:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgSHK-0006a3-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 12:24:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgSFQ-0006UC-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 12:22:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgSDx-0006Pj-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 12:21:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSDu-0005v3-W3; Tue, 13 Jan 2004 12:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSDV-0005tc-Em for rps@optimus.ietf.org; Tue, 13 Jan 2004 12:20:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26921 for ; Tue, 13 Jan 2004 12:20:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgSDU-0006NR-00 for rps@ietf.org; Tue, 13 Jan 2004 12:20:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgSBq-0006It-00 for rps@ietf.org; Tue, 13 Jan 2004 12:18:54 -0500 Received: from ip166.usw253.dsl-acs2.sea.iinet.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 1AgSAN-0006C4-00 for rps@ietf.org; Tue, 13 Jan 2004 12:17:24 -0500 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgSAN-0003cT-GG; Tue, 13 Jan 2004 09:17:23 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Larry J. Blunk" Cc: rps@ietf.org, rpslng@ripe.net Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] References: <1074010929.3795.45.camel@ablate.merit.edu> <1074013404.3795.52.camel@ablate.merit.edu> Message-Id: Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 09:17:23 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> then let me register my support for the issues and approaches >> marc raises. perhaps the system is for the benefit of operations >> more than the ease of registries? > There are a number of operators that run their own registries (e.g. > Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal > about preserving the syntax of existing RPSL attributes. thanks for representing operations. but i are one. and i have a (small) registry. i want the operational fix, thanks. randy _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Jan 13 13:21:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01426 for ; Tue, 13 Jan 2004 13:21:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgT9y-0002EF-Ch; Tue, 13 Jan 2004 13:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgT9P-00026Y-Cq for rps@optimus.ietf.org; Tue, 13 Jan 2004 13:20:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01397 for ; Tue, 13 Jan 2004 13:20:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgT9N-00030F-00 for rps@ietf.org; Tue, 13 Jan 2004 13:20:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgT7p-0002wz-00 for rps@ietf.org; Tue, 13 Jan 2004 13:18:50 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AgT6g-0002rS-00 for rps@ietf.org; Tue, 13 Jan 2004 13:17:38 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i0DIFkRX053871; Tue, 13 Jan 2004 13:15:46 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200401131815.i0DIFkRX053871@workhorse.fictitious.org> To: Randy Bush cc: "Larry J. Blunk" , rps@ietf.org, rpslng@ripe.net Reply-To: curtis@fictitious.org Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-reply-to: Your message of "Tue, 13 Jan 2004 09:17:23 PST." From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 13:15:46 -0500 In message , Randy Bush writes: > >> then let me register my support for the issues and approaches > >> marc raises. perhaps the system is for the benefit of operations > >> more than the ease of registries? > > There are a number of operators that run their own registries (e.g. > > Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal > > about preserving the syntax of existing RPSL attributes. > > thanks for representing operations. but i are one. and i have a > (small) registry. i want the operational fix, thanks. > > randy Randy, Exactly what fix is it that you want? Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Jan 13 13:25:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01601 for ; Tue, 13 Jan 2004 13:25:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgTDQ-0002QB-Do for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 13:24:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DIOasR009301 for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 13:24:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgTDQ-0002Pw-8s for rps-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 13:24:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01579 for ; Tue, 13 Jan 2004 13:24:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgTDO-0003DM-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 13:24:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgTBi-00038Y-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 13:22:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgTA7-00033E-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 13:21:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgT9y-0002EF-Ch; Tue, 13 Jan 2004 13:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgT9P-00026Y-Cq for rps@optimus.ietf.org; Tue, 13 Jan 2004 13:20:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01397 for ; Tue, 13 Jan 2004 13:20:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgT9N-00030F-00 for rps@ietf.org; Tue, 13 Jan 2004 13:20:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgT7p-0002wz-00 for rps@ietf.org; Tue, 13 Jan 2004 13:18:50 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AgT6g-0002rS-00 for rps@ietf.org; Tue, 13 Jan 2004 13:17:38 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i0DIFkRX053871; Tue, 13 Jan 2004 13:15:46 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200401131815.i0DIFkRX053871@workhorse.fictitious.org> To: Randy Bush cc: "Larry J. Blunk" , rps@ietf.org, rpslng@ripe.net Reply-To: curtis@fictitious.org Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-reply-to: Your message of "Tue, 13 Jan 2004 09:17:23 PST." From: Curtis Villamizar Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 13:15:46 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message , Randy Bush writes: > >> then let me register my support for the issues and approaches > >> marc raises. perhaps the system is for the benefit of operations > >> more than the ease of registries? > > There are a number of operators that run their own registries (e.g. > > Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal > > about preserving the syntax of existing RPSL attributes. > > thanks for representing operations. but i are one. and i have a > (small) registry. i want the operational fix, thanks. > > randy Randy, Exactly what fix is it that you want? Curtis _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Jan 13 15:31:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11285 for ; Tue, 13 Jan 2004 15:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVBm-0001DE-0K; Tue, 13 Jan 2004 15:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVBA-0001C7-8u for rps@optimus.ietf.org; Tue, 13 Jan 2004 15:30:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11213 for ; Tue, 13 Jan 2004 15:30:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgVB8-0003p6-00 for rps@ietf.org; Tue, 13 Jan 2004 15:30:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgV9H-0003kn-00 for rps@ietf.org; Tue, 13 Jan 2004 15:28:27 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AgV7Y-0003cz-00 for rps@ietf.org; Tue, 13 Jan 2004 15:26:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0DKQ1719768; Tue, 13 Jan 2004 12:26:01 -0800 X-mProtect: <200401132026> Nokia Silicon Valley Messaging Protection Received: from pobox.iprg.nokia.com (205.226.5.79) by darkstar.iprg.nokia.com smtpd1ZSjUP; Tue, 13 Jan 2004 12:25:59 PST Received: (from david@localhost) by pobox.iprg.nokia.com (8.8.8/8.6.10) id MAA02264; Tue, 13 Jan 2004 12:25:49 -0800 (PST) Message-ID: <20040113122549.C2159@iprg.nokia.com> From: David Kessens To: Randy Bush , "Larry J. Blunk" Cc: rps@ietf.org, rpslng@ripe.net Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] References: <1074010929.3795.45.camel@ablate.merit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Randy Bush on Tue, Jan 13, 2004 at 08:29:23AM -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 12:25:49 -0800 On Tue, Jan 13, 2004 at 08:29:23AM -0800, Randy Bush wrote: > then let me register my support for the issues and approaches > marc raises. perhaps the system is for the benefit of operations > more than the ease of registries? I have always agreed with Marc's comments/views on this. However, it was also my impression that we were a vocal but small minority. I rather see progress towards a pusblished standard, although it doesn't do everything exactly the way I want it, than that we reopen all the discussions again unless a lot of people changed their minds. David Kessens --- _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Jan 13 15:34:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11573 for ; Tue, 13 Jan 2004 15:34:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVF3-0001Zt-SG for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 15:34:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DKYPRs006065 for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 15:34:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVF3-0001Zk-PN for rps-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 15:34:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11539 for ; Tue, 13 Jan 2004 15:34:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgVF2-0003z8-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 15:34:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgVDM-0003w3-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 15:32:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgVBp-0003sS-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 15:31:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVBm-0001DE-0K; Tue, 13 Jan 2004 15:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVBA-0001C7-8u for rps@optimus.ietf.org; Tue, 13 Jan 2004 15:30:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11213 for ; Tue, 13 Jan 2004 15:30:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgVB8-0003p6-00 for rps@ietf.org; Tue, 13 Jan 2004 15:30:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgV9H-0003kn-00 for rps@ietf.org; Tue, 13 Jan 2004 15:28:27 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AgV7Y-0003cz-00 for rps@ietf.org; Tue, 13 Jan 2004 15:26:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0DKQ1719768; Tue, 13 Jan 2004 12:26:01 -0800 X-mProtect: <200401132026> Nokia Silicon Valley Messaging Protection Received: from pobox.iprg.nokia.com (205.226.5.79) by darkstar.iprg.nokia.com smtpd1ZSjUP; Tue, 13 Jan 2004 12:25:59 PST Received: (from david@localhost) by pobox.iprg.nokia.com (8.8.8/8.6.10) id MAA02264; Tue, 13 Jan 2004 12:25:49 -0800 (PST) Message-ID: <20040113122549.C2159@iprg.nokia.com> From: David Kessens To: Randy Bush , "Larry J. Blunk" Cc: rps@ietf.org, rpslng@ripe.net Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] References: <1074010929.3795.45.camel@ablate.merit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Randy Bush on Tue, Jan 13, 2004 at 08:29:23AM -0800 Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 12:25:49 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, Jan 13, 2004 at 08:29:23AM -0800, Randy Bush wrote: > then let me register my support for the issues and approaches > marc raises. perhaps the system is for the benefit of operations > more than the ease of registries? I have always agreed with Marc's comments/views on this. However, it was also my impression that we were a vocal but small minority. I rather see progress towards a pusblished standard, although it doesn't do everything exactly the way I want it, than that we reopen all the discussions again unless a lot of people changed their minds. David Kessens --- _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Tue Jan 13 16:47:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16909 for ; Tue, 13 Jan 2004 16:47:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgWNJ-0005Va-HI; Tue, 13 Jan 2004 16:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgWMd-0005Uw-Pv for rps@optimus.ietf.org; Tue, 13 Jan 2004 16:46:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16872 for ; Tue, 13 Jan 2004 16:46:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgWMb-000169-00 for rps@ietf.org; Tue, 13 Jan 2004 16:46:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgWKf-00013A-00 for rps@ietf.org; Tue, 13 Jan 2004 16:44:18 -0500 Received: from emr1.eu.uu.net ([195.129.12.212]) by ietf-mx with esmtp (Exim 4.12) id 1AgWIo-0000yD-00 for rps@ietf.org; Tue, 13 Jan 2004 16:42:22 -0500 Received: from imr1.eu.uu.net ([213.68.123.49]) by emr1.eu.uu.net with esmtp id 1AgWII-00061s-JI; Tue, 13 Jan 2004 21:41:50 +0000 Received: from localhost ([127.0.0.1]) by imr1.eu.uu.net with esmtp id 1AgWII-0005u1-Aq; Tue, 13 Jan 2004 21:41:50 +0000 Received: from agen1.ams.ops.eu.uu.net ([146.188.97.8] helo=amr.eu.uu.net) by imr1.eu.uu.net with esmtp id 1AgWIH-0005ty-V0; Tue, 13 Jan 2004 21:41:49 +0000 Received: from PEBBLES (dhcp1.k86.de [213.70.178.82]) by amr.eu.uu.net (8.12.10/8.12.10) with ESMTP id i0DLflsm007514; Tue, 13 Jan 2004 21:41:48 GMT SSL encryption with TLSv1/SSLv3 cipher=RC4-MD5 bits=128 SMTP AUTH used user=fbohnsac AuthMechanisms=LOGIN (envelope-from Frank.Bohnsack@deu.mci.com) Reply-To: From: "Frank Bohnsack" To: "Larry J. Blunk" , "Randy Bush" Cc: , Subject: RE: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <1074013404.3795.52.camel@ablate.merit.edu> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 22:41:47 +0100 > On Tue, 2004-01-13 at 11:29, Randy Bush wrote: > > then let me register my support for the issues and approaches > > marc raises. perhaps the system is for the benefit of operations > > more than the ease of registries? > > > > randy > > > > There are a number of operators that run their own registries (e.g. > Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal > about preserving the syntax of existing RPSL attributes. > > -Larry We doesn't have a own registry, but a lot of own tools which deals with RPSL. From my point of view I have to change both, my RPSL language parser and the interpreter. So I could not see a benefit of one solution. Personally, I would back Marks position but can not really give you a reason. How about a acclamation at the next RIPE meeting ? Frank _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Tue Jan 13 16:51:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17019 for ; Tue, 13 Jan 2004 16:51:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgWQi-0005aO-2d for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 16:50:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DLoWFZ021468 for rps-archive@odin.ietf.org; Tue, 13 Jan 2004 16:50:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgWQh-0005aB-Vv for rps-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 16:50:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17002 for ; Tue, 13 Jan 2004 16:50:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgWQf-0001Dx-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 16:50:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgWOl-0001B4-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 16:48:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgWNL-00018U-00 for rps-web-archive@ietf.org; Tue, 13 Jan 2004 16:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgWNJ-0005Va-HI; Tue, 13 Jan 2004 16:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgWMd-0005Uw-Pv for rps@optimus.ietf.org; Tue, 13 Jan 2004 16:46:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16872 for ; Tue, 13 Jan 2004 16:46:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgWMb-000169-00 for rps@ietf.org; Tue, 13 Jan 2004 16:46:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgWKf-00013A-00 for rps@ietf.org; Tue, 13 Jan 2004 16:44:18 -0500 Received: from emr1.eu.uu.net ([195.129.12.212]) by ietf-mx with esmtp (Exim 4.12) id 1AgWIo-0000yD-00 for rps@ietf.org; Tue, 13 Jan 2004 16:42:22 -0500 Received: from imr1.eu.uu.net ([213.68.123.49]) by emr1.eu.uu.net with esmtp id 1AgWII-00061s-JI; Tue, 13 Jan 2004 21:41:50 +0000 Received: from localhost ([127.0.0.1]) by imr1.eu.uu.net with esmtp id 1AgWII-0005u1-Aq; Tue, 13 Jan 2004 21:41:50 +0000 Received: from agen1.ams.ops.eu.uu.net ([146.188.97.8] helo=amr.eu.uu.net) by imr1.eu.uu.net with esmtp id 1AgWIH-0005ty-V0; Tue, 13 Jan 2004 21:41:49 +0000 Received: from PEBBLES (dhcp1.k86.de [213.70.178.82]) by amr.eu.uu.net (8.12.10/8.12.10) with ESMTP id i0DLflsm007514; Tue, 13 Jan 2004 21:41:48 GMT SSL encryption with TLSv1/SSLv3 cipher=RC4-MD5 bits=128 SMTP AUTH used user=fbohnsac AuthMechanisms=LOGIN (envelope-from Frank.Bohnsack@deu.mci.com) Reply-To: From: "Frank Bohnsack" To: "Larry J. Blunk" , "Randy Bush" Cc: , Subject: RE: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <1074013404.3795.52.camel@ablate.merit.edu> Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 22:41:47 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > On Tue, 2004-01-13 at 11:29, Randy Bush wrote: > > then let me register my support for the issues and approaches > > marc raises. perhaps the system is for the benefit of operations > > more than the ease of registries? > > > > randy > > > > There are a number of operators that run their own registries (e.g. > Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal > about preserving the syntax of existing RPSL attributes. > > -Larry We doesn't have a own registry, but a lot of own tools which deals with RPSL. From my point of view I have to change both, my RPSL language parser and the interpreter. So I could not see a benefit of one solution. Personally, I would back Marks position but can not really give you a reason. How about a acclamation at the next RIPE meeting ? Frank _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Wed Jan 14 01:29:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04464 for ; Wed, 14 Jan 2004 01:29:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgeWS-0001e1-Bp; Wed, 14 Jan 2004 01:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgeWJ-0001dQ-Kp for rps@optimus.ietf.org; Wed, 14 Jan 2004 01:28:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04455 for ; Wed, 14 Jan 2004 01:28:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgeWB-0004Qk-00 for rps@ietf.org; Wed, 14 Jan 2004 01:28:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgeT5-0004JY-00 for rps@ietf.org; Wed, 14 Jan 2004 01:25:32 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgeNq-0004Bs-00 for rps@ietf.org; Wed, 14 Jan 2004 01:20:06 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0E6IlA27311; Wed, 14 Jan 2004 08:18:47 +0200 From: Pekka Savola To: David Kessens cc: Randy Bush , "Larry J. Blunk" , , Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: <20040113122549.C2159@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Jan 2004 08:18:47 +0200 (EET) Hi, On Tue, 13 Jan 2004, David Kessens wrote: > On Tue, Jan 13, 2004 at 08:29:23AM -0800, Randy Bush wrote: > > then let me register my support for the issues and approaches > > marc raises. perhaps the system is for the benefit of operations > > more than the ease of registries? > > I have always agreed with Marc's comments/views on this. However, it > was also my impression that we were a vocal but small minority. > > I rather see progress towards a pusblished standard, although it > doesn't do everything exactly the way I want it, than that we reopen all > the discussions again unless a lot of people changed their minds. For what it's worth, I, as an operator, have roughly the same opinion. I'd like to see a standardized solution soon (I accept the current draft proposal if that's the rough consensus), but on the other hand, I'd like it to be as simple as possible to use. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Wed Jan 14 01:39:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04649 for ; Wed, 14 Jan 2004 01:39:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agefo-0002Ik-CE for rps-archive@odin.ietf.org; Wed, 14 Jan 2004 01:38:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E6ceMG008840 for rps-archive@odin.ietf.org; Wed, 14 Jan 2004 01:38:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agefo-0002IV-91 for rps-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 01:38:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04636 for ; Wed, 14 Jan 2004 01:38:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agefb-0004le-00 for rps-web-archive@ietf.org; Wed, 14 Jan 2004 01:38:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agecv-0004da-00 for rps-web-archive@ietf.org; Wed, 14 Jan 2004 01:35:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgeWl-0004Uc-00 for rps-web-archive@ietf.org; Wed, 14 Jan 2004 01:29:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgeWS-0001e1-Bp; Wed, 14 Jan 2004 01:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgeWJ-0001dQ-Kp for rps@optimus.ietf.org; Wed, 14 Jan 2004 01:28:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04455 for ; Wed, 14 Jan 2004 01:28:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgeWB-0004Qk-00 for rps@ietf.org; Wed, 14 Jan 2004 01:28:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgeT5-0004JY-00 for rps@ietf.org; Wed, 14 Jan 2004 01:25:32 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgeNq-0004Bs-00 for rps@ietf.org; Wed, 14 Jan 2004 01:20:06 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0E6IlA27311; Wed, 14 Jan 2004 08:18:47 +0200 From: Pekka Savola To: David Kessens cc: Randy Bush , "Larry J. Blunk" , , Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: <20040113122549.C2159@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Jan 2004 08:18:47 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, On Tue, 13 Jan 2004, David Kessens wrote: > On Tue, Jan 13, 2004 at 08:29:23AM -0800, Randy Bush wrote: > > then let me register my support for the issues and approaches > > marc raises. perhaps the system is for the benefit of operations > > more than the ease of registries? > > I have always agreed with Marc's comments/views on this. However, it > was also my impression that we were a vocal but small minority. > > I rather see progress towards a pusblished standard, although it > doesn't do everything exactly the way I want it, than that we reopen all > the discussions again unless a lot of people changed their minds. For what it's worth, I, as an operator, have roughly the same opinion. I'd like to see a standardized solution soon (I accept the current draft proposal if that's the rough consensus), but on the other hand, I'd like it to be as simple as possible to use. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Wed Jan 14 11:10:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25324 for ; Wed, 14 Jan 2004 11:10:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agnal-0008G6-56; Wed, 14 Jan 2004 11:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agnaf-0008FH-7r for rps@optimus.ietf.org; Wed, 14 Jan 2004 11:09:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25314 for ; Wed, 14 Jan 2004 11:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agnac-00027K-00 for rps@ietf.org; Wed, 14 Jan 2004 11:09:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgnZi-00024w-00 for rps@ietf.org; Wed, 14 Jan 2004 11:08:59 -0500 Received: from central.switch.ch ([130.59.11.11]) by ietf-mx with esmtp (Exim 4.12) id 1AgnYu-0001zU-00 for rps@ietf.org; Wed, 14 Jan 2004 11:08:08 -0500 Received: from diotima.switch.ch ([130.59.4.87]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1AgnYF-0004Y0-00; Wed, 14 Jan 2004 17:07:27 +0100 Received: (from leinen@localhost) by diotima.switch.ch (8.11.6+Sun/8.11.6) id i0EG7qb29841; Wed, 14 Jan 2004 17:07:52 +0100 (MET) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Pekka Savola Cc: David Kessens , Randy Bush , "Larry J. Blunk" , , X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: (Pekka Savola's message of "Wed, 14 Jan 2004 08:18:47 +0200 (EET)") References: Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Rps] Re: Separate attributes vs context-aware software [RE: RPS WG...] Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Jan 2004 17:07:52 +0100 Pekka Savola writes: >> I rather see progress towards a pusblished standard, although it >> doesn't do everything exactly the way I want it, than that we >> reopen all the discussions again unless a lot of people changed >> their minds. > For what it's worth, I, as an operator, have roughly the same > opinion. Me too. > I'd like to see a standardized solution soon (I accept the current > draft proposal if that's the rough consensus), but on the other > hand, I'd like it to be as simple as possible to use. Exactly. The mp-import/mp-export stuff personally doesn't bother me at all, but I heard a fellow operator complain about the expected size increase of their AS object. What about the following compromise: *) Leave both export/import and mp-export/mp-import in RPSLng (same for default/mp-default) *) Add a "mp-default-afs" attribute that defines what "import/export" means. It would default to ipv4.unicast only. That way, no existing tools break - import/export will still be used for IPv4 unicast policy like today. ISPs can add mp-{im,ex}port to document IPv6 and multicast policies. As long as "The majority of providers support IPv4 unicast only" (as Curtis pointed out, and which is still the case for our set of peers, even though we ARE an "academic" network), people just add mp- attributes for the minority of peerings that need it. Over time, Pekka's vision of congruent unicast/multicast (and/or IPv4/IPv6 unicast, but that doesn't matter) topologies may come true. At that point, people can start modifying their "mp-default-afs", and collapse many mp-{im,ex}port attributes into {im,ex}port attributes. If their peers still use non-RPSLng-compliant tools, then they will misinterpret {im,ex}port as IPv4 unicast-only, but that is probably not very relevant - IPv4 unicast is all those peers' tools can handle. In some cases it will be necessary to specifically exclude default address families, but maybe that could be done with AF-specific NOT ANY policies or something. Makes sense? -- Simon. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Wed Jan 14 11:12:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25413 for ; Wed, 14 Jan 2004 11:12:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agncb-0008MZ-02 for rps-archive@odin.ietf.org; Wed, 14 Jan 2004 11:11:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EGBuZA032141 for rps-archive@odin.ietf.org; Wed, 14 Jan 2004 11:11:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agnca-0008MK-Sy for rps-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 11:11:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25398 for ; Wed, 14 Jan 2004 11:11:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgncY-0002CC-00 for rps-web-archive@ietf.org; Wed, 14 Jan 2004 11:11:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgnbZ-00029n-00 for rps-web-archive@ietf.org; Wed, 14 Jan 2004 11:10:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Agnal-00027w-00 for rps-web-archive@ietf.org; Wed, 14 Jan 2004 11:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agnal-0008G6-56; Wed, 14 Jan 2004 11:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agnaf-0008FH-7r for rps@optimus.ietf.org; Wed, 14 Jan 2004 11:09:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25314 for ; Wed, 14 Jan 2004 11:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agnac-00027K-00 for rps@ietf.org; Wed, 14 Jan 2004 11:09:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgnZi-00024w-00 for rps@ietf.org; Wed, 14 Jan 2004 11:08:59 -0500 Received: from central.switch.ch ([130.59.11.11]) by ietf-mx with esmtp (Exim 4.12) id 1AgnYu-0001zU-00 for rps@ietf.org; Wed, 14 Jan 2004 11:08:08 -0500 Received: from diotima.switch.ch ([130.59.4.87]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1AgnYF-0004Y0-00; Wed, 14 Jan 2004 17:07:27 +0100 Received: (from leinen@localhost) by diotima.switch.ch (8.11.6+Sun/8.11.6) id i0EG7qb29841; Wed, 14 Jan 2004 17:07:52 +0100 (MET) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Pekka Savola Cc: David Kessens , Randy Bush , "Larry J. Blunk" , , X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: (Pekka Savola's message of "Wed, 14 Jan 2004 08:18:47 +0200 (EET)") References: Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Rps] Re: Separate attributes vs context-aware software [RE: RPS WG...] Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Jan 2004 17:07:52 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Pekka Savola writes: >> I rather see progress towards a pusblished standard, although it >> doesn't do everything exactly the way I want it, than that we >> reopen all the discussions again unless a lot of people changed >> their minds. > For what it's worth, I, as an operator, have roughly the same > opinion. Me too. > I'd like to see a standardized solution soon (I accept the current > draft proposal if that's the rough consensus), but on the other > hand, I'd like it to be as simple as possible to use. Exactly. The mp-import/mp-export stuff personally doesn't bother me at all, but I heard a fellow operator complain about the expected size increase of their AS object. What about the following compromise: *) Leave both export/import and mp-export/mp-import in RPSLng (same for default/mp-default) *) Add a "mp-default-afs" attribute that defines what "import/export" means. It would default to ipv4.unicast only. That way, no existing tools break - import/export will still be used for IPv4 unicast policy like today. ISPs can add mp-{im,ex}port to document IPv6 and multicast policies. As long as "The majority of providers support IPv4 unicast only" (as Curtis pointed out, and which is still the case for our set of peers, even though we ARE an "academic" network), people just add mp- attributes for the minority of peerings that need it. Over time, Pekka's vision of congruent unicast/multicast (and/or IPv4/IPv6 unicast, but that doesn't matter) topologies may come true. At that point, people can start modifying their "mp-default-afs", and collapse many mp-{im,ex}port attributes into {im,ex}port attributes. If their peers still use non-RPSLng-compliant tools, then they will misinterpret {im,ex}port as IPv4 unicast-only, but that is probably not very relevant - IPv4 unicast is all those peers' tools can handle. In some cases it will be necessary to specifically exclude default address families, but maybe that could be done with AF-specific NOT ANY policies or something. Makes sense? -- Simon. _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Sat Jan 17 18:01:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17568 for ; Sat, 17 Jan 2004 18:01:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhzRB-0005Kk-RR; Sat, 17 Jan 2004 18:01:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhzQZ-0004zG-Lx for rps@optimus.ietf.org; Sat, 17 Jan 2004 18:00:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16421 for ; Sat, 17 Jan 2004 18:00:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhwwM-0005QV-00 for rps@ietf.org; Sat, 17 Jan 2004 15:21:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhwtN-0005Cz-00 for rps@ietf.org; Sat, 17 Jan 2004 15:18:02 -0500 Received: from ommanipadmehum.force9.co.uk ([81.174.144.182] helo=dev0) by ietf-mx with esmtp (Exim 4.12) id 1Ahwqp-0004Zu-00 for rps@ietf.org; Sat, 17 Jan 2004 15:15:23 -0500 Received: from mail pickup service by dev0 with Microsoft SMTPSVC; Sat, 17 Jan 2004 19:54:56 +0000 Reply-To: "La Site" From: "La Site" To: "Rps" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_631C_01C3DD33.C2C50BF0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 17 Jan 2004 19:54:56.0179 (UTC) FILETIME=[C7CEB830:01C3DD33] X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.1 required=5.0 tests=AWL,CLICK_BELOW, FREE_MEMBERSHIP,HTML_50_60,HTML_LINK_CLICK_HERE,HTML_MESSAGE, PRIORITY_NO_NAME,TO_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 2.4 TO_HAS_SPACES To: address contains spaces * 2.6 FREE_MEMBERSHIP BODY: Free Membership * 0.1 HTML_LINK_CLICK_HERE BODY: HTML link text says "click here" * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.0 CLICK_BELOW Asks you to click below * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * -0.0 AWL AWL: Auto-whitelist adjustment Subject: [Rps] Nurture strength of spirit to shield you in sudden misfortune. Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 17 Jan 2004 19:54:47 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_631C_01C3DD33.C2C50BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable La Site Communiqu=E9 Saturday 17 January 2004 19::54 Rps, Hello, Bienvenue, Bienvenidos and G'Day. We hope this Communication finds you in good health and with great spirit. We wish to offer you a free Membership for La Site - the World's fasted growing Dating Service (Click Here) . At La Site relationships unfold in a pleasant, easy and civilised environment. We are a community. Registration with the La Site Dating Service unlocks the website and is free. Once Registered we will give you a free Platinum Membership for five days so you may fully test drive the site. You will then be welcome as a Gold member, or to upgrade at a time of your choosing. This is a no-strings, zero-pressure offer to you so you are able to make an informed choice about joining. Click Here to begin your test drive now.=20 La Site is a private place, no advertisments, no pop-ups. A Community built upon respect, tolerance and good nature. The La Site Support Team are committed to respecting individual members by providing an unsurpassed quality of dedicated, secure service for everyone.=20 Thank-you for choosing La Site. We are at your service in your search for a suitable partner. Best Wishes, La Site Support Team. Mail Delivery Options =20 ------=_NextPart_000_631C_01C3DD33.C2C50BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

La Site = Communiqu=E9
Saturday 17 January = 2004  19::54

Rps,

Hello, Bienvenue, Bienvenidos and G'Day. We hope = this Communication finds you in good health and with great spirit.

We = wish to offer you a free = Membership for La Site - the World's fasted growing Dating = Service (Click = Here). At La = Site relationships unfold in a pleasant, easy and civilised = environment. We are a community. Registration= with the La Site Dating Service unlocks the website and is = free.

Once Registered we will give you a free Platinum = Membership for five days so you may fully test drive the site. You = will then be welcome as a Gold member, or to upgrade at a time of your = choosing.

This is a no-strings, zero-pressure offer to you so you are = able to make an informed choice about joining. Click = Here to begin your test drive now.

La Site is a = private place, no advertisments, no pop-ups. A Community built upon = respect, tolerance and good nature. The La Site Support Team are = committed to respecting individual members by providing an unsurpassed = quality of dedicated, secure service for everyone.

Thank-you for = choosing La Site.
We are at your service in your search for a = suitable partner.

Best Wishes,
La Site Support = Team.

Mail Delivery = Options

------=_NextPart_000_631C_01C3DD33.C2C50BF0-- _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Sat Jan 17 18:24:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20224 for ; Sat, 17 Jan 2004 18:24:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahznb-00056k-Jm for rps-archive@odin.ietf.org; Sat, 17 Jan 2004 18:24:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0HNOFrq019630 for rps-archive@odin.ietf.org; Sat, 17 Jan 2004 18:24:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahznb-00056X-GW for rps-web-archive@optimus.ietf.org; Sat, 17 Jan 2004 18:24:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20210 for ; Sat, 17 Jan 2004 18:24:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhznT-0002GY-00 for rps-web-archive@ietf.org; Sat, 17 Jan 2004 18:24:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AhzcV-0001VB-00 for rps-web-archive@ietf.org; Sat, 17 Jan 2004 18:12:48 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ahzc8-0006Or-RM for rps-web-archive@ietf.org; Sat, 17 Jan 2004 18:12:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhzRB-0005Kk-RR; Sat, 17 Jan 2004 18:01:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhzQZ-0004zG-Lx for rps@optimus.ietf.org; Sat, 17 Jan 2004 18:00:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16421 for ; Sat, 17 Jan 2004 18:00:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhwwM-0005QV-00 for rps@ietf.org; Sat, 17 Jan 2004 15:21:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhwtN-0005Cz-00 for rps@ietf.org; Sat, 17 Jan 2004 15:18:02 -0500 Received: from ommanipadmehum.force9.co.uk ([81.174.144.182] helo=dev0) by ietf-mx with esmtp (Exim 4.12) id 1Ahwqp-0004Zu-00 for rps@ietf.org; Sat, 17 Jan 2004 15:15:23 -0500 Received: from mail pickup service by dev0 with Microsoft SMTPSVC; Sat, 17 Jan 2004 19:54:56 +0000 Reply-To: "La Site" From: "La Site" To: "Rps" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_631C_01C3DD33.C2C50BF0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 17 Jan 2004 19:54:56.0179 (UTC) FILETIME=[C7CEB830:01C3DD33] X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.1 required=5.0 tests=AWL,CLICK_BELOW, FREE_MEMBERSHIP,HTML_50_60,HTML_LINK_CLICK_HERE,HTML_MESSAGE, PRIORITY_NO_NAME,TO_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 2.4 TO_HAS_SPACES To: address contains spaces * 2.6 FREE_MEMBERSHIP BODY: Free Membership * 0.1 HTML_LINK_CLICK_HERE BODY: HTML link text says "click here" * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.0 CLICK_BELOW Asks you to click below * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * -0.0 AWL AWL: Auto-whitelist adjustment Subject: [Rps] Nurture strength of spirit to shield you in sudden misfortune. Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 17 Jan 2004 19:54:47 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_631C_01C3DD33.C2C50BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable La Site Communiqu=E9 Saturday 17 January 2004 19::54 Rps, Hello, Bienvenue, Bienvenidos and G'Day. We hope this Communication finds you in good health and with great spirit. We wish to offer you a free Membership for La Site - the World's fasted growing Dating Service (Click Here) . At La Site relationships unfold in a pleasant, easy and civilised environment. We are a community. Registration with the La Site Dating Service unlocks the website and is free. Once Registered we will give you a free Platinum Membership for five days so you may fully test drive the site. You will then be welcome as a Gold member, or to upgrade at a time of your choosing. This is a no-strings, zero-pressure offer to you so you are able to make an informed choice about joining. Click Here to begin your test drive now.=20 La Site is a private place, no advertisments, no pop-ups. A Community built upon respect, tolerance and good nature. The La Site Support Team are committed to respecting individual members by providing an unsurpassed quality of dedicated, secure service for everyone.=20 Thank-you for choosing La Site. We are at your service in your search for a suitable partner. Best Wishes, La Site Support Team. Mail Delivery Options =20 ------=_NextPart_000_631C_01C3DD33.C2C50BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

La Site = Communiqu=E9
Saturday 17 January = 2004  19::54

Rps,

Hello, Bienvenue, Bienvenidos and G'Day. We hope = this Communication finds you in good health and with great spirit.

We = wish to offer you a free = Membership for La Site - the World's fasted growing Dating = Service (Click = Here). At La = Site relationships unfold in a pleasant, easy and civilised = environment. We are a community. Registration= with the La Site Dating Service unlocks the website and is = free.

Once Registered we will give you a free Platinum = Membership for five days so you may fully test drive the site. You = will then be welcome as a Gold member, or to upgrade at a time of your = choosing.

This is a no-strings, zero-pressure offer to you so you are = able to make an informed choice about joining. Click = Here to begin your test drive now.

La Site is a = private place, no advertisments, no pop-ups. A Community built upon = respect, tolerance and good nature. The La Site Support Team are = committed to respecting individual members by providing an unsurpassed = quality of dedicated, secure service for everyone.

Thank-you for = choosing La Site.
We are at your service in your search for a = suitable partner.

Best Wishes,
La Site Support = Team.

Mail Delivery = Options

------=_NextPart_000_631C_01C3DD33.C2C50BF0-- _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Sat Jan 17 22:21:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25371 for ; Sat, 17 Jan 2004 22:21:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai3Uk-0005mR-44; Sat, 17 Jan 2004 22:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai3UD-0005ln-DC for rps@optimus.ietf.org; Sat, 17 Jan 2004 22:20:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25357 for ; Sat, 17 Jan 2004 22:20:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ai3UA-0004bU-00 for rps@ietf.org; Sat, 17 Jan 2004 22:20:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ai3TH-0004ZI-00 for rps@ietf.org; Sat, 17 Jan 2004 22:19:32 -0500 Received: from c-24-13-220-32.client.comcast.net ([24.13.220.32] helo=24.13.220.32) by ietf-mx with smtp (Exim 4.12) id 1Ai3SS-0004XB-00 for rps@ietf.org; Sat, 17 Jan 2004 22:18:40 -0500 From: 241756@bigfoot.com X-Mailer: The Bat! (v1.53d) Reply-To: 241756@delphi.com Organization: 2119417112 X-Priority: 3 (Normal) To: rps@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=19.1 required=5.0 tests=ADDR_NUMS_AT_BIGSITE, DATE_IN_PAST_06_12,FORGED_MUA_THEBAT,FORGED_THEBAT_HTML,FROM_ALL_NUMS, FROM_ENDS_IN_NUMS,FROM_STARTS_WITH_NUMS,FROM_WEBMAIL_END_NUMS6, HTML_70_80,HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_BALANCE_A,HTML_TAG_BALANCE_TABLE,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,NO_REAL_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 2.1 FROM_WEBMAIL_END_NUMS6 From webmail service and address ends in numbers * 0.3 NO_REAL_NAME From: does not include a real name * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.7 ADDR_NUMS_AT_BIGSITE Uses an address with lots of numbers, at a big ISP * 1.6 FROM_STARTS_WITH_NUMS From: starts with nums * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.1 HTML_TAG_BALANCE_A BODY: HTML has excess "a" close tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.2 HTML_TAG_BALANCE_TABLE BODY: HTML is missing "table" close tags * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 FROM_ALL_NUMS From an address that is all numbers (non-phone) * 4.3 FORGED_THEBAT_HTML The Bat! can't send HTML message only * 3.2 FORGED_MUA_THEBAT Mail pretending to be from The Bat! (mid) Content-Transfer-Encoding: 8bit Subject: [Rps] 3D Studio Max 241756 Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 17 Jan 2004 11:20:15 -0800 Content-Transfer-Encoding: 8bit OEM Software
Specials good thru 11/12/03. Please use discount code mail9221 to receive these prices.

Software: Windows XP Suites, Adobe software, Clearance, Corel Draw/Corel Ventura, Games, 3D Studio Max, Operating Systems, Utilities.
Microsoft Windows XP Professional OEM 

PowerQuest Partition Magic 8 (CD and Manual) Only $39.95  
Savings -$49.50

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. PowerQuest Partition Magic 8 (CD and Manual)
* Use this Discount Code at Checkout: mail9872

Adobe Photoshop 7.0 OEM

Microsoft Works Suite 2003 (OEM) W/ Word 2002 Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. Microsoft Works Suite 2003 (OEM) W/ Word 2002
* Use this Discount Code at Checkout: mail9872

Microsoft Office XP Professional OEM

Symantec pcAnywhere 10.5 Host/Remote OEM CD Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing Symantec pcAnywhere 10.5 Host/Remote OEM CD
* Use this Discount Code at Checkout: mail9872


Adobe Illustrator 10 OEM

Symantec Norton SystemWorks 2003 Pro OEM CD Only $59.95
Savings -$215.50

ENHANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  Symantec Norton SystemWorks 2003 Pro OEM CD
* Use this Discount Code at Checkout: mail9872

_______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Sat Jan 17 22:22:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25394 for ; Sat, 17 Jan 2004 22:22:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai3VM-0005p8-Al for rps-archive@odin.ietf.org; Sat, 17 Jan 2004 22:21:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0I3LeAO022383 for rps-archive@odin.ietf.org; Sat, 17 Jan 2004 22:21:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai3VM-0005ow-4C for rps-web-archive@optimus.ietf.org; Sat, 17 Jan 2004 22:21:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25370 for ; Sat, 17 Jan 2004 22:21:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ai3VE-0004eB-00 for rps-web-archive@ietf.org; Sat, 17 Jan 2004 22:21:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ai3Uo-0004cA-00 for rps-web-archive@ietf.org; Sat, 17 Jan 2004 22:21:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai3Uk-0005mR-44; Sat, 17 Jan 2004 22:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai3UD-0005ln-DC for rps@optimus.ietf.org; Sat, 17 Jan 2004 22:20:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25357 for ; Sat, 17 Jan 2004 22:20:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ai3UA-0004bU-00 for rps@ietf.org; Sat, 17 Jan 2004 22:20:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ai3TH-0004ZI-00 for rps@ietf.org; Sat, 17 Jan 2004 22:19:32 -0500 Received: from c-24-13-220-32.client.comcast.net ([24.13.220.32] helo=24.13.220.32) by ietf-mx with smtp (Exim 4.12) id 1Ai3SS-0004XB-00 for rps@ietf.org; Sat, 17 Jan 2004 22:18:40 -0500 From: 241756@bigfoot.com X-Mailer: The Bat! (v1.53d) Reply-To: 241756@delphi.com Organization: 2119417112 X-Priority: 3 (Normal) To: rps@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=19.1 required=5.0 tests=ADDR_NUMS_AT_BIGSITE, DATE_IN_PAST_06_12,FORGED_MUA_THEBAT,FORGED_THEBAT_HTML,FROM_ALL_NUMS, FROM_ENDS_IN_NUMS,FROM_STARTS_WITH_NUMS,FROM_WEBMAIL_END_NUMS6, HTML_70_80,HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_BALANCE_A,HTML_TAG_BALANCE_TABLE,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,NO_REAL_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 2.1 FROM_WEBMAIL_END_NUMS6 From webmail service and address ends in numbers * 0.3 NO_REAL_NAME From: does not include a real name * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.7 ADDR_NUMS_AT_BIGSITE Uses an address with lots of numbers, at a big ISP * 1.6 FROM_STARTS_WITH_NUMS From: starts with nums * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.1 HTML_TAG_BALANCE_A BODY: HTML has excess "a" close tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.2 HTML_TAG_BALANCE_TABLE BODY: HTML is missing "table" close tags * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 FROM_ALL_NUMS From an address that is all numbers (non-phone) * 4.3 FORGED_THEBAT_HTML The Bat! can't send HTML message only * 3.2 FORGED_MUA_THEBAT Mail pretending to be from The Bat! (mid) Content-Transfer-Encoding: 8bit Subject: [Rps] 3D Studio Max 241756 Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 17 Jan 2004 11:20:15 -0800 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit OEM Software
Specials good thru 11/12/03. Please use discount code mail9221 to receive these prices.

Software: Windows XP Suites, Adobe software, Clearance, Corel Draw/Corel Ventura, Games, 3D Studio Max, Operating Systems, Utilities.
Microsoft Windows XP Professional OEM 

PowerQuest Partition Magic 8 (CD and Manual) Only $39.95  
Savings -$49.50

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. PowerQuest Partition Magic 8 (CD and Manual)
* Use this Discount Code at Checkout: mail9872

Adobe Photoshop 7.0 OEM

Microsoft Works Suite 2003 (OEM) W/ Word 2002 Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. Microsoft Works Suite 2003 (OEM) W/ Word 2002
* Use this Discount Code at Checkout: mail9872

Microsoft Office XP Professional OEM

Symantec pcAnywhere 10.5 Host/Remote OEM CD Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing Symantec pcAnywhere 10.5 Host/Remote OEM CD
* Use this Discount Code at Checkout: mail9872


Adobe Illustrator 10 OEM

Symantec Norton SystemWorks 2003 Pro OEM CD Only $59.95
Savings -$215.50

ENHANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  Symantec Norton SystemWorks 2003 Pro OEM CD
* Use this Discount Code at Checkout: mail9872

_______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Mon Jan 26 20:03:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27184 for ; Mon, 26 Jan 2004 20:03:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHcM-00014h-3z; Mon, 26 Jan 2004 20:02:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al4XC-0002of-I7 for rps@optimus.ietf.org; Mon, 26 Jan 2004 06:04:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02067 for ; Mon, 26 Jan 2004 06:03:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al4X8-0000E2-00 for rps@ietf.org; Mon, 26 Jan 2004 06:03:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al4WP-00009z-00 for rps@ietf.org; Mon, 26 Jan 2004 06:03:14 -0500 Received: from [195.166.237.40] (helo=afzhg1869.com) by ietf-mx with smtp (Exim 4.12) id 1Al4VZ-0007kY-00 for rps@ietf.org; Mon, 26 Jan 2004 06:02:24 -0500 From: "DR EMMANUEL.A.CHINWEZE." Reply-To: emchinweze@hotmail.com To: rps@ietf.org X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.2 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, FORGED_YAHOO_RCVD,LINES_OF_YELLING,MSGID_FROM_MTA_SHORT,NA_DOLLARS, NIGERIAN_BODY1,NIGERIAN_BODY2,NIGERIAN_BODY3,NIGERIAN_BODY4, RATWARE_OE_MALFORMED,SUBJ_ALL_CAPS autolearn=no version=2.60 X-Spam-Report: * 2.8 RATWARE_OE_MALFORMED X-Mailer has malformed Outlook Express version * 2.0 NA_DOLLARS BODY: Talks about a million North American dollars * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.6 SUBJ_ALL_CAPS Subject is all capitals * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 0.7 NIGERIAN_BODY2 Message body looks like a Nigerian spam message 2+ * 1.6 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+ * 0.7 NIGERIAN_BODY4 Message body looks like a Nigerian spam message 4+ * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 1.0 NIGERIAN_BODY3 Message body looks like a Nigerian spam message 3+ * -0.5 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: quoted-printable Subject: [Rps] DR EMMANUEL.A.CHINWEZE. Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Jan 2004 00:00:13 -0900 Content-Transfer-Encoding: quoted-printable TRANSFER OF USD$22MILLION INTO YOUR ACCOUNT} ATTENTION=3A President=5CCEO=2E I=2C on behalf of my other colleagues from different organs of Federal Government of Nigeria =28FGN=29 owned parastatals decided to solicit your assistance as regards transfer of the above-mentioned amount into your bank account=2E This fund accrued from over invoicing of various contract awarded in my parastatal to certain Foreign Contractors sometimes ago=2E We=2C as holders of sensitive position in our various parastatals=2C were mandated by the Federal Government to Scrutinise all payments made to certain foreign Contractors and we discovered that some of the contracts they executed were grossly over-invoiced either by omission or commission=2E In the process the sum of US$27M =28Twenty Seven Million US Dollars only=29 was found lying in the parastatal suspense account after the foreign contractors had been paid their rightful dues for executing the said contracts=2E We all agreed that this over! -invoiced amount be transferred =28for our own use=29 into a bank account provided by a foreign partner=2C because we are government workers and the Code of Conduct does not allow us to operate foreign accounts=2E However=2C we have succeeded in transferring some of this money precisely US$5=2E0M =28Five Million US Dollars only=29 into a foreign account in MOROCCO =28North Africa=29=2C but the provider of the account in MOROCCO is up to some mischief and refuses to comply to the earlier mutual agreement by insisting that the total amount be paid into his nominated bank account before disbursement will take effect=2E If for a meagre sum of US$5=2E0M =28Five Million US Dollars only=29 we are not compensated=2C is it when the balance of US$22M =28Twenty-two Million US Dollars=29is transferred that we will be sure of our full compensation=3F Of course=2C this abuse of trust and inhumanity calls for sober reflection and search for absolute trust=2E Thus we are seeking your unwav! ering assistance that the remaining amount of US$22M can be speedily p rocessed and fully remitted into your nominated bank account=2E On successful remittance of the fund into your account=2C you will be compensated with 30% of the amount for your assistance and services=2E So far=2C much have been said and due to our sensitive positions=2C we cannot afford a slip in this transaction neither can we give out identity as regards our respective offices=2C but whereby cordial relationship is established=2C smooth operations commences=2C you will be furnished with details of all you deserves to know=2E I am at your disposition to entertain any question from you with respect to this transaction=2C so contact me immediately through my e=3Amail for further information on the requirements and procedure for this transaction=2E in your reply please endeavour to send me the following informations 1=2EYOUR PRIVATE PHONE AND FAX NUMBER=2C 2=2EYOUR BANK DETAIL WERE YOU MAY WISH THE FUND TO BE TRANSFRED=2E 3=2EYOUR COMPANY'S FULL DETAIL IF ANY=2E this will en! able me apply for the release of the fund to your norminated account=2E Please=2C treat with the strictest confidentiality and utmost urgency=2E Yours faithfully=2C DR EMMANUEL=2EA=2ECHINWEZE=2E _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Mon Jan 26 20:21:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28252 for ; Mon, 26 Jan 2004 20:21:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHuT-0003Ry-Go for rps-archive@odin.ietf.org; Mon, 26 Jan 2004 20:20:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R1KvJu013258 for rps-archive@odin.ietf.org; Mon, 26 Jan 2004 20:20:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHuT-0003Rl-DK for rps-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 20:20:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28083 for ; Mon, 26 Jan 2004 20:20:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlHuR-0001l4-00 for rps-web-archive@ietf.org; Mon, 26 Jan 2004 20:20:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AlHqK-0000x3-00 for rps-web-archive@ietf.org; Mon, 26 Jan 2004 20:16:40 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AlHqL-0000Hs-1m for rps-web-archive@ietf.org; Mon, 26 Jan 2004 20:16:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHcM-00014h-3z; Mon, 26 Jan 2004 20:02:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al4XC-0002of-I7 for rps@optimus.ietf.org; Mon, 26 Jan 2004 06:04:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02067 for ; Mon, 26 Jan 2004 06:03:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al4X8-0000E2-00 for rps@ietf.org; Mon, 26 Jan 2004 06:03:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al4WP-00009z-00 for rps@ietf.org; Mon, 26 Jan 2004 06:03:14 -0500 Received: from [195.166.237.40] (helo=afzhg1869.com) by ietf-mx with smtp (Exim 4.12) id 1Al4VZ-0007kY-00 for rps@ietf.org; Mon, 26 Jan 2004 06:02:24 -0500 From: "DR EMMANUEL.A.CHINWEZE." Reply-To: emchinweze@hotmail.com To: rps@ietf.org X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.2 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, FORGED_YAHOO_RCVD,LINES_OF_YELLING,MSGID_FROM_MTA_SHORT,NA_DOLLARS, NIGERIAN_BODY1,NIGERIAN_BODY2,NIGERIAN_BODY3,NIGERIAN_BODY4, RATWARE_OE_MALFORMED,SUBJ_ALL_CAPS autolearn=no version=2.60 X-Spam-Report: * 2.8 RATWARE_OE_MALFORMED X-Mailer has malformed Outlook Express version * 2.0 NA_DOLLARS BODY: Talks about a million North American dollars * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.6 SUBJ_ALL_CAPS Subject is all capitals * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 0.7 NIGERIAN_BODY2 Message body looks like a Nigerian spam message 2+ * 1.6 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+ * 0.7 NIGERIAN_BODY4 Message body looks like a Nigerian spam message 4+ * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 1.0 NIGERIAN_BODY3 Message body looks like a Nigerian spam message 3+ * -0.5 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: quoted-printable Subject: [Rps] DR EMMANUEL.A.CHINWEZE. Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Jan 2004 00:00:13 -0900 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable TRANSFER OF USD$22MILLION INTO YOUR ACCOUNT} ATTENTION=3A President=5CCEO=2E I=2C on behalf of my other colleagues from different organs of Federal Government of Nigeria =28FGN=29 owned parastatals decided to solicit your assistance as regards transfer of the above-mentioned amount into your bank account=2E This fund accrued from over invoicing of various contract awarded in my parastatal to certain Foreign Contractors sometimes ago=2E We=2C as holders of sensitive position in our various parastatals=2C were mandated by the Federal Government to Scrutinise all payments made to certain foreign Contractors and we discovered that some of the contracts they executed were grossly over-invoiced either by omission or commission=2E In the process the sum of US$27M =28Twenty Seven Million US Dollars only=29 was found lying in the parastatal suspense account after the foreign contractors had been paid their rightful dues for executing the said contracts=2E We all agreed that this over! -invoiced amount be transferred =28for our own use=29 into a bank account provided by a foreign partner=2C because we are government workers and the Code of Conduct does not allow us to operate foreign accounts=2E However=2C we have succeeded in transferring some of this money precisely US$5=2E0M =28Five Million US Dollars only=29 into a foreign account in MOROCCO =28North Africa=29=2C but the provider of the account in MOROCCO is up to some mischief and refuses to comply to the earlier mutual agreement by insisting that the total amount be paid into his nominated bank account before disbursement will take effect=2E If for a meagre sum of US$5=2E0M =28Five Million US Dollars only=29 we are not compensated=2C is it when the balance of US$22M =28Twenty-two Million US Dollars=29is transferred that we will be sure of our full compensation=3F Of course=2C this abuse of trust and inhumanity calls for sober reflection and search for absolute trust=2E Thus we are seeking your unwav! ering assistance that the remaining amount of US$22M can be speedily p rocessed and fully remitted into your nominated bank account=2E On successful remittance of the fund into your account=2C you will be compensated with 30% of the amount for your assistance and services=2E So far=2C much have been said and due to our sensitive positions=2C we cannot afford a slip in this transaction neither can we give out identity as regards our respective offices=2C but whereby cordial relationship is established=2C smooth operations commences=2C you will be furnished with details of all you deserves to know=2E I am at your disposition to entertain any question from you with respect to this transaction=2C so contact me immediately through my e=3Amail for further information on the requirements and procedure for this transaction=2E in your reply please endeavour to send me the following informations 1=2EYOUR PRIVATE PHONE AND FAX NUMBER=2C 2=2EYOUR BANK DETAIL WERE YOU MAY WISH THE FUND TO BE TRANSFRED=2E 3=2EYOUR COMPANY'S FULL DETAIL IF ANY=2E this will en! able me apply for the release of the fund to your norminated account=2E Please=2C treat with the strictest confidentiality and utmost urgency=2E Yours faithfully=2C DR EMMANUEL=2EA=2ECHINWEZE=2E _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From rps-admin@ietf.org Wed Jan 28 04:44:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22593 for ; Wed, 28 Jan 2004 04:44:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlmEq-0007Hz-JW; Wed, 28 Jan 2004 04:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlmEI-0007HJ-Bj for rps@optimus.ietf.org; Wed, 28 Jan 2004 04:43:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22541 for ; Wed, 28 Jan 2004 04:43:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlmEF-0005ss-00 for rps@ietf.org; Wed, 28 Jan 2004 04:43:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlmDM-0005pL-00 for rps@ietf.org; Wed, 28 Jan 2004 04:42:29 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AlmCw-0005kw-00 for rps@ietf.org; Wed, 28 Jan 2004 04:42:03 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 4A8C24E1B1; Wed, 28 Jan 2004 10:41:34 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id C82344E282; Wed, 28 Jan 2004 10:41:33 +0100 (CET) Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i0S9fW0G018784; Wed, 28 Jan 2004 10:41:32 +0100 Message-ID: <401783B5.1000004@ripe.net> From: Andrei Robachevsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Leinen Cc: Pekka Savola , David Kessens , Randy Bush , "Larry J. Blunk" , rps@ietf.org, rpslng@ripe.net Subject: Re: [Rps] Re: Separate attributes vs context-aware software [RE: RPS WG...] References: In-Reply-To: X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000021 X-RIPE-Signature: 7141c20683efa3519b2767cad5f5a96d X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 10:41:09 +0100 Content-Transfer-Encoding: 7bit Simon Leinen wrote: > Pekka Savola writes: > >>>I rather see progress towards a pusblished standard, although it >>>doesn't do everything exactly the way I want it, than that we >>>reopen all the discussions again unless a lot of people changed >>>their minds. > > >>For what it's worth, I, as an operator, have roughly the same >>opinion. > > > Me too. > > >>I'd like to see a standardized solution soon (I accept the current >>draft proposal if that's the rough consensus), but on the other >>hand, I'd like it to be as simple as possible to use. > If one's policy is simple so will be its documentation in RPSL[ng]. It can be as simple as in ripe-181 with the exception of explicit afi declaration. But then again, the decision has been consciously made back in March 2002 during IETF53 to make the spec more explicit (and therefore more readable by humans also) and preserve backwards compatibility as much as possible (in people's minds as well as many will default to ipv4). > > Exactly. > > The mp-import/mp-export stuff personally doesn't bother me at all, but > I heard a fellow operator complain about the expected size increase of > their AS object. > > What about the following compromise: > > *) Leave both export/import and mp-export/mp-import in RPSLng (same > for default/mp-default) > *) Add a "mp-default-afs" attribute that defines what "import/export" > means. It would default to ipv4.unicast only. > > That way, no existing tools break - import/export will still be used > for IPv4 unicast policy like today. ISPs can add mp-{im,ex}port to > document IPv6 and multicast policies. As long as "The majority of > providers support IPv4 unicast only" (as Curtis pointed out, and which > is still the case for our set of peers, even though we ARE an > "academic" network), people just add mp- attributes for the minority > of peerings that need it. > > Over time, Pekka's vision of congruent unicast/multicast (and/or > IPv4/IPv6 unicast, but that doesn't matter) topologies may come true. > > At that point, people can start modifying their "mp-default-afs", and > collapse many mp-{im,ex}port attributes into {im,ex}port attributes. > If their peers still use non-RPSLng-compliant tools, then they will > misinterpret {im,ex}port as IPv4 unicast-only, but that is probably > not very relevant - IPv4 unicast is all those peers' tools can handle. > > In some cases it will be necessary to specifically exclude default > address families, but maybe that could be done with AF-specific NOT > ANY policies or something. > > Makes sense? Not really. I think you are presenting a possible scenario of RPSL - RPSLng transition and suggest that we phase out mp- attributes. I'd rather phase out import/export attributes, as mp- attributes provide more functionality and flexibility. But in fact, such transition is not necessary. Either import/export will be phased out naturally, or it will be up to a registry to plan such transition/cleanup when they see appropriate. Regards, Andrei _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps From exim@www1.ietf.org Wed Jan 28 04:46:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22664 for ; Wed, 28 Jan 2004 04:46:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlmGL-0007ND-Au for rps-archive@odin.ietf.org; Wed, 28 Jan 2004 04:45:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S9jXuI028344 for rps-archive@odin.ietf.org; Wed, 28 Jan 2004 04:45:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlmGK-0007N2-BP for rps-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 04:45:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22657 for ; Wed, 28 Jan 2004 04:45:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlmGH-00062f-00 for rps-web-archive@ietf.org; Wed, 28 Jan 2004 04:45:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlmFK-0005yK-00 for rps-web-archive@ietf.org; Wed, 28 Jan 2004 04:44:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlmF2-0005tq-00 for rps-web-archive@ietf.org; Wed, 28 Jan 2004 04:44:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlmEq-0007Hz-JW; Wed, 28 Jan 2004 04:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlmEI-0007HJ-Bj for rps@optimus.ietf.org; Wed, 28 Jan 2004 04:43:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22541 for ; Wed, 28 Jan 2004 04:43:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlmEF-0005ss-00 for rps@ietf.org; Wed, 28 Jan 2004 04:43:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlmDM-0005pL-00 for rps@ietf.org; Wed, 28 Jan 2004 04:42:29 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AlmCw-0005kw-00 for rps@ietf.org; Wed, 28 Jan 2004 04:42:03 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 4A8C24E1B1; Wed, 28 Jan 2004 10:41:34 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id C82344E282; Wed, 28 Jan 2004 10:41:33 +0100 (CET) Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i0S9fW0G018784; Wed, 28 Jan 2004 10:41:32 +0100 Message-ID: <401783B5.1000004@ripe.net> From: Andrei Robachevsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Leinen Cc: Pekka Savola , David Kessens , Randy Bush , "Larry J. Blunk" , rps@ietf.org, rpslng@ripe.net Subject: Re: [Rps] Re: Separate attributes vs context-aware software [RE: RPS WG...] References: In-Reply-To: X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000021 X-RIPE-Signature: 7141c20683efa3519b2767cad5f5a96d Content-Transfer-Encoding: 7bit Sender: rps-admin@ietf.org Errors-To: rps-admin@ietf.org X-BeenThere: rps@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Policy System List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 10:41:09 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Simon Leinen wrote: > Pekka Savola writes: > >>>I rather see progress towards a pusblished standard, although it >>>doesn't do everything exactly the way I want it, than that we >>>reopen all the discussions again unless a lot of people changed >>>their minds. > > >>For what it's worth, I, as an operator, have roughly the same >>opinion. > > > Me too. > > >>I'd like to see a standardized solution soon (I accept the current >>draft proposal if that's the rough consensus), but on the other >>hand, I'd like it to be as simple as possible to use. > If one's policy is simple so will be its documentation in RPSL[ng]. It can be as simple as in ripe-181 with the exception of explicit afi declaration. But then again, the decision has been consciously made back in March 2002 during IETF53 to make the spec more explicit (and therefore more readable by humans also) and preserve backwards compatibility as much as possible (in people's minds as well as many will default to ipv4). > > Exactly. > > The mp-import/mp-export stuff personally doesn't bother me at all, but > I heard a fellow operator complain about the expected size increase of > their AS object. > > What about the following compromise: > > *) Leave both export/import and mp-export/mp-import in RPSLng (same > for default/mp-default) > *) Add a "mp-default-afs" attribute that defines what "import/export" > means. It would default to ipv4.unicast only. > > That way, no existing tools break - import/export will still be used > for IPv4 unicast policy like today. ISPs can add mp-{im,ex}port to > document IPv6 and multicast policies. As long as "The majority of > providers support IPv4 unicast only" (as Curtis pointed out, and which > is still the case for our set of peers, even though we ARE an > "academic" network), people just add mp- attributes for the minority > of peerings that need it. > > Over time, Pekka's vision of congruent unicast/multicast (and/or > IPv4/IPv6 unicast, but that doesn't matter) topologies may come true. > > At that point, people can start modifying their "mp-default-afs", and > collapse many mp-{im,ex}port attributes into {im,ex}port attributes. > If their peers still use non-RPSLng-compliant tools, then they will > misinterpret {im,ex}port as IPv4 unicast-only, but that is probably > not very relevant - IPv4 unicast is all those peers' tools can handle. > > In some cases it will be necessary to specifically exclude default > address families, but maybe that could be done with AF-specific NOT > ANY policies or something. > > Makes sense? Not really. I think you are presenting a possible scenario of RPSL - RPSLng transition and suggest that we phase out mp- attributes. I'd rather phase out import/export attributes, as mp- attributes provide more functionality and flexibility. But in fact, such transition is not necessary. Either import/export will be phased out naturally, or it will be up to a registry to plan such transition/cleanup when they see appropriate. Regards, Andrei _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps