Capwap Mailing List: Re: Latest Status of CAPWAP Open Issues

[Pat Calhoun (pacalhou) (pcalhoun]

Based on Dan's comments, here is the latest:

Issues remaining open:
Issue 102: Waiting for WG consensus
Issue 103: Waiting for WG consensus
Issue 53: T12. Dan is OK with the change, so I need to propagate the
change to two other message elements. I will take this to a separate
thread.
Issue 65: T24. Dan is willing to go the way the WG takes. I would
propose Margaret's approach, which we will take to a separate thread.
Issue 73: T32. Both Dan and Margaret are ok removing the message
element. I will take this to another thread.
Issue 74: T33. Pat owes Dan a response to the unanswered question.


Closed Issues:
Issue 61: T20. Closing issue 61.
Issue 42: T1. Closing issue 42.
Issue 99: CAPWAP Timer References. Closing issue 99.
Issue 63: T22. Closing issue 63.
Issue 41: CAPWAP Timer Clarification. Closing issue 41.
Issue 101: Error in message element figure in 4.6.32. Closing issue 101
Issue 100: Editorial issue in 4.6.15. Closing issue 100
Issue 89: E8. Closing issue 89
Issue 82: E1. Closing issue 82
Issue 86: E5. Closing issue 86
Issue 85: E4. Closing issue 85
Issue 97: E16. Closing issue 97

 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca [at] avaya.com] 
Sent: Thursday, June 19, 2008 10:13 AM
To: Pat Calhoun (pacalhou); capwap [at] frascone.com
Subject: Re: [Capwap] Latest Status of CAPWAP Open Issues

See in-line. 

BTW, in all this dialog you need to replace 'the IESG'  by 'the AD'
(me). This was not yet the IESG review but the AD review. Only after the
document passes IETF LC it lands on the table of the IESG. 

Dan
 

> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com]
> Sent: Thursday, June 19, 2008 7:50 PM
> To: capwap [at] frascone.com
> Subject: [Capwap] Latest Status of CAPWAP Open Issues
> 
> All,
> 
> Given the numerous messages dealing with all of issues raised by the 
> IESG, and the few additional ones discovered while fixing them, here 
> is an update on all of the issues, and what I'm waiting for in order 
> to move forward.
> 
> Issue 61: T20. The original request to change the enum lists to start 
> at zero was not acceptable to some due to the fact that it would be 
> incompatible with version -10 of the draft.
> Based on an agreement with Dan, I have simply marked zero (0) as 
> reserved. I am waiting for confirmation that this is acceptable

OK with me. 

> 
> Issue 103: Invalid Length Information Message Element. This was raised

> on the list, and pointed out a valid issue that the length field for 
> this message element was incorrect. It needed to be 20, not 18. I am 
> waiting for confirmation that this is acceptable (although I can't see

> why anyone would argue against it).

Not raised by me. Ok with whatever consensus the WG reaches. 

> 
> Issue 102: Join to Image Data state transition issue on the AC. This 
> is another issue raised on the list, and required that some new text 
> be added to this state transition description on the AC. While there 
> are a number of possible ways to fix this issue, I took the simplest 
> and more direct route to minimize the amount of text. I believe that 
> anyone implementing -10 would have assumed the change I made.

Not raised by me. Ok with whatever consensus the WG reaches. 

> 
> Issue Issue 53: T12. Dan raised an issue that he finds the way the 
> message element diagram was constructed was confusing. I have proposed

> new text, and am waiting for confirmation that he is comfortable with 
> this change. If we opt to go down this route, I would also need to 
> change the WTP Board Data and WTP Descriptor message elements. This 
> does not introduce an compatibility issue with -10, it is simply an 
> editorial change that helps make the text clearer.

OK with me. 

> 
> Issue 65: T24. The IESG raised an issue that they believed that the 
> Image Data and Image Identifier message elements should have a length 
> field. I made this change, but Margaret does not believe this change 
> is really necessary, and since it introduces an incompatibility issue 
> with -10, she would prefer that I back the change out. I am waiting 
> for other folks to provide their opinions. I agree the length is not 
> necessary.

If the WG reaches the consensus that length is not needed I will buy it.
I would however suggest to put some text on the lines of what Margaret
was explaining in her message. 
 
> 
> Issue 42: T1. This issue stated that any variable length field, or 
> length field, must have a stated maximum value.
> Many instances of this was addressed via other technical comments from

> the IESG, but I went through the draft and found a few more, which I 
> combined into this issue. I am waiting for the OK to close this issue.

Ok with me. 

> 
> Issue 99: CAPWAP Timers not referencing timers properly. This is a 
> minor change, but while fixing another issue, I found that the CAPWAP 
> timers message element was not referring to the timers in section 4.7.

> This fix simply added the references.

OK with me.

> 
> Issue 73: T32. The IESG questioned whether the number of bits in a 
> field of the WTP Operational Statistics is sufficient.
> Reading the message element, I couldn't really understand what this 
> was trying to do, so I asked the LWAPP developers, and this was an 
> idea that never turned into anything, and do not have any 
> recommendations on how to make the language clearer. Since I have no 
> idea what someone would use this for, I cannot really fix this message

> element - and would propose deleting it. I am ok leaving it in, but 
> I'd like to see the text cleaned up, and would ask that whomever wants

> me to leave it in, provide text.

I prefer the message to be taken out. 


> 
> Issue 74: T33. This one was a question on whether the 
> statistics/counters in both the WTP Radio Statistics and the WTP 
> Reboot Statistics were intended to wrap around or reset.
> I modified the text to state it is the former. I am waiting for 
> confirmation that this change is ok.

OK, but I also raised here the issue of an estimation of the minimal
wrap-up time and I did not see this answered yet. 
 

> 
> Issue 63: T22. The IESG asked why the length field was set to a 
> specific value. There was obviously some confusion about what 
> information was included, and I have provided a response on what this 
> meant. I am waiting to hear from Dan on how to proceed. I do not 
> believe a fix is required.

>From your last explanation I understand now values can be 6 or 8. If
this is correct, OK with me. 

> 
> Issue 41: CAPWAP DTLS Timer Clarification. This is a small change that

> provides some clarification on the use of timers.
> This does not introduce an incompatibility issue with -10, as I 
> suspect most people ended up figuring out (the hard way) that the 
> timers should have behaved based on my change.

Ok with me. 

> 
> Issue 101: Error in message element figure in 4.6.32. This is a small 
> editorial change to a broken message element diagram.
> No incompatibility with -10.

Ok with me

> 
> Issue 100: Editorial issue in 4.6.15. This is a small editorial change

> to add a separator between an enumerated value and its description. No

> technical change.

Ok with me

> 
> Issue 89: E8. I have rejected this issue since the creator of the 
> comment had simply not understood that the use of 
> alpha/numeral/special symbols was only for the AC, not the WTP. I am 
> waiting for Dan's OK.

I cannot find your answer, but I trust you with this one. 

> 
> Issue 82: E1. I have changed the text to address the editorial issue 
> raised, and am waiting for Dan's OK.
> 
> Issue 86: E5. I have changed the text to address the editorial issue 
> raised, and am waiting for Dan's OK.
> 
> Issue 85: E4. I have changed the text to address the editorial issue 
> raised, and am waiting for Dan's OK.
> 
> Issue 97: E16. The IESG pointed out that some timers in section 4.7 
> were not really timers, and needed to move to another place in the 
> spec. Only one of the sections they pointed to needed to move, and I 
> have. I have rejected the rest of the request. I am waiting for Dan's 
> OK.

OK for all these editorial issues. 

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

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