Capwap Mailing List: Scope of Charter Discussion (was: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.)

[James Kempf (kempf]

Alper, Behcet & Yoshi,

The intent here is to do something like iSCSI. As in that case, there are a
group of companies (one of which is DoCoMo Labs USA) that would like a
standard. They are requesting IETF help in doing it. Concensus at the BOF
was to move forward with a Working Group, we are discussing the charter. The
charter is to be focussed on designing a protocol, i.e. a solution, not
requirements, problem statement or anything of the sort.  If you have
something constructive to say about what should be in the charter, please do
so, but that should be the scope of the discussion. The bullet points for
the charter I sent a week ago, which Marcus Brunner commented on, are a good
starting point.


            jak

----- Original Message ----- 
From: "Alper Yegin" <alper [at] docomolabs-usa.com>
To: "Pat R. Calhoun" <pcalhoun [at] airespace.com>; <rkp [at] intotoinc.com>
Cc: <lwapp [at] frascone.com>
Sent: Wednesday, July 23, 2003 4:00 AM
Subject: Re: [Lwapp] Certificates, Discovery Request/Reply, and validation.


> >> I'm not comparing PANA with LWAPP. This does not make sense. LWAPP is
more
> >> like an architecture that tackles several problems. I'm trying to
understand
> >> what each one of these problems are and see if there are alternative
> >> solutions that should be considered.
> > ok, which one, specifically?
>
> I've discussed these before, but nevertheless:
> - Configuring APs: SNMP, COPS, etc.
> - Migration of AAA stuff from AP to AR: PANA
> - Auth/Authz between AP and AR: PANA (if physical security is not good
>   enough)
> - Migration of per-packet ciphering from AP to AR: Either use IPsec with
AR,
>   or tunnel 802.11 frames on the wired segment. Whether the latter should
be
>   done at IEEE vs. IETF is debatable.
>
> Did I miss any other problems we are tackling here?
>
> >
> >> PANA comes into the picture when we talk about the AAA between hosts
and AR,
> >> and AA_ between the AP and AR. I don't see PANA's relevance to all the
other
> >> bells and whistles LWAPP provides.
> >
> > correct, but somehow you keep asking the question. If we agree that
we've
> > beaten this horse to it's full extent, then I'll gladly oblige...
>
> Please see above.
>
> >
> >>>
> >>> We seem to be focused on EAP only, but again, I think the problem is
much
> >>> greater in scope - hence CAPWAP.
> >>>
> >>
> >> Is there a documented list of problems, like a problem statement? It is
> >> really hard to reverse engineer the LWAPP to undertsand the problems we
are
> >> solving here.
> >
> > Other than what's in the current document (which I assume you've read),
no.
> > However, the problems are well understood enough that many vendors are
> > actively building, or shipping, products, all with the same architecture
and a
> > protocol that looks like LWAPP.
> >
> > If the IESG believes that we need to go down the problem statement path,
and
> > tack on another 12 months of effort to CAPWAP, then we can consider it.
But
> > personally, having gone through some of this at the IETF, and the fact
that
> > this is a current problem that is known, I think that the players
involve all
> > know what we need.
>
> I still feel like missing couple of necessary steps here if we already
jump
> to solution evaluation stage.
>
> Alper
>
> >
> >
> > PatC
> >
> >
>
> _______________________________________________
> Lwapp mailing list
> Lwapp [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
>