Subject: [OPSAWG] Call for adoption, two capwap-related documents

From: Melinda Shore <[email-masked]>
Date: Thu, 11 Apr 2013 06:36:40 -0800

This is a call for working group adoption of two drafts
related to capwap use for 802.11n.

http://www.ietf.org/id/draft-shao-opsawg-capwap-hybridmac-00.txt
http://www.ietf.org/id/draft-chen-opsawg-capwap-extension-00.txt

Since the IETF 86 meeting the authors have gotten expert review
of their documents and feel that the documents are ready for
working group adoption.

We'll be assessing consensus on 25 April 2013.  Please indicate
which draft or drafts you're supporting or not supporting.

Thanks,

Melinda, Scott, and Chris

---

From: David Harrington <[email-masked]>
Date: Thu, 11 Apr 2013 11:28:04 -0700

Which types of expert review? CAPWAP experts? 802.11n experts? Security
experts? Network management experts? Operator experts?

--
David Harrington
[email-masked]
+1-603-828-1401

On 4/11/13 7:36 AM, "Melinda Shore" <[email-masked]> wrote:

>_______________________________________________
>OPSAWG mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/opsawg

---

From: Melinda Shore <[email-masked]>
Date: Thu, 11 Apr 2013 10:29:45 -0800

> experts? Network management experts? Operator experts?

Apologies for the lack of clarity.  CAPWAP, 802.11n,and
operators.

Melinda

---

From: joel jaeggli <[email-masked]>
Date: Thu, 11 Apr 2013 12:50:01 -0700

> Apologies for the lack of clarity.  CAPWAP, 802.11n,and
capwap overlaps with the ieee and the previous document series had a 
review  team with expertise on both sides. even if extensions might not 
require harmonization (I'm not saying they do or don't), review should 
be to insure the lack of messy accident.

---

From: Hui Deng <[email-masked]>
Date: Fri, 12 Apr 2013 11:00:07 +0800

thanks chair, I have seen the frustration before about IETF's product of
capwap.
Today, there are opeartors coming back and like to use IETF's CAPWAP,
It will be more than millions usage and will help SP's wifi deployment.

Seeing that there is no any revision of IEEE specification. thanks expert's
review.
I would suppor the adoption of this two documents.

Best,

-Hui

2013/4/11 Melinda Shore <[email-masked]>

---

From: "Hening (A)" <[email-masked]>
Date: Fri, 12 Apr 2013 06:58:36 +0000

Hi, all
A good protocol should be optimized along with the development of new technology. 802.11n is well-supported in draft-chen-opsawg-capwap-extension-00.txt.
A good protocol should also be optimized with new requirement. draft-shao-opsawg-capwap-hybridmac-00.txt will solve the problem of coordination of different manufacturers.

So, I support the adoption of these two drafts.

Best regards
Hening

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Melinda Shore
发送时间: 2013年4月11日 22:37
收件人: [email-masked]
主题: [OPSAWG] Call for adoption, two capwap-related documents

Thanks,

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 12 Apr 2013 20:55:48 -0400

I have no objection to this work being adopted by the OPS area working group.  I do think that it is important for CAPWAP to be updated/extended for IEEE 802.1n, and I think that these drafts are a good starting point.  Both drafts will need some work before they are ready for publication, though.

For example, both of these drafts have empty IANA Considerations sections, and that isn't right in either case.    I'm the IANA Expert Reviewer for CAPWAP allocations, so I'd like to make sure we properly understand what allocations are being requested by these documents.  I have discussed the IANA items below that I think will need to be allocated by these documents.  Am I missing anything?

> http://www.ietf.org/id/draft-shao-opsawg-capwap-hybridmac-00.txt

This document needs to allocate another WTP Mac Type for the Hybrid MAC, but the document doesn't seem to mention the WTP MAC Type at all.  It don't see how the Hybrid MAC Type can be used without assigning a WTP Mac Type value.  The registry for this value is described in section 15.26 of the base CAPWAP spec.

> http://www.ietf.org/id/draft-chen-opsawg-capwap-extension-00.txt

This document requests the allocation of several new Element IDs.  I think that these would be allocated from the CAPWAP Message Element Type registry, as defined in section 15.7 of the CAPAP base spec (RFC 5415).  There are a couple of types that include values in the spec (133 and 134, specifically).  Those values have not been allocated (to my knowledge) and should be removed from the specification until they have been requested and allocated by IANA.

