Subject: RE: [Capwap] Comments on objectives draft

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 7 Apr 2005 18:15:54 +0200

Mmm... are we deviating from the core topic.
Wehn I read things like:
> > 1.interoperability does not require a co-development 
> >   business contract of any form.
> > 
> >    I am unaware of any precedence for this sort of thing in
> >    the IETF and believe its introduction here is, as I
> >    mentioned, a ham-fisted attempt to exclude a single protocol.
> 
> No Dan, I completely disagree. When one looks at the technical merits of
> a protocol, we must not only evaluate whether a protocol satisfies 
> requirements, but we must also determine whether it even makes business
> sense. Frankly, does it make sense to design something that no one can use
> because of the business model behind it?
> 

Then I can see tension whihc may not be needed.
I think the proper statement is:

   The IETF develops standards track specification that allow any vendor or
   any person to implement that specification from the spec itself and
   by that it is required that all such implementations do interoperate.

That leaves any of the "business and contract" type discussion untouched.

If we all think in those terms and discuss in those terms,
does that then help to ease the discussion?

Bert
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Pat Calhoun" <[email-masked]>
Date: Thu, 7 Apr 2005 09:25:20 -0700

>    by that it is required that all such implementations do 

Bert, I wish I could have been as succinct in my original statement. I
completely
agree with your proposed wording.

Thanks,

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Apr 2005 10:03:01 -0700

So in line with Bert's comments, I've been pondering whether it would be
possible for SLAPP to achieve the interoperability requirement that IETF has
for moving a protocol from Proposed Standard to Draft Standard (I'm assuming
other people in the WG care about the protocol ultimately going to Draft
Standard, I certainly do). The requirement is that there need to be two
independently built interoperable implementations done from the
specification that is being put forward for advancement to Draft Standard.
It is one of the few hard and fast rules that IETF has.

As I see it, the basic issue is this:

    Is it possible for two AC implementors and two AP implementors
    *using the SLAPP spec* to achieve independently implemented
    interoperable implementations *of the control protocol* without
    reference to any other specification except those that are listed
    as Normative References in the specification and without
    exchanging any code?

The answer I think is clearly "no". This is because the SLAPP spec doesn't
address the control protocol, it just addresses discovery, negotiation of a
(probably proprietary) control protocol, and download of code to run the
control protocol, as Partha mentioned in his email. In order to actually
achieve interoperablity *on the control protocol*, the AC and AP vendors
would have to exchange an additional specification that would not be part of
the Normative References in the specification being put forward for
advancement to Draft Standard.

From this, I conclude that SLAPP does not address the goals of the CAPWAP
charter, since the CAPWAP charter clearly defines an interoperable control
protocol as one of the deliverables for the Working Group. Therefore, I
would venture that SLAPP is not a valid candidate for consideration as a
CAPWAP protocol, and it should not be considered in the upcoming protocol
decision phase (whatever that might be).

Comments?

            jak

---

From: Partha Narasimhan <[email-masked]>
Date: Thu, 7 Apr 2005 11:17:20 -0700 (PDT)

James

Thanks for your comments.

Your conclusion is a bit premature, though.

The goal of SLAPP is not to provide the most complete solution to 
the CAPWAP problem. Instead we started with the premise that there is more
than one way to solve the CAPWAP problem, especially if one wants to
address just a subset of the multiple documented architectures. 
We can either start with trying to limit choices in the proposed solution 
or go ahead and standardize a large number of architectural permutations. 
Neither of these two seemed acceptable.

So we decided to take a divide and conquer approach and specify a 
common framework using which multiple (hopefully simpler) control 
protocols can be applied for solving the CAPWAP interoperability problem. 
This way a control protocol that wishes to address say just the local MAC 
architecture can be negotiated during the SLAPP phase and then used 
without the burden of implementing an entire set of features that will not 
be used in that network. Our assumption is that these control protocols 
would be published ones and not proprietary to any specific vendor. In 
fact, any or all of the other three CAPWAP proposals can be a control 
protocol that can be negotiated using SLAPP.

This also has the added benefit that since SLAPP is completely access
technology independent, it could be used as a framework for other
technologies for discovery and authentication and then go on to execute
the control protocol defined and published for that specific access
technology. That way we can currently focus on solving the current WLAN
problems without worrying about future UWB problems about which we dont have
enough information.

