Subject: [Capwap] CONSENSUS CONFIRMATION: Issue Categorization/Resolution

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Jan 2007 10:22:38 -0500

Hi All,

This is a long note, but please read it to the end, because it
concerns the resolution of 20 open issues.

At the CAPWAP interim meeting, we reached consensus on how to
categorize all of the open CAPWAP issues into five categories:

(1) Substantive Issues: These issues are unresolved issues under
     active discussion.  These issues were listed under the "TOPIC"
     sections of the CAPWAP Interim agenda.
(2) Too New/Not Discussed on List: These issues were considered too
     new to benefit from face-to-face discussion. (NOTE: We did not
     place any issues in this category.)
(3) Editorial/Well-Understood Fix: These issues are either editorial
     in nature or have a well-understood fix that should simply be
     applied by the editors.  The editors should fix these issues, send
     an informative e-mail to the list regarding how they have been
     addressed and close them.
(4) Not Actionable: These issues will be closed without any action.
     Typically they do not contain enough information to be acted upon
     or there is some other reason why they can't be acted upon (go
     directly against previous consensus, etc.)
(5) Wish List for Future Version: These issues will not be addressed
     in the first version of the CAPWAP specifications, but will be
     considered for future versions if/when additional CAPWAP work is
     scheduled in the IETF.

Issues in categories (1) and (2) will continue to be discussed on the
list and/or in meetings until agreement is reached on a resolution.
When agreement is reached, there will be consensus call from the WG
chairs on how these issues will be resolved.

Issues in category (3) will be fixed by the editors, who will send
e-mail to the list indicating how each issue has been addressed and
subsequently close each issue.  There will be no official consensus
call on these issues, unless there is disagreement on the list with
how the editors have addressed a particular issue.

Issues in categories (4) and (5) will be closed without changes to the
CAPWAP specifications.  Issues in category (5) will be tracked for
later consideration.

We also agreed that the following issues fell into categories (3), (4)
or (5) and would be addressed as indicated above:

(3) Editorial/Well-Understood Fix (some are already fixed in -04):
101 11.8.1.1 Change to re-use 802.11 Information element definitions
122 Editorial Issues in CAPWAP-01
127 Usage of the Session ID field
159 Operations should have listed in which states they are applicable
161 The term "Mobile" is not really accurate
177 WTP Reboot Statistics belongs in the Join
194 Handling duplicate IPV4 addresses
207 New WLAN terminology proposed
218 Static IP Address message element is a MUST
231 Need clarifications on Image Data Transfer
232 WTP Static IP Address, RSNA Error Report Text Error
233 Idle Timeout needs clarification

(4) Not Actionable:
114 How does CAPWAP know there's a NAT? (It doesn't need to know)
87  Use of DTLS for CAPWAP data channel (duplicates part of #227)

(5) Wish List for Future Version:
75  recommend LWAPP add a new notification message "Gratuitous
     disconnect notification"
79  Handover issue with CAPWAP
112 MTU Discovery
148 Binding element for scanning report
205 Rogue AP Detection
206 Common MIB Statistics

If you disagree with the categorization and proposed resolution
path for any of these issues, please respond to this message with your
concerns by February 5th, 2007.  Please do not discuss the technical
content of individual issues on this thread, it is only for responses
to this consensus confirmation.

Thanks,
Margaret

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Abhijit Choudhury (achoudhu)" <[email-masked]>
Date: Mon, 29 Jan 2007 10:29:36 -0800

Hi Margaret,

Could you please elaborate on what you mean by 
Issue 87 being "Not Actionable".
Use of DTLS on the data channel is an optional feature 
that is already there in the spec.

Thanks,
Abhijit

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Monday, January 29, 2007 7:23 AM
To: capwap
Subject: [Capwap] CONSENSUS CONFIRMATION: Issue
Categorization/Resolution

Hi All,

This is a long note, but please read it to the end, because it concerns
the resolution of 20 open issues.

At the CAPWAP interim meeting, we reached consensus on how to categorize
all of the open CAPWAP issues into five categories:

Issues in category (3) will be fixed by the editors, who will send
e-mail to the list indicating how each issue has been addressed and
subsequently close each issue.  There will be no official consensus call
on these issues, unless there is disagreement on the list with how the
editors have addressed a particular issue.

Issues in categories (4) and (5) will be closed without changes to the
CAPWAP specifications.  Issues in category (5) will be tracked for later
consideration.

(4) Not Actionable:

If you disagree with the categorization and proposed resolution path for
any of these issues, please respond to this message with your concerns
by February 5th, 2007.  Please do not discuss the technical content of
individual issues on this thread, it is only for responses to this
consensus confirmation.

Thanks,
Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Jan 2007 19:10:01 -0500

Hi Abhijit,

This issue ended-up in the "not actionable" category because the  
feature requested is already present.  It raised no other issues that  
were not already addressed or duplicated in either issue #226 or  
#227.  It is certainly not our intent to remove support for DTLS on  
the data channel, we just felt that this issue had already been dealt  
with and no further action was required.

Margaret

On Jan 29, 2007, at 1:29 PM, Abhijit Choudhury ((achoudhu)) wrote:

> categorize
> call
> later
> path for