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

[Romascanu, Dan (Dan) (dromasca]

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
>