In the end, we are proposing a framework where we can have multiple simpler
published control protocols that solve smaller problems instead of one 
big, more complex control protocol solving multiple problems. The 
image download protocol defined in the draft is NOT mandatory for SLAPP.

Thanks
partha

---

From: Dan Harkins <[email-masked]>
Date: Thu, 07 Apr 2005 12:02:32 -0700

James,

  You have taken Bert's neutral and succinct statement and made it
less so on both counts.

  The -01 version of SLAPP does not define a control protocol (message
number 4 in section 4.2 is waiting though). In effect, the image download
is a vendor specific method of controlling the AP. So while it is possible
for SLAPP to be implemented in accordance with Bert's statement-- multiple
interoperable implementations according to the spec and only the spec-- the
result would not allow for complete control of the AP since vendor specific
information is not allowed.

  LWAPP can provide for some control of the AP. It also has vendor
extensions to fill it out so things can be configured on specific hardware
that are not part of the spec. While it's possible for LWAPP to be
implemented in accordance with Bert's statement the result may not be
satisfactory for most APs (that is, there are APs that have functions that
LWAPP cannot configure) since vendor specific information is not allowed.

  I don't think you're saying that all vendor specific extensions must be
removed from LWAPP (or if you are then I strongly disagree) so what I think
we're talking about is the extent that vendor specific extensions are going
to be used to control the AP. A good discussion to have. But I don't think
the objectives draft is the place to have it.

  Let's come up with neutral, succinct, and general objectives for CAPWAP
instead of trying to fashion specific objectives with the motivation to
exclude a particular proposal and advance another.

  Neither SLAPP nor LWAPP are finished products. They are both versions -01.
Future working group discussions will provide direction to the authors
and the drafts can be modified to address points raised and show how the
direction the working group wants to go in is being addressed. That is
the IETF way.

  Dan.

On Thu, 07 Apr 2005 10:03:01 PDT you wrote

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Apr 2005 15:36:39 -0700

Partha,

> Neither of these two seemed acceptable.

