From dsj at merit.edu Thu Feb 2 23:50:06 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 2 Feb 1995 17:50:06 -0500 Subject: Pride Guide?? Message-ID: <199502022250.RAA00568@home.merit.edu> Anyone, Has the new RIPE-181 Pride Guide arrived yet? Is it official? May we refer people to it? --Dale -------- Logged at Fri Feb 3 21:02:39 MET 1995 --------- From jyy at merit.edu Fri Feb 3 21:02:30 1995 From: jyy at merit.edu (Jessica Yu) Date: Fri, 03 Feb 1995 15:02:30 -0500 Subject: Mods to ripe181? Message-ID: <199502032002.PAA23182@home.merit.edu> This issue may come up before but never got addressed. Now we have real problem to describe three major providers policies who I gather routing policies from. I think we really need to seriously address this. Below is an example to illustrate the problem and a suggestion to the solution. ASh | ASi...ASj-------| \ | / | 130 | | / ----------------- / | | | / 50 60 70 / \ / \ \ ASm...ASn ASx..ASy ASz | ASa The Policy: AS130 announce to AS50 everything but not any routes whose AS path starts with AS50,AS60 and AS70. The difficulties here are a) AS130 wants to announce ASj to AS50 but not with the pass of 100 ASj. Since RIPE181 only has homeAS concept in terms of what AS to accept, we have to either describe to reject ASj or advertise ASj not advertise ASj when path is 130 ASj. b) Usually, certain in this real AS's policy case, one does not know explicitly what's behind AS130 i.e. ASi..Asj, ASh. So it is near to impossible to express such policy in ripe181 format. The problem is that RIPE181 deals with home AS only. To describe this case, we need introduce a concept of AS in the path. Suggested mods: Introduce AS in the path concept. This will solve both problem a) and b). To express the policy above: as-out: to AS50 announce ANY AND NOT {AS50in_the_path, AS60in_the_path AS70in_the_path} I suggest to use cisco's regular expression to represent the AS in the path concept. It is widely used and therefore more people understands it. as-out: to AS50 announce ANY AND NOT {^AS50_ ^AS60_ ^AS70_} ^ means the right most of the ASpath. _ same as .* --Jessica -------- Logged at Fri Feb 3 22:16:28 MET 1995 --------- From enke at mci.net Fri Feb 3 22:15:52 1995 From: enke at mci.net (Enke Chen) Date: Fri, 03 Feb 1995 16:15:52 -0500 Subject: Mods to ripe181? In-Reply-To: Your message of "Fri, 03 Feb 1995 15:02:30 EST." <199502032002.PAA23182@home.merit.edu> Message-ID: <199502032115.QAA04725@ns.mci.net> I agree with Jessica on the need of AS path in the as policy. The reality is that AS paths are widely used today in AS policies today. Here is a very simple example, currently MCInet does not re-distribute to other NSPs the routes learned from a NSP. This policy is very difficult (if not impossible) to describe without AS path. -- Enke > Date: Fri, 03 Feb 1995 15:02:30 -0500 > From: Jessica Yu > To: rr-impl at ripe.net > CC: jyy at merit.edu > This issue may come up before but never got addressed. Now we have real probl em > to describe three major providers policies who I gather routing policies from. > > I think we really need to seriously address this. Below is an example to > illustrate the problem and a suggestion to the solution. > > > ASh > | > ASi...ASj-------| > \ | / | > 130 | > | / > ----------------- / > | | | / > 50 60 70 > / \ / \ \ > ASm...ASn ASx..ASy ASz > | > ASa > > The Policy: > > AS130 announce to AS50 everything but not any routes whose AS path starts with > AS50,AS60 and AS70. > > The difficulties here are > > a) AS130 wants to announce ASj to AS50 but not with > the pass of 100 ASj. Since RIPE181 only has homeAS concept in terms of what > AS to accept, we have to either describe to reject ASj or advertise ASj not > advertise ASj when path is 130 ASj. > > b) Usually, certain in this real AS's policy case, one does not know explicitl y > what's behind AS130 i.e. ASi..Asj, ASh. So it is near to impossible to > express such policy in ripe181 format. > > The problem is that RIPE181 deals with home AS only. To describe this case, w e > need introduce a concept of AS in the path. > > Suggested mods: > > Introduce AS in the path concept. This will solve both problem a) and b). To > express the policy above: > > as-out: to AS50 announce ANY AND NOT {AS50in_the_path, AS60in_the_path AS70in_ the_path} > > I suggest to use cisco's regular expression to represent the AS in the path > concept. It is widely used and therefore more people understands it. > > as-out: to AS50 announce ANY AND NOT {^AS50_ ^AS60_ ^AS70_} > > ^ means the right most of the ASpath. > _ same as .* > > > --Jessica -------- Logged at Fri Feb 3 22:57:31 MET 1995 --------- From cengiz at ISI.EDU Fri Feb 3 22:57:13 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 3 Feb 1995 13:57:13 -0800 Subject: Mods to ripe181? In-Reply-To: <199502032002.PAA23182@home.merit.edu> References: <199502032002.PAA23182@home.merit.edu> Message-ID: <199502032157.AA19151@cat.isi.edu> Jessica, Andy and I already made changes to support this in peval and hence the config files. What is missing is the documentation. I will get to it after nanog. We can discuss the datails there if anyone is interested. Jessica Yu (jyy at merit.edu) on February 3: > This issue may come up before but never got addressed. Now we have real problem > to describe three major providers policies who I gather routing policies from. > > I think we really need to seriously address this. Below is an example to > illustrate the problem and a suggestion to the solution. > > > ASh > | > ASi...ASj-------| > \ | / | > 130 | > | / > ----------------- / > | | | / > 50 60 70 > / \ / \ \ > ASm...ASn ASx..ASy ASz > | > ASa > > The Policy: > > AS130 announce to AS50 everything but not any routes whose AS path starts with > AS50,AS60 and AS70. > > The difficulties here are > > a) AS130 wants to announce ASj to AS50 but not with > the pass of 100 ASj. Since RIPE181 only has homeAS concept in terms of what > AS to accept, we have to either describe to reject ASj or advertise ASj not > advertise ASj when path is 130 ASj. > > b) Usually, certain in this real AS's policy case, one does not know explicitly > what's behind AS130 i.e. ASi..Asj, ASh. So it is near to impossible to > express such policy in ripe181 format. > > The problem is that RIPE181 deals with home AS only. To describe this case, we > need introduce a concept of AS in the path. > > Suggested mods: > > Introduce AS in the path concept. This will solve both problem a) and b). To > express the policy above: > > as-out: to AS50 announce ANY AND NOT {AS50in_the_path, AS60in_the_path AS70in_the_path} > > I suggest to use cisco's regular expression to represent the AS in the path > concept. It is widely used and therefore more people understands it. > > as-out: to AS50 announce ANY AND NOT {^AS50_ ^AS60_ ^AS70_} > > ^ means the right most of the ASpath. > _ same as .* > > > --Jessica Cengiz -- Cengiz Alaettinoglu Information Sciences Institute Voice: (310) 822-1511 University of Southern California -------- Logged at Fri Feb 3 23:38:50 MET 1995 --------- From jyy at merit.edu Fri Feb 3 23:38:40 1995 From: jyy at merit.edu (Jessica Yu) Date: Fri, 03 Feb 1995 17:38:40 -0500 Subject: Mods to ripe181? Message-ID: <199502032238.RAA03838@cannes.merit.edu> Oh, so we have another major providers needs such function. --Jessica ------- Forwarded Message Return-Path: enke at mci.net Received: from merit.edu (merit.edu [35.1.1.42]) by home.merit.edu (8.6.9/merit-2.0) with ESMTP id QAA27316 for ; Fri, 3 Feb 1995 16:16:25 -0500 Received: from ns.mci.net (ns.mci.net [204.70.128.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id QAA23028 for ; Fri, 3 Feb 1995 16:16:24 -0500 Received: from localhost (loopback.mci.net [127.0.0.1]) by ns.mci.net (8.6.9/8.6.6) with ESMTP id QAA04725; Fri, 3 Feb 1995 16:15:53 -0500 Message-Id: <199502032115.QAA04725 at ns.mci.net> To: Jessica Yu cc: rr-impl at ripe.net, enke at mci.net Subject: Re: Mods to ripe181? In-reply-to: Your message of "Fri, 03 Feb 1995 15:02:30 EST." <199502032002.PAA23182 at home.merit.edu> Date: Fri, 03 Feb 1995 16:15:52 -0500 From: Enke Chen I agree with Jessica on the need of AS path in the as policy. The reality is that AS paths are widely used today in AS policies today. Here is a very simple example, currently MCInet does not re-distribute to other NSPs the routes learned from a NSP. This policy is very difficult (if not impossible) to describe without AS path. - -- Enke > Date: Fri, 03 Feb 1995 15:02:30 -0500 > From: Jessica Yu > To: rr-impl at ripe.net > CC: jyy at merit.edu > This issue may come up before but never got addressed. Now we have real probl em > to describe three major providers policies who I gather routing policies from. > > I think we really need to seriously address this. Below is an example to > illustrate the problem and a suggestion to the solution. > > > ASh > | > ASi...ASj-------| > \ | / | > 130 | > | / > ----------------- / > | | | / > 50 60 70 > / \ / \ \ > ASm...ASn ASx..ASy ASz > | > ASa > > The Policy: > > AS130 announce to AS50 everything but not any routes whose AS path starts with > AS50,AS60 and AS70. > > The difficulties here are > > a) AS130 wants to announce ASj to AS50 but not with > the pass of 100 ASj. Since RIPE181 only has homeAS concept in terms of what > AS to accept, we have to either describe to reject ASj or advertise ASj not > advertise ASj when path is 130 ASj. > > b) Usually, certain in this real AS's policy case, one does not know explicitl y > what's behind AS130 i.e. ASi..Asj, ASh. So it is near to impossible to > express such policy in ripe181 format. > > The problem is that RIPE181 deals with home AS only. To describe this case, w e > need introduce a concept of AS in the path. > > Suggested mods: > > Introduce AS in the path concept. This will solve both problem a) and b). To > express the policy above: > > as-out: to AS50 announce ANY AND NOT {AS50in_the_path, AS60in_the_path AS70in_ the_path} > > I suggest to use cisco's regular expression to represent the AS in the path > concept. It is widely used and therefore more people understands it. > > as-out: to AS50 announce ANY AND NOT {^AS50_ ^AS60_ ^AS70_} > > ^ means the right most of the ASpath. > _ same as .* > > > --Jessica ------- End of Forwarded Message -------- Logged at Fri Feb 3 23:42:42 MET 1995 --------- From jyy at merit.edu Fri Feb 3 23:42:36 1995 From: jyy at merit.edu (Jessica Yu) Date: Fri, 03 Feb 1995 17:42:36 -0500 Subject: Mods to ripe181? In-Reply-To: Your message of "Fri, 03 Feb 1995 13:57:13 PST." <199502032157.AA19151@cat.isi.edu> Message-ID: <199502032242.RAA03858@cannes.merit.edu> >Andy and I already made changes to support this in peval and hence the >config files. What is missing is the documentation. I will get to it >after nanog. We can discuss the datails there if anyone is interested. Cengiz, I'd like to hear what's in peval. Will it help people to regist the policy described in my example? It is nice to be able to config it but what also needed is to allow people to regist this thing in the format of ripe181. --Jessica -------- Logged at Fri Feb 3 23:43:08 MET 1995 --------- From Tony.Bates at mci.net Fri Feb 3 23:42:32 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Fri, 03 Feb 1995 17:42:32 -0500 Subject: Mods to ripe181? In-Reply-To: Your message of Fri, 03 Feb 1995 16:15:52 EST. <199502032115.QAA04725@ns.mci.net> Message-ID: <199502032242.RAA20505@lovefm.reston.mci.net> Here are re-visiting an old discussion. I personally am not in agreement with Enke on this one so this is not necessarily the whole view of MCI. --Tony. Enke Chen writes: * I agree with Jessica on the need of AS path in the as policy. * The reality is that AS paths are widely used today in AS policies * today. Here is a very simple example, currently MCInet does * not re-distribute to other NSPs the routes learned from a NSP. * This policy is very difficult (if not impossible) to describe * without AS path. * * -- Enke * * * > Date: Fri, 03 Feb 1995 15:02:30 -0500 * > From: Jessica Yu * > To: rr-impl at ripe.net * > CC: jyy at merit.edu * * > This issue may come up before but never got addressed. Now we have real * probl * em * > to describe three major providers policies who I gather routing policies * from. * > * > I think we really need to seriously address this. Below is an example to * > illustrate the problem and a suggestion to the solution. * > * > * > ASh * > | * > ASi...ASj-------| * > \ | / | * > 130 | * > | / * > ----------------- / * > | | | / * > 50 60 70 * > / \ / \ \ * > ASm...ASn ASx..ASy ASz * > | * > ASa * > * > The Policy: * > * > AS130 announce to AS50 everything but not any routes whose AS path starts * with * > AS50,AS60 and AS70. * > * > The difficulties here are * > * > a) AS130 wants to announce ASj to AS50 but not with * > the pass of 100 ASj. Since RIPE181 only has homeAS concept in terms of w * hat * > AS to accept, we have to either describe to reject ASj or advertise ASj n * ot * > advertise ASj when path is 130 ASj. * > * > b) Usually, certain in this real AS's policy case, one does not know expl * icitl * y * > what's behind AS130 i.e. ASi..Asj, ASh. So it is near to impossible to * > express such policy in ripe181 format. * > * > The problem is that RIPE181 deals with home AS only. To describe this ca * se, w * e * > need introduce a concept of AS in the path. * > * > Suggested mods: * > * > Introduce AS in the path concept. This will solve both problem a) and b) * . To * * > express the policy above: * > * > as-out: to AS50 announce ANY AND NOT {AS50in_the_path, AS60in_the_path AS * 70in_ * the_path} * > * > I suggest to use cisco's regular expression to represent the AS in the pa * th * > concept. It is widely used and therefore more people understands it. * > * > as-out: to AS50 announce ANY AND NOT {^AS50_ ^AS60_ ^AS70_} * > * > ^ means the right most of the ASpath. * > _ same as .* * > * > * > --Jessica -------- Logged at Fri Feb 3 23:46:44 MET 1995 --------- From jyy at merit.edu Fri Feb 3 23:46:30 1995 From: jyy at merit.edu (Jessica Yu) Date: Fri, 03 Feb 1995 17:46:30 -0500 Subject: Mods to ripe181? Message-ID: <199502032246.RAA03891@cannes.merit.edu> Just to explain futher. I gathered the policy from 3 ASs and can not regist them in the test RADB because the function I described is lacking in ripe181 format. --Jessica ------- Forwarded Message Return-Path: jyy at merit.edu Received: from merit.edu (merit.edu [35.1.1.42]) by home.merit.edu (8.6.9/merit-2.0) with ESMTP id RAA01785 for ; Fri, 3 Feb 1995 17:42:43 -0500 Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.6.9/merit-2.0) with ESMTP id RAA28255 for ; Fri, 3 Feb 1995 17:42:42 -0500 Received: from cannes.merit.edu (cannes.merit.edu [198.108.60.43]) by home.merit.edu (8.6.9/merit-2.0) with ESMTP id RAA01778; Fri, 3 Feb 1995 17:42:37 -0500 Received: from localhost (jyy at localhost) by cannes.merit.edu (8.6.9/8.6.5) with SMTP id RAA03858; Fri, 3 Feb 1995 17:42:36 -0500 Message-Id: <199502032242.RAA03858 at cannes.merit.edu> X-Authentication-Warning: cannes.merit.edu: jyy owned process doing -bs X-Authentication-Warning: cannes.merit.edu: Host localhost didn't use HELO protocol To: cengiz at isi.edu (Cengiz Alaettinoglu) cc: Jessica Yu , rr-impl at ripe.net, ra-team at isi.edu Subject: Re: Mods to ripe181? In-reply-to: Your message of "Fri, 03 Feb 1995 13:57:13 PST." <199502032157.AA19151 at cat.isi.edu> Date: Fri, 03 Feb 1995 17:42:36 -0500 From: Jessica Yu >Andy and I already made changes to support this in peval and hence the >config files. What is missing is the documentation. I will get to it >after nanog. We can discuss the datails there if anyone is interested. Cengiz, I'd like to hear what's in peval. Will it help people to regist the policy described in my example? It is nice to be able to config it but what also needed is to allow people to regist this thing in the format of ripe181. --Jessica ------- End of Forwarded Message -------- Logged at Sat Feb 4 00:04:37 MET 1995 --------- From cengiz at ISI.EDU Sat Feb 4 00:04:10 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 3 Feb 1995 15:04:10 -0800 Subject: Mods to ripe181? In-Reply-To: <199502032242.RAA03858@cannes.merit.edu> References: <199502032157.AA19151@cat.isi.edu> <199502032242.RAA03858@cannes.merit.edu> Message-ID: <199502032304.AA19770@cat.isi.edu> Jessica Yu (jyy at merit.edu) on February 3: > I'd like to hear what's in peval. Will it help people to regist the policy > described in my example? It is nice to be able to config it but what also > needed is to allow people to regist this thing in the format of ripe181. > > --Jessica Peval recognizes and evaluates policy expressions that contain limited as path expressions. That is all. The part that is missing is how one can register policies with such expressions. Earlier we have aggreed on the following: Have four new policy lines: extended-as-in extended-as-out extended-interas-in extended-interas-out that have the same syntax as the corresponding non-extended ones except that they allow general as path expressions (some of which is not recognized by peval yet) in them. Eg. extended-as-in: AS1 100 accept AS2 OR {1.1.1.1/32} OR AND COMM_NSF_AUP (peval can actually evaluate the above line). If a domain registers an aut-num object that has at least one extended policy line, the non-extended policy lines are ignored by the tools that know about the extended stuff, otherwise they work with the non-extended lines. For the benefit of the older tools, we would reccomend administrators to register both extended and non-extended policies where possible. When all the tools are upgraded and we reach a concensus, we might remove the non-extended policy lines. Oh, by the way, as-exclude becomes extended-as-in: ... AND NOT <.* AS1 .*> Regarding the issue of dangerous, topology dependent as paths, we will reccomend administrators not to use such expression unless necessary. I will probably work on this after nanog and send the document to the group for review. Initial feedback is welcome. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute Voice: (310) 822-1511 University of Southern California -------- Logged at Sun Feb 5 17:58:54 MET 1995 --------- From Marten.Terpstra at ripe.net Sun Feb 5 17:58:51 1995 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Sun, 05 Feb 1995 17:58:51 +0100 Subject: Pride Guide?? In-Reply-To: Your message of Thu, 02 Feb 1995 17:50:06 EST. <199502022250.RAA00568@home.merit.edu> Message-ID: <9502051658.AA20487@ncc.ripe.net> "Dale S. Johnson" writes * Anyone, * * Has the new RIPE-181 Pride Guide arrived yet? Is it official? May * we refer people to it? Yup, it is in: ftp://ftp.ripe.net/pride/docs/guide-2.0.tar.{ps|txt}.tar.Z -Marten -------- Logged at Mon Feb 6 16:21:07 MET 1995 --------- From jyy at merit.edu Mon Feb 6 16:20:58 1995 From: jyy at merit.edu (Jessica Yu) Date: Mon, 06 Feb 1995 10:20:58 -0500 Subject: Mods to ripe181? Message-ID: <199502061520.KAA15965@home.merit.edu> Tony, Please take a look at the example I provided below. That is a real policy of three major providers. I tried to regist their policy but could not do it. If you have a suggestion of how to use 181 to express that. That will be a big big help. --Jessica ------- Forwarded Message Return-Path: tony at mci.net Received: from merit.edu (merit.edu [35.1.1.42]) by home.merit.edu (8.6.9/merit-2.0) with ESMTP id RAA01804 for ; Fri, 3 Feb 1995 17:43:06 -0500 Received: from lovefm.reston.mci.net (lovefm.Reston.mci.net [204.70.128.44]) by merit.edu (8.6.9/merit-2.0) with ESMTP id RAA28258 for ; Fri, 3 Feb 1995 17:43:05 -0500 Received: from localhost (loopback.mci.net [127.0.0.1]) by lovefm.reston.mci.net (8.6.9/8.6.6) with ESMTP id RAA20505; Fri, 3 Feb 1995 17:42:33 -0500 Message-Id: <199502032242.RAA20505 at lovefm.reston.mci.net> To: Enke Chen cc: Jessica Yu , rr-impl at ripe.net Subject: Re: Mods to ripe181? In-reply-to: Your message of Fri, 03 Feb 1995 16:15:52 EST. <199502032115.QAA04725 at ns.mci.net> From: Tony Bates X-Phone: +1 703 715 7521 Date: Fri, 03 Feb 1995 17:42:32 -0500 Sender: tony at mci.net Here are re-visiting an old discussion. I personally am not in agreement with Enke on this one so this is not necessarily the whole view of MCI. --Tony. Enke Chen writes: * I agree with Jessica on the need of AS path in the as policy. * The reality is that AS paths are widely used today in AS policies * today. Here is a very simple example, currently MCInet does * not re-distribute to other NSPs the routes learned from a NSP. * This policy is very difficult (if not impossible) to describe * without AS path. * * -- Enke * * * > Date: Fri, 03 Feb 1995 15:02:30 -0500 * > From: Jessica Yu * > To: rr-impl at ripe.net * > CC: jyy at merit.edu * * > This issue may come up before but never got addressed. Now we have real * probl * em * > to describe three major providers policies who I gather routing policies * from. * > * > I think we really need to seriously address this. Below is an example to * > illustrate the problem and a suggestion to the solution. * > * > * > ASh * > | * > ASi...ASj-------| * > \ | / | * > 130 | * > | / * > ----------------- / * > | | | / * > 50 60 70 * > / \ / \ \ * > ASm...ASn ASx..ASy ASz * > | * > ASa * > * > The Policy: * > * > AS130 announce to AS50 everything but not any routes whose AS path starts * with * > AS50,AS60 and AS70. * > * > The difficulties here are * > * > a) AS130 wants to announce ASj to AS50 but not with * > the pass of 100 ASj. Since RIPE181 only has homeAS concept in terms of w * hat * > AS to accept, we have to either describe to reject ASj or advertise ASj n * ot * > advertise ASj when path is 130 ASj. * > * > b) Usually, certain in this real AS's policy case, one does not know expl * icitl * y * > what's behind AS130 i.e. ASi..Asj, ASh. So it is near to impossible to * > express such policy in ripe181 format. * > * > The problem is that RIPE181 deals with home AS only. To describe this ca * se, w * e * > need introduce a concept of AS in the path. * > * > Suggested mods: * > * > Introduce AS in the path concept. This will solve both problem a) and b) * . To * * > express the policy above: * > * > as-out: to AS50 announce ANY AND NOT {AS50in_the_path, AS60in_the_path AS * 70in_ * the_path} * > * > I suggest to use cisco's regular expression to represent the AS in the pa * th * > concept. It is widely used and therefore more people understands it. * > * > as-out: to AS50 announce ANY AND NOT {^AS50_ ^AS60_ ^AS70_} * > * > ^ means the right most of the ASpath. * > _ same as .* * > * > * > --Jessica ------- End of Forwarded Message -------- Logged at Mon Feb 6 16:35:22 MET 1995 --------- From jyy at merit.edu Mon Feb 6 16:35:16 1995 From: jyy at merit.edu (Jessica Yu) Date: Mon, 06 Feb 1995 10:35:16 -0500 Subject: Mods to ripe181? Message-ID: <199502061535.KAA16856@home.merit.edu> >Peval recognizes and evaluates policy expressions that contain limited >as path expressions. That is all. This is useful for generating configuration based on such policy registed in the RADB. Great that this done. But it won't help to regist the policy to the RADB at first which is what Peval will be based on and is I needed. >The part that is missing is how one can register policies with such >expressions. Earlier we have aggreed on the following: >Have four new policy lines: >extended-as-in >extended-as-out >extended-interas-in >extended-interas-out >that have the same syntax as the corresponding non-extended ones >except that they allow general as path expressions (some of which is >not recognized by peval yet) in them. That is the same as what suggested in my previous message. Except that I suggest to use cisco's aspath notation which is widely understood by providers. As I mentioned in my first message, we may talked about this before but it has not been done to change the express syntax to allow people regist their policy. I brought this up now again because I am not able to regist people's policy. I got routing policy from Alternet and Sprint and really had difficulty to regist them in the RADB. So can we agree on the extended syntax and implement them? --Jessica -------- Logged at Mon Feb 6 18:55:01 MET 1995 --------- From enke at mci.net Mon Feb 6 18:54:25 1995 From: enke at mci.net (Enke Chen) Date: Mon, 06 Feb 1995 12:54:25 -0500 Subject: Mods to ripe181? In-Reply-To: Your message of "Fri, 03 Feb 1995 17:42:32 EST." <199502032242.RAA20505@lovefm.reston.mci.net> Message-ID: <199502061754.MAA23438@ns.mci.net> Tony: Yes. It is the old topic, same group of people, with orgnizations reshuffled -:) -- Enke > Date: Fri, 03 Feb 1995 17:42:32 -0500 > From: Tony Bates > To: Enke Chen > CC: Jessica Yu , rr-impl at ripe.net > Here are re-visiting an old discussion. I personally am not in > agreement with Enke on this one so this is not necessarily the whole > view of MCI. > --Tony. > > Enke Chen writes: > * I agree with Jessica on the need of AS path in the as policy. > * The reality is that AS paths are widely used today in AS policies > * today. Here is a very simple example, currently MCInet does > * not re-distribute to other NSPs the routes learned from a NSP. > * This policy is very difficult (if not impossible) to describe > * without AS path. > * > * -- Enke > * > * > * > Date: Fri, 03 Feb 1995 15:02:30 -0500 > * > From: Jessica Yu > * > To: rr-impl at ripe.net > * > CC: jyy at merit.edu > * > * > This issue may come up before but never got addressed. Now we have real > * probl > * em > * > to describe three major providers policies who I gather routing policies > * from. > * > > * > I think we really need to seriously address this. Below is an example t o > * > illustrate the problem and a suggestion to the solution. > * > > * > > * > ASh > * > | > * > ASi...ASj-------| > * > \ | / | > * > 130 | > * > | / > * > ----------------- / > * > | | | / > * > 50 60 70 > * > / \ / \ \ > * > ASm...ASn ASx..ASy ASz > * > | > * > ASa > * > > * > The Policy: > * > > * > AS130 announce to AS50 everything but not any routes whose AS path start s > * with > * > AS50,AS60 and AS70. > * > > * > The difficulties here are > * > > * > a) AS130 wants to announce ASj to AS50 but not with > * > the pass of 100 ASj. Since RIPE181 only has homeAS concept in terms of w > * hat > * > AS to accept, we have to either describe to reject ASj or advertise ASj n > * ot > * > advertise ASj when path is 130 ASj. > * > > * > b) Usually, certain in this real AS's policy case, one does not know exp l > * icitl > * y > * > what's behind AS130 i.e. ASi..Asj, ASh. So it is near to impossible to > * > express such policy in ripe181 format. > * > > * > The problem is that RIPE181 deals with home AS only. To describe this c a > * se, w > * e > * > need introduce a concept of AS in the path. > * > > * > Suggested mods: > * > > * > Introduce AS in the path concept. This will solve both problem a) and b ) > * . To > * > * > express the policy above: > * > > * > as-out: to AS50 announce ANY AND NOT {AS50in_the_path, AS60in_the_path A S > * 70in_ > * the_path} > * > > * > I suggest to use cisco's regular expression to represent the AS in the p a > * th > * > concept. It is widely used and therefore more people understands it. > * > > * > as-out: to AS50 announce ANY AND NOT {^AS50_ ^AS60_ ^AS70_} > * > > * > ^ means the right most of the ASpath. > * > _ same as .* > * > > * > > * > --Jessica -------- Logged at Mon Feb 6 19:34:11 MET 1995 --------- From cengiz at ISI.EDU Mon Feb 6 19:33:26 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 6 Feb 1995 10:33:26 -0800 Subject: Mods to ripe181? In-Reply-To: <199502061754.MAA23438@ns.mci.net> References: <199502032242.RAA20505@lovefm.reston.mci.net> <199502061754.MAA23438@ns.mci.net> Message-ID: <199502061833.AA24832@cat.isi.edu> Enke Chen (enke at mci.net) on February 6: > Tony: > Yes. It is the old topic, same group of people, with orgnizations > reshuffled -:) > -- Enke This is not right:-) I was not there:-) Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Tue Feb 7 21:45:59 MET 1995 --------- From dsj at merit.edu Tue Feb 7 21:45:55 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 7 Feb 1995 15:45:55 -0500 Subject: PRDB->RADB Message-ID: <199502072045.PAA01437@home.merit.edu> FYI: The Maintainer and Aut-num objects in the PRDB have just been moved to the RADB, as part of the process of the PRDB->RADB migration. The route objects will follow in a small number of weeks. If you are importing prdb.db, it would be a good idea to start importing radb.db as well (from the same directory). (Sorry for the short notice). --Dale -------- Logged at Wed Feb 8 01:19:47 MET 1995 --------- From cengiz at ISI.EDU Wed Feb 8 01:19:18 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 7 Feb 1995 16:19:18 -0800 Subject: forwarded message from John Scudder Message-ID: <199502080019.AA27487@cat.isi.edu> Here is some feedback on the as-in interas-in interaction. The lines that start with [ca] are my comments for clarification. ------- start of forwarded message (RFC 934 encapsulation) ------- Message-Id: <9502070119.AA27306 at yurt.merit.edu> From: John Scudder To: cengiz at ISI.EDU Subject: more on pol2filters prefs Date: Mon, 06 Feb 1995 20:19:12 -0500 Cengiz, OK, I would like to revisit this old topic. I have two points: 1. As far as I can reverse-engineer it, the algorithm for writing the preference onto NSFNET gated.conf files is considerably less elaborate than the one used in pol2filters/policyparser.pl. Namely, for a given set of routes matching a given expression, e.g.: # 66 (NSF_DB{ aslist == 6:293 }) AND (NSF_DB{ aslist == 6:293(145) }) [ca] 66 is the preference used by the config file generator. It is [ca] calculated using the as-in, interas-in preference interaction. the preference is 105 + max(advisory_metric). In this case the preference is 111. This is pretty easy to express; less easy for me to figure out where to code it in. The code in get_import_policy() seems to want to do everything based on interas-in and as-in. What I need access to in order to write an NSFNET-compatible preference is the advisory stuff. Suggestions? If all else fails I can parse the comment lines and pull out the metrics, then rewrite the preference for the routes which follow. But that's not my preference :-), way too ugly. As you know, I need to produce files which slavishly follow current conventions in order to pull this transition off... 2. I note that every so often pol2filters writes a comment line with a large expression like this: # 63 (NSF_DB{ aslist == 6:293 }) AND ((NSF_DB{ aslist == 1:293 } NSF_DB{ aslist == 2:293 } NSF_DB{ aslist == 3:293 } NSF_DB{ aslist == 6:293 } ) AND NOT (NSF_DB { aslist == 1:293 } NSF_DB{ aslist == 1:293(144) } NSF_DB{ aslist == 1:293(144) } NSF_DB{ aslist == 1:293(144) } NSF_DB{ aslist == 1:293(144) } NSF_DB{ aslist = = 1:293(145) } NSF_DB{ aslist == 1:293(145) } NSF_DB{ aslist == 1:293(145) } NSF _DB{ aslist == 1:293(145) } NSF_DB{ aslist == 2:293 } NSF_DB{ aslist == 2:293(14 4) } NSF_DB{ aslist == 2:293(144) } NSF_DB{ aslist == 2:293(144) } NSF_DB{ aslis t == 2:293(144) } NSF_DB{ aslist == 2:293(145) } NSF_DB{ aslist == 2:293(145) } NSF_DB{ aslist == 2:293(145) } NSF_DB{ aslist == 2:293(145) } NSF_DB{ aslist == 3:293 } NSF_DB{ aslist == 3:293(144) } NSF_DB{ aslist == 3:293(144) } NSF_DB{ as list == 3:293(144) } NSF_DB{ aslist == 3:293(144) } NSF_DB{ aslist == 3:293(145) } NSF_DB{ aslist == 3:293(145) } NSF_DB{ aslist == 3:293(145) } NSF_DB{ aslist == 3:293(145) } NSF_DB{ aslist == 6:293 } NSF_DB{ aslist == 6:293(145) } NSF_DB{ aslist == 6:293(145) } NSF_DB{ aslist == 6:293(145) } NSF_DB{ aslist == 6:293(1 45) } )) or even much larger. These never seem to match anything in the examples I am looked at. [ca] These are the left over routes that are not explicitly accepted [ca] by interas-in. In the AS690, they evaluate to the empty set. This is more along the lines of "hmm, isn't that curious" than anything else, from someone who is looking at both pol2filters and RIPE-181 as a black box (well, as much as I can). I don't care about the noise, as long as it works. I do have a sneaking suspicion that pol2filters would run way faster if there was a way to ignore these, though. - --John ------- end ------- Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Mon Feb 13 16:50:31 MET 1995 --------- From ripe-dbm at ripe.net Mon Feb 13 16:50:28 1995 From: ripe-dbm at ripe.net (RIPE Database Manager) Date: Mon, 13 Feb 1995 16:50:28 +0100 Subject: BUG fixes Message-ID: <9502131550.AA00730@ncc.ripe.net> Dear all, These are my first two fixes in the database software ! If there are any problems, please contact me. I sent this message to db-beta and forgot you folks, so please forgive me ;-), Kind regards, David Kessens RIPE NCC # ================================= This are two related fixes. The bug was discovered by somebody trying to delete an object with more changed attributes. One of these attributes missed the date part. Fix 1: If a changed attribute missed the date part a date was added however if there where more changed attributes the date could be added to the wrong changed attribute. In the case of objects with more changed attributes and one missing date, it is most likely the oldest object didn't contain a date and it would be inappropriate to add the date of today. Missing dates in the changed attribute generate now always an error to prevent these problems. Fix 2: The database contains old objects which would not be allowed to get in with the current syntax checking. Sometimes syntax checking helps a user by adding info/changing some info and generates a warning instead of an error. However, the syntax checking was also done with the to be deleted objects. This means that the sent in object could be changed before deletion and would generate an error message that objects don't match. # =========================================== Fix 1: Make the following changes in 'syntax.pl': if ($date eq "") { $object{$key} .= " $curdate"; return $O_WARNING, "todays date ($curdate) added to \"$ATTL{$key}\" attribute"; } if ($date eq "") { return $O_ERROR, "No date specified in \"$ATTL{$key}\" attribute"; } Fix 2: And substitute 'dbupdate.pl' and 'enparse.pl' with the following files and do a 'make install'. # =========================================== #!PERL # $RCSfile: dbupdate.pl,v $ # $Revision: 0.32 $ # $Author: david $ # $Date: 1995/02/10 11:38:56 $ # This is a client that will update objects read from a file directly # in the database, without interference of updated. # It will update the object in the database that is linked to the # source field of the object, so better make sure you have a source field # and that it has a database associated to it ... @INC = ("LIBDIR", @INC); require "adderror.pl"; require "cldb.pl"; require "dbadd.pl"; require "dbclose.pl"; require "dbopen.pl"; require "defines.pl"; require "enparse.pl"; require "entype.pl"; require "enwrite.pl"; require "getopts.pl"; require "handle.pl"; require "misc.pl"; require "rconf.pl"; require "rfc822.pl"; require "syslog.pl"; # Parse options: # # -l logfile - log output to file in stead of STDOUT # -v - verbose output (LONGACK) # -M - treat input file (or STDIN) as mail and compose # and send ack mail back # -A - assume "assign" mode, only add will be allowed # usually set by parsing mail headers # -H - handle assignment mode. Will only accept persons # with nic-handle "assign" and return person entry # with the handle assigned and filled in. # (very RIPE database dependent) &Getopts('l:vMAHV'); # Need this below for running perl in tainted mode. $ENV{"PATH"} = ""; $ENV{"SHELL"} = "/bin/sh"; $ENV{"IFS"} = ""; # Read config file from RIPEDBCNF, or set to default. $conffile=$ENV{"RIPEDBCNF"}; $conffile= "DEFCONFIG" unless $conffile; print STDERR "dbupdate - reading config\n" if $opt_V; &rconf($conffile); # Save STDOUT open(SAVEOUT, ">&STDOUT"); # Open one ack file. Proper handling (stdout, logfile or mail) is handled # all the way at the end .... But, we open the logfile if needed already # because we need to exit if we cannot even create that file ... # If -M option is specified, -l is overruled. if ($opt_l) { open(LOGFILE, ">$opt_l") || die "Cannot create $opt_l: $!"; } open(STDOUT, ">$TMPDIR/dbupdack.$$") || &syslog("ERRLOG", "cannot create tmp ack file: $!"); # Make STDOUT unbuffered select(STDOUT); $| = 1; # # printstat ( arg ) # # int arg /* 0=failed, 1=ok, 2=noop */ # # prints verbose version of the update result. # sub printstat { local($stat) = @_; local($type) = &entype(*entry); print STDERR "dbupdate - printstat($stat) called\n" if $opt_V; print STDERR "dbupdate - printstat 1\n" if $opt_V; if ($hasdelete) { print "Delete "; } else { print "Update "; } print STDERR "dbupdate - printstat 2\n" if $opt_V; if ($stat == 1) { print "OK: ";} elsif ($stat == 2) { print "NOOP: ";} else { print "FAILED: "; } print STDERR "dbupdate - printstat 3\n" if $opt_V; print "[$ATTL{$type}] $entry{$type}\n\n"; print STDERR "dbupdate - printstat 4\n" if $opt_V; } # # doaction ( ) # # does all the work. # sub doaction { local($file) = @_; local($donestat) = 0; print STDERR "dbupdate - doaction($file) called\n" if $opt_V; while(1) { $donestat = 0; print STDERR "dbupdate - calling enparse\n" if $opt_V; ($parsestat, $hasdelete, %entry) = &enparse($file); # next if nothing was read next if $parsestat == $NOK; # return if only thing read was EOF return if $parsestat == $EOF; $somethingfound = 1; print STDERR "dbupdate - read an object\n" if $opt_V; local($type) = &entype(*entry); # now if we are running in -H mode, just next when we have # not found a person. if ($opt_H) { if ($type ne "pn") { print "No person object found\n"; next; } else { if ($entry{"nh"} !~ /^[aA][sS][sS][iI][gG][nN]$/) { &adderror(*entry, "nichandle \"assign\" expected"); print "\n" if &enwrite(*entry,1,1); next; } } } if (($parsestat == $O_ERROR) && (!$hasdelete)) { print STDERR "dbupdate - object has error and no delete\n" if $opt_V; if ($opt_v) { &printstat(0); } $haserror = 1; print "\n" if &enwrite(*entry,1,1,1); next; } # object parsed OK or has only warnings if ($parsestat == $O_OK || $parsestat == $O_WARNING) { # open database file associated with "so" for writing local(*db) = 'currentdb'; print STDERR "dbupdate - opening database\n" if $opt_V; if (&dbopen(db, *entry, 1)) { # Open classless database print STDERR "dbupdate - opening classless db\n" if $opt_V; &dbclopen(*entry,1); # Looks like we have some locking problem, so let's # lock the thing before we do anything else ... print STDERR "dbupdate - locking databases\n" if $opt_V; &dblock(*db); # do we delete or not ? if ($hasdelete) { print STDERR "dbupdate - deleting entry\n" if $opt_V; $dbstat = &dbdel(*db, *entry); # We do handle generation, so after a delete, we # have to delete the handle from that database # as well. if ($DOHANDLE && $HANDLEATTR{$type}) { if ($dbstat == $OK) { &DeleteHandle(*entry); } } } else { # We do handle generation, check whether we have # to assign a nic handle (if nh value is "assign") # Can be a request handle of form: assign handle # Line has already been syntax checked, so no worries # there. Errors are added by AssignHandle, so all we # need is an extra check. if ($DOHANDLE && $HANDLEATTR{$type}) { if ($entry{$HANDLEATTR{$type}} =~ /^[Aa][Ss][Ss][Ii][Gg][Nn]\s*(.*)$/) { local($handle) = &AssignHandle(*entry, $1); } else { # new object, we may have to put the handle # in the database. AddHandle will return if # if the handle is already in handle database &AddHandle(*entry); } } if (!&haserror(*entry)) { # NEW assignments && !person if ($opt_A && ($type ne "pn")) { print STDERR "dbupdate - calling dbadd\n" if $opt_V; $dbstat = &dbadd(*db, *entry); } else { print STDERR "dbupdate - calling add_or_mod\n" if $opt_V; $dbstat = &dbadd_or_modify(*db, *entry); } } else { # Fake dbstat, has error due to handle # generation ... $dbstat = $OK; } } # Totally yucky, but I do not know how to # do this better right now. The thing is that # every exit code but E_NOOP and OK are # errors, so catch NOOP first, and print # verbose warning if needed, then OK, and # then handle all the others as errors. # noop, just print stat if verbose print STDERR "dbupdate - doing acks\n" if $opt_V; if ($dbstat == $E_NOOP && $opt_v) { &printstat(2); $donestat = 1; } elsif (($dbstat != $OK) && ($dbstat != $E_NOOP)){ &adderror(*entry, "$MESSAGE[$dbstat]"); } # Object has errors, so print, and next if (&haserror(*entry)) { print STDERR "dbupdate - object has errors\n" if $opt_V; $haserror = 1; if ($opt_v) { &printstat(0); } print "\n" if &enwrite(*entry,1,1); &dbunlock(*db); &dbclose(*db); &dbclclose(); next; } # object has only warnings, so it must have # been processed. print and next. elsif (&haswarning(*entry)) { print STDERR "dbupdate - object has warnings\n" if $opt_V; $haserror = 1; if (!$donestat && $opt_v) { &printstat(1); } print "\n" if &enwrite(*entry,1,1); &dbunlock(*db); &dbclose(*db); &dbclclose(); next; } # all was OK, so only print stat if verbose if ($opt_v && !$donestat) { &printstat(1); } # all was OK, print object if nichandle assign mode if ($opt_H) { &enwrite(*entry,1,1); } &dbunlock(*db); &dbclose(*db); &dbclclose(); } else { # Not too good, probably permission problem # if this is given as output ... &adderror(*entry, "Failed to open DB file: $!"); &adderror(*entry, "Please check the \"source:\" value"); &adderror(*entry, "Contact <$HUMAILBOX> if source seems ok"); &printstat(0); &enwrite(*entry,1,1); } } } close(TMP); } # # Main program # # We want to make a local copy of the input, because we need to do mutliple # things with it ... open(COPY, ">$TMPDIR/dbupdcopy.$$") || die "Cannot open copy file: $!"; select(COPY); $| = 1; select(STDOUT); while (<>) { print COPY; } close(COPY); # Now we open the copy to actually process open(COPY, "$TMPDIR/dbupdcopy.$$") || die "Cannot open copy: $!"; # We have a mail, so let's first parse the headers ... if ($opt_M) { local($stat) = &parserfc822(COPY); # If we have at least a return address, compose the header of # the ack mail if ($stat) { if ($TESTMODE) { print "To: $DEFMAIL\n"; } else { print "To: $FROM\n"; } eval "print \"$MHEADER\";"; eval "print \"$MAILTXT\";"; # If not we are in trouble once more ... } else { print "Header could not be parsed ...\n"; } } # Take all the stuff from file COPY in doaction. It will process the # whole stuff. &doaction(COPY); if (!$somethingfound) { print "** No objects were found in your message **\n"; } elsif ($haserror) { print "$ACKERR" unless $opt_H; } else { print "$ACKOK" unless $opt_H; } print $ACKSIG unless $opt_H; close(COPY); close(STDOUT); open(STDOUT, ">&SAVEOUT"); # Output the ack, if -M specified then no logfile or stdout will be given. if ($opt_M) { system("$MAILCMD < $TMPDIR/dbupdack.$$"); } else { open(TMP, "$TMPDIR/dbupdack.$$"); while () { if ($opt_l) { print LOGFILE; } else { print; } } close(TMP); } # We sent out the ack, now send out the notifications if needed if (%notify) { &SendNotifications(); } if (%forward) { &SendForwardMails(); } # log all stuff to the right places # todays YYMMDD local($s,$m,$h,$md,$mo,$y,$wd,$yd,$is) = localtime(time); $mo+=1; $mo = "0".$mo unless $mo > 9; $md = "0".$md unless $md > 9; $y = "0".$y unless $y > 9; $YYMMDD = "$y$mo$md"; # This may seem yucky, but is needed to untaint the filename ... $filename = $LOGFILE{"UPDLOG"}."/".$YYMMDD; $filename =~ /(.*)/; $realfile = $1; # first let's log the updates send in or via stdin if (open(LOG, ">>$realfile")) { &lock(LOG); if ($opt_M) { print LOG "\n>>> MAIL UPDATE <<<\n\n"; } else { print LOG "\n>>> STDIN UPDATE <<<\n\n"; } open(TMP, "$TMPDIR/dbupdcopy.$$"); while () { print LOG; } close(TMP); close(LOG); &unlock(LOG); } else { &syslog("ERRLOG", "dbupdate cannot open $LOGFILE{\"UPDLOG\"}/$YYMMDD"); } # then we log the acknowledgement $filename = $LOGFILE{"ACKLOG"}."/".$YYMMDD; $filename =~ /(.*)/; $realfile = $1; if (open(LOG, ">>$realfile")) { &lock(LOG); if ($opt_M) { print LOG "\n>>> MAIL ACK <<<\n\n"; } else { print LOG "\n>>> STDIN ACK <<<\n\n"; } open(TMP, "$TMPDIR/dbupdack.$$"); while () { print LOG; } close(TMP); close(LOG); &unlock(LOG); } else { &syslog("ERRLOG", "dbupdate cannot open $LOGFILE{\"ACKLOG\"}/$YYMMDD"); } # remove the temp stuff we made unlink("$TMPDIR/dbtmp.$$"); unlink("$TMPDIR/dbupdcopy.$$"); unlink("$TMPDIR/dbupdack.$$"); # =========================================== # enparse - read RIPE database and check syntax errors # # $RCSfile: enparse.pl,v $ # $Revision: 1.7 $ # $Author: david $ # $Date: 1995/02/10 11:39:22 $ # # ARGUMENTS: filehandle to read from # RETURNS: INTEGER object_status # ASSOC object # # Object status = $O_OK, $O_WARNING, $O_ERROR, $EOF, or $NOK # $O_OK = object read and no errors/warnings generated # $O_WARNING = object read, but generated warnings # $O_ERROR = object read, but generated errors # $EOF = EndOfFile reached # $NOK = no object found, just garbage # # Object has warnings and errors included. # # This routine is a modified version of enread. It will read any # garbage, until it finds something of the form: # "xxxxxxx: " (no fixed length, spaces MUST be there) # or # "*xx: " # and then continues to read until it finds a line that does not # match these patterns. It then assumes it read an object, and will # start doing syntax checks. require "entype.pl"; require "syntax.pl"; require "defines.pl"; require "adderror.pl"; sub readsomething { local($file) = @_; local($inentry) = $NOK; local($tag) = ""; local(%entry) = (); while (<$file>) { s/^\s*//; s/\s*$//; s/\n*$//; next if /^#/; if (/^password:\s*(\S.*\S)/) { $PASSWORD = $1; next; } if (/^\*..:\s*(.*)/) { $inentry = $OK; $tag = substr($_, 1, 2); if ($entry{$tag}) { $entry{$tag} .= "\n"; } $entry{$tag} = $entry{$tag} . $1; next; } if (/^([a-z\-A-Z_]+)\s*:\s*(.*)/) { $inentry = $OK; $tag = $1; $tag =~ tr/A-Z/a-z/; $tag = $ATTR{$tag} if $ATTR{$tag}; if ($entry{$tag}) { $entry{$tag} .= "\n"; } $entry{$tag} = $entry{$tag} . "$2"; next; } if (/^.*$/) { next if $inentry == $NOK; $CUROBJTYPE = &entype(*entry); return ($inentry,%entry); } } $CUROBJTYPE = &entype(*entry); return ($inentry, %entry) if ($inentry); return $EOF; } sub checkobject { local(*object) = @_; local($type); local($rtcode) = $O_OK; local(%knownfield) = (); local(%mandfield) = (); local(%multfield) = (); local(%knownfield) = (); local(%guard) = (); local(%usefield) = (); local($i); print STDERR "checkobject - called\n" if $opt_V; $type = &entype(*object); if (!$type) { &adderror(*object, "unknown object type"); return $O_ERROR; } # Check guarded objects, should be authorised or maintained # The message will request the object be maintained foreach (keys %GRDOBJ) { if ($object{$_}) { if (!$object{"ua"} && !$object{"mb"}) { &adderror(*object, "the \"$ATTL{$_}\" object cannot be updated ". "automatically without a \"mnt-by\" attribute"); # now if this object was supposed to be deleted, remove # the delete attribute, since deletes will remove # syntax errors later in the program and this is one # that may not be removed. There is also no point in # doing more checks if it was supposed to be deleted. if ($object{"ud"}) { undef $object{"ud"}; return $O_ERROR; } # otherwise, continue extra checks for clarity to user $rtcode = $O_ERROR; } last; } } foreach $i ((split(/\s+/, $OBJATSQ{$type}),"ud","ua","uo","uw","ue")) { $knownfield{"$i"} = 1; } foreach $i (split(/\s+/, $OBJMAND{$type})) { $mandfield{"$i"} = 1; } foreach $i (split(/\s+/, $OBJMULT{$type})) { $multfield{"$i"} = 1; } foreach $i (split(/\s+/, $GRD{$type})) { $guard{"$i"} = 1; } foreach $i (keys %object) { $usefield{"$i"} = 1; } foreach (split(/\s+/, $OBS{$type})) { if ($object{$_}) { &addwarning(*object, "attribute \"$ATTL{$_}\" has been obsoleted,". " value removed from object"); delete $object{$_}; delete $usefield{$_}; $rtcode = $O_WARNING; } } foreach $i (keys %usefield) { if (!$knownfield{"$i"}) { if ($ATTL{"$i"}) { &adderror(*object, "attribute \"$ATTL{$i}\" unknown ". "in $ATTL{$type} object"); } else { &adderror(*object, "attribute \"$i\" unknown in $ATTL{$type} object"); } $rtcode = $O_ERROR; } undef $mandfield{"$i"} unless $object{$i} eq ""; if ($object{$i} =~ /\n/) { if (!$multfield{"$i"}) { &adderror(*object, "multiple lines not allowed for: \"$ATTL{$i}\""); $rtcode = $O_ERROR;; } } } foreach $i (keys %mandfield) { if ($mandfield{$i}) { if (defined($object{$i}) && ($object{$i} =~ /^\n*$/)) { &adderror(*object, "mandatory field \"$ATTL{$i}\" must have a value"); } else { &adderror(*object, "mandatory field \"$ATTL{$i}\" missing"); } $rtcode = $O_ERROR; } } print STDERR "checkobject - returned\n" if $opt_V; return $rtcode; } sub enparse { local($file) = @_; local(%entry); local($rtcode) = $O_OK; local($stat); local($hasdelete); print STDERR "enparse - reading something\n" if $opt_V; ($stat, %entry) = &readsomething($file); return $EOF if $stat == $EOF; return $NOK if $stat == $NOK; # Now, let's check whether this is a delete request or not # If it is, we have to skip all syntax checks ... # since syntax checks may change the object AND # one wants to be able to delete objects with wrong syntax # A wrongly defined delete attribute will return a 0, # and add a error message. if (!($hasdelete = &hasdelete(*entry))) { print STDERR "enparse - checking object format\n" if $opt_V; $rtcode = &checkobject(*entry); if ($rtcode == $O_OK) { print STDERR "enparse - checking object syntax\n" if $opt_V; $rtcode = &checksyntax(*entry); } } return $rtcode, $hasdelete, %entry; } 1; # =========================================== -------- Logged at Thu Feb 16 19:35:31 MET 1995 --------- From dsj at merit.edu Thu Feb 16 19:34:07 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 16 Feb 1995 13:34:07 -0500 Subject: [To: rradmin: prtraceroute question] Message-ID: <199502161834.NAA02675@home.merit.edu> Steve, Sorry I didn't get back to you on this. We've barely looked at prtraceroute at Merit, and the folks who worked on it at RIPE have moved on. David Kessens just started at RIPE three weeks ago to maintain and develop their code; perhaps he could have a look at this. ISI is also planning to do some upgrading to the prtools; they might also be able to help. You are correct that 198.7.0 is registered to AS2033: > fox.merit.edu% whois -h whois.ra.net 198.7.0.1 > route: 198.7.0.0/24 > descr: Public Access Networks Corporation > origin: AS2033 > remarks: na: ACCESS1 cy: US > remarks: *co: NSF > remarks: *rz: ns1.access.net ns2.access.net icm1.icp.net icm2.icp.net > remarks: *ny: hostmaster at panix.com > remarks: *ac: Alexis Rosen *ac: John A. Hawkinson *tc: John A. Hawkinson > mnt-by: MAINT-AS2033 > changed: jhawk at panix.com 940427 > source: RADB > > route: 198.7.0.0/24 > descr: Public Access Networks Corporation > descr: 110 Riverside Drive > descr: c/o Alexis Rosen > descr: New York > descr: NY 10024, USA > origin: AS2033 > withdrawn: 94/05/16 > comm-list: COMM_NSFNET > advisory: AS690 1:1800 2:1240 > mnt-by: MAINT-AS2033 > changed: nsfnet-admin at merit.edu 940516 > withdrawn: 94/05/16 > source: PRDB --Dale > From swinnett at BBN.COM Thu Feb 16 13:25:44 1995 > Date: Thu, 16 Feb 95 13:22:25 EST > From: Steven Winnett > To: rradmin at radb.ra.net > Subject: [To: rradmin: prtraceroute question] > > I am resending this message in case the original was omehow lost. > No harassment intended. Thank you. > > Steve Winnett > BBN > > ----- Forwarded message # 1: > > Date: Wed, 15 Feb 95 10:27:55 EST > From: Steven Winnett > To: rradmin at radb.ra.net > cc: swinnett at BBN.COM > Subject: prtraceroute question > > I am trying to run prtraceroute with the RA database. As a test, > I select the host ns1.access.net (198.7.0.1) which I see before me > in the RADB (which I ftp'd over). The database clearly says that > net 198.7.0.1/24 is in AS2033. So, why is it that the message is > returned, "Destination AS unknown for ns1.access.net (198.7.0.1)"? > > My command-line entry is > > prtraceroute -v -h radb.ra.net ns1.access.net > > Thank you for your assistance. > > Steve Winnett > BBN > > ----- End of forwarded messages > -------- Logged at Thu Feb 16 19:40:41 MET 1995 --------- From Tony.Bates at mci.net Thu Feb 16 19:38:53 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Thu, 16 Feb 1995 13:38:53 -0500 Subject: [To: rradmin: prtraceroute question] In-Reply-To: Your message of Thu, 16 Feb 1995 13:34:07 EST. <199502161834.NAA02675@home.merit.edu> Message-ID: <199502161838.NAA24268@lovefm.reston.mci.net> The old prtraceroute is not ripe-181 compatible. Pick up the new one from ftp.ripe.net:pride/tools --Tony. "Dale S. Johnson" writes: * Steve, * * Sorry I didn't get back to you on this. We've barely looked at * prtraceroute at Merit, and the folks who worked on it at RIPE have * moved on. David Kessens just started at RIPE three weeks ago to * maintain and develop their code; perhaps he could have a look at * this. ISI is also planning to do some upgrading to the prtools; they * might also be able to help. * * You are correct that 198.7.0 is registered to AS2033: * * > fox.merit.edu% whois -h whois.ra.net 198.7.0.1 * > route: 198.7.0.0/24 * > descr: Public Access Networks Corporation * > origin: AS2033 * > remarks: na: ACCESS1 cy: US * > remarks: *co: NSF * > remarks: *rz: ns1.access.net ns2.access.net icm1.icp.net icm2.icp.net * > remarks: *ny: hostmaster at panix.com * > remarks: *ac: Alexis Rosen *ac: John A. Hawkinson *tc: John A. Hawkin * son * > mnt-by: MAINT-AS2033 * > changed: jhawk at panix.com 940427 * > source: RADB * > * > route: 198.7.0.0/24 * > descr: Public Access Networks Corporation * > descr: 110 Riverside Drive * > descr: c/o Alexis Rosen * > descr: New York * > descr: NY 10024, USA * > origin: AS2033 * > withdrawn: 94/05/16 * > comm-list: COMM_NSFNET * > advisory: AS690 1:1800 2:1240 * > mnt-by: MAINT-AS2033 * > changed: nsfnet-admin at merit.edu 940516 * > withdrawn: 94/05/16 * > source: PRDB * * * --Dale * * * > From swinnett at BBN.COM Thu Feb 16 13:25:44 1995 * > Date: Thu, 16 Feb 95 13:22:25 EST * > From: Steven Winnett * > To: rradmin at radb.ra.net * > Subject: [To: rradmin: prtraceroute question] * > * > I am resending this message in case the original was omehow lost. * > No harassment intended. Thank you. * > * > Steve Winnett * > BBN * > * > ----- Forwarded message # 1: * > * > Date: Wed, 15 Feb 95 10:27:55 EST * > From: Steven Winnett * > To: rradmin at radb.ra.net * > cc: swinnett at BBN.COM * > Subject: prtraceroute question * > * > I am trying to run prtraceroute with the RA database. As a test, * > I select the host ns1.access.net (198.7.0.1) which I see before me * > in the RADB (which I ftp'd over). The database clearly says that * > net 198.7.0.1/24 is in AS2033. So, why is it that the message is * > returned, "Destination AS unknown for ns1.access.net (198.7.0.1)"? * > * > My command-line entry is * > * > prtraceroute -v -h radb.ra.net ns1.access.net * > * > Thank you for your assistance. * > * > Steve Winnett * > BBN * > * > ----- End of forwarded messages * > -------- Logged at Thu Feb 16 20:46:54 MET 1995 --------- From swinnett at BBN.COM Thu Feb 16 20:40:14 1995 From: swinnett at BBN.COM (Steven Winnett) Date: Thu, 16 Feb 95 14:40:14 EST Subject: [To: rradmin: prtraceroute question] Message-ID: <9502161946.AA07599@ncc.ripe.net> Tony, Which one should I take? I see: Aug 18 1994 prtraceroute-1.0.shar Nov 22 12;42 prtraceroute-2.0beta.shar.gz Nov 29 14:10 prtraceroute-2.0beta2.shar.gz Thanks for your help. Steve -------- Logged at Thu Feb 16 20:47:59 MET 1995 --------- From marten at wellfleet.com Thu Feb 16 20:46:39 1995 From: marten at wellfleet.com (Marten Terpstra) Date: Thu, 16 Feb 1995 14:46:39 -0500 Subject: [To: rradmin: prtraceroute question] In-Reply-To: Your message of Thu, 16 Feb 1995 14:40:14 EST. <9502161946.AA07599@ncc.ripe.net> Message-ID: <9502161946.AA09707@class.wellfleet> Steven Winnett writes * Tony, * * Which one should I take? I see: * * Aug 18 1994 prtraceroute-1.0.shar * Nov 22 12;42 prtraceroute-2.0beta.shar.gz * Nov 29 14:10 prtraceroute-2.0beta2.shar.gz The latest, 2.0beta2 -Marten -------- Logged at Mon Feb 27 09:59:21 MET 1995 --------- From Daniel.Karrenberg at ripe.net Mon Feb 27 09:59:18 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 27 Feb 1995 09:59:18 +0100 Subject: PRDB->RADB->configs In-Reply-To: Your message of Fri, 24 Feb 1995 14:42:34 EST. <199502241942.OAA00845@home.merit.edu> Message-ID: <9502270859.AA02844@ncc.ripe.net> > "Dale S. Johnson" writes: > Daniel, > > Curtis at ANS needs to look back at some rr-impl archives. Is there > a way to get at these? This is what we have at the moment: -rw-rw---- 1 dfk staff 85781 Feb 27 09:50 940215-940217 -rw-rw---- 1 dfk staff 87799 Feb 27 09:50 940217-940223 -rw-rw---- 1 dfk staff 88642 Feb 27 09:50 940223-940311 -rw-rw---- 1 dfk staff 86110 Feb 27 09:50 940311-940406 -rw-rw---- 1 dfk staff 87037 Feb 27 09:50 940406-940427 -rw-rw---- 1 dfk staff 85569 Feb 27 09:50 940427-940503 -rw-rw---- 1 dfk staff 156389 Feb 27 09:50 940503-940524 -rw-rw---- 1 dfk staff 87588 Feb 27 09:50 940524-940620 -rw-rw---- 1 dfk staff 126870 Feb 27 09:50 940623-940712 -rw-rw---- 1 dfk staff 121640 Feb 27 09:50 940712-940712 -rw-rw---- 1 dfk staff 88424 Feb 27 09:50 940713-940719 -rw-rw---- 1 dfk staff 146501 Feb 27 09:50 940719-940721 -rw-rw---- 1 dfk staff 164772 Feb 27 09:50 940721-940804 -rw-rw---- 1 dfk staff 123809 Feb 27 09:50 940804-940822 -rw-rw---- 1 dfk staff 89333 Feb 27 09:50 940823-940907 -rw-rw---- 1 dfk staff 86909 Feb 27 09:50 940907-940919 -rw-rw---- 1 dfk staff 90038 Feb 27 09:50 940920-941004 -rw-rw---- 1 dfk staff 85481 Feb 27 09:50 941004-941013 -rw-rw---- 1 dfk staff 86031 Feb 27 09:50 941013-941021 -rw-rw---- 1 dfk staff 85322 Feb 27 09:50 941021-941116 -rw-rw---- 1 dfk staff 124323 Feb 27 09:50 941116-941117 -rw-rw---- 1 dfk staff 91431 Feb 27 09:50 941117-941206 -rw-rw---- 1 dfk staff 86370 Feb 27 09:50 941206-941221 -rw-rw---- 1 dfk staff 100737 Feb 27 09:50 941221-950105 -rw-rw---- 1 dfk staff 86981 Feb 27 09:50 950106-950127 -rw-rw---- 1 dfk staff 77583 Feb 27 09:50 950130-950216 It is not up for public ftp. If the lsit at large has no problems with that, we can just make it available in our public archives. Otherwise ncc at ripe.net will be happy to mail you selected ones or put them up in a non-public FTP area. Daniel -------- Logged at Mon Feb 27 19:41:09 MET 1995 --------- From cengiz at ISI.EDU Mon Feb 27 19:40:41 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 27 Feb 1995 10:40:41 -0800 Subject: RtConfig version 1.0 Message-ID: <199502271840.AA24827@cat.isi.edu> Hi, A new version of RtConfig is available at ftp.ra.net:pub/tools/RAToolSet. Bug reports/fixes and suggestions are welcome as usual. The next version will enable AS-path based filters. Thanks for all those who provided feedback. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Mon Feb 27 19:47:49 MET 1995 --------- From cengiz at ISI.EDU Mon Feb 27 19:47:24 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 27 Feb 1995 10:47:24 -0800 Subject: Routing Policy System Working Group Message-ID: <199502271847.AA24842@cat.isi.edu> Hi, Here is the charter for the rps wg. There will be a BOF in Danvers. Hope to see you all there. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California Charter: The Routing Policy System Working Group will (1) define a language, referred to as Routing Policy Specification Language (RPSL), for specifying routing policy constraints; (2) define a distributed database model for registering routing policy constraints; and (3) define a set of tools for analysing registered policy constraints for global consistency, for generating router configurations, and for diagnosing operational routing problems. It is expected that RPSL will enter the standards track. The RPSL will be routing protocol independent as well as router configuration format independent to support various routing protocols such as BGP, IDRP, SDRP, and various router technologies. The RPSL will be backward compatible with RIPE-181 whenever possible; the database model will be based on the RIPE database; and RIPE pride tools will be upgraded to support RPSL as an initial set of tools. The working group will also instigate, review, or (if appropriate) produce additional RFCs to support other protocols such as multicasting and resource reservation. Goals and Milestones: Apr 95: BOF to discuss scope of work and WG creation May 95: Publish initial draft specification of RPSL Jun 95: Publish draft specification of tools and the database model Jul 95: First WG meeting Aug 95: Publish second draft specifications Begin collecting implementation experience for Standards track RFCs Dec 95: Second WG meeting Publish RPSL and Experiences RFC Jan 96: Submit RFCs for proposed standard -------- Logged at Mon Feb 27 20:28:11 MET 1995 --------- From Tony.Bates at mci.net Mon Feb 27 20:28:05 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Mon, 27 Feb 1995 14:28:05 -0500 Subject: Routing Policy System Working Group In-Reply-To: Your message of Mon, 27 Feb 1995 10:47:24 PST. <199502271847.AA24842@cat.isi.edu> Message-ID: <199502271928.OAA00759@lovefm.reston.mci.net> Seems good to me. We clearly need to get RIPE181 out as an info RFC as agreed to set some context for this group. I was sort of waiting on Daniel to get his part done but will try to do this this week and get this off to the rfc-editor. --Tony. cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: * * Hi, * * Here is the charter for the rps wg. There will be a BOF in * Danvers. Hope to see you all there. * * Cengiz * * -- * Cengiz Alaettinoglu Information Sciences Institute * (310) 822-1511 University of Southern California * * Charter: * * The Routing Policy System Working Group * will * (1) define a language, * referred to as Routing Policy Specification Language (RPSL), * for specifying routing policy constraints; * (2) define a distributed database model * for registering routing policy constraints; * and (3) define a set of tools * for analysing registered policy constraints for global consistency, * for generating router configurations, * and for diagnosing operational routing problems. * It is expected that RPSL will enter the standards track. * * The RPSL will be routing protocol independent * as well as * router configuration format independent * to support various routing protocols such as BGP, IDRP, SDRP, * and various router technologies. * The RPSL will be backward compatible with RIPE-181 whenever possible; * the database model will be based on the RIPE database; * and RIPE pride tools will be upgraded to support RPSL * as an initial set of tools. * * The working group will also instigate, review, or (if appropriate) * produce additional RFCs * to support other protocols such as multicasting and resource reservation. * * Goals and Milestones: * * Apr 95: BOF to discuss scope of work and WG creation * * May 95: Publish initial draft specification of RPSL * * Jun 95: Publish draft specification of tools and the database model * * Jul 95: First WG meeting * * Aug 95: Publish second draft specifications * Begin collecting implementation experience for Standards track RFC * s * * Dec 95: Second WG meeting * Publish RPSL and Experiences RFC * * Jan 96: Submit RFCs for proposed standard * -------- Logged at Mon Feb 27 23:37:46 MET 1995 --------- From dsj at merit.edu Mon Feb 27 23:37:42 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 27 Feb 1995 17:37:42 -0500 Subject: PRDB->RADB->configs Message-ID: <199502272237.RAA04306@home.merit.edu> Daniel, I don't think there is anything horrific in there that the world couldn't see. (Hopefully no code secrets showed up there). There is a larger question related to this: the RIPE software is enjoying considerable success and distribution. Should the rr-impl list be open to anyone installing RIPE software? ANS is seriously considering running its own registry. DSI (Milnet) will, too. One of ANS's smaller customers is, also. Should they all be allowed into rr-impl? I think probably so. --Dale > From dfk at ripe.net Mon Feb 27 04:00:00 1995 > To: "Dale S. Johnson" > Cc: cengiz at isi.edu, curtis at ans.net, epg at home.merit.edu, heimlich at ans.net, > jyy at home.merit.edu, sjr at home.merit.edu, > Subject: Re: PRDB->RADB->configs > Date: Mon, 27 Feb 1995 09:59:18 +0100 > > > > "Dale S. Johnson" writes: > > Daniel, > > > > Curtis at ANS needs to look back at some rr-impl archives. Is there > > a way to get at these? > > > This is what we have at the moment: > > -rw-rw---- 1 dfk staff 85781 Feb 27 09:50 940215-940217 > -rw-rw---- 1 dfk staff 87799 Feb 27 09:50 940217-940223 > -rw-rw---- 1 dfk staff 88642 Feb 27 09:50 940223-940311 > -rw-rw---- 1 dfk staff 86110 Feb 27 09:50 940311-940406 > -rw-rw---- 1 dfk staff 87037 Feb 27 09:50 940406-940427 > -rw-rw---- 1 dfk staff 85569 Feb 27 09:50 940427-940503 > -rw-rw---- 1 dfk staff 156389 Feb 27 09:50 940503-940524 > -rw-rw---- 1 dfk staff 87588 Feb 27 09:50 940524-940620 > -rw-rw---- 1 dfk staff 126870 Feb 27 09:50 940623-940712 > -rw-rw---- 1 dfk staff 121640 Feb 27 09:50 940712-940712 > -rw-rw---- 1 dfk staff 88424 Feb 27 09:50 940713-940719 > -rw-rw---- 1 dfk staff 146501 Feb 27 09:50 940719-940721 > -rw-rw---- 1 dfk staff 164772 Feb 27 09:50 940721-940804 > -rw-rw---- 1 dfk staff 123809 Feb 27 09:50 940804-940822 > -rw-rw---- 1 dfk staff 89333 Feb 27 09:50 940823-940907 > -rw-rw---- 1 dfk staff 86909 Feb 27 09:50 940907-940919 > -rw-rw---- 1 dfk staff 90038 Feb 27 09:50 940920-941004 > -rw-rw---- 1 dfk staff 85481 Feb 27 09:50 941004-941013 > -rw-rw---- 1 dfk staff 86031 Feb 27 09:50 941013-941021 > -rw-rw---- 1 dfk staff 85322 Feb 27 09:50 941021-941116 > -rw-rw---- 1 dfk staff 124323 Feb 27 09:50 941116-941117 > -rw-rw---- 1 dfk staff 91431 Feb 27 09:50 941117-941206 > -rw-rw---- 1 dfk staff 86370 Feb 27 09:50 941206-941221 > -rw-rw---- 1 dfk staff 100737 Feb 27 09:50 941221-950105 > -rw-rw---- 1 dfk staff 86981 Feb 27 09:50 950106-950127 > -rw-rw---- 1 dfk staff 77583 Feb 27 09:50 950130-950216 > > > It is not up for public ftp. If the lsit at large has no problems > with that, we can just make it available in our public archives. > Otherwise ncc at ripe.net will be happy to mail you selected ones > or put them up in a non-public FTP area. > > Daniel > > -------- Logged at Tue Feb 28 05:50:22 MET 1995 --------- From curtis at ans.net Tue Feb 28 05:27:28 1995 From: curtis at ans.net (Curtis Villamizar) Date: Mon, 27 Feb 1995 23:27:28 -0500 Subject: PRDB->RADB->configs In-Reply-To: Your message of "Mon, 27 Feb 1995 09:59:18 +0100." <9502270859.AA02844@ncc.ripe.net> Message-ID: <199502280427.XAA00700@curtis.ansremote.com> In message <9502270859.AA02844 at ncc.ripe.net>, Daniel Karrenberg writes: > > > It is not up for public ftp. If the lsit at large has no problems > with that, we can just make it available in our public archives. > Otherwise ncc at ripe.net will be happy to mail you selected ones > or put them up in a non-public FTP area. > > Daniel This was over a difference in interpretation of the as-in and interas-in between you and Cengiz that Dale refered to. According to Cengiz the mail was: Around september and october of 94 subjects Implementation of RIPE-181++ as-in/out interas-in/out recommendation Ripe 181 If you can just summarize the result, that would be fine. I didn't see that ripe-181 was ambiguous, and rather than fill me in on the ambiguity and indicating how it was resolved, Dale and Cengiz pointed me at the mail archives. It is obviously too way complicated an issue for Merit folks to simply explain the issue and it's resolution. :-) So if you would be so kind as to do so it would save me dredging the mail archives, which I'm not looking forward to doing. Curtis -------- Logged at Tue Feb 28 10:33:03 MET 1995 --------- From Daniel.Karrenberg at ripe.net Tue Feb 28 10:33:01 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 28 Feb 1995 10:33:01 +0100 Subject: PRDB->RADB->configs In-Reply-To: Your message of Mon, 27 Feb 1995 17:37:42 EST. <199502272237.RAA04306@home.merit.edu> Message-ID: <9502280933.AA05174@ncc.ripe.net> Unless people disagree violently I will implement the following later this week: The rr-impl list is open to anyone implementing an Internet routing registry. Its archives are available by anonymous FTP from ftp://ftp.ripe.net/ripe/archives/rr-impl. Daniel > "Dale S. Johnson" writes: > Daniel, > > I don't think there is anything horrific in there that the world couldn't > see. (Hopefully no code secrets showed up there). > > There is a larger question related to this: the RIPE software is enjoying > considerable success and distribution. Should the rr-impl list be open > to anyone installing RIPE software? ANS is seriously considering running > its own registry. DSI (Milnet) will, too. One of ANS's smaller customers > is, also. Should they all be allowed into rr-impl? I think probably so. > > --Dale -------- Logged at Tue Feb 28 15:33:52 MET 1995 --------- From Daniel.Karrenberg at ripe.net Tue Feb 28 15:33:51 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 28 Feb 1995 15:33:51 +0100 Subject: Routing Policy System Working Group In-Reply-To: Your message of Mon, 27 Feb 1995 10:47:24 PST. <199502271847.AA24842@cat.isi.edu> Message-ID: <9502281433.AA07861@ncc.ripe.net> > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > The Routing Policy System Working Group > will > (1) define a language, > referred to as Routing Policy Specification Language (RPSL), > for specifying routing policy constraints; s/specifying/describing/ s/constraints// > (2) define a distributed database model > for registering routing policy constraints; define a simple and robust distributed registry for publishing routing policies (do not wake sleeping dogs by calling it distributed database!) > and (3) define a set of tools > for analysing registered policy constraints , > for global consistency, for checking global consistency > for generating router configurations, > and for diagnosing operational routing problems. and ... > It is expected that RPSL will enter the standards track. > > The RPSL will be routing protocol independent > as well as > router configuration format independent > to support various routing protocols such as BGP, IDRP, SDRP, > and various router technologies. > The RPSL will be backward compatible with RIPE-181 whenever possible; > the database model will be based on the RIPE database; registry > and RIPE pride tools will be upgraded to support RPSL > as an initial set of tools. out of scope! > The working group will also instigate, review, or (if appropriate) > produce additional RFCs > to support other protocols such as multicasting and resource reservation. > > Goals and Milestones: > > Apr 95: BOF to discuss scope of work and WG creation > > May 95: Publish initial draft specification of RPSL Do you have it written NOW? > Jun 95: Publish draft specification of tools and the database model > > Jul 95: First WG meeting > > Aug 95: Publish second draft specifications > Begin collecting implementation experience for Standards track RFC > s > > Dec 95: Second WG meeting > Publish RPSL and Experiences RFC > > Jan 96: Submit RFCs for proposed standard -------- Logged at Tue Feb 28 15:55:15 MET 1995 --------- From dsj at merit.edu Tue Feb 28 15:49:52 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 28 Feb 1995 09:49:52 -0500 Subject: Special ftp access for IRR? Message-ID: <199502281449.JAA25299@home.merit.edu> All, We've been getting ftps of the RIPE.db failing this week because of the limit on maximum users. Presumably, this problem will get worse rather than better as the registries become more popular, and not only RIPE will have the problem. Should we consider setting up secondary ftp ports for IRR members to use to exchange their data? --Dale > Your "cron" job > > /ra/crons/import.ripe 2>&1 | tee /ra/crons/import.ripe.log | /ra/crons/err_if '***' > > produced the following output: > > > 95-02-28 03:22 /ra/crons/import.ripe getting the new ripe.db... > ****** /ra/crons/import.ripe FTP ERROR: (Tue Feb 28 03:22:18 EST 1995) > > Sorry, there are too many users at this time (25 maximum). > Please try again later. > > User anonymous access denied. > Login failed. > Not connected. -------- Logged at Tue Feb 28 16:18:58 MET 1995 --------- From bmanning at ISI.EDU Tue Feb 28 16:17:58 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 28 Feb 1995 07:17:58 -0800 (PST) Subject: Special ftp access for IRR? In-Reply-To: <199502281449.JAA25299@home.merit.edu> from "Dale S. Johnson" at Feb 28, 95 09:49:52 am Message-ID: <199502281517.AA03687@zed.isi.edu> Dale, This begs the larger question that remained unanswered from the mtg in San Jose of reliable database replication. As I remember it, we agreed to default to use FTP to copy the various .db around for the first year as an interim step. I beleive that Daniel indicated that this should be sufficent for the near term, even though we would have to come up with something else later. I point out that "stock FTP" seems to not fit the growth curve and we do need to do something soon. Perhaps we might utilize something like SUP or Harvest as the model. This would free up FTP for "normal" use and we could move to something that might last a bit longer before we need to retro-fit one more time. (This particular problem is listed in the proposed RPS charter) > > All, > > We've been getting ftps of the RIPE.db failing this week because of the > limit on maximum users. Presumably, this problem will get worse rather > than better as the registries become more popular, and not only RIPE will > have the problem. > > Should we consider setting up secondary ftp ports for IRR members to > use to exchange their data? > > --Dale > > > Your "cron" job > > > > /ra/crons/import.ripe 2>&1 | tee /ra/crons/import.ripe.log | /ra/crons/err_if '***' > > > > produced the following output: > > > > > > 95-02-28 03:22 /ra/crons/import.ripe getting the new ripe.db... > > ****** /ra/crons/import.ripe FTP ERROR: (Tue Feb 28 03:22:18 EST 1995) > > > > Sorry, there are too many users at this time (25 maximum). > > Please try again later. > > > > User anonymous access denied. > > Login failed. > > Not connected. > -- --bill -------- Logged at Tue Feb 28 16:22:48 MET 1995 --------- From GeertJan.deGroot at ripe.net Tue Feb 28 16:22:47 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Tue, 28 Feb 1995 16:22:47 +0100 Subject: Special ftp access for IRR? In-Reply-To: Your message of "Tue, 28 Feb 1995 09:49:52 EST." <199502281449.JAA25299@home.merit.edu> Message-ID: <9502281522.AA08326@ncc.ripe.net> On Tue, 28 Feb 1995 09:49:52 -0500 "Dale S. Johnson" wrote: > We've been getting ftps of the RIPE.db failing this week because of the > limit on maximum users. Presumably, this problem will get worse rather > than better as the registries become more popular, and not only RIPE will > have the problem. > > Should we consider setting up secondary ftp ports for IRR members to > use to exchange their data? Dale, Apperently a new TCP/IP stack has been launched recently. I saw *a lot* of aborted FTP transfers (still data in the transmit queue), and these have not timed out for some reason :-(. I rebooted the box, upped the limit to 100, and will monitor the box more closely. It should be replaced by some other machine RSN, but that involves some other work for which I don't have time now (basically rebuilding the info server). Please complain to if you see this again. I can make another box available if need be, but I first want to see if the problem is persistent. Thanks, Geert Jan -------- Logged at Tue Feb 28 16:40:10 MET 1995 --------- From Daniel.Karrenberg at ripe.net Tue Feb 28 16:40:08 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 28 Feb 1995 16:40:08 +0100 Subject: Special ftp access for IRR? In-Reply-To: Your message of Tue, 28 Feb 1995 09:49:52 EST. <199502281449.JAA25299@home.merit.edu> Message-ID: <9502281540.AA08489@ncc.ripe.net> > "Dale S. Johnson" writes: > Should we consider setting up secondary ftp ports for IRR members to > use to exchange their data? This seems to be a bug somewhere rhather than popularity. So it is a non problem. We will also exempt other IRR's machines from the limit on request. Daniel -------- Logged at Tue Feb 28 16:53:28 MET 1995 --------- From Daniel.Karrenberg at ripe.net Tue Feb 28 16:53:26 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 28 Feb 1995 16:53:26 +0100 Subject: Special ftp access for IRR? In-Reply-To: Your message of Tue, 28 Feb 1995 07:17:58 PST. <199502281517.AA03687@zed.isi.edu> Message-ID: <9502281553.AA08596@ncc.ripe.net> The medium term soloution as discussed in San Jose: Update arrives. If not the proper server, forward it there. Check local authorisation syntax etc. If OK: Process locally. Make local notifications. Make a record of the following atomic operations. append object replace object (same as append) delete object Add serial number. Store in file. File are closed at specific intervals and named to something reflecting the serials or time contained. Files will be available by FTP. Files can be sent by other means (mail etc) at specific intervals on request. This is easy to implement? Design bugs? -------- Logged at Tue Feb 28 17:05:36 MET 1995 --------- From bmanning at ISI.EDU Tue Feb 28 17:04:05 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 28 Feb 1995 08:04:05 -0800 (PST) Subject: Special ftp access for IRR? In-Reply-To: <9502281553.AA08596@ncc.ripe.net> from "Daniel Karrenberg" at Feb 28, 95 04:53:26 pm Message-ID: <199502281604.AA03737@zed.isi.edu> > > The medium term soloution as discussed in San Jose: > > Update arrives. > > If not the proper server, forward it there. > > Check local authorisation syntax etc. > > If OK: > > Process locally. > > Make local notifications. > > Make a record of the following atomic operations. > > append object > replace object (same as append) > delete object > > Add serial number. > > Store in file. > > File are closed at specific intervals and named > to something reflecting the serials or time contained. > > Files will be available by FTP. > > Files can be sent by other means (mail etc) at specific > intervals on request. > > > This is easy to implement? Mostly, except for the last two items... :) > > Design bugs? > Scaleability? Human intervention? Except for the last two, this sounds alot like the DNS update sequence. The ability to "notify" those who might run a backup service for you and to automatically send the updates would rest my worried mind. Not that what I care about matters of course. --bill -------- Logged at Tue Feb 28 17:13:40 MET 1995 --------- From bmanning at ISI.EDU Tue Feb 28 17:11:07 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 28 Feb 1995 08:11:07 -0800 (PST) Subject: Special ftp access for IRR? In-Reply-To: <9502281553.AA08596@ncc.ripe.net> from "Daniel Karrenberg" at Feb 28, 95 04:53:26 pm Message-ID: <199502281611.AA03763@zed.isi.edu> > > The medium term soloution as discussed in San Jose: > > Update arrives. > > If not the proper server, forward it there. > Oh yeah, I forgot this one too. There is the small problem in the US where people are being asked to register in multiple .db's since they have several connections and the various providers can't or won't trust the "other guy". MCI has the policy that you must register in their .db. It will be interesting to see how this plays when/if MCI enters the Euro market. Then their clients will need to register in the RIPE.db and the MCI.db, just they way they are asked to in the US. The point being that folks can and will register in multiple .db's. This seems to indicate that a bit more thought will need to be expended on the first steps as indicated above. --bill -------- Logged at Tue Feb 28 17:26:17 MET 1995 --------- From Tony.Bates at mci.net Tue Feb 28 17:26:08 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Tue, 28 Feb 1995 11:26:08 -0500 Subject: Special ftp access for IRR? In-Reply-To: Your message of Tue, 28 Feb 1995 08:11:07 PST. <199502281611.AA03763@zed.isi.edu> Message-ID: <199502281626.LAA17897@ns.mci.net> bmanning at ISI.EDU writes: * > * > The medium term soloution as discussed in San Jose: * > * > Update arrives. * > * > If not the proper server, forward it there. * > * Oh yeah, I forgot this one too. There is the small problem in the US where * people are being asked to register in multiple .db's since they have * several connections and the various providers can't or won't trust the * "other guy". MCI has the policy that you must register in their .db. * It will be interesting to see how this plays when/if MCI enters the Euro * market. Then their clients will need to register in the RIPE.db and the * MCI.db, just they way they are asked to in the US. * One should be careful when stating other companies policies. MCI went this way (the way of NSF I might add) becuase the RADB was not ready and still isn't in the sense that there is little information in there. It is also not accurate as we accept CA*NETs data directly. The question is not trust but having useful information that allows you to configure the net, the RADB doesn't have this. On the general issue of dfk solution, I do not believe forwarding updates around scales at all and also from a service aspect places a reliance on others to do the right thing which right now is probably not such a god idea unless we get strong agreement on authority of data. This get harder as more RRs come into play. The actual data maintenance of the files is fine though providing it can be automated and can have the needed notification of change built in. --Tony. -------- Logged at Tue Feb 28 17:35:17 MET 1995 --------- From bmanning at ISI.EDU Tue Feb 28 17:33:25 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 28 Feb 1995 08:33:25 -0800 (PST) Subject: Special ftp access for IRR? In-Reply-To: <199502281626.LAA17897@ns.mci.net> from "Tony Bates" at Feb 28, 95 11:26:08 am Message-ID: <199502281633.AA03798@zed.isi.edu> > > * people are being asked to register in multiple .db's since they have > * several connections and the various providers can't or won't trust the > * "other guy". MCI has the policy that you must register in their .db. > * It will be interesting to see how this plays when/if MCI enters the Euro > * market. Then their clients will need to register in the RIPE.db and the > * MCI.db, just they way they are asked to in the US. > * > One should be careful when stating other companies policies. I'm only quoting a note from MCI. If you'd like, I'll forward the note to this list. This specific implementation is not germain to this list other than as an example of the need to support registration in multiple databases. > On the general issue of dfk solution, I do not believe forwarding updates > around scales at all and also from a service aspect places a reliance on others > to do the right thing which right now is probably not such a god idea unless > we get strong agreement on authority of data. This get harder as more RRs > come into play. In total agreement here. > The actual data maintenance of the files is fine though providing it can be > automated and can have the needed notification of change built in. Yup, this too. > --Tony. --bill -------- Logged at Tue Feb 28 18:31:18 MET 1995 --------- From Daniel.Karrenberg at ripe.net Tue Feb 28 18:31:16 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 28 Feb 1995 18:31:16 +0100 Subject: Special ftp access for IRR? In-Reply-To: Your message of Tue, 28 Feb 1995 08:04:05 PST. <199502281604.AA03737@zed.isi.edu> Message-ID: <9502281731.AA09281@ncc.ripe.net> > bmanning at ISI.EDU writes: > > > > The medium term soloution as discussed in San Jose: > > > > Update arrives. > > > > If not the proper server, forward it there. > > > > Check local authorisation syntax etc. > > > > If OK: > > > > Process locally. > > > > Make local notifications. > > > > Make a record of the following atomic operations. > > > > append object > > replace object (same as append) > > delete object > > > > Add serial number. > > > > Store in file. > > > > File are closed at specific intervals and named > > to something reflecting the serials or time contained. > > > > Files will be available by FTP. > > > > Files can be sent by other means (mail etc) at specific > > intervals on request. > > > > > > This is easy to implement? > > Mostly, except for the last two items... :) > > > > > Design bugs? > > > Scaleability? 10s of mirror sites order of 10,000 atomic operations/day > Human intervention? Not necessary. > Except for the last two, this sounds a lot like the DNS update sequence. Yes you can keep the current serial number available by -say- whois ;-) > The ability to "notify" those who might run > a backup service for you and to automatically send the updates would rest > my worried mind. The idea is to send them automatically by whatever means and have the FTPable trails there for recovery if needed. > Not that what I care about matters of course. ???? -------- Logged at Tue Feb 28 19:24:43 MET 1995 --------- From cengiz at ISI.EDU Tue Feb 28 19:24:13 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 28 Feb 1995 10:24:13 -0800 Subject: PRDB->RADB->configs In-Reply-To: <199502280427.XAA00700@curtis.ansremote.com> References: <9502270859.AA02844@ncc.ripe.net> <199502280427.XAA00700@curtis.ansremote.com> Message-ID: <199502281824.AA26843@cat.isi.edu> Curtis Villamizar (curtis at ans.net) on February 27: > > In message <9502270859.AA02844 at ncc.ripe.net>, Daniel Karrenberg writes: > > > > > > It is not up for public ftp. If the lsit at large has no problems > > with that, we can just make it available in our public archives. > > Otherwise ncc at ripe.net will be happy to mail you selected ones > > or put them up in a non-public FTP area. > > > > Daniel > > > This was over a difference in interpretation of the as-in and > interas-in between you and Cengiz that Dale refered to. According to > Cengiz the mail was: > > Around september and october of 94 > subjects > Implementation of RIPE-181++ > as-in/out interas-in/out recommendation > Ripe 181 Daniel, I am refering to the article where you have clarified the as-in interas-in interaction. This is the article with your algorithm to obtain preferences, and few others following that one. Perhaps also the article with the algorithm that I revised from yours. I wanted Curtis to see this article, because he had an example where *from the example* it was clear that he did not understand the interaction. Later, he clarified that his example was incomplete. > > If you can just summarize the result, that would be fine. I didn't > see that ripe-181 was ambiguous, and rather than fill me in on the > ambiguity and indicating how it was resolved, Dale and Cengiz pointed > me at the mail archives. Ripe 181 has ambiguities, but as-in/interas-in interaction is not one of them, thanks to Daniel (and me for poking for it). Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Tue Feb 28 20:02:53 MET 1995 --------- From cengiz at ISI.EDU Tue Feb 28 20:02:21 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 28 Feb 1995 11:02:21 -0800 Subject: Special ftp access for IRR? In-Reply-To: <9502281553.AA08596@ncc.ripe.net> References: <199502281517.AA03687@zed.isi.edu> <9502281553.AA08596@ncc.ripe.net> Message-ID: <199502281902.AA26904@cat.isi.edu> Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on February 28: > > > The medium term soloution as discussed in San Jose: > > Update arrives. > > If not the proper server, forward it there. > > Check local authorisation syntax etc. > > If OK: > > Process locally. > > Make local notifications. > > Make a record of the following atomic operations. > > append object > replace object (same as append) > delete object > > Add serial number. > > Store in file. > > File are closed at specific intervals and named > to something reflecting the serials or time contained. > > Files will be available by FTP. > > Files can be sent by other means (mail etc) at specific > intervals on request. > > > This is easy to implement? > > Design bugs? I like it. Hence people can only ftp the changes (i.e. diffs) as opposed to whole database. This saves them a lot in re-indexing. We also aggreed to keep a file which includes the diffs up to the current time. So if one wants a copy of the ripe database as current as possible, he would get this diff. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Tue Feb 28 20:07:27 MET 1995 --------- From cengiz at ISI.EDU Tue Feb 28 20:07:04 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 28 Feb 1995 11:07:04 -0800 Subject: Special ftp access for IRR? In-Reply-To: <199502281611.AA03763@zed.isi.edu> References: <9502281553.AA08596@ncc.ripe.net> <199502281611.AA03763@zed.isi.edu> Message-ID: <199502281907.AA26912@cat.isi.edu> bmanning at isi.edu (bmanning at isi.edu) on February 28: > > > > The medium term soloution as discussed in San Jose: > > > > Update arrives. > > > > If not the proper server, forward it there. > > > Oh yeah, I forgot this one too. There is the small problem in the US where > people are being asked to register in multiple .db's since they have > several connections and the various providers can't or won't trust the > "other guy". MCI has the policy that you must register in their .db. > It will be interesting to see how this plays when/if MCI enters the Euro > market. Then their clients will need to register in the RIPE.db and the > MCI.db, just they way they are asked to in the US. > > The point being that folks can and will register in multiple .db's. This > seems to indicate that a bit more thought will need to be expended on the > first steps as indicated above. > > --bill I think this is orthogonal to what daniel suggests. I.e. one can still register AS1 in ripe.db and radb.db in Daniel's model. However, if radb gets a request from AS1 to update the copy in ripe.db, it should 1) forward it to ripe for processing 2) return the user a message to submit the request to ripe. I think we should do 2. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Tue Feb 28 20:58:37 MET 1995 --------- From bmanning at ISI.EDU Tue Feb 28 20:57:33 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 28 Feb 1995 11:57:33 -0800 (PST) Subject: Special ftp access for IRR? In-Reply-To: <199502281907.AA26912@cat.isi.edu> from "Cengiz Alaettinoglu" at Feb 28, 95 11:07:04 am Message-ID: <199502281957.AA04129@zed.isi.edu> > > > The point being that folks can and will register in multiple .db's. This > > seems to indicate that a bit more thought will need to be expended on the > > first steps as indicated above. > > > > --bill > > I think this is orthogonal to what daniel suggests. I.e. one can still > register AS1 in ripe.db and radb.db in Daniel's model. However, if > radb gets a request from AS1 to update the copy in ripe.db, it should > 1) forward it to ripe for processing > 2) return the user a message to submit the request to ripe. > > I think we should do 2. > > Cengiz > Two is fine, although I think that it should be automatic. This is only half the problem. When collecting these dbs for evaluating policy expression, there is the possibility that different policies are registered in different dbs. There is the current method of first-in, which is fraught with difficulty. We need a way to allow those that register to express preference. Eric Carroll and I worked up a method at NANOG to allow the signing of database objects. This places a larger workload on the db manager(s) who parse more than one db to search for duplicates and then prefer signed ones. Anyone care to see a more fleashed out version of this? -- --bill -------- Logged at Tue Feb 28 22:54:22 MET 1995 --------- From cengiz at ISI.EDU Tue Feb 28 22:53:55 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 28 Feb 1995 13:53:55 -0800 Subject: Routing Policy System Working Group In-Reply-To: <9502281433.AA07861@ncc.ripe.net> References: <199502271847.AA24842@cat.isi.edu> <9502281433.AA07861@ncc.ripe.net> Message-ID: <199502282153.AA27139@cat.isi.edu> Thank you for the feedback. I have incorporated almost all your suggestions and included the new charter below. Few questions: Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on February 28: > > and RIPE pride tools will be upgraded to support RPSL > > as an initial set of tools. > out of scope! Do you mean that the generating tools is out of scope, or upgrading pride tools? Even if we do not build tools as a part of the wg effort, we should still discuss what tools will be of use to the community and try to come up with definitions for them so that anyone can implement. > > > The working group will also instigate, review, or (if appropriate) > > produce additional RFCs > > to support other protocols such as multicasting and resource reservation. > > > > Goals and Milestones: > > > > Apr 95: BOF to discuss scope of work and WG creation > > > > May 95: Publish initial draft specification of RPSL > > Do you have it written NOW? No. I have changed this date to Jun. This is only initial draft for us to shoot at. Charter: The Routing Policy System Working Group will (1) define a language, referred to as Routing Policy Specification Language (RPSL), for describing routing policy constraints; (2) define a simple and robust distributed registry model for publishing routing policy constraints; and (3) define a set of tools for analysing registered policy constraints, for checking global consistency, for generating router configurations, and for diagnosing operational routing problems. It is expected that RPSL will enter the standards track. The RPSL will be routing protocol independent as well as router configuration format independent to support various routing protocols such as BGP, IDRP, SDRP, and various router technologies. The RPSL will be backward compatible with RIPE-181 whenever possible; the database model will be based on the RIPE registry; and RIPE pride tools will be upgraded to support RPSL as an initial set of tools. The working group will also instigate, review, or (if appropriate) produce additional RFCs to support other protocols such as multicasting and resource reservation. Goals and Milestones: Apr 95: BOF to discuss scope of work and WG creation Jun 95: Publish initial draft specification of RPSL Jul 95: Publish draft specification of tools and the database model Jul 95: First WG meeting Aug 95: Publish second draft specifications Begin collecting implementation experience for Standards track RFCs Dec 95: Second WG meeting Publish RPSL and Experiences RFC Jan 96: Submit RFCs for proposed standard Administrative Structure: Chair(s): Cengiz Alaettinoglu Another co-chair TBA Document Editor(s): Cengiz Alaettinoglu Internet Area Director(s) Mike O'Dell Area Advisor Mike O'Dell Mailing lists: General Discussion: rps at isi.edu To Subscribe: rps-request at isi.edu Archive: ftp.isi.edu:/pub/rps Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Wed Mar 1 09:37:12 MET 1995 ---------