Re: CAPWAP BOF follow up: nmrg - CAPWAP

["James Kempf" <kempf@docomolabs-usa.com>]

> >That would include such items as dynamic channel allocation and dynamic
> >power control.
>
> Yes,  I'm not aware of any IEEE work ongoing in this area.  Is this the
kind
> of thing that could be handled generically?  If so, one could make a case
> for a "Radio Resource Management" data model.
>

The messages could be generic I think, but the actual content would depend
on the radio type. For example, it would not make sense to tell an .11b AP
to use channel 56, because .11b doesn't have that many channels, whereas it
would make sense to tell .11a.

> >Certificate profiles
>
> Does this overlap with the ENROLL BOF?
>

Not sure. In general, though, I've noticed that when certificates come into
the picture, there is a need for profiles. TLS has one, we've been
discussing one for SEND, etc.

> >how to negotiate the ISAKMP SA, etc.
>
> Can anything useful be garnered from the work of the IPsec Policy WG?
>

Possible. I'm thinking more along the lines of IKEv2 and what exactly the
sequence of CONFIG messages would be.

> >The specification would not be for algorithms but for the interoperable
> >protocol to distribute the information. The algorithms are for
proprietary
> >innovation, and don't really need a standard for interoperability. Or, at
> >least, that is my understanding of what the supporters want.
>
> Those "supporters" sound like vendors, not users.
>

The vendors want the interoperability because they think their customers
will want to mix and match. I think this would benefit service providers
like Docomo if it resulted in reduced OPEX and CAPEX, and there are some
good arguments that it would.

> Today's Access Points have proprietary data models, but in most cases a
> standard protocol is used -- SNMP.   Adding another management protocol
> could be a problem is that results in fragmentation of wireless management
> mechanisms, particularly if the new protocol includes proprietary commands
> as well as data models.  This was one of the big issues with Diameter -- 
> even with all of the RADIUS VSAs you can generally use any RADIUS server
> with the appropriate dictionary entries.  But by adding proprietary
> commands, Diameter made it necessary to upgrade code to add
functionality -- 
> implying that two implementations of the "standard" would be unlikely to
> interoperate.
>

In the case of dynamic radio management (if that's what CAPWAP evolves
into), I think it should be parameterized such that additional code wasn't
needed.

> >My understanding is
> >currently there is no MIB for the AP, just the mobile station, though, of
> >course, one could be developed.
>
> IEEE 802.11-1999 does define MIBs for the AP as well as STA.
>

OK. This is not what Dorothy told me.

> >after bad experiences with trying to do problem statements and
requirements
> >in a WG.
>
> Yes. Many WGs don't take the problem statement phase seriously, just treat
> it as something to "get past the IESG".  It doesn't so much matter how it
> gets done, as much as how much thinking goes into it.
>

Actually, my experience was the opposite. They took the problem statement
and requirements phase *too* seriously. Seamoby argued for 2 1/2 years about
requirements and problem statement, and the resulting documents were, to put
it mildly, not useful. After discarding them, the WG got down to protocol
work and after about a year, it looks like there will be a protocol, though
it will be experimental because the vendors lost interest. Not clear how
useful the protocols are at this point, though.

            jak