Re: [Emu] Submitted 10
On 10/20/2011 8:55 PM, Sam Hartman wrote: Glen == Glen Zorn glenz...@gmail.com writes: Glen On 10/20/2011 3:09 AM, Sam Hartman wrote: I believe I've addressed all of Alan's comments with the exception of removing the RADIUS diagram from 5.3. Glen Great, so what are we supposed to do now? WGLC was issued on Glen draft-ietf-emu-chbind-09. The last call is not complete. Glen Shall we just start over? Documents are updated to reflect feedback during last calls all the time. It happens in WGs I chair; it happened with documents for which I was the AD; I've been asked to do it by ADs and other chairs. Drivers run red lights all the time, too. Obviously, sometimes it is done wrong. My thinking is that Alan's comments had been outstanding for a while, seemed fairly obvious and with the exception of the question about encoding of responses were non-contraversial. Thank you for your authoritative reading of WG consensus. If the problems (and their solutions were so obvious, why were they present in the draft at all? In fact, they become non-controversial at the end of last call, not in the middle. None of them seemed to require a second last call. By submitting 10 I've made a version with the changes folded in available for review. What I did is clearly permitted by the process. I could have sworn that the process WRT a WG Draft was that it was changed only by direction of the Chair(s) as a result of the determination of WG consensus, rather than at the whim of the editor. Maybe a different process? The chairs may of course decide I made an error and that one of Alan's comments didn't have sufficient consus. They can ask me to (or do it themselves) resubmit 09 as 11, ask me to remove some text, or give more specific guidance. We may also discover that I incorrectly applied Alan's comment. You still had the options you had before. You can review 09 if you like and send comments on 09. You can reply to Alan's comments and respond to them. You have some additional options now. If you haven't started reviewing yet you can start with 10. If you'd like you can review the diff between 10 and 9. You can review 9 and 10 separately if you have a lot of free time on your hands. You can ignore the whole thing. You get a chance to see Alan's context in the text. You can better appreciate them and if you find a problem bring it up. If you have trouble finding 09 or a diff between 09 and 10 let me know; I bet we can find one if we work together. If you have an objection to text in 9, text in 10, changes between the two bring it up. Objections of this form without an objection to actual text are not constructive. Apparently I was unclear: the specific text to which I am objecting is -10. All of it. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
On Fri, Oct 21, 2011 at 4:57 AM, Glen Zorn glenz...@gmail.com wrote: Apparently I was unclear: the specific text to which I am objecting is -10. All of it. Ooo. Someone woke up exceptionally grumpy this morning. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
Sam: My review comments: 1. Section 3, paragraph 1, should far removed be far remoted? 2. Section 3, bottom of Page 6, should virtual Lads (VLANs) be virtual LANs (VLANs)? 3. Section 5.1, page 14, paragraph 2, should I2 be i2? 4. So, client sends channel-binding data automatically or by its configuration, not per server request? It seems inefficient for peer send a big chunk of i1 without knowing whether the server supports channel binding or what information is needs. Might be better if server can request it and specific information before the peer sends it. 5. Section 7, should the title be Channel-binding AVP instead, as it talks all about AVP, not TLV? On 10/19/11 4:09 PM, Sam Hartman hartmans-i...@mit.edu wrote: I believe I've addressed all of Alan's comments with the exception of removing the RADIUS diagram from 5.3. Thanks Alan for the comments! --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
I'll respond to the question of channel binding support now. I think the current text permits an EAP method to not send channel binding if it knows the server fails to support it. If your method can discover that and optimistically avoid sending channel binding that's fine. I think we discussed the flow in a fair bit of detail and I think we have consensus on the current flow including the lack of server telling the peer which channel binding attributes it supports. As an individual, I do not support opening that up again, although if there is WG consensus to make a change we should do so. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
Sam Hartman wrote: I think we discussed the flow in a fair bit of detail and I think we have consensus on the current flow including the lack of server telling the peer which channel binding attributes it supports. As an individual, I do not support opening that up again, although if there is WG consensus to make a change we should do so. I think there's been a lot of discussion on the document. We need to get closure quickly. This means not re-opening issues which were previously discussed and decided. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
I wasn't aware of previous discussion and decision on this already. Sorry for bringing this up. Proceed with the current draft. On 10/21/11 3:36 PM, Alan DeKok al...@deployingradius.com wrote: Sam Hartman wrote: I think we discussed the flow in a fair bit of detail and I think we have consensus on the current flow including the lack of server telling the peer which channel binding attributes it supports. As an individual, I do not support opening that up again, although if there is WG consensus to make a change we should do so. I think there's been a lot of discussion on the document. We need to get closure quickly. This means not re-opening issues which were previously discussed and decided. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
I want to make sure that we have distinguished between the two statements 1. The server says that I don't support these specific attributes and 2. The server does not tell me that it did or did not do matching of some attributes. The first I think is totally optional, but the second is necessary for the tunnel draft and should be made explicit in this draft as something that needs to be done. I will be reading this document with this in mind. Jim -Original Message- From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Sam Hartman Sent: Friday, October 21, 2011 12:34 PM To: Hao Zhou Cc: Sam Hartman; emu@ietf.org Subject: Re: [Emu] Submitted 10 I'll respond to the question of channel binding support now. I think the current text permits an EAP method to not send channel binding if it knows the server fails to support it. If your method can discover that and optimistically avoid sending channel binding that's fine. I think we discussed the flow in a fair bit of detail and I think we have consensus on the current flow including the lack of server telling the peer which channel binding attributes it supports. As an individual, I do not support opening that up again, although if there is WG consensus to make a change we should do so. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
Jim == Jim Schaad i...@augustcellars.com writes: Jim I want to make sure that we have distinguished between the two Jim statements 1. The server says that I don't support these Jim specific attributes Jim and 2. The server does not tell me that it Jim did or did not do matching of some attributes. Jim The first I think is totally optional, but the second is Jim necessary for the tunnel draft and should be made explicit in Jim this draft as something that needs to be done. I think section 5.3 clearly requires that a peer learn whether the server did do matching and if so, what attributes it successfully matched. We don't currently have a way for the server to say these attributes didn't match. That's kind of tricky and I'd prefer that to be a future work item. I've left extensibility for it. Also, the client's request to the server is integrity protected. I believe we should require and would appreciate you checking that we do require: 1) A client supporting channel binding to a server supporting channel binding will get channel binding. An attacker cannot downgrade to no channel binding. I believe that by doing channel binding over an integrity-protected channel we get that. 2) If you do channel binding the client will learn the result and will learn which attributes it sent were considered and met whatever consistency check the server did. This is a little vaguely worded because there's a lot of latitude for server policy. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
Glen == Glen Zorn glenz...@gmail.com writes: Glen On 10/20/2011 3:09 AM, Sam Hartman wrote: I believe I've addressed all of Alan's comments with the exception of removing the RADIUS diagram from 5.3. Glen Great, so what are we supposed to do now? WGLC was issued on Glen draft-ietf-emu-chbind-09. The last call is not complete. Glen Shall we just start over? Documents are updated to reflect feedback during last calls all the time. It happens in WGs I chair; it happened with documents for which I was the AD; I've been asked to do it by ADs and other chairs. Obviously, sometimes it is done wrong. My thinking is that Alan's comments had been outstanding for a while, seemed fairly obvious and with the exception of the question about encoding of responses were non-contraversial. None of them seemed to require a second last call. By submitting 10 I've made a version with the changes folded in available for review. What I did is clearly permitted by the process. The chairs may of course decide I made an error and that one of Alan's comments didn't have sufficient consus. They can ask me to (or do it themselves) resubmit 09 as 11, ask me to remove some text, or give more specific guidance. We may also discover that I incorrectly applied Alan's comment. You still had the options you had before. You can review 09 if you like and send comments on 09. You can reply to Alan's comments and respond to them. You have some additional options now. If you haven't started reviewing yet you can start with 10. If you'd like you can review the diff between 10 and 9. You can review 9 and 10 separately if you have a lot of free time on your hands. You can ignore the whole thing. You get a chance to see Alan's context in the text. You can better appreciate them and if you find a problem bring it up. If you have trouble finding 09 or a diff between 09 and 10 let me know; I bet we can find one if we work together. If you have an objection to text in 9, text in 10, changes between the two bring it up. Objections of this form without an objection to actual text are not constructive. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
On 10/20/2011 3:09 AM, Sam Hartman wrote: I believe I've addressed all of Alan's comments with the exception of removing the RADIUS diagram from 5.3. Great, so what are we supposed to do now? WGLC was issued on draft-ietf-emu-chbind-09. The last call is not complete. Shall we just start over? This creation of a moving target wouldn't be so annoying if you were a newbie but you are anything but that... Thanks Alan for the comments! --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
