Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248, #249, #250, #251 & #252

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 2 Apr 2007 20:01:23 -0700

Hi Margaret,

Regarding issue 247, one pro and one alternate proposal does not sound like a consensus to me. The issue is of protocol extensibility and fwd/backward compatibility not so much about correctness (as both solutions do the right thing). It is very painful to change these things once they get cast in an rfc hence the group should think hard about extensible protocol design.

Thanks

Puneet

Sent from my handheld enabled by Broadcom EDGE/GPRS/GSM Processor and Bluetooth Technologies (www.broadcom.com)

 -----Original Message-----
From: 	Margaret Wasserman [mailto:[email-masked]]
Sent:	Monday, April 02, 2007 07:25 PM Pacific Standard Time
To:	capwap
Cc:	Dorothy Gellert
Subject:	[Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248, #249, #250, #251 & #252

Hi All,

As you have seen in previous e-mail from the editors, we discussed 8  
issues at the CAPWAP WG meeting in Prague.  This message is an  
attempt to confirm our consensus on those issues, and to close all  
eight issues by April 9th, so that the changes can be made in the  
CAPWAP documents and sent to the IEEE for review starting on April 10th.

Please Note:  This is a ONE WEEK consensus call ending on APRIL 9th,  
2007.

Usually, we have two week consensus calls, but given that the agreed  
resolutions were sent to the  mailing two weeks ago, and that there  
has been little or no objection to the proposed changes on the  
mailing list, we are having  a ONE WEEK consensus call, in order to  
allow the group to meet our IEEE review deadline.  If anyone has a  
strong objection to holding a one week consensus call on one or more  
of these issues, please let us know, and we will extend the consensus  
call for those issues to two weeks.

Three of the open issues are editorial, which means that the editors  
will make the fixes and close these issues.  Please let us know if  
there is any objection to closing the three issues listed below after  
the corresponding editorial changes have been made.

248 Both IPv4 and IPv6 Addresses not required.
250 Clarification onDTLSRehandshake/DTLSPeerAuthorize/ 
DTLSIncomingSession
252 Hearbeat timer is undefined

The resolution to one issue had been previously agreed on the list,  
but the edits were not included in the -02 draft, due to an  
oversight.  The changes were mentioned in the meeting and  
recirculated to the list by Pat Calhoun on March 19th, and there has  
been no objection to making them.  So, unless there is any objection  
before April 9th, the agreed change will be made by the editors, and  
the issue will be closed.

217 What is frame format with WTP encrypts/decrypts?

There were also four substantive issues discussed by the group:

247 MAC Addresses can be larger than 6 octets

For this issue, we agreed that we should be able to handle 8-byte MAC  
addresses in the CAPWAP protocol, and that it would be good to be  
flexible to other MAC address lengths.  There was general agreement  
in the room for a solution that replaced raw MAC addresses with a  
type-address pair.  Pat Calhoun proposed text on the list on March  
19th that uses the type-address pair, and Puneet Agarwal raised an  
objection indicating that he would prefer a type-length-address  
triplet.  No one else has offered support for the type-length-address  
triplet approach, so the chairs believe that we have rough consensus  
to proceed with the type-address approach, as discussed in Prague.

249 UDP-Lite as optional transport for CAPWAP

There was general agreement in Prague that UDP-Lite should be the  
mandatory transport for IPv6, with a checksum coverage length of 8.   
Text to this effect was circulated on the list on March 19th, and  
there has been no objection.  There was a question about CAPWAP's use  
of UDP ports, and a separate issues (#254) has been opened to clarify  
that behavior.  So, seeing no objection, the chairs believe that the  
group has consensus to make the changes circulated on March 19th to  
address this issue.

251 Retransmission of control packets is not exponential

There was agreement in Prague that this needed to be fixed.  Proposed  
text was sent to the list by Pat Calhoun on March 19th, and no  
objections or questions have been raised about that text.  So, the  
chairs believe that the WG has consensus to resolve this issue by  
making the change proposed on the list.

138 Support and negotiation of WTP data encryption in the CAPWAP  
protocol

This was the most contentious issue discussed in Prague, and it was  
difficult for us to reach consensus within the room about how to  
close this issue.  In the end, we reached consensus that the working  
group could accept the following resolution:

    To provide system component interoperability, the WTP and AC must
    support 802.11 encryption/decryption at the WTP.  The WTP and AC MAY
    support 802.11 encryption/decryption at the AC.

This text was circulated on the list by Pat Calhoun on March 19th.   
There has been no objection on the mailing list, so the chairs  
believe that the WG has rough consensus to proceed with this change,  
as circulated on the list.

Mani, Dorothy & Margaret
The CAPWAP Co-Chairs

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 3 Apr 2007 07:54:24 -0400

Hi Puneet,

The consensus call for issue #247 was not based simply on the e-mail  
exchange between you and Pat Calhoun.  We had general agreement in  
Prague to pursue a type-address approach to resolve this issue, so we  
would need to see sufficient support for your type-length-address  
triplet proposal to override the group consensus from Prague.  So  
far, you are the only person who has supported your type-length- 
address triplet proposal, and that is not sufficient to override the  
consensus.

FWIW, I do agree that people should think about the trade-offs  
between different technical proposals.  If they believe that a type- 
length-address triplet would be a superior technical approach,  
considering all factors such as extensibility and efficiency, they  
should say that on the list.  Otherwise, the assumption is that the  
group continues to agree with the consensus we reached in Prague to  
use a type-address pair.

Please let us know if you have any further concerns about this  
consensus call.

Margaret

On Apr 2, 2007, at 11:01 PM, Puneet Agarwal wrote:

> Hi Margaret,
>
> Regarding issue 247, one pro and one alternate proposal does not  
> sound like a consensus to me. The issue is of protocol  
> extensibility and fwd/backward compatibility not so much about  
> correctness (as both solutions do the right thing). It is very  
> painful to change these things once they get cast in an rfc hence  
> the group should think hard about extensible protocol design.
>
> Thanks
>
> Puneet
>
>
>
> Sent from my handheld enabled by Broadcom EDGE/GPRS/GSM Processor  
> and Bluetooth Technologies (www.broadcom.com)
>

---

From: Scott G Kelly <[email-masked]>
Date: Tue, 03 Apr 2007 05:50:37 -0700

I don't recall any detailed discussion of 247 in Prague, and in any
event, whatever judgement you might have of the consensus there, it
seems like this particular thread should be a consensus *call* on each
of these issues, shouldn't it? Many people on this list weren't in
Prague (I would venture to guess that *most* people on this list weren't
in Prague).

As for 247, I am inclined to agree with Puneet. Since the declaration
following the interim meeting was that the version number would only be
incremented for major changes in the protocol (which this would not
represent), then it seems clear that there could be two implementations
professing to support the same version number, one of which did not
recognize this payload, and would have to fail entirely if it received
it. That seems broken to me.

The alternative, of course, is to revisit the version number
construction, and have a minor version field which is incremented
whenever payload types are added or modified.

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 3 Apr 2007 07:20:42 -0700

Scott, that doesn't solve the problem. This compatibility issue occurs
when one implements a specific binding that uses a new MAC Address
length. I don't see how adding a minor number would solve the problem. I
think the current plan is the right approach, although we need to get
through Puneet's comment.

PatC 

-----Original Message-----
From: Scott G Kelly [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 5:51 AM
To: Margaret Wasserman
Cc: capwap; Dorothy Gellert
Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248,
#249, #250, #251 & #252

Margaret Wasserman wrote:
> triplet proposal to override the group consensus from Prague.  So far,

> you are the only person who has supported your type-length- address 
> triplet proposal, and that is not sufficient to override the 
> consensus.
> 
> FWIW, I do agree that people should think about the trade-offs between

> different technical proposals.  If they believe that a type- 
>> sound like a consensus to me. The issue is of protocol extensibility 
>> and fwd/backward compatibility not so much about correctness (as both

>> solutions do the right thing). It is very painful to change these 
>> things once they get cast in an rfc hence the group should think hard

>> about extensible protocol design.
>>
>> Thanks
>>
>> Puneet
>>
>>
>>
>> Sent from my handheld enabled by Broadcom EDGE/GPRS/GSM Processor and

>> Bluetooth Technologies (www.broadcom.com)
>>
>> Subject:	[Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248,

>> #249, #250, #251 & #252

---

From: "Merwyn Andrade" <[email-masked]>
Date: Tue, 3 Apr 2007 07:28:33 -0700

Margaret/Mani/Dorothy
I agree with Scott and feel the same way about #138
(encryption/decryption at WTP/AC) which was clearly debated on the list
and yet we deemed we had arrived at consensus for making it optional on
the WTP after the meeting at Prague (which I unfortunately could not
attend). 
Merv

Merwyn (Merv) Andrade
CTO, Aruba Networks
[email-masked]

-----Original Message-----
From: Scott G Kelly [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 5:51 AM
To: Margaret Wasserman
Cc: capwap; Dorothy Gellert
Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248,
#249, #250, #251 & #252

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 3 Apr 2007 11:02:55 -0400

Hi Scott,

> Prague (I would venture to guess that *most* people on this list  

I'm sorry that you don't remember the discussion of issue 247, but  
there was  a discussion...  Pat Calhoun presented the issue in his  
slide deck of open issues.  We talked about this issue, agreed that  
we at least needed to support 8-byte MAC addresses for 802.16,  
discussed the possibility of using IEEE EUI-64 identifiers and ended- 
up deciding that a more general approach, using a type and an  
address, would be preferred so that we could support addresses longer  
than 8 bytes if that was ever necessary.  The discussion in the WG  
meeting was not very long or contentious.

This thread is meant to be the mailing list verification of the  
consensus points that were reached in Prague.  The proposed  
resolution was circulated right after the meeting, and people have  
had time to consider it.  So, this _is_ the time when people on the  
mailing list who could not be at the Prague meeting should let us  
know if they do not agree with the consensus that was reached during  
the meeting.

If I understand what you're saying, you'd prefer an entirely separate  
consensus call on the list, but that approach is not supported by the  
IETF WG process BCP (RFC 2418), which indicates that consensus that  
is reached in a WG meeting should be "verified" on the list.  RFC  
2418 explicitly says, "In the case where a consensus which has been  
reached during a face-to-face meeting is being verified on a mailing  
list the people who were in the meeting and expressed agreement must  
be taken into  account.  If there were 100 people in a meeting and  
only a few people  on the mailing list disagree with the consensus of  
the meeting then the consensus should be seen as being verified."   
Now, clearly we didn't have 100 people in the room in Prague, but we  
did have enough people actively engaged in these discussions that one  
person who expresses a dissenting view on the mailing list should not  
be able to override the consensus that was reached.

So, the process described in RFC 2418 is the process that we are  
following...  We are attempting to verify the decisions reached in  
the meeting on the mailign list.  If there are people on the list who  
could not attend the meeting and who disagree with the agreement that  
was reached during the meeting, about issue #247 or any other issues,  
they should definitely speak up on the list as soon as possible.  We  
are coming into the closing stages, and it is important that people  
send their opinions to the list in a timely manner when proposals are  
circulated, so that we can reach real consensus on how to resolve the  
remaining issues, and publish the document.

I will leave your specific technical points regarding issue 247 for  
group discussion, as I don't have a strong personal preference about  
which approach we take.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 3 Apr 2007 11:24:00 -0400

Hi Merv,

I hope that my response to Scott made it clear what process we are  
trying to follow...

There was a long discussion of issue #138 in the WG meeting.  At the  
end, we did not make the decision by having one choice win out over  
the other due to technical merits.  Both choices will work from a  
technical standpoint, so it was more a matter of preferences.

We had very strong consensus that the WTP encryption mode should be  
mandatory on both ends, so we agreed that either way, we would want  
to mandate support for WG encryption on both the AC and the WTP.  The  
discussion basically came down to a question of whether to mandate  
WTP support for centralized encryption or not.

There were some people who supported making WTP support for  
centralized encryption mandatory, and a larger number of people who  
preferred to make it optional, but no clear consensus between those  
choices.  In the end, we ended-up taking a poll regarding how many of  
the WG members could accept a specification where WTP support for  
centralized encryption was optional and how many could accept a  
specification where WTP support for centralized encryption was  
mandatory.  The large majority of the group could accept a  
specification where WTP support for centralized encryption was  
optional, while only a small number could accept a specification  
where WTP support for centralized encryption was mandatory.

This was a difficult situation for the WG, because both choices are  
technically viable, and there are very few (if any) strong technical  
criteria that we could use to decide which should be mandatory and  
which should be optional on each end.  However, this is something  
that we have to decide in order to publish the document, so we  
declared consensus to proceed with the choice that was acceptable to  
the largest majority of the group.

If you are concerned about the process that is being used, please  
read the message I just sent to Scott and let us know if it addresses  
your concerns.  If not, please express your remaining concerns, and  
we will try to address them.

If you strongly disagree with the decision to make WTP support for  
centralized encryption optional (which isn't entirely clear from your  
message), you should send a message to the list expressing your  
disagreement with that decision.  It would be ideal if you could also  
state why you disagree with the decision and what you think we should  
do instead.

Your message alone won't be enough to overturn the consensus of those  
who attended the Prague meeting, but if there are several people who  
didn't attend the meeting who also disagree with the decision, the  
consensus from the meeting will not hold, and we will have to reopen  
discussion of this issue, which will likely delay publication of the  
document.

Thanks,
Margaret

---

From: <[email-masked]>
Date: Tue, 3 Apr 2007 12:12:33 -0500

Hi Merv,

If when you say "agree with Scott and feel the same way about #138, you
are implying that issue 138 (encryption/decryption at WTP/AC) was not
discussed in detail at the F2F in Prague, I would have to disagree with
that statement.  

Issue 138 had the majority of the WG's time, the discussion on the list
was recaped by slides created and presented by the chairs, and both
sides of the issue were argued by the chairs.  Everyone at the F2f had
the opportunity, again, to debate the issue.

In addition, we held several show of hands and the results were the same
and reflected in the Editor's summary posted on 3/19 and again in our
consensus call posted yesterday.

As the consensus check is still active until April 9th, the WG still has
time to comment on the WG's resolution, but the issue will close on
April 9th.

Best Regards,
Dorothy 

> From: ext Merwyn Andrade [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 7:29 AM
> To: Scott G Kelly; Margaret Wasserman
> Cc: capwap; Gellert Dorothy (Nokia-SIR/MtView)
> Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, 
> #247, #248, #249,#250, #251 & #252
> 
> Margaret/Mani/Dorothy
> (encryption/decryption at WTP/AC) which was clearly debated 
> on the list and yet we deemed we had arrived at consensus for 
> making it optional on the WTP after the meeting at Prague 
> (which I unfortunately could not attend). 
> Merv
> 
> Merwyn (Merv) Andrade
> CTO, Aruba Networks
> [email-masked]
> 
> 
> Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, 
> #247, #248, #249, #250, #251 & #252
> 
> I don't recall any detailed discussion of 247 in Prague, and 
> in any event, whatever judgement you might have of the 
> consensus there, it seems like this particular thread should 
> be a consensus *call* on each of these issues, shouldn't it? 
> Many people on this list weren't in Prague (I would venture 
> to guess that *most* people on this list weren't in Prague).
> 
> As for 247, I am inclined to agree with Puneet. Since the 
> declaration following the interim meeting was that the 
> version number would only be incremented for major changes in 
> the protocol (which this would not represent), then it seems 
> clear that there could be two implementations professing to 
> support the same version number, one of which did not 
> recognize this payload, and would have to fail entirely if it 
> received it. That seems broken to me.
> 
> construction, and have a minor version field which is 
> incremented whenever payload types are added or modified.
> 
> extensibility 
> >>     support 802.11 encryption/decryption at the WTP.  The 
> WTP and AC 
> >> MAY

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 3 Apr 2007 15:11:22 -0400

Hi Scott,

Regarding the technical details of issue #247, would you be okay with  
the length-address pair proposal that Puneet and Pat have reached  
agreement on?  Would that address your concerns about version  
compatibility?

If Scott is okay with this, is there anyone who objects to the length- 
address pair proposal?  Or do we have consensus to make that change?

Thanks,
Margaret

---

From: "Merwyn Andrade" <[email-masked]>
Date: Tue, 3 Apr 2007 16:27:09 -0700

Hi Dorothy

Sorry just got to this.
To be precise what I'm agreeing with Scott on is his comment
" Many people on this list weren't in Prague (I would venture to guess
that *most* people on this list weren't in Prague)."

We debated this on the list and I'm sure this was further discussed at
the face-to-face in Prague (thank you for giving it more time). My
assessment from the pre-meeting conversation was that there was
no-consensus on this issue and if the mailing list is a super-set of the
voters rather than a limited face-to-face at Prague. Wouldn't it be
logical that the list is the place we should go to for consensus?

Again I'm an IETF neophyte and believe that clear articulation of one's
position on lists as an individual is the best way to articulate one's
position, create a public record as opposed to an anonymous room full of
hands in nice exotic places (not at the size I can sponsor many of my
employees to be "individuals" yet ;-). I was not aware that it would be
necessary to restate/debate my position at a face-to-face meeting or
would have made the trip to Prague as might have others. 

Thank you for your patience, but this issue is important for CAPWAP's
future success in 1000's of my major enterprise customers and some of
the largest in the world that are successfully using centralized
encryption. I am sure there are similarly many 1000s of customers using
distributed encryption. I want to give each set the option to
mix-and-match WTPs from other vendors ACs via a interoperable CAPWAP
protocol. 

BTW I also support distributed encryption in my product (so I have clear
visibility into how easy both of these are to support in an actual
implementation) so I believe it is just FUD when folks say this is too
complicated (they have not done this in working code so forgive me if
I'm skeptical). 

As I have argued on the list the functionality and security properties
between centralized encryption WTP implementations v/s distributed are
clearly different as evidenced when I referred you all to the DoD 8100.2
policy around end-to-end and supported by comments from Charles. These
have also documented in drafts by our security advisors Scott and
Charles. Making centralized encryption optional from the baseline
mandatory-to-implement will prevent my DoD customers from mix and
matching COTS (commercial off the shelf gear - what they are looking
for) gear and makes "baseline" CAPWAP useless for them. 

I can understand why my competitors would like to prevent me from
proving that centralized encryption is better by claiming they didn't
support it in their WTPs since it wasn't part of the baseline to keep a
lock on their WTPs for their customers but let's remember the customers
we are building this "interoperable mix-and-match protocol" for as
opposed to parochial vendor interests. 

Let's give the market the opportunity to choose between the two and
CAPWAP will have a chance. 

Thank you for your time.

Regards
Merv

Merwyn (Merv) Andrade
CTO, Aruba Networks
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 10:13 AM
To: Merwyn Andrade; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248,
#249,#250, #251 & #252

Hi Merv,

Best Regards,
Dorothy

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 3 Apr 2007 19:49:42 -0400

Hi Merv,

In this message, I'll respond to the process points that you've raised.

I do have some personal response to your technical comments, but I  
will include those comments in a separate message, in the hopes of  
avoiding any confusion between what I am saying a chair and what I am  
saying as an individual.

> logical that the list is the place we should go to for consensus?

It is true that many members of the WG were not in Prague.  However,  
there were a significant number of people present in Prague, and it  
is likely that some of them may not be reading the mailing list right  
now.  That's why the IETF process requires that we consider people in  
both venues -- the people who express an opinion in the meeting AND  
the people who express an opinion on the list, not just one or the  
other.

The people who were at the meeting expressed their opinions in  
Prague.  The consensus text from the meeting was circulated on the  
list two weeks ago, and people on the list could have commented on it  
or asked questions about it, but few did.  Now, this is the formal  
consensus confirmation on the list, where people who could not be at  
the meeting should let us know if they do not agree with the  
consensus that was reached at the meeting.

> would have made the trip to Prague as might have others.

You can certainly influence an IETF WG by stating your opinions via e- 
mail and participating only on the mailing list.  However, we also  
hold discussions and reach tentative conclusions (to be confirmed on  
the list) during face-to-face meetings.  There are types of  
discussions that are best held in face-to-face meetings, where people  
can have a quicker back and forth than on the mailing list, and  
people who want to participate in those face-to-face discussions need  
to attend the meetings to do so.  We'd certainly be happy to have you  
at a CAPWAP meeting if/when you are able to attend.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 3 Apr 2007 20:49:36 -0400

Hi Merv,

<chair hat=off>

Here is the message where I am responding as an individual to the  
technical portions of your message.  The above notation is pseudo-XML  
shorthand for the chair taking his/her hat off, which means that I am  
now speaking as an individual.

> for) gear and makes "baseline" CAPWAP useless for them.

I've heard this argument before, but  I don't really understand it.    
Regardless of what decision we make about Issue #138, a "baseline"  
CAPWAP implementation does not have to support centralized  
encryption, because a "baseline" CAPWAP implementation does not have  
to support split-MAC mode at all.  Any customer who wants to use  
centralized encryption would already have to specify one option  
(split-MAC), so I don't understand why it would be a problem for them  
specify two options.

I understand that the U.S. DoD may end-up requiring the centralized  
encryption option if/when they decide to use CAPWAP.  If they do  
specify centralized encryption, then vendors who want to sell to the  
DoD will provide equipment that implements it.  I don't think that  
the U.S. DoD is any less likely to specify (or purchase) equipment  
that supports their preferred security model, just because that model  
is listed as optional in the IETF's CAPWAP specification.  Do you?

Let me share some of my reasoning about why I personally think it  
makes sense for the distributed model to be mandatory in both modes,  
and for the centralized encryption model to be optional.

In local-MAC mode, the only available security model is the  
"distributed model" where the 802.11 encryption terminates at the  
WTP.  There was strong agreement in Prague that it also made sense to  
make this model mandatory on both ends in split-MAC mode, since both  
ends will already have the software and hardware to support this  
model in local-MAC mode.

In the past, we reached strong agreement that we would not mandate  
centralized encryption on the AC side, as many current ACs do not  
have hardware support for encryption, and we do not want to add that  
hardware requirement to all future ACs.  So, there will be CAPWAP- 
compliant hardware that does not support centralized encryption.  I  
don't see why it makes sense to require all WTPs to support  
centralized encryption, when many of them may be controlled by ACs  
that are incapable of supporting that mode.  So, I think it makes  
sense to for the centralized encryption model to be optional on both  
ends.

> opposed to parochial vendor interests.

IMO, it is not a goal of the IETF to mandate a technology so that the  
proponents of that technology can prove that it is better...

I think it should be our goal to write a specification that will  
interoperate and that contains a minimal base set of features that  
will serve a fairly large percentage of the target end-users.  We may  
also choose to include additional options, so that the protocol can  
serve a wider group of end-users, with the hope that it can be more  
widely deployed.   I personally think that a specification that  
mandates support for the distributed security model in both local-MAC  
and split-MAC modes and allows the centralized encryption model as an  
option for split-MAC mode meets those goals.

In my experience, a technology never becomes successful because it is  
mandated by the IETF.  A technology becomes successful because it  
solves the customer's problems better than other available  
technologies.  If it is true that centralized encryption is a better  
solution than distributed encryption for the majority of end-users, I  
believe that end-users will demand that the it is supported in the  
products they purchase, whether we mandate support for the  
centralized encryption model or not.  And frankly, if vendors do not  
see customer demand for a specific feature, they won't implement it,  
even if we do try to mandate it.

</chair>

Margaret

---

From: "Merwyn Andrade" <[email-masked]>
Date: Wed, 4 Apr 2007 17:32:42 -0700

Margaret 

Sorry just got back from travel and couldn't get to this sooner. Thanks
for your comments, your last two posts clarified your position and what
transpired at Prague. 

I missed the split-MAC being optional piece. That is indeed very
unfortunate for the baseline CAPWAP standard since the majority of the
switch architectures out there (accounting for > 90% of market-share)
employ exactly that model. 

To your point about
<Margaret> " If you strongly disagree with the decision to make WTP
support for centralized encryption optional (which isn't entirely clear
from your  message), you should send a message to the list expressing
your disagreement with that decision.  It would be ideal if you could
also state why you disagree with the decision and what you think we
should do instead."

I strongly disagree with the decision and reasons are as follows: 

Today the market has migrated to a model where folks pick a system AC
and WTP from the same vendor.
In any of these WLAN switch architecture based systems, the WTP follows
the lead of the AC.
With my comment above about the majority of vendors doing split-MAC it
stands to reason that the only way customers would maintain flexibility
in choosing their ACs (centralized or dist encryption supporting) and
leverage a open-standards based CAPWAP would be to have WTPs that
support both (centralized and distributed encryption support). See
further data to prove this below.

To your point about
<Margaret> "This was a difficult situation for the WG, because both
choices are technically viable, and there are very few (if any) strong
technical criteria that we could use to decide which should be mandatory
and which should be optional on each end." 

IMHO this is the wrong question. This is not about technical criteria
but about the group ensuring that the baseline CAPWAP standard measures
up to some sensible least-common-denominator high-bar of market reality.
If we don't do this no one adopts it, or the vendors who want to do
bake-offs with a claim to adopt/support it are really doing so only for
the RFP checkoffs and are not really interested in their WTPs being
interoperable and being managed by other SM-based-ACs out there. Is this
what you want as chairs of this WG ?

Pick your favorite market share report ..I list one as informational
(just to make my point)
http://www.infonetics.com/resources/purple.shtml?ms07.wl.4q06.nr.shtml 
The Top 5 vendors with switch market share (you can read through the
technical docs to figure out where encryption is performed ..this is not
a secret) C-Centralized Enc AC, D-Dist Enc AC, CD -Centralized or
Distributed AC, SM-Split MAC, F - Legacy or Standalone Fat APs

Cisco-SM-D,F
Aruba/Alcatel-SM-CD,
Symbol/Motorola-SM-C,F
Trapeze/Nortel/3COM-SM-D,F
Meru/Foundry SM-D 

Independent of C/D/CD support they all have one thing in common .. Split
MAC (SM).

Hopefully you can see why I maintain my position given the market
reality. 

If I were in Prague my argument to the group would have been : 
a) For this effort to be successful and given the time we've spent on
this we need to see a high enough bar for a baseline CAPWAP spec. This
means we need to have WTPs that support C and D mandatory for the Split
MAC based ACs out there.
b) This is not about a strong technical decision but about allowing
CAPWAP capable WTPs in the real (SM based) world the chance to follow
what a distributed encryption AC, or a centralized encryption AC tells
them to do. Hence their need for mandatory support both schemes.
b) It is unfortunate that our mistake in leaving "SM optional" is now
the tail wagging the "WTPs mandatory to support distributed only" dog. 

I encourage folks to consider reopening that decision given the market
reality details above.

Hope this clarifies my position.

Regards
Merv 

Merwyn (Merv) Andrade
CTO, Aruba Networks
[email-masked]

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 8:24 AM
To: Merwyn Andrade
Cc: Scott G Kelly; capwap; Dorothy Gellert
Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248,
#249, #250, #251 & #252

Hi Merv,

Thanks,
Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 5 Apr 2007 08:07:22 -0400

Hi Merv,

> employ exactly that model.
[...]
> I encourage folks to consider reopening that decision given the market

The decision that split-MAC mode would be optional was made a long  
time ago, so unless some new technical information comes to light  
that indicates that there is a blocking technical problem with this  
(which is very unlikely), we are not going to reopen that question now.

So, we need to make the decision about which of the two security  
models is mandatory or optional on each end with the understanding  
that split-MAC mode _is_ optional.

Margaret

---

From: "Merwyn Andrade" <[email-masked]>
Date: Thu, 5 Apr 2007 05:50:22 -0700

Margaret

Even if you don't reopen the Split-MAC (SM) decision (unfortunate, but I
can understand in the interests of moving things forward) please take
into account my points about the market data I have provided that make
the case for #138 to not have one side optional, or refute it. 

Counters to the arguments in summary made so far
1) Arguments that this is difficult to implement etc - these can only be
valid if folks have tried. Out of the #1, 2 and 3 market leaders for
WLAN Switching out there (Cisco, Aruba and Symbol - pick your favorite
report for ordering), two out of the three (Aruba and Symbol) support
centralized (C) encryption and distributed (D) showing that it is a
matter of choice not degree of difficulty. Hopefully the group can see
why the #1 player would not like the market to have this option (C) in
there. I can understand their interests in not seeing the playing field
leveled but forgive me for not being too sympathetic.
2) We chose Split-MAC as optional and so this should be optional too -
This is simply compounding one mistake with another. Even if we don't
reopen the SM decision I would request we look at each issue (in this
case #138) and if there is fresh context on market data that was never
provided before it behooves us to do the right thing for our customers
and the base CAPWAP standard.
3) Conforming to the DOD 8100.2 directive - it is possible to build
systems yhat meet this directive with both centralized and distributed,
but as I have shown more gear is required as well as FIPS certifications
of APs are needed if they mate up to the distributed encryption only AC
suppliers. On the other hand any vendor of APs/WTPs can with CAPWAP
centralized encryption support (on their WTP) mate up to centralized
encryption ACs (for now Aruba/Symbol-Motorola) and maybe in future more
to immediately make more CAPWAP WTPs available to one of the largest
emerging markets in the world Fortune #1 (i.e. the US.Govt).

We need to make baseline CAPWAP useful in the real world and keep our
options open on #138. The world is SM, we and others have implemented
both C and D, and I would like to see arguments made against my points
that stand up to scrutiny. 

Regards
Merv  

Merwyn (Merv) Andrade
CTO, Aruba Networks
[email-masked]

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 5:07 AM
To: Merwyn Andrade
Cc: Scott G Kelly; capwap; Dorothy Gellert
Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248,
#249, #250, #251 & #252

Hi Merv,

[...]

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 5 Apr 2007 09:12:56 -0400

Hi Merv,

We understand that you disagree with the proposed resolution to issue  
#138, and we will certainly take your opinion into account in our  
final consensus determination early next week.

Margaret

---

From: "Sudhanshu" <[email-masked]>
Date: Thu, 5 Apr 2007 10:42:48 -0700

Here is my feedback on the consensus request.

Issue #138 - to wider adoption of interoperability, WTP should support both
Distributed and Centralized crypto.
Issues #217 - I think the proposed solution is not complete. E.g Figure 3
says the "protected frame" is controlled by AC only but in case of
encryption at WTP, "protected frame" should be modified both at AC and WTP. 
Issues #247 - I would prefer to have the type (enum) field instead of the
length field. I don't think supporting arbitrary length field will help any
body. There is already two published MAC (EUI-48 and EUI-64) and we should
support this. Beyond this, I don't think we need to worry. I think it is a
cleaner solution compared to length based proposal. 
Issues #248 - agree with the proposed solution. But I just want to make sure
that solution does not preclude both the message element present in the
discovery response.
Issues #249 - The only reason UDP-lite has been considered is for
performance purpose. So I don't understand the rational behind making
UDP-lite as a mandatory protocol for IPv6. I understand it is backward
compatible to UDP but it is not UDP. Also it used different protocol number.
So I will say we should make UDP-lite as optional protocol for IPv6.
Issues #250 - No comment
Issues #251 - Agree with the general requirement and solution but I don't
agree for tying this interval with the echo interval. Instead proposed
solution should preclude the "echo request" from the section 4.4.3
(retransmission policy). And we can keep the "echo request" retransmission
to "echo interval" like "hello messages" in other protocols.
Issues #252 - Agree with the changes in language.

-Suds

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 6:13 AM
To: Merwyn Andrade
Cc: capwap; Dorothy Gellert
Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248,
#249,#250, #251 & #252

Hi Merv,

Margaret

---

From: "Michael Montemurro" <[email-masked]>
Date: Fri, 6 Apr 2007 16:13:31 -0400

Merwyn,

Thank you for your North American centric view of the WLAN switch
market. Siemens has a significant marketshare world-wide and supports
local-MAC CAPWAP architecture. Both types of architectures have their
strengths and weaknesses. Local MAC architectures provide a much more
flexible architecture for deploying WLANs. They give the option of
bridging traffic locally or tunneling to the controller. It's
unfortuntate that some of the market leaders don't see the advantages
of both architectures.

Given that every WLAN chipset on the market today does onboard
encryption, I see no technical advantage in implementing encrption at
the controller. I only see disadvantages in latency and scalability. I
acknowledge that there are some customer scenarios where encryption at
the AC may be desired. That is why I believe it should be an option
for CAPWAP.

Cheers,

Mike

---

From: Jim Murphy <[email-masked]>
Date: Fri, 06 Apr 2007 17:42:24 -0700

Michael,

Well stated. There is another thorny problem with the requirement
to support centralized encryption at the WTP. When tunneling
back local-MAC frames to the AC you would not prefer to
use 802.11i encryption but would rather prefer to use
DTLS encryption on the data plane. Using DTLS to secure
data to the AC has the positive attribute in that by running
local MAC on the WTP you can make effective use of 802.11n
features like frame aggregation while still supporting centralized
encryption. If we want to make centralized
encryption a requirement, we should consider the merits of
DTLS over 802.11i. To avoid such issues, centralized
encryption should be optional at the WTP and the AC.

Thanks,

Jim