Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)]
"Larry J. Blunk" <ljb@merit.edu> Tue, 13 January 2004 16:21 UTC
Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21761 for <rps-archive@lists.ietf.org>; Tue, 13 Jan 2004 11:21:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRHs-0003JF-6I; Tue, 13 Jan 2004 11:21:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgRHQ-0003Hn-44 for rps@optimus.ietf.org; Tue, 13 Jan 2004 11:20:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21721 for <rps@ietf.org>; Tue, 13 Jan 2004 11:20:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgRHP-0001Io-00 for rps@ietf.org; Tue, 13 Jan 2004 11:20:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgRFn-0001Eh-00 for rps@ietf.org; Tue, 13 Jan 2004 11:18:56 -0500
Received: from segue.merit.edu ([198.108.1.41]) by ietf-mx with esmtp (Exim 4.12) id 1AgREh-00018v-00 for rps@ietf.org; Tue, 13 Jan 2004 11:17:47 -0500
Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151]) by segue.merit.edu (Postfix) with ESMTP id 77EB55DDAF; Tue, 13 Jan 2004 11:17:46 -0500 (EST)
Subject: Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)]
From: "Larry J. Blunk" <ljb@merit.edu>
To: Pekka Savola <pekkas@netcore.fi>
Cc: rps@ietf.org, rpslng@ripe.net
In-Reply-To: <Pine.LNX.4.44.0401020943330.8873-100000@netcore.fi>
References: <Pine.LNX.4.44.0401020943330.8873-100000@netcore.fi>
Content-Type: text/plain
Organization: Merit Network, Inc.
Message-Id: <1074010929.3795.45.camel@ablate.merit.edu>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5)
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: rps-admin@ietf.org
Errors-To: rps-admin@ietf.org
X-BeenThere: rps@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <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 11:22:09 -0500
Content-Transfer-Encoding: 7bit
On Fri, 2004-01-02 at 03:24, Pekka Savola wrote: > Hi, > > (I tailed down the Cc: list..) > > On Sat, 27 Dec 2003, Randy Bush wrote: > > > OK, I now found that the doc did have an IETF Last Call > > > in late August/Early Sept. > > > > and there were technical objections which have not been addressed > > Thanks, Randy, for reminding about that. > > Based on some off-list discussion, the technical objections being > referred to are the comments from Mark Prior on the list, one of them > copied below. > > I'll try to summarize the loooo-ong thread somehow. Mark believes > that the current RPSLng proposition unnecessarily adds complexity to > the operators' use of the language, as e.g. IPv4 and IPv6 addresses, > peerings, etc. could all be facilitated by redefining the current > attributes etc. -- and whichever would be returned could be evaluated > based on the context. As the number of operators using the language > is extremely high (and we'd like it to be higher :-) compared to the > registry/tool implementations, Mark argues that optimizing for the > simplicity to the operators is the most important goal. > > Curtis objects to this mainly based on the fact that this would break > the backward compatibility for the clients which do not expect to > receive IPv6 data back from their queries. This could be easily fixed > e.g. in tools like IRRToolSet, but that there are a probably a number > of hacks built on top of perl, telnetting to port 43, or whatever, > which might not be equally fortunate. > > Workarounds to this seem to be adding some kind of version negotiation > or inclusion to the whois protocol (in the future, maybe using CRISP), > so that only the clients who signal "yes, I can process IPv6 records!" > would activate the IPv6 context processing. This could also be passed > to the whois server with an option, like '--use-rpslng' or '-6'. Or > maybe the client would state which records it wants to get, e.g. > '-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or > something, for "NEW", otherwise only v4 would be returned :) for > both). At least RIPE database allows the use of '-Vxxx' verstion > string to tell about the version of the client software. > > The exact details of how this method would work out would need to be > fleshed out. Any takers? I don't believe this would be particularly productive. These are implementation details which are really outside the scope of the RPSLng work. I don't see the objections to RPSLng as objective technical issues, but rather subjective preferences. > > Personally, when I was trying to form an opinion on this subject, I > found myself thinking that Mark's proposal addresses only IPv4/IPv6 > case. It doesn't seem to address how one could specify different > unicast/multicast policies, or how to specify different v4/v6 > policies. This is also one goal of RPSLng.. even though the major > operators who do have multicast or v6 often want their policies to be > the same. > > How would this work out if a "more intelligence" model was adopted? > > (I'm personally a bit unsure whether a "more intelligence in the > tools" -model would or would not make sense at this point, but I think > I can see both sides of the argument..) It is very difficult to judge the impact of such a model without having a complete census of the various tools in use by ISP's. For example, C&W has an extensive set of in-house developed tools which interact with IRR's. Is it fair to ask them to hack up their tools to fit this model? > > Could we get some form of discussion and maybe consensus on what would > seem to be the right way forward? :-) I think we have already reached the point of "rough" consensus. Again, I view the expressed objections as subjective preferences rather than solid technical beefs with the specification. Regards, Larry > > =========== > Date: Tue, 23 Sep 2003 09:00:06 +0930 > From: Mark Prior <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
- 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