RE: CAPWAP BOF follow up: nmrg - CAPWAP

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

W.r.t. this piec of James' email:
> 
> W.r.t. to the "re-inventing the wheel" charge, I've been hearing that from
> people with axes to grind on the list, but perhaps NMRG doesn't have an ax.

The NMRG itself does not have to grind an ax. However, there are a lot
of SNMP biggots there, so there is some of that ...

> One thing to note, though, is that the companies who want this protocol feel
> it isn't a research issue, and if NMRG thinks it is, there's a problem.

I do not think NMRG thinks it is a research issue.

> There are some potential areas where existing work could be used, like IPsec
> for security between APs and ARs, possibly DHCP and SLP for discovery; and
> there is ongoing but just started work on device configuration in netconf
> that might be useful (I'm undecided about SNMP, but since the issue is
> device configuration, I think netconf is more appropriate), 
> but may take a long time to complete.

Indeed, we have seen other efforts fail, and there is no guarantee that
netconf will finish real soon and that vendors will jump to implement
deliver.

The discussion came up because we were talking about "What does the IETF
want WGs to do for configuring netowrk devices between now and the time
that we will have a full fledged new protocol (XML-baed, e.g. netconf work)."
They then listed various things that are going on, and CAPWAP was one
of them. The feeling is that if various devices keep doing CLI or whatever
proprietary thing they do today is fine untill we have a NetConf result.
They also feel that it will hurt if the IETF now goes down a path
where various WGs start to develop all sort of new protocols to do
network/device configuration. They felt that in that case it might be
better to build on what we have (yep SNMP SETs), specifically in areas
where such is currently being done (albeit with proprietary MIB modules).


> In each of these cases, there would need to be
> additional work to define how the existing protocol would support the
> wireless network control function, as there was in iSCSI (in fact, iSCSI
> seems very similar, except for the lack of another standards body
> threatening a competing standard). There is also some work, like protocol
> support for the AR to load balance mobiles between access points and
> eliminate the possibility of mobiles "ping-ponging" between access points,
> that isn't supported by any existing protocol.
> 
NMRG people were/are aware of that requirement/work. 

Hope this helps/clarifies
Bert