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
