[12:31:12] --- ohm has become available
[13:29:25] --- ohm has left: Replaced by new connection
[13:29:25] --- ohm has become available
[14:47:25] --- ohm has left: Replaced by new connection
[14:47:25] --- ohm has become available
[14:53:51] --- SharonChisholm has become available
[14:54:48] <SharonChisholm> did the agenda
[14:54:56] <SharonChisholm> Going over work item status
[14:55:55] <SharonChisholm> problem statement & architecture drafts
[14:56:01] <SharonChisholm> Milestone Review
[14:56:32] <SharonChisholm> we had 6 month short term charter. Pretty much done.
[14:57:36] <SharonChisholm> either conclude or recharter
[14:57:52] <SharonChisholm> Thanks to the architecture taxonomy design team
[14:59:26] <SharonChisholm> Next up is Lily with comments on the architecture taxonomy ---------------------------------------
[15:01:06] <SharonChisholm> Status update ...
[15:02:57] <SharonChisholm> Changes since the last IETF
[15:03:11] <SharonChisholm> between version 1 and version 2 was the bulk of the work
[15:03:34] <SharonChisholm> had a review from IEEE 802.11 last may and received lots of comments
[15:04:16] <SharonChisholm> received some more survey submissions
[15:04:27] <SharonChisholm> also had a security review
[15:04:45] <SharonChisholm> ready for working group last call to go as an informational RFC
[15:05:12] <SharonChisholm> List of Design Team members ...
[15:05:47] <SharonChisholm> architecture survey template - asked a bunch of questions -design considerations & requirements; WLAN functions supported, etc.
[15:06:21] <SharonChisholm> have received 16 surveys ... 15 are vendors
[15:06:59] <SharonChisholm> Capwap architecture taxonomy
[15:07:25] <SharonChisholm> three buckets - autonomous architecture; centralized architecture; distributed architecture
[15:08:15] <SharonChisholm> Autonomous architecture: traditional WLAN Architecture
[15:08:51] <SharonChisholm> Centralized Architecture
[15:10:12] <SharonChisholm> From Autonomous to Centralized
[15:11:38] <SharonChisholm> (the other axis label seems to be Autonomous, local MAC, Splot MAC, Remote Mac)
[15:11:53] <SharonChisholm> Functional Destribution Matrix for local MAC
[15:13:26] <SharonChisholm> data aggregation is the bit that varies between vendors
[15:13:46] <SharonChisholm> Functional Distribution Matrix for Split Mac
[15:14:35] --- Suresh Krishnan has become available
[15:15:22] --- SharonChisholm has left: Replaced by new connection
[15:15:22] --- SharonChisholm has become available
[15:15:23] --- SharonChisholm has left
[15:15:32] --- SharonChisholm has become available
[15:16:41] --- SharonChisholm has left: Replaced by new connection
[15:16:41] --- SharonChisholm has become available
[15:16:41] --- SharonChisholm has left
[15:19:09] --- SharonChisholm has become available
[15:19:36] <SharonChisholm> (ironically enough, I'm having wireless issues)
[15:19:45] <SharonChisholm> We are not on the Simmary slide
[15:20:05] <SharonChisholm> Summary that is
[15:20:46] <SharonChisholm> 3 distinct architecture families
[15:20:59] <SharonChisholm> amoung centralized architecture family - 3 sub categories
[15:21:26] <SharonChisholm> harder question: interoperability across achitectures - necessary? feasible?
[15:21:49] <SharonChisholm> next steps - define the exact interoperability scope for the protocol(s)
[15:23:11] --- SharonChisholm has left: Replaced by new connection
[15:23:11] --- SharonChisholm has become available
[15:23:11] --- SharonChisholm has left
[15:25:14] --- SharonChisholm has become available
[15:26:18] --- SharonChisholm has left: Replaced by new connection
[15:26:18] --- SharonChisholm has become available
[15:26:18] --- SharonChisholm has left
[15:26:32] --- SharonChisholm has become available
[15:26:49] <SharonChisholm> (If I drop again, I'm giving up)
[15:27:12] <SharonChisholm> there is discussion about the difference between mac and split mac being minor
[15:28:01] --- SharonChisholm has left: Replaced by new connection
[15:28:01] --- SharonChisholm has become available
[15:28:01] --- SharonChisholm has left
[15:28:59] --- SharonChisholm has become available
[15:29:18] <SharonChisholm> (one last try) the IEEE likely won't define the split mac
[15:30:09] <SharonChisholm> comment - you said the triple s was not far along. agree. we have received feedback from ieee, we should provide some to them
[15:30:29] <SharonChisholm> comment - tell then in 11s to spend some time on the architeture
[15:30:52] <SharonChisholm> comment (new) - IEEE's goal in defining 802.11 was to be flexible and extensible
[15:31:16] <SharonChisholm> comment - i think it has been succesful in that goal. IEEE will continue in this goal
[15:31:38] <SharonChisholm> Proposed Next Steps
[15:32:07] <SharonChisholm> version -04 to be taken to wg last call. then to IESG review for informational rfc
[15:32:23] <SharonChisholm> in parallel discuss re-charter for protocol work
[15:32:34] <SharonChisholm> define the scope of interoperability -> proposed protocols
[15:32:42] <SharonChisholm> Another thank you to the design team
[15:33:07] <SharonChisholm> ------------------------------------------
[15:33:19] <SharonChisholm> Dorothy is going to summarize the IEEE liaisons
[15:34:34] <SharonChisholm> IETF request for IEEE 802.11 review of capwap taxonomy document
[15:34:52] <SharonChisholm> IETF Request - Need for AP Functional Definition
[15:35:30] <SharonChisholm> For the first one, we have received the feedback and included it in version -03
[15:36:18] <SharonChisholm> For the second one ... the IEEE have formed a new study group to look at this
[15:36:28] <SharonChisholm> she is chairing it
[15:37:37] <SharonChisholm> they are doing some process work to ensure things are in order
[15:37:57] <SharonChisholm> there will also be content presentations
[15:38:29] <SharonChisholm> meeting again in sept
[15:38:39] <SharonChisholm> comment - next steps?
[15:39:06] <SharonChisholm> answer - finalize the process stuff; then approval process; formation of new task process; depends what the study group decides
[15:39:15] <SharonChisholm> comment - is there a timeline for having the work done?
[15:39:30] <SharonChisholm> answer - no; intent is as soon as possible; work will be ongoing
[15:39:59] <SharonChisholm> This couple be a couple of years
[15:40:45] <SharonChisholm> comment - almost a no brainer that to develope protocols we need requirements. If we can do requiremetns here, that would be great; can you discuss the interactions
[15:41:00] <SharonChisholm> answer - we have a request from capwap to provide additional descriptions of AP functions
[15:41:24] <SharonChisholm> comment (new) - from the IEEE standpoint, do you see a need of working in parallel or serial?
[15:41:29] <SharonChisholm> answer - in parallel
[15:42:08] <SharonChisholm> comment (new) - if the IETF is the one that requested that stuff, there was a reason it was because there was confusion about how to split the MAC. if that will take a few years, how do we proceed?
[15:42:39] <SharonChisholm> answer - i don't think we had confusion about how to split the MAC. The question was how to do it in a standard manner. ... interoperate
[15:43:31] <SharonChisholm> answer - every vendor has its own AP function. people looking for more of a statement as to what these functions are. we find we need it for ourselves.
[15:43:51] --- toro_toro has become available
[15:44:25] <SharonChisholm> comment - I understand that. IEEE is doing it for their own purposes, but was motivated by our comments. I don't want the IEEE to go off and do their work and the IEEE not being able to leverage it
[15:44:35] <SharonChisholm> comment - if you are talking years, I don't know how to proceed
[15:45:10] --- toro_toro has left
[15:45:17] <SharonChisholm> answer - the more prodcution model would be for this group to make its decision of how you want to proceed. document your questions. We can have some back and forth discussions. you can have answers before the official answers
[15:45:46] <SharonChisholm> comment (new) - this AP function is not going to redefine the MAC. the MAC is the MAC.
[15:46:12] <SharonChisholm> answer - the initial comment was for definition, but we decided to look at description (with respect to functions)
[15:46:28] <SharonChisholm> comment (new) - what does IEEE think of splitting a MAC
[15:46:34] <SharonChisholm> <laughing)
[15:46:56] <SharonChisholm> answer - the actuall IEEE specifications don't comment on it
[15:47:20] <SharonChisholm> comment (new) - there is a distinction between developing tools for general purpose compared to using those tools to do specific things
[15:47:46] <SharonChisholm> answer - this stuff becomes importtant when you put things together to do things
[15:47:57] <SharonChisholm> (that should have been a comment)
[15:48:42] <SharonChisholm> comment (new) - the IEEE does not think about splitting the MAC. The IEEE defines the MAC. It is a standard, not an implementation. It talks about the method of communicating the information. It describes requirements and communication and nothing else
[15:50:28] --- SharonChisholm has left: Replaced by new connection
[15:50:28] --- SharonChisholm has become available
[15:50:28] --- SharonChisholm has left
[15:50:38] --- SharonChisholm has become available
[15:51:09] <SharonChisholm> bert - we don't seem to have broken anything in the ieee protocol from your review
[15:51:39] <SharonChisholm> bert - if you can enhance these descriptions, that would be great
[15:52:14] <SharonChisholm> bert - what you want to now do is standardize on these architectures. It seems doable, but do we want to do it here?
[15:52:41] <SharonChisholm> ----------------------------------------
[15:52:48] <SharonChisholm> Re-charter Proposals
[15:53:46] <SharonChisholm> Scope: Build upon the original charter to develop a CAPWAP protocol to provide interoperability among WLAN ....
[15:54:02] <SharonChisholm> 1. Objectives draft
[15:54:36] <SharonChisholm> - provides a vendor and customer perspective; lists ieee AP functional features to be distributed; reviewed by IEEE
[15:54:59] <SharonChisholm> Why objectives? - more than a requirement ... includes motifivation for requirements
[15:55:29] <SharonChisholm> other things
[15:56:24] <SharonChisholm> 2. Evaluate proposals
[15:56:36] <SharonChisholm> - Evaluate set of candidate protocols
[15:56:53] <SharonChisholm> - selection will be the base protocol for CAPWAP Protocol
[15:57:11] <SharonChisholm> 3. CAPWAP Protocol & MIB
[15:57:22] <SharonChisholm> - Based on Selected Protocol from Evaluation Document
[15:57:34] <SharonChisholm> - MIB support for the CAPWAP Protocol
[15:57:42] <SharonChisholm> Goals & Milestones
[15:58:45] <SharonChisholm> runs from Oct 04 to Jan 06
[15:59:59] <SharonChisholm> comment - tried this in a working group tried, it failed; someone else tried and it took forever
[16:00:30] <SharonChisholm> comment - this idea of coming up with requirements and then doing protocol. People have protocol and just want that through. IESG can kicks stuff back.
[16:01:00] <SharonChisholm> comment - vendors out there with products. Put them in a room and let them fight them out. Give them 6 months and then if they don't suceed we can shoot the working group
[16:01:23] <SharonChisholm> answer - we know this stuff can be a problem. We are looking for process feedback
[16:01:33] <SharonChisholm> comment (new) - how do you plan on taking customer input?
[16:01:53] <SharonChisholm> answer - have been given a list of possible customer contacts from the IESG, others. We can call them.
[16:02:22] <SharonChisholm> answer - there is also criticism that this is what the vendors want, but are we addressing the market place
[16:02:44] <SharonChisholm> comment - just want to make sure that customer seclection is done in a way that is fair
[16:02:52] <SharonChisholm> comment - this schedule seems a bit aggresive
[16:03:37] <SharonChisholm> answer - my reasoning behind that is there is stuff out there, people are thinking out it. I'm expecting people to develop those protocol between august and october with quick turn around
[16:03:45] <SharonChisholm> comment - want to be optimistic, but ...
[16:04:31] <SharonChisholm> comment (new) - comment about customers. In an exterprise ... I don't know how you would chose the customers and how would you be fair to vendors. Within an organiation itself, there would be different opinions.
[16:04:53] <SharonChisholm> answer - the higher level perspective is to categorize the customers and sample from each
[16:05:47] <SharonChisholm> comment - there are various implementations today, protocols. invested thought and money. there will be opinion that it should be done in such and such a way. tough to resolve. Could do minimal instead of super set.
[16:05:57] <SharonChisholm> comment - example split, local MAC.
[16:06:07] <SharonChisholm> answer - that is one of the criteria
[16:06:48] <SharonChisholm> comment (new) - there is a gap between the taxonomy document and architecture and the protocol. When you start on protocols you need a well established reference architecture
[16:06:54] <SharonChisholm> ansewr - that would be the IEEE stuff
[16:07:05] <SharonChisholm> comment - I guess we have 14 flavours of the architecture
[16:07:45] <SharonChisholm> answer - taxonomy work as shown a convergence to three architecture classes. then we can see if we can develop a protocol to meet all of these
[16:08:04] <SharonChisholm> comment - defining the architecture is part of the re-charter?
[16:08:05] <SharonChisholm> answer - yes
[16:08:30] <SharonChisholm> comment (new) - go back to charter ... <something>
[16:08:49] <SharonChisholm> answer - just tried to summarize. interoperability among the various architectures that Lily discussed
[16:08:57] <SharonChisholm> answer - we can rework it.
[16:09:31] <SharonChisholm> comment (new) - wanted to response. I heard yes we will define a single architeture. but that is not what we are really seeing.
[16:09:51] <SharonChisholm> answer - i think that will be part of the discussion. whether we will converge on a single architecture
[16:10:12] <SharonChisholm> comment - some language that objectives is more than requirements
[16:10:30] <SharonChisholm> answer - not just requirements; also talk about how it relates to the problem statement; richer
[16:11:54] <SharonChisholm> bert - helped a bit with that. I used objectives; another working group did this. When you talk about requirements you would do it without looking at the architeture. When you call it requirements, there is a lot of discussion about whether it too costly. Don't want to go there until you deep dive on the protocol
[16:12:30] <SharonChisholm> bert - that discussion can be done at the protocol/implementation level; not doing it should speed things up
[16:13:16] <SharonChisholm> comment (new) - looks like there is a gap ... we have taxonomy ... then classifiers ... from there candidate protocol ... we need an architecture in between
[16:13:35] <SharonChisholm> answer - this has been discussed on the list
[16:15:12] <SharonChisholm> answer - i think the tax did a good job at overviewing the market place; definition of mac and split mac. i think the working group is happy with it. if you have issues. I think you should raise those now against the tax document
[16:15:51] <SharonChisholm> comment - i'm agreeing with you with what you said. before jumping into the protocol .. which shade of grey ... there is a missing link
[16:16:48] <SharonChisholm> answer - take your comments to the list
[16:17:32] --- Suresh Krishnan has left: Disconnected
[16:17:41] <SharonChisholm> comment (new) - there are shades of grey in local MAC. There are shades of grey everywhere. what we need to do is to agree
[16:17:43] --- Suresh Krishnan has become available
[16:19:13] <SharonChisholm> comment (new) - difference between feature lists and something else. We argue over feature lists. The way to resolve issues is to include everything. creates inherant bias towards bloat. This is an attempt to get around that. To look at minimal set of things needed to be succesful and support extensibility
[16:20:17] <SharonChisholm> comment (new) - the one thing that is differnt between this plan and other plans is to ask prospective customers. It probably won't reveal enough detail. Could just get general requirements that can't be boiled down into decisions
[16:20:32] <SharonChisholm> comment - what it might do is that it might get the vendors to agree.
[16:20:57] <SharonChisholm> comment - getting the requirements might emphasize the economic insentive
[16:21:27] <SharonChisholm> comment (new) - what we really want to know is the list of things that make things very painful to them, not a wish list
[16:22:00] <SharonChisholm> answer - right, in the tax. we did do some market place stuff.
[16:22:17] <SharonChisholm> answer - validate problem statement and architectures
[16:22:20] --- reh has become available
[16:22:43] <SharonChisholm> comment (new) - strong desire to ensure that the selection of customers is fair
[16:23:04] --- reh has left
[16:23:25] <SharonChisholm> bert - how may people are here from those we submitted architectures?
[16:23:45] <SharonChisholm> <lots of hands>
[16:23:45] <SharonChisholm> bert - I was pleased that the tax. got done when it said it would
[16:24:06] <SharonChisholm> bert - I keep hearing 'that is has to be fair'. not the same start.
[16:24:22] <SharonChisholm> bert - raise your hand if you think the goal is to come to one standard protocol
[16:24:22] <SharonChisholm> <lots of hands>
[16:24:56] <SharonChisholm> bert - i would assume when you come to the IETF ... all here with the sincere intent that you are here to be fair and come to best technical solution.
[16:25:37] <SharonChisholm> comment (new) - i actually agree. what I meant to say. I don't know who you mean to talk to. do they feel the pain or do they only have one AP in their network?
[16:25:50] <SharonChisholm> ---- Discussion ---
[16:26:14] <SharonChisholm> - wg consensus (on the approach; deliverables; timelines)
[16:26:45] <SharonChisholm> issues to consider (requirements draft black hole; protocol proposals may be similar; dependencies on IEEE)
[16:26:55] <SharonChisholm> preventative measures ...
[16:27:26] <SharonChisholm> Are there any other comments?
[16:27:40] <SharonChisholm> Do people want to recharter? hum
[16:27:46] <SharonChisholm> Good but tired hum
[16:27:58] <SharonChisholm> Those apposed? Not a peep
[16:28:17] <SharonChisholm> bert - also check that there is not concensus on this charter?
[16:28:25] <SharonChisholm> answer - take to list and wordsmith
[16:28:33] <SharonChisholm> hum for this charter - less hum
[16:28:38] <SharonChisholm> those appose - no hum
[16:28:54] <SharonChisholm> ---------
[16:29:16] <SharonChisholm> We have some time to go through the classifications document
[16:29:55] <SharonChisholm> CAPWAP Classifications & Requirements
[16:30:04] <SharonChisholm> CAPWAP Taxonomy
[16:30:46] <SharonChisholm> Classifications of Function Blocks
[16:32:11] <SharonChisholm> functional blocks - verification of associationg request; updation of association entry ... traffic aggregation & Distinction
[16:32:28] <SharonChisholm> Framework
[16:32:51] <SharonChisholm> Requirements
[16:34:02] <SharonChisholm> Possible Path Forward
[16:34:49] <SharonChisholm> ----------
[16:34:53] --- Suresh Krishnan has left: Replaced by new connection
[16:34:53] --- Suresh Krishnan has become available
[16:34:53] --- Suresh Krishnan has left
[16:35:01] <SharonChisholm> If no other comments ... we are done
[16:35:05] <SharonChisholm> End of Session
[16:59:39] --- SharonChisholm has left: Disconnected