From lily.l.yang@intel.com Tue Jun 1 19:28:14 2004
From: lily.l.yang@intel.com (Yang, Lily L)
Date: Tue, 1 Jun 2004 11:28:14 -0700
Subject: [Capwap] CAPWAP DT teleconference minutes (05/27/04)
Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE5C43E2@orsmsx408>
This is a multi-part message in MIME format.
------_=_NextPart_001_01C44806.339D0990
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
May 27, 2004 8-9am PST
Attendees (8): Lily, Petros, Emek, Victor, Partha, Inderpreet, Jim, =
Peyush
The objective of this teleconference was to formulate a working plan to =
revise the CAPWAP Taxonomy Draft to v03 in the next few weeks. =
Potentially this could be the version that the DT asks for the WG last =
call on. The two main work items for v03 are:
1) Address comments received on v02 so far, including comments from =
IEEE CAPWAP Ad Hoc Committee (AHC) and others made via IETF CAPWAP =
mailing list.
2) Solicit more input from mesh vendors to help us revise the =
Distributed Architecture section better than what we currently have, but =
it is expected that the Distributed Architecture Section would not =
treated as thoroughly as the Centralized Architecture Section.=20
Plan to work on item #1 is:
1) Use the spread sheet from IEEE to collect and track other =
comments. Add new columns to the spread sheet so that resolutions or =
clarification/feedback can be documented as well.
2) A primary owner is designated from the DT for each comment so =
that he/she can take responsibility to understand the issue, clarify =
with the comment provider if necessary, and provide recommendation to =
the DT and WG on how to address the comment. When in doubt, the owner =
should always bring up the issue with the DT and WG in general for =
discussion.
3) The DT and WG would be given a chance to go over the =
recommendations before the final resolutions are accepted and =
incorporated into the draft.
Plan to work on item #2 is to first encourage and collect more input =
from mesh vendors on the topic in the next 1-2 weeks. Some vendors =
already agreed (verbally and informally) to do that.
Schedule for v03: need to be discussed by the DT, co-chairs, and the WG.
In this conference, we also went over some of the more significant =
comments from IEEE Ad Hoc Committee:
1) Comments were made that we need to better describe the =
functional interface between AC and WTP in each architecture. The =
problem is that we don't have enough raw data to do that, given the fact =
that each vendor implements that interface with its proprietary =
technology. However, this problem underlines the need for open standard. =
It is agreed that we should explicitly state the proprietary nature of =
such interface in the reality and the difficulty of describing it in =
details.
2) Comments were made that real-time or non-real-time is not well =
defined anywhere, which is true. We should state the reality clearly and =
honestly.
3) Comments were made about how much advantages and disadvantages =
should be pointed out for each architecture variant. The group feels =
that Taxonomy document should stay clear of subjective judgments, but =
analysis of the technical implications of each architecture is within =
the realm of this document.
4) Comments were made regarding the WME/11e entry in the matrix - =
it is not clear what the entry tries to address -- whether it should be =
what (WME or 11e or both) gets implemented or where (AC or WTP or both) =
it gets implemented. The group aggress that it should be the later, not =
the former, and if necessary, contributing vendors should be contacted =
to clarify this and gather new data for this.
5) Security section: questions were raised whether we should have =
more detailed security section. However, it is agreed that we can only =
go as far as the vendor input allow us to go. So Inderpreet agrees to =
take another look at the vendor inputs for security considerations.
6) Comments were also made regarding the distributed architecture =
section and mesh, esp. current development in IEEE .11s group (ESS =
Mesh). We agree to expand a bit more on that section, but also =
acknowledge the difficulty without enough vendor input.
7) Question was raised regarding Section 4.7 and its relevance to =
the document. The group feels that it is indeed important and maybe just =
some clarification is needed.
WE didn't have enough time to discuss the schedule, so we agree to take =
this to the DT mailing list first and get a sense from the DT on when we =
can accomplish work item #1 and #2. I will do that separately.
Thanks,
Lily
------_=_NextPart_001_01C44806.339D0990
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
CAPWAP DT teleconference minutes (05/27/04)
May 27, =
2004 8-9am=20
PST
Attendees (8): Lily, Petros, Emek, Victor, =
Partha,=20
Inderpreet, Jim, Peyush
The =
objective of=20
this teleconference was to formulate a working plan to revise the CAPWAP Taxonomy =
Draft to=20
v03 in the next few weeks. Potentially=20
this could be the=20
version that the DT asks for the WG last=20
call on. The two =
main work =
items for v03=20
are:
1) Address comments received on v02 so far, including comments =
from=20
IEEE CAPWAP Ad Hoc=20
Committee (AHC) and others made via IETF =
CAPWAP mailing=20
list.
2) Solicit=20
more input from mesh vendors to help us revise the Distributed Architecture section better than =
what we=20
currently have, but it is expected =
that the=20
Distributed =
Architecture Section would =
not =
treated as=20
thoroughly as the Centralized Architecture Section.
Plan to =
work on item #1=20
is:
1) Use =
the spread sheet=20
from IEEE to collect and track other comments. Add new columns to the =
spread=20
sheet so that resolutions or clarification/feedback can be documented as =
well.
2) A =
primary owner is=20
designated from the DT for each =
comment so that=20
he/she can take responsibility to understand the issue, clarify with the =
comment=20
provider if necessary, and provide recommendation to the DT and=20
WG on how to address the comment. When in=20
doubt, the owner should always bring up the issue with the DT and WG in general=20
for discussion.
3) The =
DT and WG would=20
be given a chance to go over the recommendations =
before the =
final=20
resolutions are accepted and incorporated into the =
draft.
Plan to =
work on item #2=20
is to first encourage and collect more input from mesh vendors on the=20
topic in the next 1-2 weeks. Some =
vendors already=20
agreed (verbally and informally) to do that.
Schedule for v03: need to be discussed by the DT, =
co-chairs, and=20
the WG.
In this =
conference, we=20
also went =
over some of the more significant comments from=20
IEEE Ad Hoc Committee:
1) Comments were=20
made that we need to=20
better describe the functional interface =
between AC and=20
WTP in each architecture.=20
The problem is that we =
don’t =
have enough raw=20
data to do that, given the fact that each vendor implements that =
interface with=20
its proprietary technology. However,=20
this problem underlines the need for =
open=20
standard. It is agreed that we=20
should explicitly state the proprietary nature of such =
interface in=20
the reality and the difficulty of describing it in =
details.
2) Comments=20
were made that real-time or non-real-time is not well defined=20
anywhere, which is true. We should state the reality clearly and =
honestly.
3) Comments were=20
made about how much advantages and =
disadvantages=20
should be pointed out for each architecture variant. The =
group feels that=20
Taxonomy document should stay clear =
of=20
subjective judgments, but analysis of the =
technical=20
implications of each=20
architecture is within the realm of this=20
document.
4) Comments=20
were made regarding the=20
WME/11e entry in the =
matrix – it is not clear what the entry tries to =
address -- whether it should be what (WME or 11e or both) =
gets implemented =
or where (AC or=20
WTP or both) it gets implemented. The group aggress that it should =
be the later,=20
not the former, and if necessary, contributing vendors should be =
contacted to=20
clarify this and gather new data for this.
5) Security section:=20
questions were raised whether we should have more detailed security =
section.=20
However, it is agreed that we can only go as far as the vendor input =
allow us to=20
go. So Inderpreet agrees to take another look at the vendor inputs for =
security=20
considerations.
6) Comments=20
were also made regarding the distributed architecture section and mesh, esp. current development in IEEE =
.11s group (ESS=20
Mesh). We agree to =
expand a bit more=20
on that section, but also acknowledge the difficulty without enough =
vendor=20
input.
7) Question was raised=20
regarding Section 4.7 and its relevance to the document. The group feels that it is indeed important =
and maybe just some=20
clarification is needed.
WE=20
didn’t have enough time to discuss the schedule, so we agree to take =
this to=20
the DT mailing list first and get a sense from the DT on when we can =
accomplish=20
work item #1 and #2. I=20
will do that =
separately.
Thanks,
Lily
------_=_NextPart_001_01C44806.339D0990--
From Internet-Drafts@ietf.org Wed Jun 2 14:53:10 2004
From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org)
Date: Wed, 02 Jun 2004 09:53:10 -0400
Subject: [Capwap] I-D ACTION:draft-ietf-capwap-problem-statement-01.txt
Message-ID: <200406021353.JAA22154@ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF.
Title : CAPWAP Problem Statement
Author(s) : P. Calhoun, et al.
Filename : draft-ietf-capwap-problem-statement-01.txt
Pages : 9
Date : 2004-6-1
This document describes the Configuration and Provisioning for
Wireless Access Points (CAPWAP) problem statement.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-capwap-problem-statement-01.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-capwap-problem-statement-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-capwap-problem-statement-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2004-6-2100802.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-capwap-problem-statement-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-capwap-problem-statement-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2004-6-2100802.I-D@ietf.org>
--OtherAccess--
--NextPart--