Capwap Mailing List: Recap of current pending issues

[Pat Calhoun (pacalhou) (pcalhoun]

All,

With the IETF Last Call ending in a few hours, I wanted to provide an
updated list of the issues, and required actions. I have updated Tracker
to reflect the current state of all issues. I would like to get review,
and confirmation, that the changes I have proposed are satisfactory
before I publish another rev of the spec. Assuming I get nothing from
the list (which I hope does not happen), my plan would be to publish the
specs next Monday. So in order to ensure we have a high quality spec, I
would urge you to look at the proposed changes and make sure that we are
good to do. The resulting three specs (DHCP, Base and Binding) would
then be ready to move to the IESG for publication.

 
ISSUES WAITING FOR PASI's REVIEW

Issue 156 (Need more details on use of DNS for discovery). This was a
rather small change, but I got it wrong the first time. I am waiting for
confirmation that this time around we are good to go.

Issue 159 (Question on CAPWAP control protocol). This was a question,
which I have responded to. There was no need for change, unless Pasi
raises a specific issue. At this point, I consider this issue closed.

Issue 166 (Various IANA Issues). This issue has been addressed, but I am
waiting for Pasi's feedback.

Issue 168 (DTLS and Retransmissions). Charles provided text for section
2.4.1, but we need Pasi to provide clarification on what he needed in
section 2.4.3.

Issue 171 (Pasi nits on binding spec). I believe this is done - I am
just waiting to see if Pasi has issues with any of the proposed
resolutions

ISSUES WAITING FOR WG FEEDBACK.

Issue 106 (WaitJoin may be unnecessary). Yes, this is an old one, but in
fixing 173 I realized that we never should have removed the WaitJoin
timer, but instead cleaned it up. This fix re-introduces the timer, but
it is enabled/disabled differently from the WaitDTLS timer. I am waiting
for WG feedback on this proposed change.

Issue 150 (Allocation of WBIDs). There is no clear agreement on this
issue. The current spec requires a Standards Action to allocate a WBID,
but it doesn't look like EPCGlobal plans on submitting their protocol to
the IETF. So we either agree to keep the document as it (although we did
agree to remove 802.16), or change the IANA action from "Standards
Action" to something else, such as perhaps "Designated Expert". We need
clear resolution on this.

Issue 151 (MTU discovery doesn't look right). Pasi stated that the MTU
Discovery text was not sufficient, since we pointed to RFCs that
described MTU Discovery behavior, but no protocol specifics. So I had to
re-instate some old CAPWAP text (and new) to add protocol discovery. I
am waiting for feedback for this issue.

Issue 154 (Should we use IPv4 Multicast Address?). A request for a known
multicast address to be registered. I proposed we reject this issue, and
am waiting to make sure that we have consensus on this proposal.

Issue 155 (WTP/AC ACL Synchronization Issue). So this is another
interesting issue, and talking to the LWAPP developers it was introduced
to support a mode of operation that the CAPWAP standard does not
currently support. In the thread, I proposed we remove these message
elements, otherwise we will need to do much more specmanship in order to
support this new deployment requirement.

Issue 161 (NAT Inconsistencies). This is another issue that uncovered
some real problems in the CAPWAP protocol. Fixing it required some
changes that will create backward compatibility issues - but there was
no choice. The old text had two different possible ways of doing the
same thing, with little/no guidance that would clearly create issues.

Issue 165 (Image Download inconsistencies). This issue uncovered some
problems in the CAPWAP protocol's mechanism of downloading firmware to a
WTP. It required some changes to the protocol and I am waiting for
feedback from folks before I consider this closed. Note this new text
does possibly break backward compatibility, depending on how folks had
interpreted the original text.

Issue 169 (What to do with QoS tags exceeding maximum). Another one
where we have a potential interoperability issue, and we need to agree
on what behavior the WTP will take if it receives a packet whose QoS
marking violates the configured policy. Alternatives have been proposed
- waiting for feedback.

Issue 172 (How is the WTP Descriptor's Encryption Capabilities
defined?). This is a particularly thorny issue that can cause us to
break backward interoperability, or worse, severely limit the scope of
the protocol. We need a good resolution, and I have proposed a few
already. Waiting for WG feedback.

Issue 173 (Inconsistency in enabling DTLSWait timer). The text was
inconsistent in how it was making use of the WaitDTLS timer.
Specifically, there were two state transitions that referenced the
timer, when it would have been stopped already before reaching that
transition. I have already sent text and am waiting for feedback.

Issue 175 (Retransmission clarification required). The text that
specifies how control messages are retransmitted needs some
clarification, specifically around the text that deals with congestion
control. I have proposed a change, and am waiting for WG feedback.

PatC