I'd be happy to work with the authors to properly document these allocations, so that they can request the allocations from IANA.  I think that can happen after these drafts are adopted by the WG, though.

Margaret

---

From: Melinda Shore <[email-masked]>
Date: Fri, 12 Apr 2013 17:46:45 -0800

On 4/12/13 4:55 PM, Margaret Wasserman wrote:
> I have discussed the IANA items below that I think will need to be
> allocated by these documents.  Am I missing anything?

[ ... ]

> I'd be happy to work with the authors to properly document these
> allocations, so that they can request the allocations from IANA.  I
> think that can happen after these drafts are adopted by the WG,
> though.

Thanks, that's exactly the sort of feedback we need and it's
much appreciated.

Melinda

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 14 Apr 2013 15:44:46 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of joel jaeggli
> Sent: Thursday, April 11, 2013 10:50 PM
> To: Melinda Shore; David Harrington
> Cc: [email-masked]
> Subject: Re: [OPSAWG] Call for adoption, two capwap-related documents
> 
> >> Which types of expert review? CAPWAP experts? 802.11n experts?
> >> Security experts? Network management experts? Operator experts?
> > Apologies for the lack of clarity.  CAPWAP, 802.11n,and operators.

[[DR]] Absolutely so. If these items are adopted as work items by the OPSAWG I will suggest to add explicit text in the charter concerning coordination with and reviews by IEEE 802.11 

Regards,

Dan

---

From: Lucy yong <[email-masked]>
Date: Tue, 16 Apr 2013 12:34:44 +0000

Support both.
Lucy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Melinda Shore
> Sent: Thursday, April 11, 2013 9:37 AM
> To: [email-masked]
> Subject: [OPSAWG] Call for adoption, two capwap-related documents
>

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 19 Apr 2013 16:46:35 +0900

Hi, I support both.

cheers,
--satoru

---

From: "Cao,Zhen" <[email-masked]>
Date: Wed, 24 Apr 2013 16:50:24 +0800

Hi,

I read the drafts and support both, based on the need of collecting capwap
experience and defining new wireless features.

Best regards,
zhen

---

From: Melinda Shore <[email-masked]>
Date: Wed, 24 Apr 2013 08:37:55 -0800

This is a reminder that working group last call for these documents
closes tomorrow.  Please have a look at them if you haven't already
done so.

Melinda

-------- Original Message --------
Subject: Call for adoption, two capwap-related documents
Date: Thu, 11 Apr 2013 06:36:40 -0800
From: Melinda Shore <[email-masked]>
To: [email-masked]

Thanks,

---

From: joel jaeggli <[email-masked]>
Date: Wed, 24 Apr 2013 10:44:19 -0700

> closes tomorrow.  Please have a look at them if you haven't already
I don't think this is a WGLC so we should correct the record on that.

---

From: liu dapeng <[email-masked]>
Date: Thu, 25 Apr 2013 10:54:42 +0800

I support the adoption of those two drafts. There are some comments that
intent to improve the quality of the drafts, I think the authors can update
it after the adoption.

Thanks,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: "George, Wes" <[email-masked]>
Date: Mon, 29 Apr 2013 11:24:06 -0400

Apologies on being a few days late...

In scanning through these documents, I'm left wondering why capwap-extension doesn't formally replace (-bis) 5416 or at least update it, and why it's an informational document. This seems more like a proposed standard update, making me wonder if it perhaps belongs elsewhere (i.e. not an ops group).

Similarly, capwap-hybrid-mac seems like an update to 5415 to correct the lack of clear distinction between AP and AC that has been proven necessary for interoperability. This also seems like a proposed standard since it is apparently necessary to implement this to improve interoperability.

I think we need to sort out the intent of these documents before we determine if OpsAWG is the right fit.

Thanks,

Wes George

> Of Melinda Shore
> Sent: Thursday, April 11, 2013 10:37 AM
> To: [email-masked]

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Rong Zhang <[email-masked]>
Date: Tue, 30 Apr 2013 16:51:20 +0800

Hello Wes George,