So you agree that SLAPP does not completely address the CAPWAP charter
objectives (which, for your reference, are listed here:
http://www.ietf.org/html.charters/capwap-charter.html)?

> protocol that can be negotiated using SLAPP.

Speaking with my service provider hat on, I'm opposed to this kind of
design, because I believe it complicates deployment configuration and
management. The fewer knobs and dials my management people get to twiddle
and monitor, the less I have to worry about something going wrong. I've made
this point on the list, I won't belabor it again.

            jak

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Apr 2005 16:01:13 -0700

Dan,

> information is not allowed.

But my point was it is not possible for SLAPP as written to completely
fufill the CAPWAP charter. Do you agree or not?

> the objectives draft is the place to have it.

Actually, I *do* want the vendor specific extensions removed from LWAPP, so
we'll have to disagree here.

Such vendor extensions have caused no end of problems for service providers
over the years in RADIUS, to the point that when Diameter was standardized,
the IESG specifically mandated that any Diameter command extensions (which
would require different code in the AAA server) must have IETF approval. It
seems like SLAPP is taking exactly the same approach as Diameter, and runs
exactly the same risk, that the code might not be on the AP.

>   Neither SLAPP nor LWAPP are finished products. They are both
versions -01.

I never said that LWAPP was a finished product.

> direction the working group wants to go in is being addressed. That is

As I've said in the past, from a service provider perspective, what I think
we need is to have a simple, interoperable protocol with a standardized set
of messages for AP control and provisioning, not just discovery, protocol
negotiation, and code download (though those may be included as a subset of
the control and provisioning operations).

You have in the passed expressed concern about innovation. There are plenty
of examples of IETF protocols that have been standardized that have
undergone modification to accommodate innovation. I don't see having a
standardized protocol across the AC/AP interface as inhibiting that, and,
besides, as I've said in the past, there are plenty of other places where AC
and AP vendors can innovate rather than in the location of particular bits
in the PDUs. An example that comes to mind here is IKE/IPsec. Innovation can
occur in the cryptosuite algorithms, for example, adding a new elliptic
curve algorithm, rather than in the basic protocol for setting up the SA.
Similarly, as an example, I can see AC/AP vendors innovating in the
algorithms about how they do load balancing instead of the protocol used to
tell the APs how they should handle the load. SLAPP is too coarse-grained a
tool to allow this, IMHO.

            jak

---

From: Partha Narasimhan <[email-masked]>
Date: Thu, 7 Apr 2005 16:29:45 -0700 (PDT)

> this point on the list, I won't belabor it again.

This is all the more reason why you dont want to have the burden of a 
single protocol that attempts to address all of the CAPWAP architectures. 
If your organization is interested in, for example, the local MAC 
architecture, then you choose a solution that supports that architecture 
and maybe not everything else under the sun. Especially, since your 
earlier comments in the meetings seemed to suggest that most solutions 
will pick one architecture and may never mix more than one at the same 
time.

Thanks
partha

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Apr 2005 16:26:29 -0700

> will pick one architecture and may never mix more than one at the same

Right, and AFIKT, the Split/Local MAC architecture should be sufficient (or,
at least speaking with my service provider hat on, that's all I'm interested
in).  These are similar enough that I believe developing an interoperable
protocol should be straightforward. I don't see the need for the extra
complexity of trying to accommodate others within the same protocol.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Apr 2005 16:29:05 -0700

> will pick one architecture and may never mix more than one at the same

Oh, and let me repeat my question (since you didn't see fit to answer it in
your original reply):

    Is SLAPP intended to completely address the CAPWAP charter requirement
for a control and provisioning protocol or not?

            jak

---

From: Dan Harkins <[email-masked]>
Date: Thu, 07 Apr 2005 16:28:30 -0700

On Thu, 07 Apr 2005 16:01:13 PDT you wrote
> fufill the CAPWAP charter. Do you agree or not?

No I do not agree with that.

> we'll have to disagree here.

This is something that needs to be flushed out here and now. Is CAPWAP
going to disallow vendor specific extensions or not? That should be in
the objectives if anything is.

In my discussions about LWAPP for the past few weeks people always bring
up vendor specific extensions as the counter to the statement that LWAPP
is too rigid and will inhibit innovation.

So to prevent a bait-and-switch on the group I think we should all decide
whether they are allowed or not.

> exactly the same risk, that the code might not be on the AP.

Probably why Diameter has such widespread deployment when compared to
RADIUS, eh? 

> tool to allow this, IMHO.

I'm glad you mentioned IKE. New elliptic curve algorithms are one of those
things that _haven't_ been innovated using the capabilities that IKE 
provides.

What has been "innovated" is new exchanges to allow for username/password
based authentication, which is something that the base IKE spec did not
allow for. Unfortunately the most popular one of those, XAUTH, is
insecure but on top of that there are so many flavors of XAUTH that
multivendor interoperability is a joke.

Multivendor interoperability on these new exchanges is so bad that people
buy both ends (client and gateway) from one vendor only. That, I hope, is
not the path down which CAPWAP will go.

But IKE is not like CAPWAP. The number of components of an IPsec SA
(which IKE "controled and provisioned") are extremely small compared
to the number of configurable components of an AP, and features of an
AS that require AP nerd knobs. And people are continuing to define new
features for APs and ASs. No one is defining new features of IP that
need to be negotiated by IKE. So the problem space is so much different,
and so much larger.

That's why I don't think a single monolithic control protocol will do the
trick. 

  Dan.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Apr 2005 09:56:02 -0700

Dan,

> No I do not agree with that.

Then perhaps you can point out to me where the protocol for the following
functions is defined in draft-narasimhan-ietf-slapp-00.txt or one of its
Normative References:

   o  RF monitoring, such as Radar detection, noise and interference
      detection and measurement.
   o  RF configuration, e.g., for retransmission, channel selection,
      transmission power adjustment, etc.
   o  WTP configuration, e.g., for SSID, etc.
   o  WTP firmware loading, e.g., automatic loading and upgrading of WTP
      firmware for network wide consistency.
   o  Network-wide STA state information database, including the
      information needed to support value-added services, such as
      mobility, load balancing etc.
   o  Mutual authentication between network entities, e.g., for AC and
      WTP authentication in a Centralized WLAN Architecture.

These functions (lifted verbatim from draft-ietf-capwap-arch-06.txt) are a
partial list of the functions in Section 2.2 of
draft-ietf-capwap-arch-06.txt that are the WG concensus about what a CAPWAP
protocol must provide to solve the problems defined in RFC 3990. Without
support for these functions and the others defined in Section 2.2 of
draft-ietf-capwap-arch-06.txt, I cannot see how a protocol could claim to
fufill the CAPWAP charter, and thereby be a candidate for a standardized
CAWAP protocol.

> whether they are allowed or not.

My objection is to vendor-specific extensions if such extensions require
different code on the AP involved in protocol operation, not extensions per
se. I've got no objection to standardized extensions, nor to vendor-specific
extensions that don't involve different code for protocol operation. So a
vendor "extension" that involves a different algorithm and code for load
balancing but uses the same protocol messages and protocol state machine as
the standard isn't a problem, nor is a vendor "extension" that involves use
of a particular protocol operation with different parameters. Anything that
would involve different code for protocol operation or changes in the state
machine (which amounts to the same thing) should require IETF standards
action to be accepted into the protocol.

> Probably why Diameter has such widespread deployment when compared to

Nothing to do with that. The problem with Diameter deployment is that it
missed the market window because the WG spent too long arguing. Perhaps an
object lession for CAPWAP. :-)

