Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)]
Curtis Villamizar <curtis@workhorse.fictitious.org> Tue, 13 January 2004 17:09 UTC
Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25801 for <rps-archive@lists.ietf.org>; Tue, 13 Jan 2004 12:09:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgS2G-0005VX-Qo; Tue, 13 Jan 2004 12:09:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgS1b-0005Uk-9K for rps@optimus.ietf.org; Tue, 13 Jan 2004 12:08:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25758 for <rps@ietf.org>; Tue, 13 Jan 2004 12:08:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgS1Z-00058q-00 for rps@ietf.org; Tue, 13 Jan 2004 12:08:17 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRzs-00056y-00 for rps@ietf.org; Tue, 13 Jan 2004 12:06:33 -0500
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AgRyX-00053n-00 for rps@ietf.org; Tue, 13 Jan 2004 12:05:09 -0500
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i0DH3CRX053524; Tue, 13 Jan 2004 12:03:12 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200401131703.i0DH3CRX053524@workhorse.fictitious.org>
To: "Larry J. Blunk" <ljb@merit.edu>
cc: Pekka Savola <pekkas@netcore.fi>, rps@ietf.org, rpslng@ripe.net
Reply-To: curtis@fictitious.org
Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)]
In-reply-to: Your message of "13 Jan 2004 11:22:09 EST." <1074010929.3795.45.camel@ablate.merit.edu>
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: rps-admin@ietf.org
Errors-To: rps-admin@ietf.org
X-BeenThere: rps@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rps>, <mailto:rps-request@ietf.org?subject=unsubscribe>
List-Id: Routing Policy System <rps.ietf.org>
List-Post: <mailto:rps@ietf.org>
List-Help: <mailto:rps-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rps>, <mailto:rps-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/rps/>
Date: Tue, 13 Jan 2004 12:03:12 -0500
In message <1074010929.3795.45.camel@ablate.merit.edu>, "Larry J. Blunk" writes : > On Fri, 2004-01-02 at 03:24, Pekka Savola wrote: > > Hi, > > > > (I tailed down the Cc: list..) > > > > On Sat, 27 Dec 2003, Randy Bush wrote: > > > > OK, I now found that the doc did have an IETF Last Call > > > > in late August/Early Sept. > > > > > > and there were technical objections which have not been addressed > > > > Thanks, Randy, for reminding about that. > > > > Based on some off-list discussion, the technical objections being > > referred to are the comments from Mark Prior on the list, one of them > > copied below. > > > > I'll try to summarize the loooo-ong thread somehow. Mark believes > > that the current RPSLng proposition unnecessarily adds complexity to > > the operators' use of the language, as e.g. IPv4 and IPv6 addresses, > > peerings, etc. could all be facilitated by redefining the current > > attributes etc. -- and whichever would be returned could be evaluated > > based on the context. As the number of operators using the language > > is extremely high (and we'd like it to be higher :-) compared to the > > registry/tool implementations, Mark argues that optimizing for the > > simplicity to the operators is the most important goal. > > > > Curtis objects to this mainly based on the fact that this would break > > the backward compatibility for the clients which do not expect to > > receive IPv6 data back from their queries. This could be easily fixed > > e.g. in tools like IRRToolSet, but that there are a probably a number > > of hacks built on top of perl, telnetting to port 43, or whatever, > > which might not be equally fortunate. > > > > Workarounds to this seem to be adding some kind of version negotiation > > or inclusion to the whois protocol (in the future, maybe using CRISP), > > so that only the clients who signal "yes, I can process IPv6 records!" > > would activate the IPv6 context processing. This could also be passed > > to the whois server with an option, like '--use-rpslng' or '-6'. Or > > maybe the client would state which records it wants to get, e.g. > > '-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or > > something, for "NEW", otherwise only v4 would be returned :) for > > both). At least RIPE database allows the use of '-Vxxx' verstion > > string to tell about the version of the client software. > > > > The exact details of how this method would work out would need to be > > fleshed out. Any takers? > > I don't believe this would be particularly productive. These > are implementation details which are really outside the scope of > the RPSLng work. I don't see the objections to RPSLng as objective > technical issues, but rather subjective preferences. I'll agree with that. So if any comments I made having to do with transition and backwards compatibility are holding this up, comments which I beleive I made as suggestions, then please consider those to be resolved issues. > > Personally, when I was trying to form an opinion on this subject, I > > found myself thinking that Mark's proposal addresses only IPv4/IPv6 > > case. It doesn't seem to address how one could specify different > > unicast/multicast policies, or how to specify different v4/v6 > > policies. This is also one goal of RPSLng.. even though the major > > operators who do have multicast or v6 often want their policies to be > > the same. > > > > How would this work out if a "more intelligence" model was adopted? > > > > (I'm personally a bit unsure whether a "more intelligence in the > > tools" -model would or would not make sense at this point, but I think > > I can see both sides of the argument..) > > It is very difficult to judge the impact of such a model without > having a complete census of the various tools in use by ISP's. For > example, C&W has an extensive set of in-house developed tools which > interact with IRR's. Is it fair to ask them to hack up their tools > to fit this model? > > > > > Could we get some form of discussion and maybe consensus on what would > > seem to be the right way forward? :-) > > I think we have already reached the point of "rough" consensus. > Again, I view the expressed objections as subjective preferences rather > than solid technical beefs with the specification. > > Regards, > Larry I agree here too. Perhaps Mark can tell us whether he has any specific suggestions for changing the language from what is currently proposed. Curtis > > =========== > > Date: Tue, 23 Sep 2003 09:00:06 +0930 > > From: Mark Prior <mrp@mrp.net> > > To: curtis@fictitious.org > > Cc: Pekka Savola <pekkas@netcore.fi>, iesg@ietf.org, rpslng@ripe.net, > > rps@ietf.org > > Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard > > > > Curtis Villamizar wrote: > > > > > How is RPSLng not a superset of RPSL? Nothing has been removed from > > > RPSL. > > > > Superset is probably not the best word to describe what I want. > > > > > The issue is just how do you make transition easiest, supporting older > > > RPSL only clients. If you just extend import rather than rename it > > > mp-import and extend it, then old RPSL only clients will consider you > > > autnum broken. If you include mp-import but forget to reflect you > > > IPv4 policy in plain import then the old RPSL client will pick up a > > > subset of you policy. > > > > > > In either case, extending import, or adding mp-import and putting the > > > extensions there, it would make for a smoother transition if the > > > server code could recognize old clients and feed them with objects > > > translated into plain RPSL. > > > > I think I have been consistent in wanting the smarts to be in the > > software and not the language. I would prefer to overload the syntax > > then create new syntax and let the software work out what is required. > > We don't use different syntax in computer languages when we want to > > operate on integers rather than reals so why make the distinction in > > RPSL? If we have a route object that has a IPv6 address in it surely the > > software can work out if it wants it or not given it's current context? > > > > I know you (and others :-) keep on about the old clients but we have > > left them behind once before in the transition from RIPE 181 to RPSL so > > do it again but this time lets leave some mechanism behind so that when > > we need (RPSLng)ng we don't go through this pain yet again. Saying it's > > not part of the language is a pathetic excuse in my book for not fixing > > it. If we need a "shim" document to describe the interaction between a > > server and a client then lets do it. It would make the client software > > writers life a lot easier if there weren't (at least) 3 server > > interaction languages to deal with. > > > > Mark. > > ========== > > > _______________________________________________ > Rps mailing list > Rps@ietf.org > https://www1.ietf.org/mailman/listinfo/rps _______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps
- RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft) Larry J. Blunk
- RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft) Wijnen, Bert (Bert)
- RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft) Randy Bush
- Separate attributes vs context-aware software [RE… Pekka Savola
- Re: Separate attributes vs context-aware software… Mark Prior
- Re: Separate attributes vs context-aware software… Larry J. Blunk
- Re: Separate attributes vs context-aware software… Randy Bush
- Re: Separate attributes vs context-aware software… Larry J. Blunk
- Re: Separate attributes vs context-aware software… Curtis Villamizar
- Re: Separate attributes vs context-aware software… Randy Bush
- Re: Separate attributes vs context-aware software… Curtis Villamizar
- Re: Separate attributes vs context-aware software… David Kessens
- RE: Separate attributes vs context-aware software… Frank Bohnsack
- Re: Separate attributes vs context-aware software… Pekka Savola
- [Rps] Re: Separate attributes vs context-aware so… Simon Leinen
- Re: [Rps] Re: Separate attributes vs context-awar… Andrei Robachevsky