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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 2 Apr 2007 20:12:59 -0700

Puneet, in your proposal the type and length fields are redundant. In the spirit of byte conservation, I can't see how we can justify having both.

In my previous response to your point, I can't see how an implementation could receive a format it doesn't understand. It would have to support the binding to begin with.

PatC

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

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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

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

Puneet,
 
As I was trying to say, the type implies length, but I believe that you
are looking for an explicit length instead. This allows general purpose
built HW to be able to parse the frames, and not require a new ASIC to
handle a future wireless technology that may use a longer MAC Address
length. If that is the case, let's agree to replace type with length,
and not require yet another field. 
 
PatC

________________________________

From: Pat Calhoun (pacalhou) 
Sent: Monday, April 02, 2007 8:13 PM
To: Puneet Agarwal; Margaret Wasserman; capwap
Cc: Dorothy Gellert
Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248,
#249,#250, #251 & #252

Puneet, in your proposal the type and length fields are redundant. In
the spirit of byte conservation, I can't see how we can justify having
both.

In my previous response to your point, I can't see how an implementation
could receive a format it doesn't understand. It would have to support
the binding to begin with.

PatC

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

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,

Mani, Dorothy & Margaret
The CAPWAP Co-Chairs