Subject: RE: [Capwap] Recap of eval recommendations

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 20 Dec 2005 13:31:16 -0800

Dorothy,

In re-reading the evaluation recommendations document, I see the
reference to "a CAPWAP protocol", but nowhere do I see an explicit
request (or recommendation) to rename LWAPP to CAPWAP. I view the use of
"a CAPWAP protocol" as really no different from the AAA WG refering to
"an AAA protocol", while the name of the actual protocol is Diameter.

In my time at the IETF, I have found that the WG name and a protocol
name, are not necessarily one and the same. The old RADIUS WG is a
different beast because the WG was created to document an existing
protocol.

Further, while I could be wrong, I don't recall having such a discussion
within this mailing list.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, December 20, 2005 10:47 AM
> To: Pat Calhoun (pacalhou); [email-masked]
> Subject: RE: [Capwap] Recap of eval recommendations
> 
> Pat-
> 
> Don't forget that according to the recoommdations and WG 
> agreement the new Working group draft based on LWAPP will be 
> named CAPWAP. 
> 
> Thanks,
> Dorothy
> 
> 
> -----Original Message-----
> From: ext Pat Calhoun (pacalhou) [mailto:[email-masked]]
> Sent: Tuesday, December 20, 2005 8:10 AM
> To: [email-masked]
> Subject: [Capwap] Recap of eval recommendations
> 
> All,
> 
> As I'm preparing for the next version of the lwapp 
> specification, I'd like to get some closure on the evaluation 
> team's recommendations. Here is a recap from previous e-mail threads.
> 
> Section 9.1.1
>    Summary: Change message element's type field from an 8 bit 
> to 16 bit field
>    WG Update: no opposition to the change
>    Pat's Recommendation: Make the change
>  
> Section 9.1.2
>    Summary: Change LWAPP control security to DTLS
>    WG Update: much debate on this topic, but Scott Kelly and 
> Eric Escorla are working on a draft
>    Pat's Recommendation: WG debates the contents of the draft 
> and then makes a decision
> 
> Section 9.1.3.1:
>    Summary: Introduce tunneling in Local MAC mode, meaning 
> the following modes would exist in LWAPP:
>             1. Split-MAC: Tunnel native MAC frames in UDP 
> (e.g., 802.11)
>             2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames
>             3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP
>    WG Update: Rough consensus on adding this mode of operation
>    Pat's Recommendation: I'm still not crazy on this change 
> as I see this as adding complexity to the
>                          protocol because we are simply 
> adding yet another mode of tunneling, where split
>                          MAC already handles data tunneling. 
> However, in the spirit of compromise, I will
>                          add text to support this mode of 
> operation as it does appear to reflect rough
>                          consensus.
> Section 9.1.3.2:
>    Summary: Pick one mode of operation and make it the default value
>    WG Update: Little discussion on this topic so far, but 
> some agreement on mode 2 (above)
>    Pat's Recommendation: Postpone this change until after the 
> publication of the first draft.
> 
> Section 9.2.1: 
>    Summary: Move Add Mobile outside of 802.11 binding section
>    WG Update: No discussion
>    Pat's Recommendation: This is a reasonable request since 
> the Delete Mobile is outside of the binding
>                          section. I think we should accept 
> this request and would propose having this in
>                          the first draft.
> 
> Section 9.2.2:
>    Summary: Remove layer 2 mode
>    WG Update: Limited discussion (2 people so far)
>    Pat's Recommendation: Push this change until after the 
> publication of the first draft. If there is rough
>                          consensus, either remove it 
> entirely, or create a separate document that only 
>                          defines the layer two encapsulation mode (my
> preference)
> 
> Section 9.2.3: 
>    Summary: Either use L2TP or GRE for encapsulation
>    WG Update: Although I raised the issue, no discussion on 
> this topic on the list
>    Pat's Recommendation: While I understand the overall 
> recommendation, I believe that there are 
>                          misunderstandings of what this 
> really means (see 
>  
> http://lists.frascone.com/pipermail/capwap/msg01864.html). My 
> recommendation is 
>                          that do not implement this change.
> 
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> _________________________________________________________________
> 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: Dorothy Stanley <[email-masked]>
Date: Wed, 21 Dec 2005 06:35:39 -0800

Pat, all,

I support Dorothy G's request, to re-name the protocol from LWAPP to CAPWAP
(or another name) as
the first draft of the protocol produced by the CAPWAP Working Group.

The name "LWAPP" is also associated with specific product(s) and
vendor(s).The
protocol developed by the CAPWAP WG will be distinct from the "traditional"
usage of "LWAPP".

For clarity, the protocol developed by the CAPWAP  WG should have a distinct
name. Actually,
the name need not be "CAPWAP", it could be "CAPP" - Control of APs Protocol,
or another distinct
name that the group decides on.

Dorothy Stanley