> not the path down which CAPWAP will go.

You're forgetting IKEv2. In IKEv2, they've defined a way to do
username/password that is standardized and secure, using EAP. This is how
CAPWAP could evolve. It might be possible to make the evolution a little
less messy, so something like insecure vendor XAUTH extensions doesn't
happen (a good reason not to have vendor extensions). Maybe more like DNS
where the DNS community has a more straightforward (and I'd dare say more
open) process in place for evolution, so vendors and others with extensions
feel welcome to come to the IETF with their proposals, and they get the kind
of peer review that is IETF's value added. The IPsec WG was never open to
more that a few extensions (such as cryptosuites) that were defined into IKE
in the first place, and it was only overwhelming reality-based evidence that
caused them to change.

> That's why I don't think a single monolithic control protocol will do the

Most of the components involved in controlling a radio access network are
actually pretty well known from work in the cellular community, especially
for the case where there's a centralized RAN controller. I believe the
process is people taking features that are known from cellular RAN work and
applying them to 802.11. There are some differences based on the radio MAC
and the fact that there's no need for isochronous backhaul due to the lack
of soft handover, but I don't really see that having a standardized control
protocol is such a problem.

I think the real issue is that in order to get a standardized control
protocol (not just discovery, secure code download, and negotiation for a
proprietary control protocol), the protocol design must make some
assumptions about the RAN architecture, essentially to bake an architectural
decision into the protocol design. Unfortunately, I don't see any way to get
around this. If the architecture is made negotiable, then, from a user
standpoint, the control protocol must be too, and that provides too many
nerd knobs for good interoperability, IMHO.

            jak

---

From: Dan Harkins <[email-masked]>
Date: Fri, 08 Apr 2005 12:14:45 -0700

James,

On Fri, 08 Apr 2005 09:56:02 PDT you wrote
>       WTP authentication in a Centralized WLAN Architecture.

In -01 of SLAPP these are handled through a vendor specific extension-- the 
image download. I can do all of those and more today by doing an image
download to an AP. 

> action to be accepted into the protocol.

Of course they require new code on the AP! Go back to Pat's RF coloring
example. How is LWAPP handling that? Through vendor-specific extensions
that enable an AC to communicate something to the AP that is not part of
the LWAPP spec. Most any innovation that an AP vendor comes up with that
needs control and provisioning will need some vendor-specific extension
to handle it. 

  Dan.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Apr 2005 13:54:51 -0700

Dan,

> image download. I can do all of those and more today by doing an image

Vendor specific functions aren't enough to guarantee interoperability, since
these functions are not handled by the SLAPP specification nor in the
Normative References. Remember, the requirement for Draft Standard is that
two independently implemented interoperable implementations can be
demonstrated from the specification and any Normative References.

> needs control and provisioning will need some vendor-specific extension

But my point is, it should not require new code for the protocol state
machine. With my service provider hat on, that's what I need for doing a
multivendor WLAN RAN. Any other code is the vendor's herbs and spices, and
shouldn't affect protocol interoperability.

            jak

---

From: Dan Harkins <[email-masked]>
Date: Fri, 08 Apr 2005 23:28:01 -0700

On Fri, 08 Apr 2005 13:54:51 PDT you wrote
> demonstrated from the specification and any Normative References.

And two independently implemented interoperable implementations (phew, what
a mouth full) can interoperate on discovery, authentication and control
negotiation. The vendor specific functions encompassed in an image download
are, by definition, interoperable. If two parties use SLAPP to negotiate
(in an interoperable fashion) a particular control plane function they will
interoperate in that control plane function.

> shouldn't affect protocol interoperability.

