Hi Sam, I think you list some good reasons for going with encoding 2. I'm comfortable with including this in the draft given that the document is still going through working group review. I'll see if I can get some help on reviewing the 802.11 text, but I think it would be OK to move this into a separate document if it is going to hold up the main document.
Cheers, Joe On Jun 28, 2011, at 12:33 PM, Sam Hartman wrote: > > > Over the past couple of days I've been organizing proposed edits for the > channel binding document. > > First, I could really use some help producing some ascii art diagrams. I > think I have non-ascii-art diagrams for the packets involved; is anyone > willing to step forward and help with this? > > Secondly, I'd like to ask the chairs' permission to revisit the encoding > decision. I was uncomfortable with how rough that consensus was and > despite being not in the rough, I've been trying to work through whether > we're doing the right thing. > > A couple of things have caused me to believe that Alan is right and that > encoding #2 (re-using RADIUS encoding for RADIUS AVPs) is the right > approach. > > 1) With encoding 1 (the current text) we cannot encode an attribute > value greater than 254 octets. This isn't an issue for RADIUS, but if we > ever had some other attribute format it could be an issue. We all agree > that 255 octets is as long (or longer) than any attribute we'd want to > see in channel binding. However with overhead for things like vendor > numbers, diameter attribute numbers or the like, I'm concerned that in > the future we might be off by one or two octets in what we can encode > vs what we need to encode. > > 2) I recently re-read draft-ietf-radext-radius-extensions again. RADIUS > attribue naming is getting more complicated. I think there's more > RADIUS-specific code to re-use. > > So, I'd like to ask the chairs if they believe the consensus call was > close enough that they'd have a problem with me going with option #2 > instead of #1 given these somewhat new reasons. > If you think we're done on this issue I'm happy to go forward with #1: > it's already in the document. I'm just no longer sure it's right. > I'm still reasonably convinced this is not a huge issue. > > Besides that, we're still waiting for review of the 802.11 text. If that > review does not happen by Quebec I'll ask the chairs for permission to > pull that text so we can last call the framework. > > Specific changes I'd like to make are: > > 1) Update authors' addresses > > 2) Move the encoding to option #2 with the chairs' permission > > 3) Remover some references to diameter encoding that are still in the > text. > > 4) Add ascii art. > > With that I believe the only open issue will be the 802.11 text. I read > through the document and am quite happy with where we are. > _______________________________________________ > Emu mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