Thanks for your kind comments,
for 1) your comments is right, same as other comment as well, we will
update capwap-extension to standard track other than informational document
once submit to 00 WG document if it is adopted. Since it is only about 11n
part other than update original 5416document, so we didn't use "bis".
for 2)  RFC 5415 has recommended Split and Local, capwap-hybrid-mac is not
trying to obsolete them, but define a new model in the middle, it does
not write the normaltive text, so it won't belongs to the scope of standard.

Anyway,  we appreciate your comments.

Best regards,

-Rong
On Mon, Apr 29, 2013 at 11:24 PM, George, Wes <[email-masked]>wrote:

> In scanning through these documents, I'm left wondering why
> capwap-extension doesn't formally replace (-bis) 5416 or at least update
> it, and why it's an informational document. This seems more like a proposed
> standard update, making me wonder if it perhaps belongs elsewhere (i.e. not
> an ops group).
>
> Similarly, capwap-hybrid-mac seems like an update to 5415 to correct the
> lack of clear distinction between AP and AC that has been proven necessary
> for interoperability. This also seems like a proposed standard since it is
> apparently necessary to implement this to improve interoperability.
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 30 Apr 2013 09:16:01 -0800

On 4/30/13 12:51 AM, Rong Zhang wrote:
> update capwap-extension to standard track other than informational
> document once submit to 00 WG document if it is adopted. Since it is
> only about 11n part other than update original 5416document, so we
> didn't use "bis". 
> for 2)  RFC 5415 has recommended Split and Local, capwap-hybrid-mac is
> not trying to obsolete them, but define a new model in the middle, it
> does not write the normaltive text, so it won't belongs to the scope
> of standard.

Wes:

Can you live with this?

Melinda

---

From: "George, Wes" <[email-masked]>
Date: Tue, 30 Apr 2013 14:07:00 -0400

> From: Melinda Shore [mailto:[email-masked]]
> Sent: Tuesday, April 30, 2013 1:16 PM
> >
[WEG] Initially I was under the impression that as an ops group, OpsAWG was like many others in that it wasn't chartered to do protocol work. As a result, I wasn't sure how this fit into the charter of OpsAWG other than being home for orphaned work from concluded WGs (since CAPWAP was an OpsArea WG). So I looked at the charter, and found "Maintenance and small scale extensions of documents that were developed in working groups that have concluded (e.g. MIB modules)."
I guess someone needs to decide if this is truly considered a small-scale extension and enough of the former CAPWAP participants are involved in OpsAWG such that we get the right level of review. If the answer to those questions is yes, I'd be fine with adopting this one.

> > does not write the normaltive text, so it won't belongs to the scope
[WEG] I don't really see the lack of normative text as a particularly convincing argument on this one. The draft asserts that a lack of definition in the standard is leading to interoperability problems due to differences in vendor-specific implementation choices, and proposes a solution. It doesn't have to obsolete the old one, but I think that it is still an update to the standard, and requires normative text to define what behaviors MUST or SHOULD be followed to improve interoperability over the current standard, and possibly to define how backwards compatibility might work.
Otherwise, the same comments apply here as to whether this is the correct WG for this draft.

Hope that helps to clarify

Wes George

---

From: Melinda Shore <[email-masked]>
Date: Tue, 30 Apr 2013 12:01:05 -0800

On 4/30/13 10:07 AM, George, Wes wrote:
> I guess someone needs to decide if this is truly
> considered a small-scale extension and enough of the former CAPWAP
> participants are involved in OpsAWG such that we get the right level
> of review. If the answer to those questions is yes, I'd be fine with
> adopting this one.

Well, I think the "someone" is us as a group.  Taking off
my chair hat, I think that this is pretty clearly not a
major revision of capwap and would not merit a 'bis'
document.  There's also been a considerable amount of
outreach to former capwap participants and to the IEEE
802.11n community, which may have not been visible to
working group participants.

Melinda

---

From: Hui Deng <[email-masked]>
Date: Wed, 1 May 2013 08:45:24 +0800

Hi Wes,

Yes, as we presented during the last two times IETF meeting, WG and AD
recommended that this is a small revision, we need not to reopen the capwap
working group, OPSAWG is the right place to document here.

If we look at two models in previous RFC, it doesn't say "Must" and
"Should", I think we also don't need to add this two words in this document
in order to align with previous RFC for the readers, if people are really
recommending standard track, then probably we can check it again during the
WG LC.

thanks a lot

-Hui

2013/5/1 Melinda Shore <[email-masked]>