Perhaps you should stop putting on and taking off hats because I'm not sure
which James Kempf I'm speaking to. One James Kempf wants vendor specific
extensions removed from LWAPP. Another says they're OK as long as they 
don't change the protocol state machine. The vendor specific extensions
in LWAPP really don't seem to change the protocol state machine so I'm 
having a hard time reconciling the two James Kempfs.

I encourage you to look at SLAPP. Check out what state the state machine is
in after it downloads an image. All the "herbs and spices" that happen after
that image download don't change the SLAPP state machine. They don't 
affect interoperability of SLAPP.

  Dan.

---

From: "Pat Calhoun" <[email-masked]>
Date: Sun, 10 Apr 2005 12:00:16 -0700

> I encourage you to look at SLAPP. Check out what state the 
> state machine is in after it downloads an image. All the 
> "herbs and spices" that happen after that image download 
> don't change the SLAPP state machine. They don't affect 
> interoperability of SLAPP.

Dan, there is a difference in what you mean by "herbs and spices":

1. Herbs and spices is a complete control protocol (e.g., SLAPP). In
This case, the WG gets away with not defining an interoperable protocol,
And simply defines a discovery mechanism. The AP vendor is free to 
Implement one, two or as many control protocols as he/she feels is needed
To have a successful product in the market. My personal opinion is that 
There is really not much different between SLAPP and what we have today.
A cornucopia of proprietary protocols.
2. Herbs and spices are vendor extensions (e.g., LWAPP). In this case,
The WG allows for vendors to include their own innovation, but these are
Not required for basic interoperability, allowing a WTP and an AC to 
Provide full 802.11 service to the user, while addressing all of the 
Issues defined in the problem statement and the objectives document.

I realize I am being somewhat repetitive, but for the record, I believe
that option one does not benefit the Internet community or the vendors. 
imagine the IT manager that buys the WTP, which supports the CAPWAP
protocol, but after plugging it in, realizes that the "proprietary control
protocol" is not supported, and therefore the WTP cannot interoperate 
with the IT manager's infrastructure.

Further, as we all know from prior experience, we will all end up with
RFPs that require that we support all protocols - so we might as well
choose one and make all of our, and our customer's, lives easier.

Pat Calhoun

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan Harkins
> Sent: Friday, April 08, 2005 11:28 PM
> To: James Kempf
> Cc: [email-masked]
> Subject: Re: SLAPP and IETF DS Interoperability Requirement 
> (was: Re: [Capwap] Comments on objectives draft) 
> 
> > Vendor specific functions aren't enough to guarantee 
> interoperability, 
> > since these functions are not handled by the SLAPP 
> specification nor 
> > in the Normative References. Remember, the requirement for Draft 
> > Standard is that two independently implemented interoperable 
> > implementations can be demonstrated from the specification 
> and any Normative References.
> 
> And two independently implemented interoperable 
> implementations (phew, what a mouth full) can interoperate on 
> discovery, authentication and control negotiation. The vendor 
> specific functions encompassed in an image download are, by 
> definition, interoperable. If two parties use SLAPP to 
> negotiate (in an interoperable fashion) a particular control 
> plane function they will interoperate in that control plane function.
> 
> > > > My objection is to vendor-specific extensions if such 
> extensions 
> > > > require different code on the AP involved in protocol 
> operation, 
> > > > not extensions
> > per
> > > > extensions that don't involve different code for protocol 
> > > > operation. So
> > a
> > > > vendor "extension" that involves a different algorithm and code 
> > > > for load balancing but uses the same protocol messages and 
> > > > protocol state machine
> > as
> > > > the standard isn't a problem, nor is a vendor "extension" that 
> > > > involves
> > use
> > > > of a particular protocol operation with different parameters. 
> > > > Anything
> > that
> > > > would involve different code for protocol operation or 
> changes in 
> > > > the
> > state
> > > > machine (which amounts to the same thing) should require IETF 
> > > > standards action to be accepted into the protocol.
> > >
> > > Of course they require new code on the AP! Go back to Pat's RF 
> > > coloring example. How is LWAPP handling that? Through 
> > > vendor-specific extensions that enable an AC to communicate 
> > > something to the AP that is not part of the LWAPP spec. Most any 
> > > innovation that an AP vendor comes up with that needs control and 
> > > provisioning will need some vendor-specific extension to 
> handle it.
> > >
> > 
> > machine. With my service provider hat on, that's what I 
> need for doing 
> > a multivendor WLAN RAN. Any other code is the vendor's herbs and 
> > spices, and shouldn't affect protocol interoperability.
> 
> Perhaps you should stop putting on and taking off hats 
> because I'm not sure which James Kempf I'm speaking to. One 
> James Kempf wants vendor specific extensions removed from 
> LWAPP. Another says they're OK as long as they don't change 
> the protocol state machine. The vendor specific extensions in 
> LWAPP really don't seem to change the protocol state machine 
> so I'm having a hard time reconciling the two James Kempfs.
> 
> 
>   Dan.
>

