[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSP Use of FilterEntry (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)
Mahadevan, There has been some discussion on this list and, of course, on
the IPSP list but there's no conclusive answer as yet. Jamie and I have
discussed this and we'll leave the IPsec Config Policy Model (ICPM, aka
ICIM) as it is for now. The reason is primarily one of timing: the PCIMe
draft is being written right now and ICPM needs to be updated in time for
the March meeting. We need stability in the technical content and these
kind of representation details are really secondary right now.
That said, in the long run whether we use FilterEntry or
PolicyVariable/PolicyValue pairs is tbd, but the answer will lie in how the
IPSP WG sees the trade-offs between common policy representation vs. a model
that's close to its device-level implementation.
Lee
----- Original Message -----
From: "Mahadevan Iyer" <iyermahadevan@xxxxxxxxx>
To: <policy@xxxxxxxxxxxxxxx>
Sent: Tuesday, February 06, 2001 4:09 AM
Subject: Re: Preliminary results from PCIMe technical meeting, 1/24/01 -
1/26/01
> --- John Strassner <jstrassn@xxxxxxxxx> wrote:
> > This last sentence is misleading. One can easily
> > define
> > equivalences between the
> > FilterEntry.MatchConditionType and
> > the PolicyVariable classes and also between the
> > FilterEntry.MatchConditionValue and the PolicyValue
> > classes.
> > The perception that PolicyVariables and PolicyValues
> > somehow
> > break FilterEntries is just plain wrong.
>
> Can someone summarize the reasons why we will continue
> to have the notion of FilterEntry in IPSP drafts. If
> the reasons have been summarized in a thread, a
> pointer to the thread would be sufficient.
>
> Thanks
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - Buy the things you want at great prices.
> http://auctions.yahoo.com/
>