---

From: "James Kempf" <[email-masked]>
Date: Sun, 10 Apr 2005 18:22:15 -0700

Dan,

> having a hard time reconciling the two James Kempfs.

Here's what I want: no vendor specific extensions that change the state
machine, which I think was the same criteria for Diameter (vendor-specific
AVPs are OK since they get processed within the existing state machine, new
commands which would require new code in peers need IETF standards action)
which is what I said in my original post. And, yes, the LWAPP extensions
don't seem to change the current state machine, they are like Diameter AVPs.
SLAPP vendor extensions, on the other hand, result in a vendor-specific
state machine being installed onto the WTP.

> affect interoperability of SLAPP.

I did.  SLAPP supports discovery, security, and image download but that's
*all* is supports (I discount the protocol negotiation part, that's just a
way to get a vendor-specific state machine onto the WTP, which is I believe
is harmful for interoperability). As I've said in the past, it is not a
complete solution to the problem and therefore isn't going to work for
satisfying CAPWAPs objectives, IMHO, because discovery, negotiation and
security is *all* that SLAPP does, and a real interoperable RAN control
protocol requires much more.

            jak

---

From: Dan Harkins <[email-masked]>
Date: Mon, 11 Apr 2005 09:49:57 -0700

James,

On Sun, 10 Apr 2005 18:22:15 PDT you wrote
> state machine being installed onto the WTP.

That's not what you said in your original post. What you said was, 

"Actually, I *do* want the vendor specific extensions removed from LWAPP, so
we'll have to disagree here."

You then went on to justify this statement by describing LWAPP's vendor
extensions as the same sort of vendor extensions that have caused problems
for service providers:

"Such vendor extensions have caused no end of problems for service providers
over the years in RADIUS, to the point that when Diameter was standardized,
the IESG specifically mandated that any Diameter command extensions (which
would require different code in the AAA server) must have IETF approval."

But now you're saying that LWAPP's vendor extensions are not like those
that have caused problems in the past and you don't want them removed
from LWAPP.

So what happened? Why did you change your mind? 

  Dan.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Apr 2005 14:26:57 -0700

Because I looked at the LWAPP spec for the first time in a while, and saw
that the vendor extensions were more like Diameter AVPs than commands. :-)

Being on two IETF design teams, monitoring Mobike, and trying to make sure
that CAPWAP results in a true interoperable standard, sometimes I end up
shooting from the hip due to lack of time.

Dan, people change their minds all the time. Think about it, could make
CAPWAP converge faster...

            jak

----- Original Message ----- 
From: "Dan Harkins" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 11, 2005 9:49 AM
Subject: Re: SLAPP and IETF DS Interoperability Requirement (was: Re:
[Capwap] Comments on objectives draft)

---

From: Dan Harkins <[email-masked]>
Date: Mon, 11 Apr 2005 14:58:20 -0700

On Mon, 11 Apr 2005 14:26:57 PDT you wrote
> CAPWAP converge faster...

Nothing wrong with changing your mind, especially when a previous opinion
was made with insufficent information.

A whole bunch of people changing their minds either way would speed things
in CAPWAP. And the preferred way that is done is by freely exchanging ideas
convincing people that your's is the best way to go.

Another way to speed up CAPWAP would be to engage in the IETF version
of a Zimbabwean election where opposition to one side is outlawed,
effectively guaranteeing the other side victory. Then the trappings of
process are run through and the pre-ordained winner is officially
declared the victor.

I hope we're doing the former and not the latter.

  Dan.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Apr 2005 15:38:26 -0700

> I hope we're doing the former and not the latter.

I hope so too, these are serious allegations, if allegations they are.

In the end, if you or anybody else think they've been dealt with unfairly,
an appeal is always possible. The IETF process is set up to be self
correcting in that way.

            jak