Re: Last Call: draft-arkko-eap-aka-kdf (Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')) to Informational RFC
Hi Jari, Thanks for your response. I am sorry I am still slow to respond. I agree we are better off standardizing a new method at the IETF. I think we should get rid of the AKA KDF in AKA' so that these are two separate methods. Method-level negotiation is easier IMO. However, if you are after the idea of having a single EAP method implementation in mobiles (just AKA' with support for AKA inside it), please let me know. I would prefer that. That would require a bit of coordination with 3GPP and 3GPP2 folks however. thanks, Lakshminath On 10/13/2008 6:35 AM, Jari Arkko wrote: Hi Lakshminath, and thanks for your review. After some conversations and thought, I think that the goal of limiting the effects of compromised access network nodes and keys (should that be clarified?) can be achieved with fewer changes to AKA. Fewer is better, lets talk about this. I like that we are trying to define a new method. I guess I can appreciate the move to SHA-256 (although are we claiming that HMAC-SHA-1 is a problem?). We are not. It is merely an engineering decision. If we are changing the behavior and specification for other reasons, updating the hash functions to newer ones is easy at the same time. Updating them at another time would be significantly more painful, e.g., possibly involving another new EAP Type code, backwards compatibility problems, etc. However, it is quite confusing in that the new method AKA's tries to be backward compatible and forward compatible (KDF negotiation). AKA' with old KDF, AT_KDF set to 1, seems to cause quite a bit of confusion by raising the issue of how would the backward compatibility really work. Why is the old KDF needed with AKA'? This is a feature of EAP-AKA' that we do not strictly speaking require in any of the uses cases that I'm aware of. So if you have some evidence that it is causing significant confusion, we could re-consider whether it needs to stay in the document. But let me explain the rationale. We designed EAP-AKA' not just because 3GPP wanted to use new key derivation functions, but also because EAP-AKA had no ability to negotiate key derivation functions to begin with. (I predict that we have not seen the last update to the key derivation functions.) Once you have this ability, EAP-AKA' is merely a superset of EAP-AKA, capable of using EAP-AKA KDF (KDF=1), the new KDF (KDF=2), or some future KDF. Again, choosing to use plain old EAP-AKA is also possible by negotiating it at the EAP method level. So you could argue that its superfluous to do this. However, if there is confusion I want to understand if its because of the ability to use EAP-AKA within EAP-AKA' or because the negotiation mechanism itself is confusingly described. If its the former, we can reconsider. If its the latter, we need to fix the text. Please see -06 that was posted today, as it includes some additional explanation of the negotiation mechanism, based on last call input we have gotten. The channel bindings and the CK' and IK' stuff seems also to be confusing. It was interpreted at least in one context as using key derivation to enforce EAP channel bindings (which is really not necessary). As it is, we are talking about method-level channel bindings, which then seems to be confusing elsewhere. I am wondering whether we can fix this all up before going forward with approval. For simplicity, I believe, we should just specify AKA' as a new method with no attempt at backward compatibility. Next, I think we should work on channel bindings at EAP level and not at the method level, especially given that AKA is used so widely. If you think removing KDF=1 helps, we can do that, but its a very small part of the specification. I agree that the IETF should work on EAP channel bindings, but as someone who has trying to do that for 5-6 years I do not think we should hold our breath. I think we may actually make some progress on that, but EAP-AKA' binding model is a very limited one compared to what a generalized channel binding mechanism would do. You could even argue that its a different concept, see what Pasi said in EMU discussion about this: http://www.ietf.org/mail-archive/web/emu/current/msg00929.html The use of CK' and IK' is central to the entire idea of 3GPP's new authentication model for AKA. What I want to ensure is that we have an interoperable IETF specification for running AKA in EAP under their new system. I did not design AKA or the new system, but I do want to ensure that the use of the new system does not break EAP. If we do not deliver a spec that is capable of doing this, there is a ready made set of hacks that some people want to use instead of a new EAP method. Of course, those hacks would destroy interoperability with RFC 4187. I do not want that to happen, so perhaps you understand why I want to make the minimal change to a method that we can change, and move on. Jari
Re: Last Call: draft-arkko-eap-aka-kdf (Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')) to Informational RFC
Sorry for the last minute nature of this email, but I was checking with folks active in the standards bodies that use EAP-AKA. After some conversations and thought, I think that the goal of limiting the effects of compromised access network nodes and keys (should that be clarified?) can be achieved with fewer changes to AKA. I like that we are trying to define a new method. I guess I can appreciate the move to SHA-256 (although are we claiming that HMAC-SHA-1 is a problem?). However, it is quite confusing in that the new method AKA's tries to be backward compatible and forward compatible (KDF negotiation). AKA' with old KDF, AT_KDF set to 1, seems to cause quite a bit of confusion by raising the issue of how would the backward compatibility really work. Why is the old KDF needed with AKA'? The channel bindings and the CK' and IK' stuff seems also to be confusing. It was interpreted at least in one context as using key derivation to enforce EAP channel bindings (which is really not necessary). As it is, we are talking about method-level channel bindings, which then seems to be confusing elsewhere. I am wondering whether we can fix this all up before going forward with approval. For simplicity, I believe, we should just specify AKA' as a new method with no attempt at backward compatibility. Next, I think we should work on channel bindings at EAP level and not at the method level, especially given that AKA is used so widely. thanks, Lakshminath On 9/15/2008 7:50 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') ' draft-arkko-eap-aka-kdf-05.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-10-13. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-arkko-eap-aka-kdf-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17483rfc_flag=0 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Hi Enrico, Vijay, Thank you for the summary of what transpired after the Dublin meeting. I appreciate you taking the time. My reading at the BoF was that there were some concerns about this work being done in haste without clearly understanding what it is that we want to do and what it is that we need to do to address this particular problem space (there were even suggestions to move some of the work to the IRTF). My perception and my understanding of some of the dissenting opinions was that some of those need to be worked out before creating a working group. We have been in situations where working groups have been created in haste to address important and urgent problems, but then people disagree so much in working groups that some such working groups never made any real progress or had to be shut down (folks, please don't try to guess which WG(s) and try to explain the individual situations; thanks). Surely, we don't want that to happen here. Some of the disagreements here in this thread now, and the intent of some of the folks to whitewash the issues raised do seem troublesome. It would be great if we could rather focus on trying to understand all aspects of the problem, have the charter reflect the correct level of scope (too wide or too narrow are problematic as we know), and move forward. thanks, Lakshminath On 10/10/2008 5:15 AM, Enrico Marocco wrote: Lakshminath Dondeti wrote: The minutes (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say this: +++ Many people agreed that this is important work for the IETF, also some (less) people hummed against. Hum was inconclusive - some of the no hums were (in Jon's words) vehement. +++ Given that there was no consensus, it would have been nice if the sponsoring AD(s) or the IESG explained what's going on, but then transparency, it appears, is not really a goal in this case. If the idea was to just go forward anyway, we really wasted 3, may be 6 months. The half measures are a waste of everyone's time. Lakshminath, the objections raised during the BoF in Dublin were on very specific issues, namely the general service discovery problem supposedly addressed by the charter, a too broad scope in terms of information exchanged between ALTO clients and ALTO servers, and the connection between traffic localization and optimization someone seemed to see implied in the problem statement. During the weeks following the meeting, people who had expressed concerns at the mic and on the list constructively contributed to the discussion and the group converged on a charter the current version is a slight variant of. For this reason, and for the amount of interest shown in Dublin -- we called inconclusive the hum on the charter, but interest in the problem was made pretty clear by what we heard at the mic, by the number of contributors, and by the number of people in the room -- we managed to convince our sponsoring AD (and transitively the IESG) to send it out for IETF-wide review. If the community identifies new serious issues or considers the old ones not completely addressed, probably a new BoF will be the best way to sort them out. Of course I'm only speaking for myself, not certainly on behalf of Lisa nor the IESG. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
On 10/10/2008 12:21 PM, Lisa Dusseault wrote: Lakshminath and Vidya, Vijay, Enrico and Stefano have said what I was going to say (e.g. below) -- as sponsoring AD for this charter I've been following the WG discussion, working with the rest of the IESG, and talking to people to confirm that there's better consensus on the list, even if there was confusion at the BOF. This IETF Last Call is also part of confirming whether there's now consensus. Hi Lisa, My concern can be put in really simple terms. We have some really very confusing processes and we seem to add to the confusion and not make things simpler. I left Dublin thinking, out of the p2pi efforts, TANA will be a WG (there was strong consensus and agreement on the problem space and what needs to be done) and ALTO may have another BoF. As of today, there is a WG proposal on the table for ALTO and in a different area from where we started; TANA is on the BoF wiki. Next, my experiences in the past on BoFs that did not have consensus have been dramatically different from what is happening on ALTO. The IESG has really even refused to allow another BoF much less directly started creating a working group. So, it makes me wonder whether the rules have recently been changed or whether they are selectively applied. I am also confused by your use of the word consensus; you say that you've talked to people to confirm that there's better consensus on the list, but also say that the charter review is also part of the consensus process. Shouldn't there be a call for consensus? It's difficult to write a charter without actually designing the solution. This is an interesting opinion. May I translate that to mean that there is already a solution in the minds of the people who wrote the charter? Why then would we bother with the proposed requirements effort, writing down a problem statement and all the rest? Why not put an RFC number on the solution? It also makes me wonder what your opinion on the following from 2418. - Is the proposed work plan an open IETF effort or is it an attempt to bless non-IETF technology where the effect of input from IETF participants may be limited? What would help with the charter, even now, is for people to write up proposals for the solution -- ideally in the form of Internet-Drafts. This seems to be starkly different from the process I know of. Are you really suggesting that people come up with solutions to help with the charter? What problem are we solving? What are the requirements? Based on the proposal that was sent out, we won't have consensus on all of those until Oct 2009 or later. Apr 2009: Working Group Last Call for problem statement Jun 2009: Submit problem statement to IESG as Informational Aug 2009: Working Group Last Call for requirements document Oct 2009: Submit requirements document to IESG as Informational I haven't yet selected chairs for the WG, so as you can imagine editors and authors aren't yet selected. It would be most excellent to see some individual proposals before a committee gets their hands on them :) I am sorry Lisa, but I am really confused by your request for proposals before we even agree on the problem. I am hoping for a clarification. thanks, Lakshminath Lisa On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: ... And since the BoF, much has changed to narrow the scope of the charter down to more manageable pieces as well as establish a channel with IRTF to move certain aspects of the work there (as the timeline in my previous email indicated.) Lakshminath Dondeti wrote: My perception and my understanding of some of the dissenting opinions was that some of those need to be worked out before creating a working group. But I believe that we have done exactly that: the list has been busy since Dublin on attempts to move the work forward in a manner that is conducive to all participants. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thanks for the clarification Enrico :). best, Lakshminath On 10/10/2008 6:27 PM, Enrico Marocco wrote: Lakshminath Dondeti wrote: It's difficult to write a charter without actually designing the solution. This is an interesting opinion. May I translate that to mean that there is already a solution in the minds of the people who wrote the charter? Nope. Who has been following the p2pi list for the last five months probably knows that there are three different approaches (solutions?) floating around: the sorting oracle (described in a SIGCOMM paper authored by folks from TU-Berlin, a variant of which is IDIPS), P4P (soon to be published as I-D and, IIRC, described in another SIGCOMM paper), and Stanislav's proposal (discussed in Dublin and on the list: http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html). Who wrote the charter had all those approaches clear in mind and took special care that none of them got ruled out. Why then would we bother with the proposed requirements effort, writing down a problem statement and all the rest? Why not put an RFC number on the solution? It also makes me wonder what your opinion on the following from 2418. - Is the proposed work plan an open IETF effort or is it an attempt to bless non-IETF technology where the effect of input from IETF participants may be limited? I don't know Lisa's opinion, but am sure that this is not the case here. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
Brian, Thanks for your response. Please see inline: On 6/26/2008 4:23 PM, Brian E Carpenter wrote: Lakshminath, On 2008-06-26 23:43, Lakshminath Dondeti wrote: On 6/25/2008 2:41 PM, Brian E Carpenter wrote: ... Our fundamental collective job is defined in RFC 3935: The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. That means that it is *not* our collective job to ensure that a WG consensus survives critical review by the IETF as a whole and by the IESG, if there's reason to believe that the IETF as a whole doesn't agree with the WG consensus. And it's clearly the IESG's job to ensure that the critical review and final consensus (or lack of consensus) occur. But, surely the WG consensus counts as part of the overall IETF consensus process, doesn't it? Please see the example in my response to Jari. The shepherding AD (or at least the document shepherd) has an idea of the WG consensus as well as the IETF consensus. We cannot simply weigh the latest opinions more than all the discussions that have happened as part of the WG consensus. At one level I agree. But suppose that the set of people who are active in the SXFG7M WG are so focused on the sxfg7m protocol that they have all missed the fact that it's extremely damaging to normal operations of the m7gfxs protocol? And this includes the responsible AD, who has no deep knowledge of m7gfxs? This is the sort of problem that IETF Last Call and IESG review is intended to find, and it may well mean that the WG consensus ends up being irrelevant to the IETF non-consensus. (I'm not in the least suggesting that this applies to the draft that led to the appeal that led to this thread.) For what it's worth, I am not talking about a specific draft or a specific WG at this point. I am of the opinion that we are not discussing a one-off issue. If protocol X disrupts protocol Y, we get into very interesting situations. It is also going to get us into a rathole that I want to avoid. My point was this: if a WG actually missed anything substantial and that comes out during an IETF last call, and the shepherding AD agrees, the document gets sent back to the WG. If the shepherding AD also misses or misjudges, any member of the IESG can send it back to the WG for resolution. What I think is not acceptable is for the author and one or more DISCUSS ADs to hack up the document and publish it. If it so happens that the issue raised was considered and ruled out as a non-issue by the WG, then the shepherding AD knows the situation already. Strong consensus in the working group damaging a protocol that matters to very few people (ok, that's a rathole) -- but here is where judgment is necessary. And as you note, any of the judgment calls are appealable. regards, Lakshminath My conclusion, again, is that in the end this is the sort of judgment call that we *expect* the IESG to make. And when we feel they've misjudged, we appeal, and that tunes their judgment for the future. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
On 6/26/2008 6:35 PM, SM wrote: At 04:43 26-06-2008, Lakshminath Dondeti wrote: But, surely the WG consensus counts as part of the overall IETF consensus process, doesn't it? Please see the example in my response to Jari. The shepherding AD (or at least the document shepherd) has an idea of the WG consensus as well as the IETF consensus. We cannot simply weigh the latest opinions more than all the discussions that have happened as part of the WG consensus. The document may be a product of WG consensus. It still has to pass through the community and the IESG to be published as an IETF document. The WG knows about the internals of the document and generally have a focused view. The last call allows a wider range of input and to gauge the impact the proposal may have in other areas. It is not about weighing the latest opinions more. The author/shepard can always post an explanation. The participants in the WG should be aware that there will be an IETF-wide last call. You cannot blame the process if they choose to remain silent instead of taking part in the last call. Note that letter-writing campaigns in a last call have been proven to be ineffective. Is it really necessary for all the battles to repeat on the IETF list? Why can't the shepherding AD judge the overall consensus? thanks, Lakshminath Regards, -sm ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
On 6/25/2008 9:19 AM, Melinda Shore wrote: On 6/25/08 11:44 AM, Lakshminath Dondeti [EMAIL PROTECTED] wrote: I would like to hear others' opinions (I was going to put together a draft with some ideas on how we might define these roles, but I want to hear others' thoughts before I do that) on this topic. I think your points are valid, but I'm not sure what the effect would be if you controlled for quality coming out of the working groups. That is to say, I think that occasionally working groups are coming to consensus on bad documents or bad ideas, and that the incidence of that is increasing. Well that is a disturbing trend as well. A long while ago now, one of the then ADs mentioned that he needed to put a DISCUSS on a few successive MSEC documents that I was shepherding and mentioned that he wants to have a chat with the chairs on the quality of documents that we are forwarding. I asked him to come to one of our meetings and explain the expectations directly to the WG. That never happened. But that is the kind of direction or steering an area director might do if working groups are indeed producing bad documents and advancing bad ideas. Presumably they are several cases here, viz., going against charter or just being plain terrible at writing interoperable specifications. Pushing a document back to the WG is actually a better thing, I am beginning to think. Sure that may introduce delays initially as we learn how to operate in that mode, but the process of writing specifications is more transparent and more consensus based than in the current model of operation. One of the problems with the current model is that comments toward the end of the process, either AD's or reviewers', are weighted more than comments during the working group discussions, at least in some cases. If that's true it once again raises the very familiar question of picking up quality problems earlier in the process. Actually, that latter question applies regardless. Yes, I have heard it mentioned several times before, but I haven't seen any concrete steps to achieve that. I am now making the case that if a document makes it beyond the shepherding AD and put on the IESG telechat, changes to the text should be relatively a big deal. There can be changes, but they should be reviewed by the WG. In some cases, there have been bitter disputes about taking change control from authors and putting it in the hands of a WG, but the current model toward the end of the process seems to put change control in too few hands. That is what I am trying to highlight. regards, Lakshminath Melinda ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
Jari, Thanks. Some thoughts inline: On 6/25/2008 11:30 AM, Jari Arkko wrote: Lakshminath, Better understanding of the type of behaviors in this space would certainly be useful. And I don't want to disagree with your assessment of the behaviors; many of them sound like something that appears in practice. In particular, the shepherds are far less involved in the Discuss resolutions than the authors. And we do not involve the WGs as much as we should. I think writing guidelines on what the role of the various persons in the process is would be very useful. And obviously we should start by better following of the existing documents, like the Proto Shepherd RFC or the Discuss criteria document. Of course. I will try and see if I can put something of an initial draft coherently. However, with regards to blocking consensus of a WG, please remember that the WG is not necessarily the only place where consensus is tested. I recently had a case which had significant IETF Last Call discussion. I held a Discuss to ensure that the (fairly clear, IMO) conclusion from the discussion would be taken into the document. It did eventually, but only after significant back-and-forth with the authors. Overriding the original WG consensus? Yes. Right thing to do? I think so, not only was it right technically but it was something backed up by the Last Call. Did we get the details right, did the text go too far or did it fall short? I don't know, its a judgment call. The end result was somewhere between the LC guidance and authors' opinions. Painful for the WG? Sure. So, here is where I am probably confused as to how consensus is determined. I understand that the documents are eventually IETF Consensus with the IESG determining what the consensus is. The sponsoring AD has the overall view of any given document better than anyone else, at least in the authoritative role (for this discussion, I am just considering WG documents). Consider a hypothetical case: a large WG has strong consensus on one of their documents, they believe it is within the charter's scope and think that the document is in the best interest of the Internet. The WG chairs assess the consensus, and forward the document to the shepherding AD. The shepherding AD takes one last look, determines everything is in order and sends it to last call. A few people on the IETF Discussion list think that the proposed specification is about to doom the Internet. A few others who have not even read the document agree based on emails. Most of the WG members are either not on the IETF list or choose to stay silent. The shepherding AD considers those comments, thinks that those issues have been addressed already and puts the document on the IESG agenda. All other ADs (except one) think that everything is fine and vote No Objection. One AD agrees with the few people on the IETF Discussion list and decides to put a DISCUSS and proceeds to hack the document. In the current model, other than the very few exceptions cited recently, the AD gets what he or she wants for the most part. It is plausible that AD may do this even if no one else identified a problem. Responding to Brian here: Note that I am not pointing fingers at IESG alone, but yes, I am pointing fingers at our process in that the hypothetical situation described above is allowed to happen at the moment. Brian suggests external factors, but I am sorry I am not convinced. If there are WGs that have forgotten the IETF's mission, it is one of the primary roles of the ADs and the IESG to steer those WGs in the right direction. If our technology is becoming harder and more complex, it calls for involving more people and increasing transparency and not the other way around. On text that comes from the IESG: this is more common in recent years than it was before. I am one of the ADs who tends to do that, both for the documents that I sponsor and for resolving my Discusses. But I would rather not do it. But I often end up doing it if there is no progress otherwise; I want to get my sponsored documents approved and I want to reduce the list of my outstanding Discusses. If I can help my authors by proposing text, I will do it. Jari, as I have noted before, if the status quo is considered the best way forward, I would rather you continue to propose text. I as an author and document shepherd have appreciated that compared to the alternative. That alternative, the iterative guess work, takes forever. But I would really like to see the document shepherds in active role here. Or at least the authors. The general guidance for authors whose document gets a Discuss is to first confirm whether the raised issue is a real one or not. If it is not, ask the Discuss to be cleared. Fight if needed! If it is real, work with your shepherd and WG to develop a proposal to fix the problem. Mail the proposal to the Discussing ADs in a timely manner.
Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
On 6/25/2008 4:28 PM, John C Klensin wrote: --On Thursday, 26 June, 2008 09:41 +1200 Brian E Carpenter [EMAIL PROTECTED] wrote: ... And of course, individual ADs have to think carefully whether a given issue is or is not worthy of a DISCUSS, and sometimes they get it wrong. But that will always be true, however we tune the process and procedures. Brian, While I agree with this, I also believe that there have to be effective safeguards against bad judgments prevailing for too long. And I believe that those have largely slipped away from us... unless we believe that making changes, unvalidated by WG or mailing list consensus, simply to get a DISCUSS removed is the right way to get to high quality, relevant technical and engineering documents Indeed that is the issue! regards, Lakshminath john ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
On 6/25/2008 2:41 PM, Brian E Carpenter wrote: On 2008-06-26 06:30, Jari Arkko wrote: Lakshminath, Better understanding of the type of behaviors in this space would certainly be useful. And I don't want to disagree with your assessment of the behaviors; many of them sound like something that appears in practice. In particular, the shepherds are far less involved in the Discuss resolutions than the authors. And we do not involve the WGs as much as we should. I think writing guidelines on what the role of the various persons in the process is would be very useful. And obviously we should start by better following of the existing documents, like the Proto Shepherd RFC or the Discuss criteria document. However, with regards to blocking consensus of a WG, please remember that the WG is not necessarily the only place where consensus is tested. I recently had a case which had significant IETF Last Call discussion. I held a Discuss to ensure that the (fairly clear, IMO) conclusion from the discussion would be taken into the document. It did eventually, but only after significant back-and-forth with the authors. Overriding the original WG consensus? Yes. Right thing to do? I think so, not only was it right technically but it was something backed up by the Last Call. Did we get the details right, did the text go too far or did it fall short? I don't know, its a judgment call. The end result was somewhere between the LC guidance and authors' opinions. Painful for the WG? Sure. On text that comes from the IESG: this is more common in recent years than it was before. I am one of the ADs who tends to do that, both for the documents that I sponsor and for resolving my Discusses. But I would rather not do it. But I often end up doing it if there is no progress otherwise; I want to get my sponsored documents approved and I want to reduce the list of my outstanding Discusses. If I can help my authors by proposing text, I will do it. But I would really like to see the document shepherds in active role here. Or at least the authors. The general guidance for authors whose document gets a Discuss is to first confirm whether the raised issue is a real one or not. If it is not, ask the Discuss to be cleared. Fight if needed! If it is real, work with your shepherd and WG to develop a proposal to fix the problem. Mail the proposal to the Discussing ADs in a timely manner. Address explicitly all components raised in a Discuss, either by explaining how they are not issues or providing a solution to resolve the issue. Our fundamental collective job is defined in RFC 3935: The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. That means that it is *not* our collective job to ensure that a WG consensus survives critical review by the IETF as a whole and by the IESG, if there's reason to believe that the IETF as a whole doesn't agree with the WG consensus. And it's clearly the IESG's job to ensure that the critical review and final consensus (or lack of consensus) occur. But, surely the WG consensus counts as part of the overall IETF consensus process, doesn't it? Please see the example in my response to Jari. The shepherding AD (or at least the document shepherd) has an idea of the WG consensus as well as the IETF consensus. We cannot simply weigh the latest opinions more than all the discussions that have happened as part of the WG consensus. That, IMHO, is the proper role of a DISCUSS and the proper reason for delays in document approval. And if we see fluctuation in these delays, and fluctuation in the amount of active intervention by the ADs, it does not follow that the IESG is to blame. Maybe there are external factors, maybe there are WGs that are forgetting the IETF's mission, maybe our technology is getting harder and more complex. So I'm very dubious about using either quantitative *or* qualitative observations to point the finger at the IESG, or at process issues in general, without digging much deeper. Of course, the IESG needs to pay attention to delays, so Jari's data (like the earlier data that Bill Fenner used to produce) are very valuable. And of course, individual ADs have to think carefully whether a given issue is or is not worthy of a DISCUSS, and sometimes they get it wrong. But that will always be true, however we tune the process and procedures. I am suggesting that we make further progress along the lines of the definition of the role of the document shepherd and reassert (or clearly define and state the expectations) on the roles of the document shepherd and shepherding AD. regards, Lakshminath Brian ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
Hi all, I am concerned by the following trends: * Number of outstanding Discusses is growing. (Thanks to Jari's data) * The extent of text changes as part of Discuss Resolution is increasing (I have only anecdotal evidence on this; perhaps others have statistics). * In some cases, members of the IESG are pretty much writing core parts of documents (or worse yet make authors iterate until the text is satisfactory), overruling WG consensus, based on personal opinions or citing solicited reviews. There are a number of derivative trends as well: * ADs who cannot convince working groups seem to use the threat of DISCUSS to get their way. * I would have thought document shepherds represent and defend working group consensus and shepherding ADs defend the completeness, accuracy, relevance of the drafts and defend their assessment of the IETF consensus. But, increasingly, it seems to fall on an AD holding a DISCUSS position, and authors to discuss and agree on text which becomes finalized without any other review. (Note: I am a guilty party in some of these cases, as document author and document shepherd. In all cases, I seem to have looked for an expedient way out rather than find a solution to what seems to be problematic). * One of the new trends seems to be to use DISCUSS to include applicability statements in current drafts to avoid potential DISCUSS positions on future drafts. That or some variation of that is status quo. It should not be that way. I would like to see a better definition of the roles of the WG, authors of a document, document shepherds, shepherding ADs and other ADs in our standards process. I would like to hear others' opinions (I was going to put together a draft with some ideas on how we might define these roles, but I want to hear others' thoughts before I do that) on this topic. thanks, Lakshminath On 6/25/2008 4:37 AM, Jari Arkko wrote: deleted text That being said, it is beneficial to understand what is happening and what changes are occurring in the process. Or understand where improvements might have a negligible vs. visible impact. One of the things that the IESG has been concerned about recently is that the number of outstanding Discusses is growing. We talked about this in our May retreat and identified some actions to help reduce this problem. For instance, better tool support so that the ADs would better see the different things that are waiting for their action, getting the document shepherds better involved in the resolution process, informing authors how they should respond to Discusses, using RFC Editor notes to make small changes when the authors are slow in producing a new version, better checks of documents before they come to telechats (e.g., to ensure that formal syntax in a document is free of errors), etc. These would be in addition to the usual things we'd do, like debate whether the Discuss was within the Discuss criteria, whether the issue is real, try to ensure that the AD and the authors are being responsive over e-mail, etc. Another interesting area to think about is the time that our processes take. For instance, documents that go through me take on the average five months from publication request to approval. But there is a lot of variation. This time includes everything from AD review, IETF Last Call to IESG review and waiting for document revisions, etc. One interesting piece of information is that documents that require no revision during this process are very rare, but they go through the system about five times as fast. If we look at the (unreliable) substates, they appear to indicate that the IESG processing time is divided roughly 1:2:1 for waiting on AD, authors, and mandatory process waits like last call periods. I am working to extend the analysis a little bit further by including individual draft and WG document stages. You see some of the results of this in the third URL above, but I'd like to understand what fraction of the overall draft-smith-00 to RFC time is taken by the different stages for all IETF work, and how the stages have developed over time. Comments and suggestions on what would be useful to measure are welcome. Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
On 6/17/2008 9:45 AM, Dave Crocker wrote: Lakshminath Dondeti wrote: Hi David, Thank you for sharing this information. Now that the community knows this, perhaps this will be an option when there are snags in the process in future. Folks keep missing the point: The current situation is not about lacking creativity or options. It is about having rules but failing to follow them or inventing them on the fly. I am not claiming that not having precedence (which is now corrected to widely-known precedence) is the only problem. However, there is a point here in that if one or two ADs are failing to follow [rules] or inventing them on the fly, what are the rest of the IESG members doing? I have received a few responses, offline and in this thread to that question. regards, Lakshminath What David's note underscores is that it is entirely possible to take even a difficult Discuss and attempt to pursue it actively and constructively. His seeking to assess consensus within the IESG is an exemplary case of trying to work as a team rather than an 'expert' individual. d/ ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
On 6/13/2008 6:14 PM, John C Klensin wrote: I note that, while the present situation and 2821bis constitute particularly glaring examples of these misplaced priorities and abuses, none of the issues above is unique to 2821bis. They are really about how the IESG manages and expresses its authority and discretion. John, I applaud your decision to appeal an IESG DISCUSS (I have read far enough to understand that the basis of the appeal was consensus among folks who are closely following this matter and chose to comment on the matter of whether to file an appeal). I do not have a strong opinion about this specific case (I may even be in disagreement with some of the specifics stated in the appeal), but I believe it is necessary for the community to exercise their right to appeal to let the IESG know that their predisposition to use DISCUSS for imposing personal preferences, biases or undocumented norms is inappropriate at best. I strongly agree with the conclusion that we cannot rely on norms supposedly established based on instances of compliance under duress (ok, I agree that is a bit of hyperbole). I have also been disappointed by the IESG not once invoking the override procedures even when a DISCUSS is clearly inappropriate. An appeal crossed my mind a few times in the recent past and I have seriously considered appealing a couple of times, but due to time constraints chose to pursue the path of least resistance. I thank you for taking the time and energy to appeal. best regards, Lakshminath ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: EMSK key hierarchy and the DSRK
The DSRK can be scoped just as the EMSK can be scoped. regards, Lakshminath On 3/19/2008 9:45 AM, Dan Harkins wrote: Hello, My apologies for being obtuse. This Mother of All Root Keys I've been describing is what the EMSK Key Hierarchy calls the DSRK. The HOKEY key that the ERP/ERX draft uses can be derived in one of two ways: EMSK | USRK-- the HOKEY key, aka rRK or like this: EMSK | DSRK--- the MOARK | DSUSRK -- the HOKEY key, aka rRK This latter derivation is the one that will be used in practice, I believe. This DSRK is not properly defined and cannot be properly scoped. It really has nothing to do with Handover Keying which is what HOKEY is supposed to be working on. I believe the DSRK is problematic and the ability to derive a DSRK should be removed from the ESMK key hierarchy draft and the corresponding change be made to the ERP/ERX draft to remove reference to using a DSRK to derive HOKEY keys. This change would also simplify the key hierarchy and remove a you can do it this way, or you can do it that way option which experience has shown is a really bad idea. regards, Dan. On Tue, March 18, 2008 6:22 pm, Dan Harkins wrote: Hi Avi, On Tue, March 18, 2008 3:13 pm, Avi Lior wrote: [snip] I suggest we discuss the issues with deriving keys from EMSK so that people can make informed decisions. Lets keep the FUD factor low. Good idea. Can we start with the Mother Of All Root Keys (MOARK) that is derived from the EMSK? This seems like a particularly un-scope-able and undefined key. It is not needed for Handover Keying; all HOKEY needed to do was define a HOKEY-specific key from the EMSK but it didn't, it defined a MOARK, and then a HOKEY-specific key is being derived from the MOARK. Since the MOARK is really the only key being derived from the EMSK I guess this makes for a nicely constrained discussion. Dan. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom process realities of confidentiality
On 3/19/2008 11:12 AM, Eric Gray wrote: Dave, I think I disagree with you on several of the details in your discussion without necessarily disagreeing with where you are going with it. First of all, I think that the realistic view of the possibility of something leaking is enough to ensure that people do not make things up when giving feedback. The fact that what a person says may eventually get back to the one they said it about tends to make people stick to facts. Eric, May I assume you use the word leaking above in the context of (d) and (e) below and other similar contexts? Next, I wouldn't quite say people make things up; each person communicates their perceptions and the nomcoms may then investigate how pervasive is the said feeling in the community, if they don't already know from the feedback already collected, balance all other view points and figure out what is in the best interests of the community. It is a subjective process and that's why we use humans to do it. thanks, Lakshminath That is useful. But the possibility needs to be very small. However important people may feel it is to verify what they hear, it is not a good idea to turn everything you hear into some sort of juicy gossip to be handed around like used needles. That is not only not useful, it leads to potentially seriously disruptive emotional reactions to what may very well have been meant as consturctive criticism. In addition, I think that someone who cannot deal with the possibility that they may hear things that they have to either keep entirely to themselves, or exercise a very high degree of discretion about, should be straight-forward about that at some point before they are exposed to that kind of information. If that means they have to step down from a liaison role, or some other role in the NomCom process, then that is what they need to do. However, I think this is buried in your comments under what I think you're identifying as the human factor - and it is true that the degree of discretion that applies is a very hard fence to walk. Never-the-less, some very simple guide-lines do exist. For example, consider the following: In a private NomCom discussion Sigfreed tells Signund that she heard that the candidate Borg has a reputation for being excessively stubborn. Signund happens to know Borg very well and they have been friends for many years. The possible choices for Signund range across (at least) the following possibilities - a) ignore the comment because it is clearly already second hand information, b) explore the comment further with Sigfreed to see if there is anything she knows from first hand, c) accept the comment as one data point but otherwise keep it to themselves, d) check with a number of other people to see if they have gotten a similar impression, but without referring to any specific source(s), e) check with Borg to see if there is any reason why anyone might have gotten the impression that Borg is stubborn (again being careful not to offer names), f) ask a few people where Sigfreed might have gotten such an impression about Borg, g) tell Borg that Sigfreed is saying that Borg is a stubborn person. Assuming that we all have pretty much the same ideas about what confidentiality means, I think it is fairly obvious that most people would agree that either a), b) or c) would be correct behaviors, and that d) and (possibly) e) might be okay under some circumstances but f) and g) are definitely out of line. I suspect that d) and e) are in the area in which leaking of confidential information is most likely to occur. Sure, it is possible that someone has decided to ignore a more conventional meaning of the word confidential to suit a personal agenda. Or it is possible that they are operating with a different understanding of what most people mean by confidential. But - for the most part - indiscretion in this context is a result of simply sharing more information than intended while trying to verify something we need to be certain about. On the whole, I think most people understand that is something that can happen. I also think that what people are really concerned about is that confidentiality is not being observed as a convention, and as promised during the process. That must remain a legitimate concern. And the reason why that is the case is that it is necessary in getting honest and unambiguous feedback about people that the people being asked _believe_ that they're comments will be kep confidential. -- Eric Gray Principal Engineer Ericsson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Wednesday, March 19, 2008 1:11 PM To: IETF Discussion Subject: Nomcom process realities of
Re: Thoughts on the nomcom process
Mike, Thanks for your note. Are you saying that there is text within 3777 that says that confirming bodies should not ask for verbatim feedback but could ask for verbatim questionnaire responses? Consider this: what if the next nomcom were to be asked to provide verbatim feedback by one of the confirming bodies, what should they do? The supporting information that was cited from 3777 is very generic (with specific information provided later, if I may point out again) and so I don't see a reason why it cannot be cited in the context of that request. For the nomcom process to work, a number of people in the community ought to believe in it sufficiently to volunteer their time and a larger number of people need to believe in it to provide feedback. What am I hearing from my vantage point (having been a nomcom member for 3 out of the past 4 years) is what guides me to work on this; my goal is to maintain and if possible increase the level of confidence in the process. When I ask for information, I provide assurances that the information is for nomcom's eyes only (for instance, this was specifically the case when we interviewed people). 3777 also says any dissemination of private information by the nomcom must be minimal. So, I for one cannot just hand out private information without clearer text in 3777. Finally, when I make a mistake, I am more than ready to own up to that. In this case, my choice of words is quite appropriate. regards, Lakshminath On 3/16/2008 3:28 PM, Michael StJohns wrote: At 05:46 PM 3/16/2008, Ole Jacobsen wrote: You said: The confirming bodies should not be concerned with the way the Nomcom got to the point of nominating someone (at least not during the process), but they are there to examine the nomination and nominee and to determine if - in the confirming body's best judgement - the nominee is acceptable for the position. And yet you believe that ALL the information provided by a candidate to the nomcom should be freely available to the confirming bodies? That's not actually what I said. What I said was the list of information requested by the IAB in the referenced document was reasonable and appropriate. But let's break down ALL for a minute A candidate provides data that is either a) relevant to his selection by the Nomcom or b) is not relevant. If the Nomcom relies on a piece of information provided to it by the candidate (lots of possibilities, but lets try something like I currently work for ABC company - and I realize the other AD also works there, however I'm leaving my current job on X date and moving to Y. My new employer has agreed to sponsor me.),then its relevant. I'm unsure how the confirming body confirms the candidate without also being apprised of this information. I can do more examples, but my personal belief is that any information a candidate provides that the Nomcom relied upon to select the candidate is fair game for the confirming body. In general though, I think the IAB struck a good balance with what it wanted. The only thing at issue here is: What information did the candidate think would be forwarded to the confirming body and what information did he/she have a reasonable expectation would stay within the committee? Not really. As has been pointed out numerous times before, the confirming bodies are within the cone of silence of the nominations process. This interpretation of the confirming bodies as adversaries to the Nomcom that shouldn't ever see the raw material is fairly recent - 5-6 years maybe. Ask any given candidate about whether or not they anticipated their responses to the questionnaire were or were not fair game for the confirming body and I expect you'll get a huh? I know if I submit something to the process, I expect it will be used where it needs to be used to get me confirmed. Why, given any reasonable reading of 3777 (or its predecessors), would I think otherwise? This may not require a new process RFC, it may simply require a questionnaire with a confidential section. A Please don't tell the IAB but you should know... section? And what exactly would you expect a candidate to put in this section? I'm not saying its a bad idea, but I'm having problems conceiving of information that the Nomcom should consider that the Confirming body should not. If you're talking about information provided in confidence to the Nomcom as commentary by one candidate on another - that's a whole other matter and has its own set of problems. But I think that's not what you're talking about here? The rest of your note isn't worth responding to since you choose to use such phrases as FUD and HOG WASH. Sorry Mike, I would have expected better from you! And I would have thought better of you as well. I would have expected you to consider my terms, then consider the tone of Dondeti's text. He said: I believe that the IAB's
Re: draft-ietf-hokey-emsk-hierarchy-04.txt
Hi Joel, Many thanks for your review. Some notes inline: I am a bit under the weather, and so if I am incoherent, please feel free to say so. Thanks. On 3/17/2008 1:47 PM, Joel M. Halpern wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). Please resolve these comments along with any other Last Call comments you may receive. Document: Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) Reviewer: Joel M. Halpern Review Date: 17-March-2008 IETF LC End Date: 17-March-2008? IESG Telechat date: N/A Summary: This document appears ready for publication. Comments: While there has been much discussion on the IETF list of the references to applications in this document, I have chosen not to comment on that. It seems to me that the relevant statement is that specific usages are out of scope for this document. The one thing that bothers me a little is the intended status of this document. Given that the EMSK is entirely inside a system, and that therefore the actual generation process is internal to that system, I am not sure that a registry tied to the specifics of the generation mechanism, is appropriate. A lot of this document is of the form if you don't define it some other way, do this. While very useful text, it actually doesn't seem to affect on-the-wire interoperability. So I wonder if this whole document is more informational than proposed standard? I'm not sure on this, but the containment property did strike me reading the document. The peer and the server need to arrive at the same derivations. The keynames derived as specified in this document would be used in protocols specified elsewhere to refer to the keys derived independently at both ends. So, whereas there are no on the wire packet formats in this document, other documents will put information derived as specified in this document in their packets. Minor: While I would guess that the usage is actually the normal usage, the definitions of Usage Specific Root Key, Domain Specific Root Key and Key Management Domain are somewhat confusing for the outside reader. Specifically, the Key Management Domain is defined as being the scope of a given root key. This leads the reader to conclude that any root key is inherently domain specific, because it defines a domain. So how can one have a special kind of Domain Specific Root Key that is restricted to use in a specific key management domain. At a guess it is the difference between a domain defined by the key and a key defined to fit an existing domain. But I hate guessing when it comes to RFCs. Given that the document later defines the domain for DSRK in terms of domain names, adding separately defined or even defined by a domain name to the DSRK definition would address this. The last of the requirements (about separation of domain keys and usage keys and avoiding label collision) requires material later in the document in order to be understood. A forward reference would be a good idea, indicating where the domain name and usage key label are described. It looks like some clarification is in order in the text. regards, Lakshminath ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confirming vs. second-guessing
On 3/16/2008 7:36 PM, Michael StJohns wrote: My apologies, I was going to leave this alone, but this ... chastisement .. is off-target. At 09:50 PM 3/16/2008, Joel M. Halpern wrote: Mike, whatever your personal opinion, based on the public information many people have concluded in good faith that something went wrong. I agree with this. Something went wrong. Asserting that the problems are FUD does not help anyone resolve this. I'm sorry you didn't actually read what I wrote. I did not refer to the problems as FUD. I called one specific statement by LD FUD and hogwash. The statement was an attempt to use an emotional response to an unlikely or improbable action by the IAB sometime in the future to gain an outcome (e.g. don't let this dangerous precedent stand) that matched his personal belief. What would you call it if not FUD? Never mind. Substitute an emotional appeal for FUD and This is an absurd extrapolation of what the IAB may do in the far future for hogwash and see if you like the text better. I guess I should respond to this. Why would the extrapolation be absurd? Where is it stated that a confirmation body cannot seek such information? One of the IAB requirements is to provide a summary of feedback on a candidate. From there to asking for verbatim feedback is not a stretch. I am not saying IAB would ask for this. I am saying one of the confirmation bodies could ask for this and the nomcom would be in the same situation. Expressing incredulity does not work in such situations. I have tried. regards, Lakshminath Mike ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: On the confidentiality of the information and communication within the nomcom context
I have been a bit under the weather and responding to some of the emails. I hope to catch up in the next couple of days. On 3/16/2008 1:56 PM, Brian E Carpenter wrote: Hi Lakshimnath, just a few notes and queries... On 2008-03-16 16:10, Lakshminath Dondeti wrote: ... * Nominee lists should be made public. In fact, other selection processes within the IETF make the candidate lists public and so it is time we let go of this in the nomcom context. The case against is fairly weak at this point in time. As I recall, this was discussed extensively before 3777 (and before 2727) and opinions were so evenly split that the only possible conclusion was no consensus for change. So we'll need to see if opinions have changed... (My opinion: on the occasions when I was a candidate, I would have had no problem with it being made public. But the tricky part is at what stage the list of candidates is considered stable enough to be published.) As Ole noted, we have crossed this bridge in some cases within the IETF already. I understand Melinda's concern about the whole process beginning to look like elections, but I think this would be for the better. We can keep everything else pretty much the same, publish the nominees lists and take away the complexity within the feedback collection process. The positive side effects (in fact, these would be my goals) are that we will get more nominees and more feedback, on balance. As it stands now, we make the lists pretty much public (by casting a wide net as the current nomcom has done and as some of the past nomcoms have done), but they are not public until after the nominations are closed. There are also a few people who want the list of nominees for one or more areas and we say no, for obvious reasons. * Nominees are required to publish a statement for public consumption; in fact, I would go further and require making some of the information that normally goes into a typical questionnaire response public. I think that depends completely on the previous point. Yes. * The nomcom in the course of its operation may collect any type of information and all that is for nomcom's eyes only. The nomcom shall only provide testimony to the confirmation body based on that information. * Members of the community may contact any nomcom member and ask to anonymize their feedback; nominees cannot provide anonymous feedback on other nominees for the same position. * Non voting members may share and assert the opinions of the bodies they represent, at will. All personal opinions shall be shared on a pull-basis, initiated by the voting members or the chair. * The nomcom chair should not share personal opinions on candidates. It To be clear, do you mean the chair should not share his or her personal opinions? Yeah. I am ok with leaving this to the chair though, if that is better. is advisable to not share opinions even on a pull-basis. The chair's role is to ensure that the nomcom voting members consider all opinions from the community. * The confirmation bodies shall not receive any verbatim information pertaining to the nomcom (either information collected by the nomcom or generated during the nomcom process). I think that's a pointless restriction. In fact I would see a positive benefit in the nomcom's testimony including extracts from community feedback. There's no point in forcing the nomcom to perform an exercise in paraphrase. (Any such extracts should be anonymous, of course.) My worry is that verbatim text may leak information about who provided them. Some of us have unique styles in writing. Anyway, that's my opinion. * The confirmation bodies are to be provided testimony on the selection of each candidate. The testimony shall include the nature of information collection and the debates; it may include a summary of feedback and a characterization of the the strength of support for the candidate within the community and the nomcom. * Confirmation bodies may base their decision on information not available to the nomcom. They are encouraged to share information on nominees with the nomcom and contribute to the timely completion of the nomcom process. * Confirmation bodies must inform the nomcom of their decision within 4 weeks of receipt of the first communication from the nomcom with the names of the candidates and the mandatory information to be included in the testimony. If there is no response, the candidates are assumed to be confirmed. The rules currently say The completion of the process of confirming the candidates is due within 1 month. I can see an advantage in making that more precise, as you suggest. But I don't like the default exit - if a confirming body doesn't respond, I believe that should trigger a rather uncomfortable blowback towards the confirming body. Otherwise we are setting them up to abstain when
Re: IETF Last Call on Walled Garden Standard for the Internet
On 3/17/2008 7:23 PM, Harald Tveit Alvestrand wrote: Narayanan, Vidya skrev: All said and done, here is what it boils down to - any application of EAP keying material to other services (using the term here to include things ranging from handoffs to mobility to L7 applications) is only feasible when those services are provided either by or through the provider handling network access. It is also only feasible when those services are only running over EAP-capable interfaces (well, without horrible abominations, anyway). So, if a network access provider requiring EAP is rolling out applications, I don't see a good reason why the application cannot use keys coming out of the EMSK. The counterargument is, of course, that such coupling will put the network access provider into a privilleged position wrt providing those applications on his networks; in particular, any competitor wanting to deliver those same services (think Internet telephony/Skype or video-on-demand/YouTube) will have to roll out his own authentication/authorization infrastrucure, and get users to adopt it in addition to the one they already have - OR to beg permission from the network owner to leverage his infrastructure. This violates the principle of network neutrality; you could easily argue that this is a battle that should be fought in the courts of public opinion and the US legislature, not in the standards organizations, but traditionally, the IETF's participants has had strong opinions on this matter. Fair enough. Although, we already facilitate this with EAP over IKEv2. The new stuff is just optimization, as Jari noted. The contention, at least between him and me is whether the optimization is needed or not. Our role at the IETF should be in defining the applicability of using such key material such that readers understand that this does not work when the application provider is independent of the network access provider or when the application runs over interfaces that do not do EAP. And, I believe our role ends there. I believe I agree with this statement, mostly. Jari wrote Tighten up the language in the hokey spec to not allow application keying, and we're done and I don't believe we are. We can do that and just sit back and watch non-compliant key hierarchies propping up everywhere (and worry about interoperating with those when we write our next spec) or do the responsible thing, which would be to clearly define the applicability, along with providing an interoperable means of defining the key hierarchy for those usages that want to/can use it. If usages exist that we find reasonable at all (that is, if we define ANY extensible hierarchy), I think experience shows that we'll have trouble achieving control by restricting the registration procedure - the early years of MIME is the poster child for that. While I have my doubts as to how much effect we have on the world by explaining why a particular thing is stupid/wrong/offensive/immoral, I have even more doubts about the effect of restricting registration as a controlling tool. The anecdote I'm reminded of is one from the Norwegian army, just before the German invasion of 1940 Senior Officer: And if the country is invaded, Lieutenant, how would you prevent the enemy from using the railroad system to move troops? Junior Officer: Burn all the tickets, SIR! Funny! :) Applicability statements and strong applicability statements come to mind! regards, Lakshminath Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-hokey-emsk-hierarchy-04.txt
Thanks Joel. Followup notes inline: On 3/17/2008 6:47 PM, Joel M. Halpern wrote: Thank you. Comment following your clarification. Joel Lakshminath Dondeti wrote: ... The one thing that bothers me a little is the intended status of this document. Given that the EMSK is entirely inside a system, and that therefore the actual generation process is internal to that system, I am not sure that a registry tied to the specifics of the generation mechanism, is appropriate. A lot of this document is of the form if you don't define it some other way, do this. While very useful text, it actually doesn't seem to affect on-the-wire interoperability. So I wonder if this whole document is more informational than proposed standard? I'm not sure on this, but the containment property did strike me reading the document. The peer and the server need to arrive at the same derivations. The keynames derived as specified in this document would be used in protocols specified elsewhere to refer to the keys derived independently at both ends. So, whereas there are no on the wire packet formats in this document, other documents will put information derived as specified in this document in their packets. That does make for a good reason for PS. I am however then confused by the description that the EMSK never leaves the server. I presume that this relates to other aspects of EAP that I am not familiar with. You may want to see if there is a way to phrase it that makes it a bit clearer. But given what you say, this is another minor issue, not a big deal. The note about EMSK never leaving the server is contextual; the other master session key, the MSK is sent to the authenticator (and thus leaves the server). We'll make a note of this as well for clarification. So, on balance, we have two clarifications make: one on domains (that came up elsewhere too, so we'll work on the text once again -- we did that during WG discussions) and another on EMSK being held at the server. regards, Lakshminath ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Thoughts on the nomcom process
Folks, I spent the last five days listening to the debates on the nomcom candidate confirmation process and the proposals to fix the process. As much as possible, I tried to stay away from the debates so I can carefully listen, understand and reflect. It appears that opinions on the causes ranged from 'everyone messed up' to 'everyone did the right thing, under the circumstances.' After listening to the many opinions, I further thought about the proceedings of the past 9 months and reflected on what went wrong. Next, I went back and reread various notes and emails. Andrew, this year's nomcom adviser, sent an email to me on July 24, 2007, titled Notes to next-year's chair in which he said the following confirmation process: I'll be happy to chat about the confirmation process well ahead of time so you know what to expect. We had that conversation in Chicago, and I recall Andrew noting that there were difficulties in the confirmation process with the IAB, and that he'll help out when the time comes. I recall noting that I will be extra careful in ensuring that we do all the due diligence in candidate selection and in preparation of testimony. However, I stopped there; in retrospect I should have exhibited more common sense and curiosity and asked Andrew more questions. But, I did not do that! I guess I can think of many excuses, but after all, I accepted the position and clearly did not do a good job. I can never explain how hard it is for me to say this, but I am sorry for my mistake. I know I made at least one more mistake in running the process. I think it is unfair to blame the entire nomcom in this case. The volunteer voting members deserve the thanks and appreciation that the community at large showed them at the plenaries last week, but none of the blame. Please direct any blame on the nomcom at me. I accepted the position of chairing this nomcom and the mistake of not catching this issue early enough is mine. So, what should we do now? First, I don't believe what Harald has suggested is the right direction. I believe that the IAB's interpretation of 3777 on the matter of the confirmation process sets a dangerous precedence whereby one of the confirming bodies could require that the nomcom provide (samples of) verbatim feedback. One could interpret the same text that the IAB cites -- all information and any means acceptable to them -- as being in support of that requirement as well. The community tends to express their lack of confidence in the process by not participating, for instance, not volunteering or not providing feedback. So, what is the best direction? I think a revision to 3777 is in fact needed. There are at least three things to do: 1. Define the roles and responsibilities of the people and the bodies involved in the process, more clearly. 2. Define the expectations on the confidentiality of the information collected. 3. Specify the nature information sharing within the nomcom process. Once we arrive at consensus conclusions on those, state those and revise 3777 to delete text that is inconsistent with those conclusions. Unlike other parts of our process, nomcoms are under hard time constraints and much of the work happens in secrecy. We are already late for any revision to be useful for the next nomcom. thanks, Lakshminath ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
On the confidentiality of the information and communication within the nomcom context
I understand that there is work underway on the topic of revising 3777 and I have also had several discussions with various folks on this topic. With no intention to undermine the work already underway, I will briefly state some of my thoughts. * Nominee lists should be made public. In fact, other selection processes within the IETF make the candidate lists public and so it is time we let go of this in the nomcom context. The case against is fairly weak at this point in time. * Nominees are required to publish a statement for public consumption; in fact, I would go further and require making some of the information that normally goes into a typical questionnaire response public. * The nomcom in the course of its operation may collect any type of information and all that is for nomcom's eyes only. The nomcom shall only provide testimony to the confirmation body based on that information. * Members of the community may contact any nomcom member and ask to anonymize their feedback; nominees cannot provide anonymous feedback on other nominees for the same position. * Non voting members may share and assert the opinions of the bodies they represent, at will. All personal opinions shall be shared on a pull-basis, initiated by the voting members or the chair. * The nomcom chair should not share personal opinions on candidates. It is advisable to not share opinions even on a pull-basis. The chair's role is to ensure that the nomcom voting members consider all opinions from the community. * The confirmation bodies shall not receive any verbatim information pertaining to the nomcom (either information collected by the nomcom or generated during the nomcom process). * The confirmation bodies are to be provided testimony on the selection of each candidate. The testimony shall include the nature of information collection and the debates; it may include a summary of feedback and a characterization of the the strength of support for the candidate within the community and the nomcom. * Confirmation bodies may base their decision on information not available to the nomcom. They are encouraged to share information on nominees with the nomcom and contribute to the timely completion of the nomcom process. * Confirmation bodies must inform the nomcom of their decision within 4 weeks of receipt of the first communication from the nomcom with the names of the candidates and the mandatory information to be included in the testimony. If there is no response, the candidates are assumed to be confirmed. regards, Lakshminath ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
On 3/13/2008 8:49 PM, Jari Arkko wrote: Avi, For what it is worth, this ex-EAP co-chair also thinks that the use of EAP keys for applications is a very bad idea. Why? For a number of reasons. Take this from someone who has actually tried to do this in the distant past and has realized that it was a bad idea. But first let me clarify that I'm not criticizing HOKEY for EAP keys in any way; HOKEY is a fine application for EAP keys. The document that started this thread can be fixed by better IANA and applicability sections. I've also changed the subject to reflect the new topic. Back to the reasons for why application keying based on EAP is a bad idea. First, there is an applicability statement in RFC 3748 which discourages the use of EAP for other applications than network access. We've generally treated this liberally and included things like VPN access (IKEv2) and mobility services in this as well. Use of EAP keys in other contexts than the network access itself presents a number of problems. The primary problem is that while EAP runs on many, many interfaces and products, the number of networks where is still relatively small, or at least its nowhere near ubiquitous. This presents a problem for applications that require EAP-based keys. This hotel network supports web logins, not EAP so does that mean I would be unable to use the EAP-based applications? And from the point of view of an application provider, why would I want to exclude the 99.9% of current Internet users that are not behind an EAP-based network interface? Let us consider the opposite situation. Let us say the hotel network uses EAP for authentication and the hotel front desk gives the IETF folks a scratch card with credentials. We then use the credentials for authentication using 802.1X-EAP (example only). The hotel or an associated third party also offers some services/applications and wants to provide them for free for the IETF folks. However the hotel does not want to share the credentials with the third party server. Sure, the hotel may not make this facility of key management for all application providers out there and this mechanism is not useful for general purpose application access. Why would we force the hotel to provide multiple sets of credentials for each additional service/application that they want to provide? Perhaps your argument is to use IKEv2-EAP in that case. Sure, we can use that. But, why not use the optimization when it is available? Why force IKEv2 again? Please see below for additional notes. The conclusion from this is that application keying should be arranged independently of network access. Note that in some cases you can use the same credentials to access a particular application, even if you are not reusing keys from the network access phase. For instance, IKEv2 and its EAP capability has been used in some mobility designs. But this is an independent run of EAP, nothing to do with the network access EAP run (if there even was one). This is an interesting distinction and I would really like to understand the logic behind the restriction. Using key material derived from the EMSK, derived after network access authentication using an EAP method for applications is not ok. However using the MSK from an EAP method run over IKEv2 for applications is ok. Are you saying that a fresh verification of possession of long term credentials is necessary for application access? Or does this have to do with some access technologies not choosing to adopt our protocol, EAP and us trying to optimize for those situations? If the latter, why wouldn't we add features to our protocols and increase adoption of our protocols? Or, perhaps we are suggesting that other people should not be using EAP and build their own mechanisms. Please clarify. Finally, many of the things that you want to do are impossible if you tie your applications to network access keys. For instance, if you are mobile you would ideally want to move from one access network to another. What if one of these access networks does not support EAP for network access. E.g., Wimax - 3G? What would this do to your ability to use an application? From what I know Wimax and 3GPP2 use EAP. 3GPP does not. We should optimize for access networks that use our protocols. When the user does roam to a non-EAP capable network, we force them to use IKEv2-EAP and they bear the cost of IKEv2 and an EAP method run. thanks, Lakshminath Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
On 3/9/2008 1:30 PM, Brian E Carpenter wrote: Lakshimnath, On 2008-03-08 21:12, Lakshminath Dondeti wrote: ... Reviewers are not accountable for delays. Well, at least for Gen-ART there is a deadline: the end of Last Call for LC reviews, and a day or so before the telechat for pre-IESG reviews. Obviously, reviewers are human and sometimes miss those deadlines, but they exist. Brian Brian, Thanks for the clarification. I know of those deadlines. Sam W also sets deadlines on sec-dir deadlines. My reference to the delays was in the context of overall delays that Thomas was also referring to, that is if and when a dialog ensues between one or more reviewers and authors and the goal becomes 'achieving some kind of a consensus with the reviewers' and there is really no accountability for delays and such. regards, Lakshminath ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
On 3/7/2008 11:18 AM, Thomas Narten wrote: Lakshminath Dondeti [EMAIL PROTECTED] writes: I have reviewed documents as a Gen-ART reviewer (during Brian's tenure I think), sec-dir reviewer and also provided IETF LC comments on some documents. As a reviewer, I am not sure whether I was expecting answers all those times. I am pretty sure I have not always stated whether or not the answers are satisfactory. On this one point. IMO, one of the biggest causes of problems (and most under-appreciated process weakness) in the IETF (and any consensus based organization for that matter) is poor handling of review comments. The ideal way to deal with them is to always respond, and to get an I am satisfied with your response to close the thread. Ideal being the keyword though. Not everyone, for any number of reasons, including cultural reasons, will come out and state all clear. It is also asking too much to ask the reviewer to get into a debate with the authors. It also fosters an environment where the reviewer starts becoming an authority. Anything else runs the risk of: - author says I dealt with those comments in the revised ID, with the reviewer saying Nope, I was ignored. - author says I dealt with those comments in the revised ID, and this actually was the case, except that they accidentally missed one or two important issues. Reviewer is left wondering was I blown off, or was this just an oversight, or... - author thinking they are done, because they responded on the list. But, no changes in the document and/or reviewer is still not happy. - reviewer having invested a not-insignificant amount of time doing a quality review feeling what's the point, which doesn't help to motivate a volunteer organization. This is especially problematic from the cross-area review perspective. I am not sure this is the right kind of motivation here. As one such reviewer, all I look for is thanks from the AD whose directorate or team I am serving on. And they have always been thankful. No, I do not constitute representative population. I am just offering one data point. Repeat above several times and intersperse with long periods of time where nothing happens on a document. You now have an idea of why it seems to take a long time to get documents through the system. Indeed. What started out as a great idea -- I volunteered to be a GenART reviewer 3-4 years ago now -- is beginning to become yet another burden in the process. One of the reasons I'm such a fan of issue trackers is that it tends to remove a lot of the above stuff by simply not allowing stuff to fall through the cracks. Sure, trackers have overhead and are overkill in some cases. But if one could somehow analyze the number of documents that have been delayed for some time due to poor handling of review comments... Yeah, it would be interesting. Although, I wonder what we will do with that information. Reviewers are not accountable for delays. There is no expectation of time commitment from them, for instance. Thomas ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
On 3/7/2008 10:56 AM, Russ Housley wrote: Lakshminath: So, I'll tell everyone how I deal with Gen-ART Reviews. Other General ADs may have done things slightly different. When I use a Gen-ART Review as the basis of a DISCUSS, I put it in one of two categories. (1) The Gen-ART Review was ignored. Like any other Last Call comment, it deserves an answer. So, this is a procedural objection. In this situation, I've been careful to say that the authors do not need to accept all of the comments, but then need to answer them. I have reviewed documents as a Gen-ART reviewer (during Brian's tenure I think), sec-dir reviewer and also provided IETF LC comments on some documents. As a reviewer, I am not sure whether I was expecting answers all those times. I am pretty sure I have not always stated whether or not the answers are satisfactory. Next, I can imagine an author not wanting to respond to something I may have said because it was totally bogus or inappropriate and does not deserve a response. That might very well happen when I review documents on a topic that I am not familiar with and haven't had the time to read related references (that varies depending on the time available, etc.). Perhaps that is not such a bad thing; being blissfully ignorant on some topics keeps me, well, blissful. I use somewhat of a hyperbole for obvious reasons. I am sure many other situations are much more nuanced. I hope ADs don't continue to hold a DISCUSS in those situations waiting for a dialog to take place or waiting for a consensus to emerge. I sometimes hint in my reviews that the topic may be at the border of my knowledge and if I have a bias. Perhaps that is helpful. Even if the response does not go to the person making the comments, ADs need to see a response. Silence does not help us understand if consensus has been achieved. Last Call is the only point in the development and review of many documents where review from other IETF Areas takes place. It is very important that this cross-Area review take place. Russ Russ, Thank you for your note. It's a fair thing to say that the ADs need to see a response. I also agree that cross-area review is important and at times unearths issues that may not have been raised in WG-level reviews. Personally, I prefer cross-area reviews to take place prior to the LC process and hope that the the LC process is for those issues that may have been really overlooked despite the best efforts of the WG chairs and ADs. I do not however quite understand the idea that we have to get consensus in the context of each GenART/Sec-dir/fill-in-the-blank review. It is of course quite plausible that one or two of those reviewers will never be satisfied with any level of revision of a given specification. In other cases, it may be that the reviewer has his or her personal preference on how to write documents and will never come out and say that the document they reviewed is ready. I have winced when some authors wrote to me after a review saying something along the lines of does the following revised text sound better. I would have been merely pointing out something I thought was not clear or might cause interoperability issues that they may have overlooked or missed. How they might fix it is entirely up to them (or the ADs involved). If their take was that they considered the comment and thought what they wrote is much more meaningful in the context of their work or the interoperability issue I raised does not apply within the scope of their specification, well so be it. Next, I trust them to do that. I don't need to see a dialog. I am willing to clarify my comments, and if I cannot articulate the issues I am raising clearly, well then the document needs to move on in the process. Either the shepherding AD or the AD who solicited the review needs to determine what if anything specific needs to be done in all these cases. They are the judges of consensus. No matter who the reviewer might be they were not selected by the community to do the AD's job. Creating an environment where all these additional reviews and reviewers essentially block document progress is not the right direction. best regards, Lakshminath ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: a thanks to the Gen-ART reviewers
And my thanks, specifically to Pasi, Miguel(twice), Vijay and Joel, who as GenART reviewers, provided thorough reviews of documents I recently shepherded or co-authored, and followed up diligently after revised documents have been published and sent a ready for publication or addresses all comments emails. Thanks guys. (I picked the recent instances). best, Lakshminath On 3/8/2008 7:03 AM, Michael Thomas wrote: Andrew Newton wrote: To Eric, Spencer, and all the other Gen-ART reviewers: Thank you. My experience with Gen-ART reviews has been very positive, and I appreciate your work and effort. I realize you weren't seeking public praise, but your volunteer contribution to the good of the IETF should be recognized. I have to say that I really like these and the cross area reviews a lot. As an author/editor having to digest zillions of posts on the lists mixed with time and entropy, it gets really hard to look at the draft with the critical eye of somebody who might have to actually try to make sense of it. Not to mention trying to determine what the draft says versus the lore that's built up around it. If I could make a suggestion, what might really be useful as well is collecting implementation notes, and especially what throws people off when coding up the draft, or implements things in new and unintended ways. Unintended can sometimes be very cool, but often it's that the draft isn't sufficiently precise. Mike, who tries to do this but given a cookie cutter form might do better On Mar 7, 2008, at 2:45 PM, Eric Gray wrote: Minimally, as one of the people to whom that has happened, it would be nice if at least an initial (thanks for the review and comments) mail included the commenter, in every case. Even a I wish you would stop bothering us with all of these silly comments would be a response. Of course, I presonally would prefer that that sort of response was not addressed to the list, with or without me on it. :-) ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom 2007-8 Chair's Report
Ralph, Thanks for your kind words. Indeed the nomcom members have put in a lot of hard work and as such deserve recognition. For the most part, the credit for the conception of the report goes to the circumstances that led to dispute resolution during the confirmation process. RFC 3777 says that the chair is to include the dispute report when reporting on the activities of the nominating committee. Normally we report on the activities of the nomcom during the IESG plenary. But, when there is a dispute report, it appears that a supplementary means of publishing the report is necessary. That said, I agree with you that, keeping the confidentiality issues firmly in mind, future nomcom chairs should publish such reports in an attempt to make the nomcom process as open as possible. I hope that the openness helps increase community participation in the process and encourage people to volunteer to be a voting member, provide feedback and accept nominations more so than in the past. best regards, Lakshminath On 3/6/2008 7:57 AM, Ralph Droms wrote: Lakshminath - thanks a lot for publishing this report. We all appreciate and applaud the work you and the Nomcom put into this year's I* selections, and I especially appreciate that you invested the time and effort - after all that earlier hard work - to produce this report. It will be of great value to future Nomcom chairs as well as the community as a whole, and I hope future Nomcom chairs will sustain the custom of producing similar reports (now I wish I had produced a report like yours after I served as Nomcom chair). - Ralph On Mar 5, 2008, at Mar 5, 2008,6:05 PM, Lakshminath Dondeti wrote: Folks, A report on the nomcom's activities is available at https://www.tools.ietf.org/group/nomcom/07/nomcom-report. Please direct any comments to [EMAIL PROTECTED] I will make a brief presentation at the IESG plenary. Abstract This document reports on the work of Nomcom 2007-8. The topics of discussion include the experiences in starting the nomcom process early enough to facilitate the nomcom to do their work at 2 face-to- face meetings, the various logistical challenges involved in the nomcom process and the differing interpretations of RFC 3777 by different people and organizations involved in the process. This document also discusses the challenges in the interaction between the nomcom and the confirmation bodies. regards, Lakshminath ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
Cullen, Thank you for your statement that you are keen to make sure your DISCUSSes are within the parameters of the discuss criteria ION. I appreciate it. Perhaps I am naive or my understanding of the English language is poor (they are both probably true), but could you explain how one of your most recent DISCUSSes: Cullen Jennings: Discuss [2008-03-05]: There has been a lot of discussion about keying modes for SRTP, so I'm glad to see a document that covers this topic for MIKEY. For that reason, I think it's really important to get this right. It looks to me like some of the issues EKR raises need to be fixed in order to achieve that. does not fit into the DISCUSS non-criteria? Unfiltered external party reviews. While an AD is welcome to consult with external parties, the AD is expected to evaluate, to understand and to concur with issues raised by external parties. Blindly cut-and-pasting an external party review into a DISCUSS is inappropriate if the AD is unable to defend or substantiate the issues raised in the review. You chose to not even cut-and-paste the comments. I also wonder which of the DISCUSS criteria fit to advance that specific document to an informational RFC. Are we to guess which of the the issues EKR raises the authors need to fix? Needless to say, we don't need to debate the specifics of that document here, but whereas your intent is honorable, the externally observable behavior is unfortunately different. Sorry for picking on you; I can probably find other similar examples on other ADs, but I was thinking that the ION is not a BCP and so I have no basis to raise the issue. Perhaps I am misunderstanding the ION or perhaps as Brian says that there should be some flexibility in the application of the rules. regards, Lakshminath On 3/6/2008 1:04 PM, Cullen Jennings wrote: Ted, Speaking for myself here but I suspect that other ADs are in the same boat ... I'm keen to make sure my Discusses are within the parameters of the discuss criteria ION regardless of the official status of this document. Agree we need to sort out what we the end result is of several experiments. I believe Russ is working to get that some IESG agenda time. Cullen On Mar 6, 2008, at 12:01 PM, Ted Hardie wrote: The call for comments on IONs seems to have ended without clarifying the effect of the end of the experiment on the standing of current IONs. For most of them, I honestly don't think the standing is much of an issue. But for the discuss criteria ION, I believe it is a serious issue. At this point, it is difficult to know whether the discuss criteria document is in force or not, and the extent to which the issuing body is bound by it. I think this is a very bad thing. I call on Russ to restore this document to its original status as an Internet Draft and to process it as a BCP. IESG DISCUSSes are a very serious part of our process at this point. Having a community agreed standard to which IESG members could be held was always a better path than than a document approved only by the IESG. Now that the ION experiment is over and the status of its document is in limbo, things are even worse. The current document is here: http://www.ietf.org/IESG/content/ions/ion-discuss-criteria.html for those readers playing the home game. Ted Hardie ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
Sam, I fail to understand why this has to be a guessing game. I also don't understand the argument about resolving DISCUSSes sequentially (in reference to your point about Cullen holding his DISCUSS beyond resolution of Russ's). I have seen better examples where for instance your DISCUSS quotes what you think needs to be resolved from the external review. Likewise, Russ states what needs to be resolved from the external review. Recently Tim put a DISCUSS on another document based on my comments stating what his specific concerns are. In all those cases, it is at least somewhat clear as to what the AD might want. In closing, perhaps some of us would like to be behind a DISCUSS that states resolve some of the issues of a 3rd party. I for one find it very hard to work in that kind of an environment. From my view point, here is how the process looks: First we have to beg to know what the issues are, then propose text, only to have it dismissed after some time, propose text again, repeat that for a non-deterministic number of times and eventually hope that the AD is satisfied; repeat that for the next AD, and so on. That is seriously broken!! All I am asking for though is to just remove the first step for starters. We shouldn't have to ask to know what the DISCUSS is about. best regards, Lakshminath On 3/6/2008 1:51 PM, Sam Hartman wrote: Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes: Lakshminath Cullen, Lakshminath Thank you for your statement that you are keen to make sure your Lakshminath DISCUSSes are within the parameters of the discuss criteria ION. I Lakshminath appreciate it. Perhaps I am naive or my understanding of the English Lakshminath language is poor (they are both probably true), but could you explain Lakshminath how one of your most recent DISCUSSes: Lakshminath Cullen Jennings: Lakshminath Discuss [2008-03-05]: Lakshminath There has been a lot of discussion about keying modes for Lakshminath SRTP, so I'm glad to see a document that covers this topic Lakshminath for MIKEY. For that reason, I think it's really important Lakshminath to get this right. It looks to me like some of the issues Lakshminath EKR raises need to be fixed in order to achieve that. Presumably Cullen is agreeing with the discuss position that I'm holding and that Russ is holding. If Cullen plans to hold his discuss position past the resolution of Russ's discuss (Russ has agreed to take on mine), then I agree his discuss is inappropriate. I'm not sure that Cullen made the best use of the tool, but I'm not sure he did anything wrong either. I believe that my discuss is consistent with the discuss criteria because while it is based on an external review, I've explained what parts of the review I consider blocking. I haven't read Russ's discuss. I believe that if he selected what parts of the review he considers are a valid discuss,or if he simply asked you to respond to Eric's comments (saying that he believes last call discussion is still ongoing), then it is a valid discuss. The second discuss (please respond to Eric and conclude the last call discussion) is a process discuss not a content discuss; he would be asking you to actually engage in a discussion. If he later believed that Tim had incorrectly evaluated the consensus of that discussion, he might change his position to another process discuss about a consensus problem. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
Thanks for the clarification Cullen. I appreciate it. Speaking from the view point of someone on the other side, more often than not, a detailed DISCUSS is much more helpful. Thank you again. best wishes, Lakshminath On 3/6/2008 2:23 PM, Cullen Jennings wrote: Part of the reason I replied so quickly on this thread is that I think I currently have two discuss that do not meet the discuss criteria (this being one of them the other being on Lost). Totally fair to pick on me here. Both were entered as, excuse the pun, fairly fluffy comments because I believe fully stating each point by point things would have actually make it significantly harder for the editor of the documents to find a good solution. In both cases I believe the editor pretty much understands the issue and if I get requests to please rewrite to be a reasonable discuss, I'm glad to do that after the meeting. On Mar 6, 2008, at 1:35 PM, Lakshminath Dondeti wrote: Cullen, Thank you for your statement that you are keen to make sure your DISCUSSes are within the parameters of the discuss criteria ION. I appreciate it. Perhaps I am naive or my understanding of the English language is poor (they are both probably true), but could you explain how one of your most recent DISCUSSes: Cullen Jennings: Discuss [2008-03-05]: There has been a lot of discussion about keying modes for SRTP, so I'm glad to see a document that covers this topic for MIKEY. For that reason, I think it's really important to get this right. It looks to me like some of the issues EKR raises need to be fixed in order to achieve that. does not fit into the DISCUSS non-criteria? Unfiltered external party reviews. While an AD is welcome to consult with external parties, the AD is expected to evaluate, to understand and to concur with issues raised by external parties. Blindly cut-and-pasting an external party review into a DISCUSS is inappropriate if the AD is unable to defend or substantiate the issues raised in the review. You chose to not even cut-and-paste the comments. I also wonder which of the DISCUSS criteria fit to advance that specific document to an informational RFC. Are we to guess which of the the issues EKR raises the authors need to fix? Needless to say, we don't need to debate the specifics of that document here, but whereas your intent is honorable, the externally observable behavior is unfortunately different. Sorry for picking on you; I can probably find other similar examples on other ADs, but I was thinking that the ION is not a BCP and so I have no basis to raise the issue. Perhaps I am misunderstanding the ION or perhaps as Brian says that there should be some flexibility in the application of the rules. regards, Lakshminath On 3/6/2008 1:04 PM, Cullen Jennings wrote: Ted, Speaking for myself here but I suspect that other ADs are in the same boat ... I'm keen to make sure my Discusses are within the parameters of the discuss criteria ION regardless of the official status of this document. Agree we need to sort out what we the end result is of several experiments. I believe Russ is working to get that some IESG agenda time. Cullen On Mar 6, 2008, at 12:01 PM, Ted Hardie wrote: The call for comments on IONs seems to have ended without clarifying the effect of the end of the experiment on the standing of current IONs. For most of them, I honestly don't think the standing is much of an issue. But for the discuss criteria ION, I believe it is a serious issue. At this point, it is difficult to know whether the discuss criteria document is in force or not, and the extent to which the issuing body is bound by it. I think this is a very bad thing. I call on Russ to restore this document to its original status as an Internet Draft and to process it as a BCP. IESG DISCUSSes are a very serious part of our process at this point. Having a community agreed standard to which IESG members could be held was always a better path than than a document approved only by the IESG. Now that the ION experiment is over and the status of its document is in limbo, things are even worse. The current document is here: http://www.ietf.org/IESG/content/ions/ion-discuss-criteria.html for those readers playing the home game. Ted Hardie ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
Sam, There is no need to prolong this particular side of the discussion now that Cullen clarified his position. But, I have to say that this thread is but one example that we often don't clearly understand each other's positions. You interpret Cullen's DISCUSS as : I think it's reasonable for Cullen to say I agree with that other discuss, and that's how I interpret his current position. Cullen clarifies it as: I believe the editor pretty much understands the issue and if I get requests to please rewrite to be a reasonable discuss, I'm glad to do that after the meeting. Most of the IESG members' names have four letters or less :). It is not very hard to type Agree with even if someone is in a hurry. Next, I can't read Steffen and Dragan's minds, and so I don't know what their understanding of the issue is and whether they understand it as Cullen agreeing with the other discuss or something else. At this point, we have that additional step of saying please rewrite your discuss to be a reasonable discuss. It looks like my interpretation was right that I have to beg for clarification to go forward here. best, Lakshminath On 3/6/2008 2:32 PM, Sam Hartman wrote: Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes: Lakshminath Sam, Lakshminath I fail to understand why this has to be a guessing game. I also don't Lakshminath understand the argument about resolving DISCUSSes sequentially (in Lakshminath reference to your point about Cullen holding his DISCUSS beyond Lakshminath resolution of Russ's). I guess I was unclear. I think it's reasonable for Cullen to say I agree with that other discuss, and that's how I interpret his current position. I think it's kind of odd for him to stick that in the discuss box rather than the comment box, but I don't think it is particularly harmful provided that his discuss never blocks the document. I.E. he needs to make sure his discuss is removed before Russ clears. Put another way, it's fine for Cullen to tell other IESG members that he agrees with a discuss. It's fine for him to agree so strongly that he'd like to be given an opportunity to take on the discuss if for example the person holding the discuss gives up and wants to drop the issue. It's not fine for him to expect you to do anything based on a discuss that vague. It's not fine for his inaction to cause your document to get stuck based on a discuss that vague. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
Hi Russ, Thanks for your response. Some notes inline: On 3/6/2008 4:09 PM, Russ Housley wrote: Ted, Lakshminath, and the Rest of the IETF Community: I fail to understand why this has to be a guessing game. The handling of reviews by non-IESG members seems to be an important part of this discussion. I agree and have contributed to that part of the solution, only now I am realizing that it may be becoming part of the problem, so to speak. The concern is that over time it seems to be degenerating into, I will use Ted's phrase here because that is what it feels like, go satisfy that guy. Consider how it sounds when trying to explain to an outsider: the document is held up in IESG processing because X, who is not an IESG or IAB member, does not like it. I think your own word is answer (I have heard respond) in lieu of satisfy. Some notes on that below: So, I'll tell everyone how I deal with Gen-ART Reviews. Other General ADs may have done things slightly different. When I use a Gen-ART Review as the basis of a DISCUSS, I put it in one of two categories. (1) The Gen-ART Review was ignored. Like any other Last Call comment, it deserves an answer. So, this is a procedural objection. In this situation, I've been careful to say that the authors do not need to accept all of the comments, but then need to answer them. I have reviewed documents as a Gen-ART reviewer (during Brian's tenure I think), sec-dir reviewer and also provided IETF LC comments on some documents. As a reviewer, I am not sure whether I was expecting answers all those times. I am pretty sure I have not always stated whether or not the answers are satisfactory. Next, I can imagine an author not wanting to respond to something I may have said because it was totally bogus or inappropriate and does not deserve a response. That might very well happen when I review documents on a topic that I am not familiar with and haven't had the time to read related references (that varies depending on the time available, etc.). Perhaps that is not such a bad thing; being blissfully ignorant on some topics keeps me, well, blissful. I use somewhat of a hyperbole for obvious reasons. I am sure many other situations are much more nuanced. I hope ADs don't continue to hold a DISCUSS in those situations waiting for a dialog to take place or waiting for a consensus to emerge. I sometimes hint in my reviews that the topic may be at the border of my knowledge and if I have a bias. Perhaps that is helpful. regards, Lakshminath (2) I agree with one or more concerns raised in the Gen-ART Review that has not been resolved. I often break the unresolved review comments into DISCUSS and COMMENT. AD judgement is needed, and I consider the DISCUSS Criteria in making that judgement. Russ ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
Brian, A small clarification below on the reference to the interpretation problems related to 3777: On 3/6/2008 4:10 PM, Brian E Carpenter wrote: Dave, On 2008-03-07 12:34, Dave Crocker wrote: Sam Hartman wrote: Making it a BCP will make the interpretation problem worse not better. How? To some extent that depends on how carefully the putative BCP is crafted, with should and when to disregard should being very precise. What I think we've seen, with 2026 over the years, and apparently this year with 3777, is that it's virtually I am not sure whether you have made it to the appendix in my report, but the disagreements in interpretation of 3777 have a history (see Page 37). The only thing special about the current nomcom is that we chose to bring it to the community's attention. In Ralph's case, he brought it to the IESG and IAB's attention in March 2006. thanks, Lakshminath Nomcom 2007-8 Chair impossible to write precise procedural text that deals with completely unexpected circumstances. Yet if the text has the force of a BCP, it becomes very hard to interpret it flexibly when flexibility is clearly needed. I don't know if that is Sam's point, of course. Brian ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs discuss criteria
Thanks Cullen. regards, Lakshminath On 3/6/2008 5:05 PM, Cullen Jennings wrote: I believe Sam's discuss cover the issues I was concerned about and I have removed my discuss. On Mar 6, 2008, at 2:57 PM, Lakshminath Dondeti wrote: Sam, There is no need to prolong this particular side of the discussion now that Cullen clarified his position. But, I have to say that this thread is but one example that we often don't clearly understand each other's positions. You interpret Cullen's DISCUSS as : I think it's reasonable for Cullen to say I agree with that other discuss, and that's how I interpret his current position. Cullen clarifies it as: I believe the editor pretty much understands the issue and if I get requests to please rewrite to be a reasonable discuss, I'm glad to do that after the meeting. Most of the IESG members' names have four letters or less :). It is not very hard to type Agree with even if someone is in a hurry. Next, I can't read Steffen and Dragan's minds, and so I don't know what their understanding of the issue is and whether they understand it as Cullen agreeing with the other discuss or something else. At this point, we have that additional step of saying please rewrite your discuss to be a reasonable discuss. It looks like my interpretation was right that I have to beg for clarification to go forward here. best, Lakshminath On 3/6/2008 2:32 PM, Sam Hartman wrote: Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes: Lakshminath Sam, Lakshminath I fail to understand why this has to be a guessing game. I also don't Lakshminath understand the argument about resolving DISCUSSes sequentially (in Lakshminath reference to your point about Cullen holding his DISCUSS beyond Lakshminath resolution of Russ's). I guess I was unclear. I think it's reasonable for Cullen to say I agree with that other discuss, and that's how I interpret his current position. I think it's kind of odd for him to stick that in the discuss box rather than the comment box, but I don't think it is particularly harmful provided that his discuss never blocks the document. I.E. he needs to make sure his discuss is removed before Russ clears. Put another way, it's fine for Cullen to tell other IESG members that he agrees with a discuss. It's fine for him to agree so strongly that he'd like to be given an opportunity to take on the discuss if for example the person holding the discuss gives up and wants to drop the issue. It's not fine for him to expect you to do anything based on a discuss that vague. It's not fine for his inaction to cause your document to get stuck based on a discuss that vague. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom 2007-8 Chair's Report
On 3/6/2008 10:44 PM, Harald Tveit Alvestrand wrote: Lakshminath Dondeti skrev: Folks, A report on the nomcom's activities is available at https://www.tools.ietf.org/group/nomcom/07/nomcom-report. Please direct any comments to [EMAIL PROTECTED] I will make a brief presentation at the IESG plenary. Abstract This document reports on the work of Nomcom 2007-8. The topics of discussion include the experiences in starting the nomcom process early enough to facilitate the nomcom to do their work at 2 face-to- face meetings, the various logistical challenges involved in the nomcom process and the differing interpretations of RFC 3777 by different people and organizations involved in the process. This document also discusses the challenges in the interaction between the nomcom and the confirmation bodies. regards, Lakshminath ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf Laksminath, thank you very much for providing the report - and thank you for trying to defend people's expectations of confidentiality! Hi Harald, as nomcom chair You are welcome. I do agree with Scott that the process needs clarification - unlike him, I think it can be done without reopening 3777 on this point. speaking as an individual Sure, there are ways. A solution without changing 3777 is for future chairs to be made aware that this is coming and advise them that they need to prepare accordingly. First, it will be great if the IAB could clarify their requirements. It is simply not acceptable to say candidate statement == questionnaire response. Nomcoms may collect all kinds of information from nominees through a questionnaire or for that matter, other means. The questionnaire itself is prepared by a nomcom process. They cannot share that information just because a confirmation body asks for it pointing to their own internal documents. Future nomcoms could, in the absence of any response from the current IAB or the one a week from today, include an item in the questionnaire that asks for information for IAB's consumption: specifically, CV and candidate's statement (nominee's statement, when the nomcom asks for it) pointing to http://www.iab.org/documents/docs/2003-07-23-nomcom.html. Note: A variation of the above idea has been suggested by others. I am not coming up with anything original there. Of course the question then is, what purpose does 3777 serve when a confirming body chooses to prepare their own list of what needs to be provided as supporting material? To repeat my own take on this, of all things, 3777 is quite clear on what needs to be provided. There is no ambiguity whatsoever. The text that the IAB point to -- all information and any means acceptable to them does not say anything about the nomcom facilitating it. Now one could say, any means acceptable includes not confirming until the information they ask for is provided. If we go down that road however, the same text reference could be used (note: hypothetical case) to ask for community feedback. The other question is why should the IAB get any special consideration here? Surely, the IESG and the ISOC BoT could ask for more information too and should be privy to the same level of information that IAB is privy to. So, we also need to be consistent, however we choose to do this going forward. What is not good is to leave it be and let each nomcom fight it out with the IAB. I'll have more to say when that discussion opens up. The time is now, assuming that the next nomcom starts 2-3 months from now. The timing is especially crucial if the consensus points to an update to 3777 to resolve this as Scott has concluded. regards, Lakshminath Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Nomcom 2007-8 Chair's Report
Folks, A report on the nomcom's activities is available at https://www.tools.ietf.org/group/nomcom/07/nomcom-report. Please direct any comments to [EMAIL PROTECTED] I will make a brief presentation at the IESG plenary. Abstract This document reports on the work of Nomcom 2007-8. The topics of discussion include the experiences in starting the nomcom process early enough to facilitate the nomcom to do their work at 2 face-to- face meetings, the various logistical challenges involved in the nomcom process and the differing interpretations of RFC 3777 by different people and organizations involved in the process. This document also discusses the challenges in the interaction between the nomcom and the confirmation bodies. regards, Lakshminath ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2007-8 Chair's Report
Folks, A report on the nomcom's activities is available at https://www.tools.ietf.org/group/nomcom/07/nomcom-report. Please direct any comments to [EMAIL PROTECTED] I will make a brief presentation at the IESG plenary. Abstract This document reports on the work of Nomcom 2007-8. The topics of discussion include the experiences in starting the nomcom process early enough to facilitate the nomcom to do their work at 2 face-to- face meetings, the various logistical challenges involved in the nomcom process and the differing interpretations of RFC 3777 by different people and organizations involved in the process. This document also discusses the challenges in the interaction between the nomcom and the confirmation bodies. regards, Lakshminath ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Nomcom 2007-8: IAB Selection Announcement
Folks, The nomcom has finished the IAB member selection process. The ISOC Board of Trustees has confirmed the nomcom's selection of the following individuals for a two-year term as IAB members. Gonzalo Camarillo Stuart Cheshire Olaf Kolkman Gregory Lebovitz Andy Malis David Oran The nomcom reviewed the IAB's requirements, nominees' questionnaire responses and community feedback on the nominees, and after careful deliberations, and some interviews, selected the candidates. We thank all the nominees who agreed to be considered for the position. We understand that the nomcom process takes a long time and we appreciate everyone's patience from the nominations to selections phase. About Gonzalo: Gonzalo Camarillo is the head of the Multimedia Research Laboratory in Ericsson Finland. He is the IETF liaison manager to 3GPP and currently cochairs the SIPPING and HIP working groups. His research interests include signaling, multimedia applications, transport protocols, and networking architectures. He has authored a number of RFCs, books, and papers on these areas. Gonzalo received M.Sc. degrees in electrical engineering from the Stockholm (Sweden) Royal Institute of Technology and from Universidad Politecnica de Madrid (Spain). He is originally from Spain. About Stuart: Stuart Cheshire is currently a Senior Scientist with Apple Computer, Cupertino, CA, specializing in Internet Protocols. He previously worked on IBM Token Ring with Madge Networks, Little Chalfont, U.K. He has previously published papers in the areas of wireless and networking, and Mobile IP. Stuart is the architect of Apple's Bonjour family of technologies, including Multicast DNS, DNS-based Service Discovery, etc., co-chair of the ZEROCONF working group and author of several RFCs. Stuart received the B.A. and M.A. degrees from Sidney Sussex College, Cambridge, U.K., in June 1989 and June 1992, and the M.Sc. and Ph.D. degrees from Stanford University, Stanford, CA, in June 1996 and April 1998. About Olaf: Olaf Kolkman was born and raised in the Netherlands. He was trained as an astronomer but his interest in Internet technology took hold of his career path around 1996. He joined the RIPE NCC around 1997 where he got involved in the test-traffic project. That project brought him in contact with the IETF and he attended his first meeting in Munich. After acting as operations manager for a while he became systems architect, responsible for DNSSEC deployment at the NCC, in 2000. From that time on he has been active in the DNS community for instance as co-chair of the DNSEXT working group. In 2005 he joined NLnet Labs, a RD foundation, as chief executive. He is an IAB member since March 2006. About Gregory: Gregory Lebovitz is Sr. Technical Director and Solutions Architect for the Security Products Group of Juniper Networks. He leads both advanced technology development initiatives as well as Enterprise Solutions Engineering. Prior to it's acquisition by Juniper, Gregory worked in the office of the CTO at NetScreen Technologies. He has been with Juniper/NetScreen for over nine years, almost since NetScreen's inception. He has been an active contributor to the IETF for several years, having been an RFC author, working group chair (PKI4IPSEC), and Security Area Directorate member; contributed to IAB's Unwanted Traffic Workshop in 2006. Gregory graduated from UC Santa Cruz, with a double major in Economics (w/ Honors) and Psychology; he received the Dean's Award for Outstanding Research in Economics. About Andy: Andy is currently Principal Member of the Technical Staff, Packet Network Architecture at Verizon Communications. He has been active in wide-area data networking and telecommunications for over 30 years, beginning with the ARPANET (he wrote IMP code and supported network operations; of special mention is his work in managing the cutover from NCP to TCP in the network). He has held senior engineering positions at Bolt, Beranek, and Newman; Ascom Nexion; Cascade Communications; Ascend Communications; Lucent Technologies; Vivace Networks; and Tellabs. Andy has been to just about every IETF meeting since IETF 19 in Boulder, CO, chaired several working groups including iplpdn, ipatm, and frnetmib, and authored numerous RFCs starting from RFC 802 to RFC 4901. In addition he holds senior leadership positions in various other standards organizations. Andy received a Bachelor of Science degree in Computer Science and Applied Mathematics from Brown University, and a Master of Science degree, also in Computer Science and Applied Mathematics, from Harvard University. About David: David Oran is a Fellow at Cisco Systems. His technical interests lie in the areas of Quality of Service, Internet multimedia, routing, and security. He was part of the original team that started Cisco's Voice- over-IP business in 1996 and worked on a number of aspects, including the development SIP,
Re: Gen-ART review of draft-ietf-hokey-erx-09 (-10)
Hi Pasi, all Following up on this, I think ERX-11 addresses all of Pasi's comments. I have previously added (in v10) clarifying text to address the lock-step issue based on Bernard's suggestion in his detailed review. I have now added a section on lower layer considerations. The channel binding parameter processing is clarified in v11, primarily in its own section and also elsewhere. I have incorporated Pasi's suggestions on IANA considerations. Pasi's comment 3 is addressed by the EMSK-hierarchy document. Anyway, I went over Pasi's list a few times, and think that all of them are now addressed :). Based on Dan's comments, I have added some more text to the security considerations section (talked about implications of key compromise, implications of hop-by-hop security and compromise of proxies, etc.). I have made the key naming changes in v10 already. I worked with Bernard's detailed comments in preparing v10; additional clarifications were added in v11 as well. I have also incorporated Joe's suggestions in v10 and v11. (Which implies one of Alan's comments is not addressed. Joe wants less repetition between the EMSK and the ERX specs and Alan wants some duplication so the ERX document is more independent.) Joe's suggestions helped clean up the AAA related stuff and also the multitude of options in identifying the rIK used. The text is much more clear now and there is only one way to identify the key. Earlier options existed for identity privacy reasons, but the working group consensus was that we don't care about that requirement at the moment. It is simpler to delete those now and add them in a future revision if identify privacy is deemed necessary then. Thanks again to all the reviewers. Thank you for your patience while I worked through all the comments and prepared the revised version(s). best regards, Lakshminath On 2/19/2008 4:15 AM, [EMAIL PROTECTED] wrote: I have just scanned through version -10 of this draft, posted couple of hours ago. This version addresses my comments 5 and 6; and comments 4 and 10 are obsolete since the text I commented has been removed. The remaining comments are still valid. One additional comment for version -10: 16) Section 5.3.2, EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64-bits in length and so the username portion takes up 128 octets. EMSKname is not defined in this document (or any of its references, as far as I can tell); and encoding 64 bits as hexadecimal doesn't take 128 octets anyway. Best regards, Pasi -Original Message- From: Eronen Pasi (Nokia-NRC/Helsinki) Sent: 05 February, 2008 14:30 To: '[EMAIL PROTECTED]'; 'ext Tim Polk'; '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]'; 'ietf@ietf.org'; 'ext Lakshminath Dondeti'; [EMAIL PROTECTED] Subject: Gen-ART review of draft-ietf-hokey-erx-09 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-hokey-erx-09 Reviewer: Pasi Eronen Review Date: 2008-02-05 IETF LC End Date: 2008-02-07 IESG Telechat date: 2008-02-07 Summary: This draft is on the right track but has open issues, described in the review. Comments: Most serious comments first: 1) The document should contain explicit text about the relationship between ERP and the lower layers; for example, what would need to be changed in lower layers that use EAP to add support for ERP. (E.g. with parallel EAP-Request/Identity+EAP-Initiate/Reauth-Start the protocol is no longer lock-step; the authenticator is no longer responsible for all the retransmissions, etc.) 2) The document specifies message fields for so-called channel binding information, but contains basically no text about what to put in the field, or how to process them. Note that just saying RADIUS Calling-Station-Id is not very helpful, since peers don't usually implement RADIUS. The spec either needs to describe what the field should contain, or should tell where that is described. Also, the semantics are highly unclear: the spec says these attributes can be included in EAP-Initiate/Re-Auth and EAP-Finish/Re-Auth messages -- but how do the peers know when to include them? Or what to do with them when received? E.g. if the EAP-Initiate/Re-Auth contains some of these attributes, should the EAP-Finish/Re-Auth also contain them? With same values? (Answers to some of these questions may be obvious to people who participated in the channel binding discussions 3..5 years ago; but they're not in the current specification. And if there's any difficulty in writing text about them, it IMHO suggests they are not that obvious.) 3) The document uses terms EAP Peer-ID and EAP Session-ID
Nomcom 2007-8: IESG Selection Announcement
Folks, The nomcom has finished the IESG member selection process and the IAB has confirmed the following individuals for a two-year term as IESG members. Lisa Dusseault, Applications Area Jari Arkko, Internet Area Dan Romascanu, Operations and Management Area Cullen Jennings, Real-time Applications and Infrastructure Area Ross Callon, Routing Area Pasi Eronen, Security Area Magnus Westerlund, Transport Area The nomcom thanks them for agreeing to serve as area directors until the first IETF meeting in 2010. The nomcom reviewed the IESG's requirements, nominees' questionnaire responses and community feedback on the nominees, and after careful deliberations, and some interviews, selected the candidates. In the security area, the IESG's posted requirements and the nomcom's understanding of the community's consensus requirements were different and our selections were according to the community's consensus requirements for the position. The nomcom also thanks all the nominees who agreed to be considered for the different positions. We understand that the nomcom process takes a long time and we appreciate everyone's patience from the nominations to selections phase. Short biographies of the selected IESG members are as follows: Lisa Dusseault has been involved in Internet protocol design since 1994 and in standardization since 1997. Her primary interests are in collaborative software, including Calendaring, Instant Messaging, and shared authoring. She has served as co-chair of the IMAP Extensions, Calendar Simplifications, WebDAV and XMPP Working Groups. Lisa is the author of the standard book on WebDAV, WebDAV: Next-Generation Collaborative Web Authoring (Prentice Hall, 2003). She has been serving as IETF Applications Area Director since March 2006. Lisa holds a BASc in Systems Design Engineering from the University of Waterloo, Ontario, Canada. Jari Arkko is an Expert at Ericsson Research NomadicLab in Jorvas, Finland. He has been an active participant at the IETF since 1996, working in the areas of mobility protocols, security mechanisms, and various IP layer issues. He has co-chaired the EAP, MOBIKE, and EMU working groups, and has been serving as an Area Director for the Internet Area since March 2006. His research interests include Internet architecture, deployable security mechanisms and efficient mobility. In his day job, Jari has worked in the implementation of various software and communication systems, including network access servers, VPN devices, testing tools, databases, and compilers. He received his Licentiate's degree from Helsinki University of Technology in 1996. Dan Romascanu is Director for External Standards in the CTO organization at Avaya. Dan holds a BA and M.Sc. degrees from the Polytechnic Institute of Bucharest, Faculty of Automation and Computer Engineering. Don has been serving as an Area Director for the Operations and Management Area since March 2006. He has been an active contributor to IEEE and IETF standards for more than a decade. Cullen Jennings is a Distinguished Engineer in the Voice Technology Group at Cisco where he focuses on voice and video communication systems, security, and NAT traversal. He is an active contributor to several open source projects including resiprocate.org. He is an author of Practical VoIP, published by O'Reilly and is a frequent speaker at major Voice and Security Conferences. Cullen has been serving as the Real-time Applications and Infrastructure Area Director since 2006. Ross Callon is a Distinguished Engineer at Juniper Networks. He has been serving as the Routing Area Director since 2006. He was previously on the IESG between 1989 and 1991. In between, he has been co-chair of several IETF working groups and has authored and co-authored several RFCs. Ross has a B.Sc. in Mathematics from MIT (1973), and an M.Sc. in Operations Research from Stanford (1977). Pasi is currently a Member of Research Staff at the Internet Laboratory in Nokia Research Center. He has been an active contributor to the IETF for several years, having been a co-author in ten RFCs, working group co-chair (TLS), working group secretary (MOBIKE), tools developer (Daily Dose of IETF), and member of General Area Review Team (Gen-ART) and Security Directorate. Pasi has a Master's degree in Computer Science from Helsinki University of Technology, and has published a number of papers in the area of network security. Magnus Westerlund is a researcher at Ericsson Research in Stockholm, Sweden. Magnus has worked on a number of projects related to real-time media transport and application signaling. He has been active in IETF since 2000 and served as Audio/Video Transport (AVT) working group chair for 3 years before becoming Transport Area Director and chair of the transport working group (TSVWG). Magnus has a Master of Science in Computer Science from Luleå University of Technology. best regards,
Re: Gen-ART review of draft-ietf-hokey-erx-09 (-10)
On 2/19/2008 4:15 AM, [EMAIL PROTECTED] wrote: I have just scanned through version -10 of this draft, posted couple of hours ago. This version addresses my comments 5 and 6; and comments 4 and 10 are obsolete since the text I commented has been removed. The remaining comments are still valid. One additional comment for version -10: 16) Section 5.3.2, EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64-bits in length and so the username portion takes up 128 octets. EMSKname is not defined in this document (or any of its references, as far as I can tell); and encoding 64 bits as hexadecimal doesn't take 128 octets anyway. Oops, I meant 128 bits. Is my math still wrong? I thought I added a reference. I will make sure. thanks, Lakshminath Best regards, Pasi -Original Message- From: Eronen Pasi (Nokia-NRC/Helsinki) Sent: 05 February, 2008 14:30 To: '[EMAIL PROTECTED]'; 'ext Tim Polk'; '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]'; 'ietf@ietf.org'; 'ext Lakshminath Dondeti'; [EMAIL PROTECTED] Subject: Gen-ART review of draft-ietf-hokey-erx-09 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-hokey-erx-09 Reviewer: Pasi Eronen Review Date: 2008-02-05 IETF LC End Date: 2008-02-07 IESG Telechat date: 2008-02-07 Summary: This draft is on the right track but has open issues, described in the review. Comments: Most serious comments first: 1) The document should contain explicit text about the relationship between ERP and the lower layers; for example, what would need to be changed in lower layers that use EAP to add support for ERP. (E.g. with parallel EAP-Request/Identity+EAP-Initiate/Reauth-Start the protocol is no longer lock-step; the authenticator is no longer responsible for all the retransmissions, etc.) 2) The document specifies message fields for so-called channel binding information, but contains basically no text about what to put in the field, or how to process them. Note that just saying RADIUS Calling-Station-Id is not very helpful, since peers don't usually implement RADIUS. The spec either needs to describe what the field should contain, or should tell where that is described. Also, the semantics are highly unclear: the spec says these attributes can be included in EAP-Initiate/Re-Auth and EAP-Finish/Re-Auth messages -- but how do the peers know when to include them? Or what to do with them when received? E.g. if the EAP-Initiate/Re-Auth contains some of these attributes, should the EAP-Finish/Re-Auth also contain them? With same values? (Answers to some of these questions may be obvious to people who participated in the channel binding discussions 3..5 years ago; but they're not in the current specification. And if there's any difficulty in writing text about them, it IMHO suggests they are not that obvious.) 3) The document uses terms EAP Peer-ID and EAP Session-ID which are not part of RFC 3748; they are defined in draft-ietf-eap-keying, which needs to be (normatively) referenced. 4) Section 4.1.1 defines NameDerivationKey = EAP Session-ID, when K used in rRK derivation is the EMSK; however, existing EAP methods are not required to export a Session-Id. This document needs to specify what is done when no Session-ID is exported, or explicitly say that it works only with EAP methods that export a session id. 5) Section 5.1, In this case, the lower layer may already have derived the TSKs based on the MSK received earlier. The lower layer may then choose to ignore the rMSK that was received with the ER bootstrapping exchange. Alternatively, the lower layer may choose to generate a TSK from the rMSK. Who/what coordinates this; that is, ensures that both peer and authenticator use the same key (MSK or rMSK)? The following comments are basically nits that should be easy to fix: 6) Section 4.1.1 specifies rRK derivation seed as S = rRK Label + \0 + NULL + length. It's not clear what NULL means here; IMHO one obvious interpretation would be a single zero octet (same as \0), but then again, perhaps an empty (zero-length) string is intended, since a different notation was used? 7) Section 4.1.1 specifies the rRK label as EAP Re-(newline)(white space)authentication Root [EMAIL PROTECTED]; this is a rather unfortunate place to break a line, as the hyphen could be interpreted in two different ways. 8) Inconsistent IANA considerations: slightly different USRK label string is used in Sections 4.1.1 and 8. 9) Section 4.1.5 says the most significant k octets of the output are used; the term most significant makes sense when talking about integers. When talking about octet
Nomcom 2007-8: Status Update
Folks, As of now, the nomcom has completed the selection and confirmation of candidates for IAOC and IAB open positions. We have also been working with the IAB on the IESG candidate selection and confirmation as diligently as possible. Despite our best efforts, at the moment, we are effectively delayed (again) in spite of starting early. I am hoping that we can finish the process before the end of this week and announce the candidates for the open IESG positions. I apologize for the delay, as I should have planned better for potential delays, given that we have indeed started early. The nomcom members for their part have worked diligently to meet the schedule we set for ourselves. We thank all the nominees for their continued patience and I hope to get in touch with them in the next few days with the results. best regards, Lakshminath ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Nomcom 2007-8: IAB Selection Announcement
Folks, The nomcom has finished the IAB member selection process. The ISOC Board of Trustees has confirmed the nomcom's selection of the following individuals for a two-year term as IAB members. Gonzalo Camarillo Stuart Cheshire Olaf Kolkman Gregory Lebovitz Andy Malis David Oran The nomcom reviewed the IAB's requirements, nominees' questionnaire responses and community feedback on the nominees, and after careful deliberations, and some interviews, selected the candidates. We thank all the nominees who agreed to be considered for the position. We understand that the nomcom process takes a long time and we appreciate everyone's patience from the nominations to selections phase. About Gonzalo: Gonzalo Camarillo is the head of the Multimedia Research Laboratory in Ericsson Finland. He is the IETF liaison manager to 3GPP and currently cochairs the SIPPING and HIP working groups. His research interests include signaling, multimedia applications, transport protocols, and networking architectures. He has authored a number of RFCs, books, and papers on these areas. Gonzalo received M.Sc. degrees in electrical engineering from the Stockholm (Sweden) Royal Institute of Technology and from Universidad Politecnica de Madrid (Spain). He is originally from Spain. About Stuart: Stuart Cheshire is currently a Senior Scientist with Apple Computer, Cupertino, CA, specializing in Internet Protocols. He previously worked on IBM Token Ring with Madge Networks, Little Chalfont, U.K. He has previously published papers in the areas of wireless and networking, and Mobile IP. Stuart is the architect of Apple's Bonjour family of technologies, including Multicast DNS, DNS-based Service Discovery, etc., co-chair of the ZEROCONF working group and author of several RFCs. Stuart received the B.A. and M.A. degrees from Sidney Sussex College, Cambridge, U.K., in June 1989 and June 1992, and the M.Sc. and Ph.D. degrees from Stanford University, Stanford, CA, in June 1996 and April 1998. About Olaf: Olaf Kolkman was born and raised in the Netherlands. He was trained as an astronomer but his interest in Internet technology took hold of his career path around 1996. He joined the RIPE NCC around 1997 where he got involved in the test-traffic project. That project brought him in contact with the IETF and he attended his first meeting in Munich. After acting as operations manager for a while he became systems architect, responsible for DNSSEC deployment at the NCC, in 2000. From that time on he has been active in the DNS community for instance as co-chair of the DNSEXT working group. In 2005 he joined NLnet Labs, a RD foundation, as chief executive. He is an IAB member since March 2006. About Gregory: Gregory Lebovitz is Sr. Technical Director and Solutions Architect for the Security Products Group of Juniper Networks. He leads both advanced technology development initiatives as well as Enterprise Solutions Engineering. Prior to it's acquisition by Juniper, Gregory worked in the office of the CTO at NetScreen Technologies. He has been with Juniper/NetScreen for over nine years, almost since NetScreen's inception. He has been an active contributor to the IETF for several years, having been an RFC author, working group chair (PKI4IPSEC), and Security Area Directorate member; contributed to IAB's Unwanted Traffic Workshop in 2006. Gregory graduated from UC Santa Cruz, with a double major in Economics (w/ Honors) and Psychology; he received the Dean's Award for Outstanding Research in Economics. About Andy: Andy is currently Principal Member of the Technical Staff, Packet Network Architecture at Verizon Communications. He has been active in wide-area data networking and telecommunications for over 30 years, beginning with the ARPANET (he wrote IMP code and supported network operations; of special mention is his work in managing the cutover from NCP to TCP in the network). He has held senior engineering positions at Bolt, Beranek, and Newman; Ascom Nexion; Cascade Communications; Ascend Communications; Lucent Technologies; Vivace Networks; and Tellabs. Andy has been to just about every IETF meeting since IETF 19 in Boulder, CO, chaired several working groups including iplpdn, ipatm, and frnetmib, and authored numerous RFCs starting from RFC 802 to RFC 4901. In addition he holds senior leadership positions in various other standards organizations. Andy received a Bachelor of Science degree in Computer Science and Applied Mathematics from Brown University, and a Master of Science degree, also in Computer Science and Applied Mathematics, from Harvard University. About David: David Oran is a Fellow at Cisco Systems. His technical interests lie in the areas of Quality of Service, Internet multimedia, routing, and security. He was part of the original team that started Cisco's Voice- over-IP business in 1996 and worked on a number of aspects, including the
Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Hi Joe, Sorry for the delayed response. I was without a functional laptop for the better part of the last 30 or so hours and so I am behind on a few things here. Please see inline: On 2/6/2008 10:00 PM, Joseph Salowey (jsalowey) wrote: Thanks for your quick response, comments inline: -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 1:03 AM To: Joseph Salowey (jsalowey) Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard Thanks for the review Joe. On 2/5/2008 11:26 PM, Joseph Salowey (jsalowey) wrote: In reading this draft (-09 version) I came up with a few questions and comments: Section 3 - Section 3 is a bit confusing it seems that much of the text is section 3.1 (detailed description of exchanges) should go into section 3.0 because it seems that much of the process should be the same for local or remote cases. Currently it is difficult to really tell what pertains to local, remote and both. It does not appear to be clear how the peer knows if it is in the home case or the local case, whether the network is capable of ERX (and vice versa) or how the peer knows what key to use. Perhaps I missed this elsewhere in the document. We worked to clarify this in the last revision. I will make another pass at it while preparing v10 and run it by you (probably sometime tomorrow). Section 4 - Section 4.1.1 duplicates text in internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt. It really should not. It should reference KDF functions instead of PRFs. I believe if you replace prf+ with KDF it would be fine. Do you want to use the naming defined in internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt or are you specifying your own? Are these key names really necessary? They do no appear to be used anywhere? This is true. I think we were trying overly hard to name everything (one of 4962 things?) and I realized earlier that we have a procedure to even name the rMSKs. But, it is not clear whether the rMSK names will be used anywhere. I just sent that email about naming and so we should be able to clean this stuff up now if that is acceptable to everyone. [Joe] If this is what we discussed I believe it will help, I will take a look at that. Yes, and I am going to poll some folks to make sure that is ok with them too. Please review; if you want I can provide details (might ask Dan for some help) for your review. On duplication, it seems we have two strong opinions here. You are suggesting less duplication and Alan is suggesting more :). I guess we may have actually achieved the (un)happy medium! My opinion is that we should have less duplication, perhaps to the extent you are suggesting, so the idea is to not have to update (when we need) text in two different drafts. That said, there are some usage specific properties to consider, specifically we are trying to specify crypto-agility in case of ERP and for those reasons, the derivations may need to be spelled out again. [Joe] I think if we need to spell out the derivations in this document there is a problem. This would indicate there is something wrong with the EMSK document that needs to be fixed. Yeah, I tend to agree. I am talking to Alan soon and after that propose a direction here. In the next revision, I'll see what I can do to reduce the duplication (but before that I will talk to Alan to see what he wants). Why such a long key label? Which one? EAP Re-authentication Root [EMAIL PROTECTED]? I guess we could call it EAP rRK but that might be an abbreviation for something else in the future. Please suggest another name :), but hopefully one that does not involve changing the entire document (I don't want to introduce errors with too many global changes). [Joe] I suppose it doesn't matter much, it just seems that name is unnecessarily long. The point of registering the labels with IANA is to avoid conflicts. Section 5 - Section 5.1 What state are you referencing here? I don't think the CalledStation-ID is what you want to reference, I believe RADIUS routing is typically done with the username when EAP is used. Why is it only RECOMMENDED to maintain this state? It seems either it is a MUST or it doesn't matter. In general authenticators do not do routing, AAA does routing. Authenticators copy the correct attributes from EAP into the correct attributes in the AAA message. This seems much more complicated (routing, multiple attributes TLVs etc). Its not clear if the 3 sub-bullets of the first bullet refer to what the authenticator needs to do or the peer needs to do. It seems that the authenticator should be able to extract a single field from the peer message to determine
Re: OM Directorate Review of draft-ietf-hokey-erx-09
Hi Bernard, Many thanks for your review. Please see inline for some thoughts and proposals for improvement of erx-09: On 2/6/2008 4:07 PM, Bernard Aboba wrote: Review of draft-ietf-hokey-erx-09 I have reviewed this document as part of the Operations and Management directorate effort. These comments were primarily written for the benefit of the OM area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Detailed review comments are available here: http://www.drizzle.com/~aboba/EAP/erx-review.txt An answer to typical OM issues is included below: 1. Is the specification complete? Can multiple interoperable implementations be built based on the specification? There are a few areas of the document which are unclear to me, such as how AAA routing is accomplished, and how/when peers require the local realm, and if so, how it is to be obtained. Also, clarity with respect to algorithm agility could be improved. There are also some issues with respect to the required behavior of ERX peers and severs (use of normative language). There are also situations in which multiple approaches can be chosen (such as the various bootstrap options), without one being chosen as mandatory or default. Choosing one approach would seem to be better. In my judgement, addressing these issues would improve the likelihood of being able to build multiple interoperable implementations. I agree. This has been brought up by Joe and we'll clarify the text. Some of the confusion has to do with the evolution of the draft; Vidya and I spent a good amount of time cleaning up around the WGLC time, but it appears that we can do better. Pasi suggested adding a section on lower layer considerations. That should help as well. 2. Is the proposed specification deployable? If not, how could it be improved? Based on my reading of the document, it would appear that the ERX proposal requires changes to EAP peers, authenticators and servers, as well as RADIUS clients, proxies and servers. It also appears possible that changes to the lower layer protocols will be required in at least some cases, such as to make the local domain available to the peer. Given my experience in designing and operating wireless networks, deployments requiring changes only to peers and authenticators (but not servers or RADIUS infrastructure) can take as long as 3-5 years to complete. For example, WPA2 is still not universally deployed, even though the specification was finished in 2004. WPA2 compliance requires hardware upgrade in many cases and that may have been the reason for the delay. In addition, some enterprises found an alternative solution, i.e., IPsec VPNs, and so were not as motivated to move to WPA2. In case of ERX, a firmware upgrade should be sufficient, which is much more easier. By also requiring changes to AAA infrastructure, it seems to me that ERP deployment will be made more difficult than upgrades to the lower layer (such as IEEE 802.11r), which appear to achieve a similar objective. This puts the ERX proposal at a competitive disadvantage, and makes it unlikely that it will be widely deployed in its current form. In the context of WLANs, I can understand your argument, but in the context of foo wireless network, much of the work of 11r security, needs to be repeated. 11r also requires firmware upgrades to APs and STAs; furthermore, when physical threats to edge devices are considered, the R0-KH needs to be in a safer location and that may mean more L2 architectural considerations. The problems don't go away; they go to a different standards organization :). When considering new wireless network standards, I think ERP along with the EMSK key hierarchy is better. Keys for other usages can also be derived (the current alternative is static key provisioning). 3. Does the proposed approach have any scaling issues that could affect usability for large scale operation? The proposed approach introduces state into NASes, as well as RADIUS proxies and servers. This state is typically of two types: routing state and key state. In terms of key state storage, it would appear that the RADIUS server needs to store key state for each authenticated user within the Session-Id lifetime, regardless of where they are located. Local ERX servers store state for all local users, regardless of their home realms. In order to scale to handle a large user population, additional RADIUS servers are typically deployed, going against a replicated backend store (such as an LDAP directory). Similarly, additional RADIUS proxies are deployed to handle the forwarding load. To support the concept of local ER servers, I agree that additional servers need to be deployed. However, in case of ERP with home, no additional devices/hardware resources are necessary. Consider the alternative: in the
Re: OM Directorate Review of draft-ietf-hokey-erx-09
Hi Bernard, Thanks for the followup. Some notes inline: On 2/8/2008 8:47 AM, Bernard Aboba wrote: Comments below. Date: Fri, 8 Feb 2008 01:38:30 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: ietf@ietf.org Subject: Re: OM Directorate Review of draft-ietf-hokey-erx-09 Hi Bernard, Many thanks for your review. Please see inline for some thoughts and proposals for improvement of erx-09: On 2/6/2008 4:07 PM, Bernard Aboba wrote: Review of draft-ietf-hokey-erx-09 I have reviewed this document as part of the Operations and Management directorate effort. These comments were primarily written for the benefit of the OM area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Detailed review comments are available here: http://www.drizzle.com/~aboba/EAP/erx-review.txt An answer to typical OM issues is included below: 1. Is the specification complete? Can multiple interoperable implementations be built based on the specification? There are a few areas of the document which are unclear to me, such as how AAA routing is accomplished, and how/when peers require the local realm, and if so, how it is to be obtained. Also, clarity with respect to algorithm agility could be improved. There are also some issues with respect to the required behavior of ERX peers and severs (use of normative language). There are also situations in which multiple approaches can be chosen (such as the various bootstrap options), without one being chosen as mandatory or default. Choosing one approach would seem to be better. In my judgement, addressing these issues would improve the likelihood of being able to build multiple interoperable implementations. I agree. This has been brought up by Joe and we'll clarify the text. Some of the confusion has to do with the evolution of the draft; Vidya and I spent a good amount of time cleaning up around the WGLC time, but it appears that we can do better. Pasi suggested adding a section on lower layer considerations. That should help as well. 2. Is the proposed specification deployable? If not, how could it be improved? Based on my reading of the document, it would appear that the ERX proposal requires changes to EAP peers, authenticators and servers, as well as RADIUS clients, proxies and servers. It also appears possible that changes to the lower layer protocols will be required in at least some cases, such as to make the local domain available to the peer. Given my experience in designing and operating wireless networks, deployments requiring changes only to peers and authenticators (but not servers or RADIUS infrastructure) can take as long as 3-5 years to complete. For example, WPA2 is still not universally deployed, even though the specification was finished in 2004. WPA2 compliance requires hardware upgrade in many cases and that may have been the reason for the delay. In addition, some enterprises found an alternative solution, i.e., IPsec VPNs, and so were not as motivated to move to WPA2. In case of ERX, a firmware upgrade should be sufficient, which is much more easier. [BA] One thing that we've learned from the WEP/WPA experience is that changes that often can be delivered via firmware/software upgrade are often linked to new hardware for efficiency reasons. For example, while TKIP was designed for backward compatibility with WEP, few vendors offered upgrades to existing WEP APs; most introduced the changes on new models instead, out of the desire to only continue development on newer branches of the code tree. Similar examples exist for peer updates (e.g. IPv6 support on legacy operating system versions). I guess we can go on this forever as I have a different take on this and so far haven't seen any new information to change my mind. In case of ERP, there are fewer messages, whereas in case of TKIP and IPv6 the upgrade involves additional processing requirements. I do realize that processing logic is slightly more complex, but with some of the proposed optimizations in the recent reviews, the complexity is quite low. So in practice, making changes to a component will often result in the need for new hardware, even if hardware changes were not required by the design. Generally speaking, yeah, I do agree. I think the one barrier for ERP deployment is local ER server deployment. Everywhere else, while there is a need for a software/firmware upgrade, there is no need for hardware upgrades, in my opinion. One caveat is potential memory upgrade requirements on home ER servers. By also requiring changes to AAA infrastructure, it seems to me that ERP deployment will be made more
Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Thanks for the review Joe. On 2/5/2008 11:26 PM, Joseph Salowey (jsalowey) wrote: In reading this draft (-09 version) I came up with a few questions and comments: Section 3 - Section 3 is a bit confusing it seems that much of the text is section 3.1 (detailed description of exchanges) should go into section 3.0 because it seems that much of the process should be the same for local or remote cases. Currently it is difficult to really tell what pertains to local, remote and both. It does not appear to be clear how the peer knows if it is in the home case or the local case, whether the network is capable of ERX (and vice versa) or how the peer knows what key to use. Perhaps I missed this elsewhere in the document. We worked to clarify this in the last revision. I will make another pass at it while preparing v10 and run it by you (probably sometime tomorrow). Section 4 - Section 4.1.1 duplicates text in internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt. It really should not. It should reference KDF functions instead of PRFs. I believe if you replace prf+ with KDF it would be fine. Do you want to use the naming defined in internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt or are you specifying your own? Are these key names really necessary? They do no appear to be used anywhere? This is true. I think we were trying overly hard to name everything (one of 4962 things?) and I realized earlier that we have a procedure to even name the rMSKs. But, it is not clear whether the rMSK names will be used anywhere. I just sent that email about naming and so we should be able to clean this stuff up now if that is acceptable to everyone. On duplication, it seems we have two strong opinions here. You are suggesting less duplication and Alan is suggesting more :). I guess we may have actually achieved the (un)happy medium! My opinion is that we should have less duplication, perhaps to the extent you are suggesting, so the idea is to not have to update (when we need) text in two different drafts. That said, there are some usage specific properties to consider, specifically we are trying to specify crypto-agility in case of ERP and for those reasons, the derivations may need to be spelled out again. In the next revision, I'll see what I can do to reduce the duplication (but before that I will talk to Alan to see what he wants). Why such a long key label? Which one? EAP Re-authentication Root [EMAIL PROTECTED]? I guess we could call it EAP rRK but that might be an abbreviation for something else in the future. Please suggest another name :), but hopefully one that does not involve changing the entire document (I don't want to introduce errors with too many global changes). Section 5 - Section 5.1 What state are you referencing here? I don't think the CalledStation-ID is what you want to reference, I believe RADIUS routing is typically done with the username when EAP is used. Why is it only RECOMMENDED to maintain this state? It seems either it is a MUST or it doesn't matter. In general authenticators do not do routing, AAA does routing. Authenticators copy the correct attributes from EAP into the correct attributes in the AAA message. This seems much more complicated (routing, multiple attributes TLVs etc). Its not clear if the 3 sub-bullets of the first bullet refer to what the authenticator needs to do or the peer needs to do. It seems that the authenticator should be able to extract a single field from the peer message to determine what to do with it. Either it will handle it locally or it will pass the message within the AAA protocol copying the appropriate field into the message. I see. I will make it clear and separate as to what the peer must and what the authenticator must do. I think we have done that in the sections after that, but I can see the ambiguity. On the AAA stuff and the reference to state, could you please suggest text? Thanks. We should say the AAA client in the ER authenticator to be more precise. I was going to talk to Alan about the AAA stuff later this week, but in the meanwhile, please suggest text in this case and that'll help clean up that text. Thanks. Is the integrity checksum a keyed hash or MAC (if so why use another term?)? Integrity checksum is the most generic term (I would think that keyed hash would not be sufficiently generic; I guess MAC might work, but people have had problems with that word, especially folks with L2 background). I do see that there are references to authentication tags and integrity checksums. There is no need for multiple terms (or at least we should say they mean the same thing). If so what key is used? If a key is used in the context in the packet enough to determine the key? Is it possible that more that one EMSK has been generated by the same peer? The key is rIK and there is an rIKname to refer to it.
Nomcom 2007-8: IAOC Selection Announcement
Original Message Subject: Nomcom 2007-8: IAOC Selection Announcement Date: Thu, 31 Jan 2008 13:46:23 -0800 From: Lakshminath Dondeti [EMAIL PROTECTED] To: [EMAIL PROTECTED] Folks, The nomcom has finished the IAOC member selection process. The IESG has confirmed the nomcom's selection of Ed Juskevicius for a two-year term as an IAOC member. The nomcom reviewed the IAOC's requirements, candidates' questionnaire responses and community feedback on the candidates, and after careful deliberations, selected Ed for the position. We thank all the candidates who agreed to be considered for the position. We understand that the nomcom process takes a long time and we appreciate everyone's patience from the nominations to selections phase. About Ed: Ed Juskevicius has been an IAOC member for the past three years. Ed's first IETF meeting was IETF-23 (San Diego, 1992), and he has been at 19 more meetings since then. Ed was local host for the IETF-64 held in Vancouver. Outside of IETF and IAOC, Ed has been volunteering some of his time to the ISOC Advisory Council since 2002. Many thanks to Ed for agreeing to take on this position for another 2-year term. best regards, Lakshminath Nomcom 2007-8 Chair ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Session ID (Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard)
On 2/3/2008 1:23 AM, Glen Zorn wrote: Lakshminath Dondeti scribbled on Sunday, February 03, 2008 1:30 PM: ... There was also the issue of not being able to export EAP session IDs (IIRC) that I referred to in my other message. Hmmm. draft-ietf-eap-keying-22.txt says EAP methods supporting key derivation and mutual authentication SHOULD export a method-specific EAP conversation identifier known as the Session-Id, as well as one or more method-specific peer identifiers (Peer-Id(s)) and MAY export one or more method-specific server identifiers (Server-Id(s)). EAP methods MAY also support the import and export of channel binding parameters. EAP method specifications developed after the publication of this document MUST define the Peer-Id, Server-Id and Session-Id. The Peer-Id(s) and Server-Id(s), when provided, identify the entities involved in generating EAP keying material. For existing EAP methods the Peer-Id, Server-Id and Session-Id are defined in Appendix A. Not sure where the can't export session IDs idea came from, but the above would seem to contradict it. ... Hi Glen, Yeah, that was my recollection from an old discussion (that SHOULD was a MAY not too long ago). In any event, it appears that my statements were incorrect or at least ambiguous. My sincere apologies! If the session-id based keyname derivation can be made to work, I have no objection to use it. I looked at draft and in fact, this is what is stated there: NameDerivationKey = EAP Session-ID, when K used in rRK derivation is the EMSK, NameDerivationKey = DSRK Name, when K used in rRK derivation is the DSRK. I looked at some old versions and there was an explanation Unlike the rRK_name, the EAP session ID is not used to derive the rIK_name. This is done in order to avoid any collisions with USRK names. The key label used for USRKs is IANA registered, while the string rIK Name is not. We probably need to mix in the domain name too to avoid key label collision. I also recall (I know my recollection is bad :) ) Vidya and I discussing that ID collisions may be likely due to at least a couple of other reasons too when the domain specific keying is considered. The various EAP servers do not coordinate session ID derivation and not all methods derive sufficiently long and random session IDs. I now checked session ID derivation in some methods again and it seems reasonably random in methods that I care about (I know that's irresponsible :), but the generic solution is already in the draft). Any suggestions on the direction here? Would it help if we used the following? NameDerivationKey = f(EAP Session-ID, domain-name), when K used in rRK derivation is the DSRK. regards, Lakshminath ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
On 2/3/2008 12:28 AM, Glen Zorn wrote: Dan Harkins scribbled on Saturday, February 02, 2008 8:46 AM: Hello again, Pardon my repetition but I have come up with a very valid reason why naming keys using HMAC-SHA-256 is a bad idea. If one wants to administratively remove all keys in a particular key hierarchy (which seems like an entirely reasonable request) It doesn't seem particularly reasonable to me. The one reason I can think of for this is to disable access for a particular user in some domain; to do that it doesn't seem necessary to explicitly remove all the keys in the hierarchy, just the root key (after disconnecting the user). Disconnecting the user should delete the PMK, TSKs, etc., right? one must do a linear search of all keys in all key hierarchies that a particular server maintains! all identifying key information for all key hierarchies to the same name space. It precludes using something like a hash table for fast lookup of all related keys. If keys were named by concatenating the EAP Session-ID with a string that identified the particular key in the key hierarchy rooted at the MK derived in that EAP Session-ID then the EAP Session-ID could be used as an index into a hash table and all keys for that particular key hierarchy could be looked up very efficiently. I won't argue that indexing the keystore by Session-ID is a bad idea (though Username might be better), but I can't see how that depends upon the actual key name. I like this approach :). Indirection works here (too), it seems like, so let's do that. I will add that session ID based naming as Dan proposes, while it has some interesting properties, needs to be further explored. Semantic key names can also get very long and can make messages inefficient. After some debates, we concluded that 64 bits are necessary (I don't quite agree with the necessary part, but I am willing to go with it) and sufficient. Dan, could you elaborate further and specifically address collision issues and keyname length issues? thanks, Lakshminath regards, Dan. On Fri, February 1, 2008 5:16 pm, Dan Harkins wrote: Hello, I believe this is a well organized and complete document. On numerous occasions while reviewing it I made a mental question regarding something only to have the question answered in a subsequent paragraph. I do have several comments though: 1. this protocol can be used in the presence of AAA proxies. Due to the nature of AAA proxies a peer or authenticator may not even know whether they are part of the communication chain. Therefore, from the view of a security threat their presence must be assumed by the peer and authenticator. The Domain referred to in section 2 (part of the EMSK key hierarchy draft) specifically allows for proxies as part of the distributed system of computers that define the Domain. This brings up many significant issues that are not addressed in this draft. - It cannot be claimed that a key is being bound to its context when the context cannot even be scoped. (Section 6) - The domino effect is not prevented because compromise of a proxy will compromise keying material on (other) authenticators. - A pairwise key is being given by one of the entities that share it, e.g. the server, to a 3rd entity, e.g. a proxy, without the consent of the other peer that shares the key, e.g. the peer. This brings up security considerations that are not discussed. - During discussions at a HOKEY meeting and on the list the rationale that justified proxies was that the peer is more concerned about receiving network access (which is confirmed in the ERP document when it says, The primary purpose [of ERP] is network access control.) than about specifically authenticating the network. Provided that service is obtained with no surprises in the bill at the end of the month the rationale was that the peer didn't care if the key was distributed to proxies if it was necessary to continue to provide network access. Which is a reasonable rationale. But it needs to be mentioned in this document. It has a unique threat model that is not discussed anywhere. - The aforementioned rationale begs the question of why have Domain Specific Keys. If the peer doesn't care whether proxies have a key, potentially for a different domain, then it doesn't care about key separation between domains. This is significant added complexity for no benefit. - RFC4962 REQUIRES things-- bind key to its context, prevent the domino effect-- that ERP cannot support. ERP is a AAA key management protocol though and falls under the scope of RFC4962. There needs to be justification for why ERP is not meeting the mandatory requirements of
Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Hi all, Some of the reviews I have seen start with good things to say about the document pointing about a few things that need to be fixed. Yoshi pointed out one issue that he apparently missed during the WGLC. We have been going back and forth on these topics and not really making progress. Many, if not most of the folks, are also active in the HOKEY WG and support the charter. Let us get together on a telecon sometime next week, and resolve these pending issues. I will send an offline request so we can figure out a time that works for all of us. Thanks. I have seen one comment so far which declares clear opposition. I am going to respond to that separately. regards, Lakshminath On 2/3/2008 1:14 PM, Alan DeKok wrote: Dan Harkins wrote: Yea, mapping by Username might be better. Oone reason is that you could develop a rational searching strategy to identify keys if you indexed with something like Username. That is a great suggestion and a useful alternative to what is in the draft now. I would support such a change. It is also existing practice. The term hotlining refers to the process of pro-actively kicking a user offline after they have previously been authenticated. ERX has to be able to support this practice. It has to be able to delete *all* keys associated with a particular user/cui/session, so that those keys can no longer be used to obtain network access. Alan DeKok. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-hokey-erx to Proposed Standard
Hi Anthony, I am sorry that the quality of the document is not up to your expectations. We tried and the result was satisfactory to many people, some of whom chose to explicitly say so. But, if you have the time, please point out our errors and we'll work to fix them in the revision. Your item 7 below alludes to some of the problems and we'll use those comments as additional guidance in the revision. On other issues, please do let me know if you have suggestions to improve the current document. As to taking a different direction, I will note that other options, including the one you pointed to, were considered and here we are after long and tedious work of the working group consensus process. One of our WG co-chairs wrote one of the documents you point to and as of my last conversation with him was supportive of the ERP. Well, I must add that some of the ideas in that draft came from him. In our analysis, we could not come up with a protocol that is as efficient as ERX without changes to authentication functionality. If you have such a solution, please write a draft and point us to that. You use the words forklift upgrade. A few days ago I re-flashed thirdparty firmware on my almost-bricked WLAN AP in about a few minutes. No forklifts were involved! Normally, I can upgrade the firmware in seconds. We also have an implementation of the protocol where we changed the peers, authenticators and servers, again neither forklifts nor screwdrivers were required! On your point 3, an MSK based hierarchy was considered and after a lot of debate and discussion we have the WG consensus that EMSK based key hierarchy is the direction. Your idea of abuse is also quite interesting. You note that a popular use of EMSK-based key hierarchies is for implementation of walled garden style application authentication based on EAP. If you are suggesting that we at the IETF should not attempt open standardization because we will disturb undocumented proprietary uses, wait ... is this the IETF? Perhaps I am in the wrong place. Finally, we in the HOKEY WG are aware of method-based reauthentication mechanisms and were chartered to do better. Fast handovers in radio access technologies using licensed spectrum have very stringent requirements. I tried to get EAP adopted in 3GPP EPS. They didn't want to do it -- too slow and too many messages were the reason. Many of us worked to get it adopted in 3GPP2 UMB. We succeeded. We are trying to specify method independent reauthentication for faster handovers. That's our charter. Thank you again for your review. If you want to work together on open standardization, I am happy to work with you. If you think we shouldn't publish new proposed standards because you are aware of proprietary undocumented extensions of IETF protocols, well then, we have different views of what the IETF should be doing. best wishes, Lakshminath On 2/1/2008 1:54 PM, Anthony Leibovitz wrote: I've read through [draft-ietf-hokey-erx-08] and oppose adoption this document as a Proposed Standard. The key problem with the document is cost associated with deployment and implementation. In addition to requiring updates to EAP peers and servers, the ERX proposal also requires that authenticators be updated or replaced, because instead of using existing EAP packet types, the ERX proposal requires the addition of new EAP packet types as well as peer-initiated messages. As a result ERX requires a forklift ugprade of peers, servers, authenticators and proxies. This is unrealistic, particularly when there are alternatives that can deliver the same performance and the same (or better) security with lower deployment barriers. For example, see references [1] and [2], there are existing deployments that only require modifications to EAP peers and authenticators (but not EAP servers), and research papers which describe schemes that only require changes to EAP peers and servers (but not authenticators). Given the greater deployment barriers for ERX, some other benefit (such as simplicity, ease of implementation, etc.) needs to be demonstrated to tip the scales in favor of the ERX approach. Unfortunately, ERX is also more complex than other schemes, and provides no better (and potentially worse) security than the alternatives. In addition to these basic issues, the ERX scheme has lots of other issues: 1. Proposed key hierarchy - the key hierarchy on which this document is based is complex and unclear. It adds additional server roles in both single and multi-domain environments, it defines new key types to be generated, maintained and distributed. Furthermore I am not clear how crypto-agility is supported within the proposed hierarchy. If the assumption is that EAP or EAP methods will do the negotiation then even once platforms are updated to support this technology most existing
Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Hi Dan, Many thanks for your review. Please see inline for some notes. On 2/1/2008 5:16 PM, Dan Harkins wrote: Hello, I believe this is a well organized and complete document. On numerous occasions while reviewing it I made a mental question regarding something only to have the question answered in a subsequent paragraph. Thanks. I do have several comments though: 1. this protocol can be used in the presence of AAA proxies. Due to the nature of AAA proxies a peer or authenticator may not even know whether they are part of the communication chain. Therefore, from the view of a security threat their presence must be assumed by the peer and authenticator. The Domain referred to in section 2 (part of the EMSK key hierarchy draft) specifically allows for proxies as part of the distributed system of computers that define the Domain. This brings up many significant issues that are not addressed in this draft. - It cannot be claimed that a key is being bound to its context when the context cannot even be scoped. (Section 6) - The domino effect is not prevented because compromise of a proxy will compromise keying material on (other) authenticators. - A pairwise key is being given by one of the entities that share it, e.g. the server, to a 3rd entity, e.g. a proxy, without the consent of the other peer that shares the key, e.g. the peer. This brings up security considerations that are not discussed. - During discussions at a HOKEY meeting and on the list the rationale that justified proxies was that the peer is more concerned about receiving network access (which is confirmed in the ERP document when it says, The primary purpose [of ERP] is network access control.) than about specifically authenticating the network. Provided that service is obtained with no surprises in the bill at the end of the month the rationale was that the peer didn't care if the key was distributed to proxies if it was necessary to continue to provide network access. Which is a reasonable rationale. But it needs to be mentioned in this document. It has a unique threat model that is not discussed anywhere. We'll document this in the revision. - The aforementioned rationale begs the question of why have Domain Specific Keys. If the peer doesn't care whether proxies have a key, potentially for a different domain, then it doesn't care about key separation between domains. This is significant added complexity for no benefit. Well, the added complexity is 1 additional level in the key hierarchy. The advantage is that if a domain supports multiple usages, it is efficient to send a domain specific key, DSRK, and let the domain and the peer derive all the usage keys appropriate within that domain. Different domains may support different usages and all usages may or may not be supported or even understood within the home domain. So, if a new usage is introduced and that is not supported by the key server in the home, that is ok; as long as the server in the visited domain supports the usage, it is sufficient. - RFC4962 REQUIRES things-- bind key to its context, prevent the domino effect-- that ERP cannot support. ERP is a AAA key management protocol though and falls under the scope of RFC4962. There needs to be justification for why ERP is not meeting the mandatory requirements of RFC4962. We got a clarification from the author of 4962 that proxies are ok. As you noted earlier, we'll document that the properties that are not supported in the presence of proxies and summarize the kind of guarantees that are available. I think all of these issues need addressing before advancement of this Internet-Draft. 2. Inter-Domain ERP It is this reviewers recollection that consensus was reached in HOKEY to require a peer to reauthenticate back to the home AAA server every time it attached to a POP in different domain. Therefore, I wonder why a Domain-Specific key, the DSRK, and all it's progeny-- DS-rIK, DS-rRK, DSUSRK, etc.-- continue to be used by this protocol. A HOKEY-KEY, a USRK, should be derived from the EMSK and that is the key given, through proxies if need be, to the ER server in the visited domain. If the peer goes to a different domain then it does a full reauthentication resulting in a _new_ USRK, that has no relation to the previous USRK, being given to the ER server in the new domain. Again, it was my understanding that the group already reached consensus on this matter. Please see above about the need for domain specific keys. 3. HMAC-SHA256 as a key naming technique SHA-256 is a computationally intensive operation; HMAC-SHA256 doubly so. There should, therefore, be some justification to use such
Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
On 1/31/2008 6:23 AM, Yoshihiro Ohba wrote: On Wed, Jan 30, 2008 at 10:53:25PM -0800, Lakshminath Dondeti wrote: ... hence the authenticator initiation of the ERP exchange may require the authenticator to send both the EAP-Request/Identity and EAP-Initiate/ Re-auth-Start messages. Yes. Have existing EAP peer implementations been validated to work under these assumptions? i.e. will they break? Will they see unexpected EAP messages or content, and reject or discard the response? Kedar noted from his implementation experience and it worked with hostap/wpa_supplicant. Shouldn't compliant implementations discard EAP messages with unknown codes? I am rather concerned with authenticator behavior. Since EAP is designed as a lock-step protocol which only supports a single packet in flight, allowing two outstanding requests breaks one basic design principle of EAP. In order to allow two outstanding requests, I would expect significant modifications to EAP state machines described in RFC 4137, and such modifications should be described in ERP document. Hi Yoshi, We have had these discussions in the WG. The consensus was that there may be a notion of an ERP state machine and it interacts with the EAP state machine. regards, Lakshminath Yoshihiro Ohba ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
On 1/31/2008 7:01 AM, Alan DeKok wrote: Lakshminath Dondeti wrote: Have existing EAP peer implementations been validated to work under these assumptions? i.e. will they break? Will they see unexpected EAP messages or content, and reject or discard the response? Kedar noted from his implementation experience and it worked with hostap/wpa_supplicant. Shouldn't compliant implementations discard EAP messages with unknown codes? Well, yes. But I've successfully crashed EAP implementations in the past by intentionally violating SHOULD or MUST requirements. We need to be pro-active to ensure that this change not only is compatible with the standards, but also existing implementations and deployments. When does the peer send these messages? Under what circumstances? When the peer attaches to an authenticator. The text needs to be clarified to explain that. Right now, it appears that there are no time or state sequence restrictions on sending those messages. It is specified elsewhere in the document. We'll make it more consistent and clear. This work would appear to be fairly core to the solution. EAP servers are commonly deployed in conjunction with AAA servers, and interact with AAA proxies. Can any of that discussion be added to this document? As it stands, the document is unclear as to interaction between ERP and AAA protocols. Wouldn't that be duplication? A paragraph or two explaining the issues and concepts would help clarify the ERX document. As it stands now, the ERX document cannot really be understood without also reading a number of other documents. i.e. small amounts of duplication that stop a potential infinite regression is likely acceptable. We'll add some text, hopefully generic text that does not force a lock-step update of multiple specifications each time something needs to change. I see your point. On the other hand, EAP methods don't send lifetime of the MSK. The peer already relies on the authenticator for lifetime management. If the consensus shifts along these lines, I don't mind doing this. EAP supplicants don't need to know the lifetime of the MSK because their network connection drops when the MSK expires. i.e. they are pro-actively notified. ERX supplicants need to know the lifetime of the keys that they use for re-authentication, because they may not be connected when a key expires. In that case, ERX would *increase* the number of packets and time required to authenticate. This is because the supplicant would have to try ERX, fail, and then fall back to EAP. I understand. This is the first mention of AAA proxies in this document. There is no definition of AAA proxy, and no discussion of how they interact with, or affect, ERP. Should be covered in draft-gaonkar. I strongly suggest adding *some* text about AAA and ERP interaction in this document. Ok. Subsequently, when the peer attaches to an authenticator within the local domain, it may perform an ERP exchange with the local ER server to obtain an rMSK for the new authenticator. It would be good to mention that this process only occurs for the lifetime of the relevant keys. Not sure I understand. We are trying to treat the rMSK as similar to the MSK as possible and so the peer does not know the lifetime. It could, as you note earlier, but it does not at the moment. As it stands, the text I quoted has no time restrictions on the use of the rMSK. Text should be added to the section I quoted, saying that the ERP exchange may only be performed during the lifetime of the rMSK. Saying that here would also clarify the motivation for *always* sending the lifetime of the keys to the peer. If the rMSK is valid only for a particular time, then the peer *must* have that information. This is convincing to me and as it stands does not hurt anything (other than one of the prototypes we have, but I can deal with that). This change gives motivation to the derivation of multiple rMSKs, and ties them into specific entities in the network. Ok, so this would also address your note above about the motivation for the hierarchy too, right? Yes. S = rRK Label + \0 + NULL + length Is this string concatenation? What is NULL? How is length encoded? Are there test vectors that can be used to validate these calculations? All of this comes from the EMSK document. Everything is specified in that document. We might repeat it in this I-D, but that would be bad in that we'd have to change things in two places if things do change. My issue was that as it stands, it's unclear as to what that text means. Perhaps the EMSK document could define parameterized functions to calculate S. This document could then reference those functions. I understand. Referencing is a tough balance. I will talk to Joe and others and see what might make sense. Alan DeKok. Thanks Alan. regards, Lakshminath
Nomcom 2007-8: IAOC Selection Announcement
Folks, The nomcom has finished the IAOC member selection process. The IESG has confirmed the nomcom's selection of Ed Juskevicius for a two-year term as an IAOC member. The nomcom reviewed the IAOC's requirements, candidates' questionnaire responses and community feedback on the candidates, and after careful deliberations, selected Ed for the position. We thank all the candidates who agreed to be considered for the position. We understand that the nomcom process takes a long time and we appreciate everyone's patience from the nominations to selections phase. About Ed: Ed Juskevicius has been an IAOC member for the past three years. Ed's first IETF meeting was IETF-23 (San Diego, 1992), and he has been at 19 more meetings since then. Ed was local host for the IETF-64 held in Vancouver. Outside of IETF and IAOC, Ed has been volunteering some of his time to the ISOC Advisory Council since 2002. Many thanks to Ed for agreeing to take on this position for another 2-year term. best regards, Lakshminath Nomcom 2007-8 Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org http://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
A couple of comments to be considered as part of the last call comments: 1. Some folks from 3GPP2 (Parag Agashe, Dinesh Dharmaraju and others) reviewed the document and pointed out that IANA stuff needs to be cleaned up further. Charles Clancy pointed out this earlier and we thought we caught all of them. Specifically, the following instances need to edited and clarified: Page 16: If the lifetime flag was set in the EAP-Initiate/Re-auth message, the ER server SHOULD include the rRK lifetime in the EAP-Finish/Re-auth message. Whereas there is a lifetime flag in the EAP-Finish/Re-auth message, the corresponding TLV has not been specified. Page 24: Authenticator Identifier: This is a TLV payload. The Type is TBD Page 29: cryptosuite list TLV type assignment is not listed in the IANA section. 2. Katrin Hoper noted that There might be a problem with the proposed usage of sequence numbers for re-authentication, if multiple protocol sessions are initiated _simultaneously_ by the same peer with several authenticators in range. and proposed addressing that issue by allowing a window of acceptable sequence numbers Glen supported and said that we should add the windowing scheme to the draft. (quoting slightly out of context, but Glen made his intent clear in an offline conversation). + We will address these issues and incorporate suggested changes in the next revision. I am cc'ing Tim so he can track these before forwarding to the IESG. thanks, Lakshminath On 1/24/2008 8:12 AM, The IESG wrote: The IESG has received a request from the Handover Keying WG (hokey) to consider the following document: - 'EAP Extensions for EAP Re-authentication Protocol (ERP) ' draft-ietf-hokey-erx-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-02-07. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15997rfc_flag=0 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Alan, Thanks much for your comments. Please see inline: On 1/29/2008 8:32 AM, Alan DeKok wrote: Reviewing the document, it looks very good overall. I have a few comments and questions about Sections 1 through 4. The later sections will be reviewed in a separate message. Section 2: Defines a number of terms, but not AAA server, which is first referenced in Section 3.1. Similarly for AAA proxy. It should also define key lifetime, which is a concept used multiple times, but not defined. Ok. Section 3.1, Figure 1. The diagram could be clarified to make it obvious that it is one diagram split in two for space reasons. e.g. having linking notes between the different portions in the first half and second half. Ok, perhaps it should be split into two. These exchanges in fact could happen at different points in time. We will revise the figure and split into two and add text to clarify. When the peer subsequently identifies a target authenticator that supports EAP re-authentication, it performs an ERP exchange, as shown in Figure 1 as well; the exchange itself may happen when the peer attaches to a new authenticator supporting EAP re-authentication, or prior to attachment. The peer initiates ERP by itself; ... Figure 1 does not appear to show the peer initiating an ERP exchange. How does the peer advertise ERP capability? Note the square brackets on the first two messages. The peer could proactively start with EAP Initiate/Re-auth I am also unclear as to how the EAP exchange in Figure 1 will work with existing implementations. The Reauth-Start message at the top of the second half of the diagram is unsolicited by the peer. ... hence the authenticator initiation of the ERP exchange may require the authenticator to send both the EAP-Request/Identity and EAP-Initiate/ Re-auth-Start messages. Yes. Have existing EAP peer implementations been validated to work under these assumptions? i.e. will they break? Will they see unexpected EAP messages or content, and reject or discard the response? Kedar noted from his implementation experience and it worked with hostap/wpa_supplicant. Shouldn't compliant implementations discard EAP messages with unknown codes? We introduce two new codes to EAP: EAP-Initiate and EAP-Finish. The peer sends an EAP-Initiate/Re-auth message that includes the Peer-ID or a temporary NAI based on the rIKname, and a sequence number for replay protection. ... When does the peer send these messages? Under what circumstances? When the peer attaches to an authenticator. ... The message is routed using the NAI in the rIKname-NAI [4], field and if that is not present, it is routed using the NAI in the Peer-ID. ... Routed to where? This is the first mention of routing in the document. Is this routing related to the common practice of routing AAA requests by NAI? Yes. Do ERP servers have a routing relationship? If so, how does it interact with AAA routing? That is the topic of draft-gaonkar. We'll include a reference. ... Ongoing work in [10] describes an additional key distribution protocol that can be used to transport the rRK from an EAP server to one of many different ER servers that share a AAA trust relationship with the EAP server. This work would appear to be fairly core to the solution. EAP servers are commonly deployed in conjunction with AAA servers, and interact with AAA proxies. Can any of that discussion be added to this document? As it stands, the document is unclear as to interaction between ERP and AAA protocols. Wouldn't that be duplication? In an ERP bootstrap exchange, the peer may request the rRK lifetime to be sent to it. If so, the ER server sends the lifetime along with the EAP-Finish/Re-auth message. This is the first mention that they keys may have a lifetime. I would suggest always sending the key lifetime to the peer. It is a small amount of data, and is useful for the peer to know. i.e. there should be strong motivations for *not* sending the key lifetime. I see your point. On the other hand, EAP methods don't send lifetime of the MSK. The peer already relies on the authenticator for lifetime management. If the consensus shifts along these lines, I don't mind doing this. Section 3.2 The defined ER extensions allow executing the ERP with a local ER server that may be topologically closer to the authenticator. ... I'm not sure what this means, because the previous text does not discuss network topologies. Yeah, topology may not be the right word. We'll try to use the phrase local domain and refer to the EMSK-hierarchy document. ... The local ER server may be collocated with a local AAA server. I think this should be co-located. Ok, thanks. As shown in Figure 2, the local ER server may be present in the path of the full EAP exchange (e.g., this may be one of the
Thank you
Hi Ray, I had a chance to look at the schedule for the next meeting and I observed that you took the feedback about normalizing the cutoff times into account (http://www.ietf.org/meetings/71-cutoff_dates.html). I appreciate your prompt action on this very much. Happy holidays. best, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Nomcom 2007-8 at the Vancouver Meeting
Folks, The nomcom has been busy with the selection process over the past several months reviewing candidates' questionnaire responses, processing community feedback and gearing up to make use of the face-to-face time at the Vancouver meeting as effectively as possible. We have scheduled some interviews at the Vancouver meeting and may schedule additional interviews with candidates over the phone or may ask for additional information via email. If you are a candidate, we very much appreciate your patience while we work on the selections. We are slightly behind in our schedule, but expect to send out requests for feedback on IAB and IAOC candidates in the next few days. While the community provides feedback on the IAB and IAOC candidates, we plan to finalize the selections for the open IESG positions. We hope that this parallelization will put us back on track to meet the deadlines. We will make all attempts to meet the posted deadlines. Nomcom members will continue to listen to community feedback at the Vancouver meeting. Please send an email to one of the nomcom members or me directly to setup a time to chat about the selections this year. Thank you again for the nominations and feedback on candidates. best regards, Lakshminath 2007-8 Nomcom Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Our deadlines are dizzyingly complex and confusing
From my point of view, it can be any timezone as long as the cutoff time is the same in all cases. While we are on topic, I propose to use AOE as defined by IEEE (I think 802.16). regards, Lakshminath On 11/26/2007 10:33 AM, Spencer Dawkins wrote: Spencer Dawkins wrote: Laksminath's note is more detailed, but it's roughly what I was thinking at about 2 PM EST today :-( I'm sure there's an opportunity for us to pick a time zone for IETF 71 cutoffs! you mean like UTC? :-) OK, guilty. My point was that the cutoff time seemed to be close of business, ET, and I was kinda hoping that whatever time we picked would be close of business, a little further west :-) ... especially if we were headed toward using the same cutoff TIME for all IETF cutoffs (BOF requests, WG meeting requests, registration, ID cutoffs, etc) ... Thanks, Spencer I'd note that all the reference times in this message were in the same timezone just not at the same time. I submit that I really hate having to convert the offset from my current timezone in someone else's particularly when I can't remember when their daylight savings time begins or ends. however the challenge really is that they're not all in my calender rather than than that I need to calculate the offset because software will happily do that for me. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Our deadlines are dizzyingly complex and confusing
Just in case you are not familiar with AOE, it stands for Anywhere on Earth (See http://www.ieee802.org/16/aoe.html) regards, Lakshminath On 11/26/2007 10:39 AM, Lakshminath Dondeti wrote: From my point of view, it can be any timezone as long as the cutoff time is the same in all cases. While we are on topic, I propose to use AOE as defined by IEEE (I think 802.16). regards, Lakshminath On 11/26/2007 10:33 AM, Spencer Dawkins wrote: Spencer Dawkins wrote: Laksminath's note is more detailed, but it's roughly what I was thinking at about 2 PM EST today :-( I'm sure there's an opportunity for us to pick a time zone for IETF 71 cutoffs! you mean like UTC? :-) OK, guilty. My point was that the cutoff time seemed to be close of business, ET, and I was kinda hoping that whatever time we picked would be close of business, a little further west :-) ... especially if we were headed toward using the same cutoff TIME for all IETF cutoffs (BOF requests, WG meeting requests, registration, ID cutoffs, etc) ... Thanks, Spencer I'd note that all the reference times in this message were in the same timezone just not at the same time. I submit that I really hate having to convert the offset from my current timezone in someone else's particularly when I can't remember when their daylight savings time begins or ends. however the challenge really is that they're not all in my calender rather than than that I need to calculate the offset because software will happily do that for me. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Our deadlines are dizzyingly complex and confusing
Yeah, I can deal with any TZ actually (AOE is one suggestion and I think most intuitive, UTC is another), but can't handle the varying cutoff times :). On why AOE is intuitive, everyone gets to treat the deadline with their own TZ substituted for AOE (the actual deadline for most people would be a bit or a lot later in reality). regards, Lakshminath On 11/26/2007 10:42 AM, Eric Rescorla wrote: At Mon, 26 Nov 2007 10:39:03 -0800, Lakshminath Dondeti wrote: From my point of view, it can be any timezone as long as the cutoff time is the same in all cases. While we are on topic, I propose to use AOE as defined by IEEE (I think 802.16). AOE == UTC-1200. UTC seems much more natural. That said, once you've selected one time zone as the reference, it's not like it's difficult to translate. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Our deadlines are dizzyingly complex and confusing
Hi, I just found out that I missed the deadline for early-bird registration and payment. I registered early, but was planning to pay just in time, but alas the deadline has passed. I was thinking that the deadline is later in the day, end of the business day Eastern time. We have deadlines at 9:00 ET, 12:00 ET and 17:00 ET for draft submission, WG session scheduling, payments and proceedings submission. I was thinking that all payment deadlines are at 17:00 ET, end of business day. They are not! The early-bird registration and payment deadline is at 12:00 ET and the final pre-registration and pre-payment deadline is 17:00 ET. Perhaps there is a logic to this, but it is not intuitive to me. Could all deadlines be at the same time (on different days obviously) to avoid such confusion in future? thanks, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-aboba-sg-experiment-02
Just for the record, if the norm ends up being Idea -- BoF-1 -- BoF-2 -- SG -- WG, I would be very disappointed and would chalk that up under the law of unintended consequences :). I am hoping that Idea -- SG -- WG or Idea -- BoF1 -- SG -- WG in that order become the norm (where SG is involved of course), especially when proponents of new work are people who may not be regulars at the IETF. regards, Lakshminath On 10/11/2007 1:38 AM, John C Klensin wrote: In the notation of Lakshminath's recent chart, we have moved from Idea -- WG being the normal case, to Idea -- BoF-1 -- BoF-2 -- WG being the normal case, to some risk of making Idea -- BoF-1 -- BoF-2 -- SG -- WG normal. Under some circumstances, that would be a year well spent. Under others, it is just another year wasted in exploration, extended problem description, and procedures when the goal should be to do technical work and get useful results out (and to cut unfocused ideas and ideas with insufficient support out of the system with as little wasted time and energy as possible). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-aboba-sg-experiment-02
My cynicism hasn't reached that level yet, although people tell me that it will get there very soon given some of the activities I have signed up for. :) That out of the way, the intention of the proposal is to provide a framework for people with reasonable ideas for work at the IETF to develop those ideas and eventually succeed in standardization of protocols in that area, and sooner than later. (the venue for developing the ideas for work is the SG whereas standardization of protocols is to happen in WGs that may or may not have been formed as a result of the SGs). regards, Lakshminath On 10/11/2007 11:02 AM, John C Klensin wrote: --On Thursday, 11 October, 2007 10:03 -0700 Lakshminath Dondeti [EMAIL PROTECTED] wrote: Just for the record, if the norm ends up being Idea -- BoF-1 -- BoF-2 -- SG -- WG, I would be very disappointed and would chalk that up under the law of unintended consequences :). Unfortunately, there is some history in the IETF that might lead someone who is even mildly cynical about the way procedures unfold and are used (and it is probably obvious that I passed mildly long ago) to predict that would be exactly the outcome, unintended or not. To the extent to which the IESG tends to be responsive to community input and sensitive to constraints about meeting and management time --and I'd hope they would be responsive to both -- it might take only a few loud voices saying not ready to turn BOF1 into a requirement for BOF2 (arguably we see that already) and similar voices to turn the outcome of BOF2 from WG into SG and more consideration. In practice, that might turn at least some SGs into exactly what I think you are trying to avoid: an indeterminable series of BOF-list sessions with a charter and under a different name. That would also be an unintended consequence, but I don't see how to avoid it other than to trust the IESG to manage SGs more aggressively than they have historically managed WGs and to assume that the community would vigorously support them in applying that level of management. I am hoping that Idea -- SG -- WG or Idea -- BoF1 -- SG -- WG in that order become the norm (where SG is involved of course), especially when proponents of new work are people who may not be regulars at the IETF. If the goal is really the education and socialization of newcomers and refinement of their ideas, shouldn't we be thinking about more direct, explicit, and efficient ways to do that, rather than about new procedures and process steps? john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-aboba-sg-experiment-02
On 10/11/2007 9:47 PM, Pekka Savola wrote: On Thu, 11 Oct 2007, Lakshminath Dondeti wrote: Just for the record, if the norm ends up being Idea -- BoF-1 -- BoF-2 -- SG -- WG, I would be very disappointed and would chalk that up under the law of unintended consequences :). I am hoping that Idea -- SG -- WG or Idea -- BoF1 -- SG -- WG in that order become the norm (where SG is involved of course), especially when proponents of new work are people who may not be regulars at the IETF. One of the reasons for having a BoF is that the BoF proponents need to convince the rest of the IETF that the idea is workable and there's sufficient interest to work on the topic. If there is expectation that no BoF is held between the SG and WG phase, how can we guarantee that the IETF as a whole thinks the charter and the other deliverables the SG worked on are convincing and worth doing? Hi Pekka, Section 2.3 of 2418 would apply. regards, Lakshminath As for the timeslot scheduling, I'd say SGs should have a precedence over IRTF research groups, given that we're talking about IETF meetings, not IRTF meetings. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-aboba-sg-experiment-03.txt
Given the confusion around this, let me try to enumerate all paths (I will enumerate the end result as WG, but please substitute it with Stop for the failure cases) Idea -- WG Idea -- SG -- WG Idea -- BoF-1 -- WG Idea -- BoF-1 -- BoF-2 -- WG Idea -- BoF-1 -- SG -- WG Idea -- BoF-1 -- BoF-2 -- SG -- WG I am not too keen on SG -- BoF; but, if the sponsoring AD wants to do it, I guess it may make sense to not explicitly disallow it. We can probably look for that data during the experiment. If the SG failed to develop a consensus charter during its life, a BoF session most likely won't result in a different result (although one could argue that due to time constraints or other reasons, the community evaluation of the charter they developed can be done at a f2f meeting as opposed to at a meeting; a similar argument has been made here by folks). To not flout the 2418 rule, if two BoFs were already held and an SG was created, it's WG or nothing after the SG. So, we may also accommodate Idea -- SG -- BoF-1 -- WG Idea -- BoF-1 -- SG -- BoF-2 -- WG The following two options do not make sense: Idea -- SG -- BoF-1 -- BoF-2 Idea -- BoF-1 -- SG -- BoF-2 -- BoF (2418 disallows this) Idea -- BoF-1 -- BoF-2 -- SG -- BoF (2418 disallows this) (Hope I didn't make a mistake there ;) ) regards, Lakshminath On 10/10/2007 8:08 PM, Spencer Dawkins wrote: Hi, The complete text of the strawman -03 document is available here: http://www.drizzle.com/~aboba/IAB/draft-aboba-sg-experiemnt-03.txt Easily corrected typo, but just for ease of clicking, the correct URL is http://www.drizzle.com/~aboba/IAB/draft-aboba-sg-experiment-03.txt Now, for something completely different... Since this is an experiment - please don't hold up the experiment while you try to legalese-craft all the corner cases, but you might include a things to clarify if the experiment succeeds list... which might include this question... From way down at the bottom of the 03 Introduction (which is really long, but): This document describes an RFC 3933 [RFC3933] experiment in the Working Group formation process, known as the Study Group. Study Groups MAY be formed by the IESG when there is evidence of clear interest in a topic on the part of IETF participants and end-users, and relevance to the Internet community has been demonstrated, but other RFC 2418 [RFC2418] criteria relating to Working Group formation (including creation of a satisfactory Charter) have not yet been met as the result of a first or second Birds-of-a-Feather (BOF) session. So far, so good... I'm not confused until the next paragraph: Study Group milestones are focused on completion of prerequisites for Working Group formation, and as a result they are expected to conclude within a short time frame, with limited opportunities for milestone extension. This Study Group experiment does not alter the Working Group formation guidelines described in RFC 2418 [RFC2418] Section 2.1, the processes relating to BoFs [BOF] or the Internet Standards Process described in RFC 2026 [RFC2026]. Is everyone but me totally clear on how BOFs interact with SGs and WGs? The way I'm reading this, the mainline path through this procedure is that some community of interest requests a BOF, with a request that's plausible enough for an AD to go for it, and then the IESG suggests a SG after the BOF. If the SG succeeds, is there any opportunity to hold a second BOF (which seems reasonable, as a WG-forming BOF that would have more IETF-wide visibility), or does the SG have to go straight to WG (which is the way I read version 03)? And, for extra credit, if the answer is yes, what if the community held two BOFs before the SG formed (which would be the 2418 limit)? The answer based on does not alter the process seems to be no - is that what we want? And a couple of nits... Nit: there are places in this draft that say charter, but since both SGs and WGs have charters, it would be great if these occurences were qualified as SG charter or WG charter. Nit: [BOF] is great advice (I've reviewed it at least once for Thomas), but it's not the processes relating to BOFs [BOF]. The last time I saw [BOF], it was intended to be informational - the process is still normatively described in 2418. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-aboba-sg-experiment-02
Thanks Jari, Eric. Some notes inline ... On 10/8/2007 12:03 AM, Jari Arkko wrote: snip Currently this document simply has it at the IESG's discretion: If at any point during the Working Group formation process, including after a first or second BoF session, interest within the IETF and end-user community has been demonstrated, but one or more Working Group formation criteria outlined in [RFC2418] Section 2.1 has not yet been met, the IESG MAY propose that a Study Group be formed. This seems ripe for abuse of the kind I outlined above. IMO this document would benefit from a clearer statement of the conditions under which it was appropriate to form an SG, thus reducing pressure on ADs. I am not sure what kind of abuse you are worried about Eric. Please clarify. This would be helpful. Bernard, Laksminath, any ideas? I don't think we should make it algorithmic and instead should leave the steering, direction and judgment aspects of an IESG job intact. That said, my expectation is that the sponsoring AD is responsible for considering the general guidance the draft offers and making a decision on whether to form an SG, suggest a(nother) BoF session, form a WG, or say that the work is not appropriate at the IETF at the time, etc. The motivating text is: In some situations, while interest on the part of IETF participants and end-users may be evident, and the relevance to the Internet community may be demonstrated, the answer to other questions (such as an understanding of existing work, achievability of goals, or overlap with existing working groups or standards bodies) may not be as clear. The guiding text is: Study Groups MAY be formed by the IESG when there is evidence of clear interest in a topic on the part of IETF participants and end-users, but other criteria relating to Working Group formation (including creation of a satisfactory Charter) have not yet been met. We could make the guiding text more precise (perhaps include some specific criteria), if that is what the community wants. Arguably, SG formation should be subject to an IETF LC in the same way that WG formation is. Hm. I believed this was already the case. SGs are subject to exactly the same process as WGs, and I was assuming that like, WG formation, SG formation would include discussion in the IESG, consultation with the IAB, and IETF Last Call. Perhaps this needs clarification. Authors? We could clarify, but the intent is to follow the WG process for formation. Finally, it's unclear the extent to which SGs are intended to transition directly to WGs without going through another BOF phase. I have two concerns here: 1. It will be hard for the IESG to deny successful SGs the right to form a WG. Saying NO is still going to be needed. 2. BOFs are a defined in-person event at which everyone knows that WG formation is being considered. This provides an opportunity for public high bandwidth discussion of that topic. I don't think an LC on the IETF list is an adequate substitute. Good point. Bernard, Laksminath -- any ideas here? I disagree with Eric here. I believe that we are not a meeting based organization and should be making more of these important decisions via email where we have more time to consider the proposals carefully. My observation based on some of the BoFs I have been involved with recently is that far too much time is wasted between two BoF sessions. With little or no discussion between sessions, a good portion of the meeting time is used to get on the same page (again). That aside, if the sponsoring AD believes that the in-person events are important, they may suggest a BoF as a first step to bringing new work to the IETF. An SG may come after that. regards, Lakshminath 3. The experiment be structured to do the minimal amount of harm if it fails. In IESG review of this proposal, one of the things we talked about was whether there is a way to limit this experiment so that we can indeed test the idea but avoid impacting everyone. One of the suggestions was to set a limit on the number of SGs during the experiment to some low value, such as three. I would be in favor of this limitation. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-aboba-sg-experiment-02
Hi Eric, Following up on this ... On 10/8/2007 11:30 AM, Eric Rescorla wrote: At Mon, 08 Oct 2007 11:13:50 -0700, Lakshminath Dondeti wrote: Thanks Jari, Eric. Some notes inline ... On 10/8/2007 12:03 AM, Jari Arkko wrote: snip Currently this document simply has it at the IESG's discretion: If at any point during the Working Group formation process, including after a first or second BoF session, interest within the IETF and end-user community has been demonstrated, but one or more Working Group formation criteria outlined in [RFC2418] Section 2.1 has not yet been met, the IESG MAY propose that a Study Group be formed. This seems ripe for abuse of the kind I outlined above. IMO this document would benefit from a clearer statement of the conditions under which it was appropriate to form an SG, thus reducing pressure on ADs. I am not sure what kind of abuse you are worried about Eric. Please clarify. You trimmed out the section where I explained: A related issue is that this puts pressure on ADs to approve SGs for efforts that they would ordinarily simply refuse WGs for. I.e., OK, so you won't give us a WG, how about a SG. Currently this document simply has it at the IESG's discretion: I didn't connect abuse and suggesting a direction in bringing new work to the IETF. :) To clarify, the reasonably high bar for WG formation plus the two BOF rule has the effect of enabling ADs to say so No to work that really is not ready. The concern is that efforts which are denied WGs will turn around and ask for an SG and that it will be difficult to turn them down even though they really need to go back to the drawing board. As Jari notes, the ADs should still say No to work that is not ready. Suppose after a first BoF or after initial evaluation, an AD considers a piece of work to be sufficiently important and pertinent to be done at the IETF; telling an ad hoc group of folks to develop the idea offline and come back again, say after ~4 months, may not work well in all cases. This would be helpful. Bernard, Laksminath, any ideas? I don't think we should make it algorithmic and instead should leave the steering, direction and judgment aspects of an IESG job intact. Nor did I argue differently. However, there is a difference between exercising judgement and unguided sole discretion. My concern is that the language in the draft errs to far in the latter direction. There is a balance we need to achieve here. On the one hand we don't want to create check lists; on the other hand we do want to avoid the possibility of, in your words, unguided sole discretion. We could make the guiding text more precise (perhaps include some specific criteria), if that is what the community wants. Yes, I think this would be valuable. Bernard and I will work on some wording. Arguably, SG formation should be subject to an IETF LC in the same way that WG formation is. Hm. I believed this was already the case. SGs are subject to exactly the same process as WGs, and I was assuming that like, WG formation, SG formation would include discussion in the IESG, consultation with the IAB, and IETF Last Call. Perhaps this needs clarification. Authors? We could clarify, but the intent is to follow the WG process for formation. In that case, I think it needs clarification. Ok. Finally, it's unclear the extent to which SGs are intended to transition directly to WGs without going through another BOF phase. I have two concerns here: 1. It will be hard for the IESG to deny successful SGs the right to form a WG. Saying NO is still going to be needed. 2. BOFs are a defined in-person event at which everyone knows that WG formation is being considered. This provides an opportunity for public high bandwidth discussion of that topic. I don't think an LC on the IETF list is an adequate substitute. Good point. Bernard, Laksminath -- any ideas here? I disagree with Eric here. I believe that we are not a meeting based organization and should be making more of these important decisions via email where we have more time to consider the proposals carefully. Well, you might prefer that the IETF functioned this way, but I think it pretty clearly does not. As a practical matter, nearly all WGs have BOFs prior to their formation, and that's the only time that there is high-bandwidth cross-area discussion. That same discussion by and large does not happen on the IETF mailing list during LC. IMO the effect of eliminating the in-person time will be to eliminate said discussion, not transfer it to the mailing list. If you wish the IETF to do more work via email, I think the first step would be to improve the quality of the email discussion. I knew this discussion will sidetrack us. I am sorry I started it. We can talk about it some other time. My observation based on some of the BoFs I have been involved with recently is that far too much time
Re: Comments on draft-aboba-sg-experiment-02
On 10/8/2007 1:43 PM, Brian E Carpenter wrote: On 2007-10-09 07:30, Eric Rescorla wrote: At Mon, 08 Oct 2007 11:13:50 -0700, Lakshminath Dondeti wrote: big snip My observation based on some of the BoFs I have been involved with recently is that far too much time is wasted between two BoF sessions. With little or no discussion between sessions, a good portion of the meeting time is used to get on the same page (again). I consider this a good indicator that the work is not ready to bring to the IETF. Eric, you're probably assuming that discussion groups will automatically form around viable BOF proposals, and proceed in a reasonably organized way. That's certainly necessary for success. My feeling is that as the IETF expands its reach to more and more countries and time zones, it's become progressively harder for such self-organization to happen. I see Study Groups as a way to use IETF resources to support those discussion groups, instead of leaving them to self-organize. It seems reasonable to test out the idea, but it should certainly be made clear that SGs may flunk out. Yes, one of the possible outcomes of an SG may be documentation of the discussion and the conclusions in non-standards track documents and closure of the SG. regards, Lakshminath Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] draft-aboba-sg-experiment-02.txt
Hi Tobias, Many thanks for your review. Please see inline for my thoughts on your observations. On 10/1/2007 9:39 AM, Tobias Gondrom wrote: Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document described an RFC3933 experiment in forming a Study Group prior to Working Group formation. As such I agree with the authors that there are no additional specific security considerations as also discussed in RFC3933. Aside from the Security Review, I have three comments: 1. editorial comment to section 1: s/those who have no followed the/ those who have not followed the We'll fix this in the revision. 2. comment to section 2: Section 2 states that: If at any point, including after a first or second BoF session, ... the IESG MAY propose that a Study Group be formed. This sounds to me like partially conflicting with RFC2418, which clearly states that an absolute maximum of two BOFs are allowed for a topic. This would implicate that if a Study Group was formed after the second BOF, it would have to directly lead to a WG (or be abandoned) as it can not go back to BOF. I would propose to change this to that a Study Group may be initiated after the first BOF but not after the second to prevent this conflict. (The second BOF is already an extension and we should not add the Study Group as a second extension to the system. People should be pretty well prepared at a second BOF to get either a Yes or No -- and if they are not ready for a decision by then, another second extension may probably also not help.) My take is that after the SG it is a WG or nothing. The sponsoring and other ADs would have the opportunity to observe the SG in progress just as they would do a BoF and can assess whether to form a WG or not. With that clarification, does the current wording sound alright? So, proposal to change the line in section 2 accordingly: s/including after a first or second BoF session/including after a first BoF session I.e. if a first BOF does not lead to the anticipated results (WG: yes/no decision), the appropriate mechanism for the AD should be to decide whether s/he wants to use this experiment or run straight with the second BOF as defined in the process. With the study group the second BOF could be initiated after the Study Group has concluded if the AD does not want to go to WG directly without second BOF. 3. comment to section 3: In section 3 it is described that a study group shall have and run the same infrastructure identical to a WG. I would not agree with this suggestion, but think it should be limited to less than a WG. It is in fact less than a WG. More specifically, A Study Group charter MUST NOT include milestones relating to development of a protocol specification. was included to make it less than a WG. The limited lifetime is another constraint. The other processes are intentionally made similar so as to reuse our current operational structures. Does that clarification alleviate this concern? regards, Lakshminath Otherwise it might lead to false impressions, de-facto situations and also prolong the work of the study group to finally get a go for a WG, as they might consider this an already fully functional lightweight WG. Summary: I believe that this idea of a Study Group is a great idea that will add a new tool for the AD for the situation that a BOF has not been satisfactory preparing a WG formation. However I would suggest to make sure to keep a clear distinction between a WG and a study group, as they differ dramatically in the regard of role and acceptance by the IETF community. If they both look similar this might be misunderstood by people outside or new to the IETF. Greeting, Tobias ***__* *Tobias Gondrom* Head of Open Text Security Team Director, Product Security *Open Text* Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:[EMAIL PROTECTED] Internet: http://www.opentext.com/ Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Nomcom 2007-8: Nominations Close on Sep 10, 2007
WGchairs, IESG and IAB members Please forward this request to the lists you manage and request feedback and nominations. All, Here is the link to nominate: https://tools.ietf.org/group/nomcom/07/nominate You may also send nominations or comments via email to [EMAIL PROTECTED] or [EMAIL PROTECTED] We have received very few nominations (1, 2, 2, 2, 3, 4, 8, 8, 19) and even fewer accepted (1-2 people in each area, IAB acceptances is 4 at last count). I request the community to provide feedback on the incumbents (send email or send notes via the web page). 1) If you think that the incumbent is doing a good job a) provide feedback AND b) nominate similar people just in case there is strong negative feedback on the incumbent 2) If you think the incumbent can do somethings better a) provide feedback AND b) nominate someone who you think might do better Candidates, if time commitment is the only issue, please indicate that to the nomcom and accept the nominations. thanks, Lakshminath ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2007-8: Requirements for the Open IAOC Position
Folks, The following is the IAOC's desired expertise in the candidates for the open IAOC position. The nomcom is now accepting the community's input on the qualifications required for that position. Please send your notes, either as commentary on the following or independent notes to nomcom07 at ietf.org. Thank you. regards, Lakshminath Original Message Subject: Requirements for Open IAOC Position Date: Fri, 24 Aug 2007 12:05:38 -0400 From: IETF Executive Director [EMAIL PROTECTED] To: NomCom Chair [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Dear Lakshminath: Below is a description of the expertise desired in the candidate selected to fill the position of the IAOC member whose term will expire during the first IETF Meeting in 2008. Regards, Barbara -- This note outlines the expertise and duties for a member of the IETF Administrative Oversight Committee (IAOC). The structure of the IETF Administrative Support Activity (IASA) is described and regulated in BCP101. BCP101 defines the IASA as The IETF Administrative Support Activity (IASA) provides the administrative structure required to support the IETF standards process and to support the IETF's technical activities. As of the time at which this document was written, this included the work of IETF working groups, the IESG, the IAB, and the IRTF. Should the IETF standards process at some future date come to include other technical activities, the IAOC is responsible for developing plans to provide administrative support for them. Such support includes, as appropriate, undertaking or contracting for the work described in [RFC3716], including IETF document and data management, IETF meetings, and any operational agreements or contracts with the RFC Editor and the Internet Assigned Numbers Authority (IANA). The IASA is also ultimately responsible for the financial activities associated with IETF administrative support, such as collecting IETF meeting fees, paying invoices, managing budgets and financial accounts, and so forth. The IASA is responsible for ensuring that the IETF's administrative needs are met, and met well. The IETF does not expect the IASA to undertake the bulk of this work directly; rather, the IETF expects the IASA to contract this work from others and to manage these contractual relationships to achieve efficiency, transparency, and cost effectiveness. The IASA is distinct from IETF-related technical functions, such as the RFC Editor, the IANA, and the IETF standards process itself. The IASA has no influence on the technical decisions of the IETF or on the technical contents of IETF work. Note, however, that this in no way prevents people who form part of the IASA from participating as individuals in IETF technical activities. The exact mechanics of how the IAOC operates and governs are further described in BCP101. Besides providing the above mentioned operational support for the IETF together with and through the IAD, the members of the IAOC as well as the IAD serves as Trustees of the IETF Trusts, that holds the IETFs intellectual property assets, for example in the form of copyrights to the RFCs, the name IETF, logo etc. BCP101 in paragraph 3.2 defines the role of the IAOC as The IAOC's role is to provide appropriate direction to the IAD, to review the IAD's regular reports, and to oversee IASA functions to ensure that the administrative needs of the IETF community are being properly met. The IAOC's mission is not to be engaged in the day- to-day administrative work of the IASA, but rather to provide appropriate direction, oversight, and approval. Therefore, the IAOC's responsibilities are as follows: o To select the IAD and to provide high-level review and direction for his or her work. This task should be handled by a sub- committee, as described above. o To review the IAD's plans and contracts to ensure that they will meet the administrative needs of the IETF. o To track whether the IASA functions are meeting the IETF community's administrative needs, and to work with the IAD to determine a plan for corrective action if they are not. o To review the IAD's budget proposals to ensure that they will meet the IETF's needs, and to review the IAD's regular financial reports. o To ensure that the IASA is run in a transparent and accountable manner. Although the day-to-day work should be delegated to the IAD and others, the IAOC is responsible for ensuring that IASA finances and operational status are tracked appropriately, and that monthly, quarterly, and annual financial and operational reports are published to the IETF community. o To designate, in consultation with the IAB and the IESG, the person or
Nomcom 2007-8: Candidate Questionnaires Posted on the Nomcom website
Folks, The Candidate Questionnaires are now posted on the nomcom website https://www3.tools.ietf.org/group/nomcom/07/questionnaire. If you are a candidate and have accepted the nomination, please respond to the questionnaire by Sep 17, 2007. Please send a note to me ([EMAIL PROTECTED]) saying that you have accepted the nomination as soon as possible, however. We are accepting nominations until Sep 10, 2007. Please nominate and soon so as to give sufficient time to candidates to fill in the questionnaires. thanks, Lakshminath ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Meeting the requirements of a BCP
Sam, You said the following on BCPs on the EMU list recently. (The context is irrelevant, I think, but please feel free to bring in the context if you deem it necessary.) I'd like to understand whether we can meet all the requirements of that BCP For some reason that sounded odd to me, specifically I wondered what in the words best current practice resonates with requirements. So I went and read 2026 and the operative word there is guidelines. So, I am curious about why you think BCPs can state requirements that other RFCs should try to meet. The best I can come up with is that a BCP can record the then IETF consensus on a particular procedure or mode of operation. Further, the BCP process is to be used as an outlet to propose ideas to stimulate work or raise the community's sensitivity to a certain issue and so on. But it doesn't appear that these things can be hard and fast requirements. I am probably misunderstanding the notion of BCPs and welcome education :). Thanks. regards, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Nomcom 2007-8: Nominations Close on Sep 10, 2007 (Full Timeline is now Published)
Please nominate your favorite candidates to the IESG, IAB and IAOC at https://tools.ietf.org/group/nomcom/07/nominate before Sep 10, 2007. Instructions are available at https://tools.ietf.org/group/nomcom/07/. Self-nominations are permitted. Nomcom timeline is now available at https://tools.ietf.org/group/nomcom/07/ regards, Lakshminath ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: e2e
I guess I'll jump in as well. I was reading some of the related papers recently for a different reason including the ones on active networks (thank gods they are history) and whether that concept is in line with the e2e philosophy. In any event, exploring one of your examples with the concepts in the paper in mind (perhaps I am using a verbatim application of the concepts) that the network may filter some (and that being the keyword) malware or suspicious traffic based on certain parameters is fine; but the point is that in the end, an application may have to determine what it accepts as legitimate traffic based on its own criteria. Email junk filtering comes to mind as an example. Trying to map that to one of the statements from the paper: For the data communication system to go out of its way to be an extraordinary filter does not reduce the burden on the application program to filter as well. In some sense it does reduce it, i.e., for most apps or users, the functionality provided by the network may be sufficient, but we get the idea. Entities in the data communication system :), say the mail servers, do some filtering, but different email applications utilize different techniques to get the job done and some are adaptive based on user input etc. I know there are efforts to do more and more in the mail servers, but the email applications are also getting more sophisticated over time. Your point is well taken of course that there are no cut and dried rules. For instance, I am not fully in tune with the arguments on security (secure data encapsulation to be more precise) in the paper. The paper says that data will be in the clear and thus vulnerable as it passes into the target node and is fanned out to the target application. Third, the authenticity of the message must still be checked by the application. That goes to the extent of saying that end-node to end-node protection is not sufficient and that the data must really protected all the way at the application layer. I might in other contexts make the argument for security properties that do belong in the application layer (non repudiation comes to mind for instance), but there are security properties that we'd get through network layer security that we might not really get through application layer security. I am also not sure I understand the thing about the authenticity of the message having to be checked by the application (do they mean that the data is vulnerable and that's why?). I am also curious if some of this has to do with multi-user systems being popular back then. Now that sounds like a rant ;). regards, Lakshminath On 8/14/2007 2:21 PM, Fred Baker wrote: On Jul 26, 2007, at 8:47 PM, Hallam-Baker, Phillip wrote: I don't think that I am misrepresenting the paper when I summarize it as saying 'keep the complexity out of the network core' I'm slogging through some old email, and choose to pick up on this. Following Noel's rant (which is well written and highly correct), it is not well summarized that way. For example, quoting from the paper, Performing a function at a low level may be more efficient, if the function can be performed with a minimum perturbation of the machinery already included in the low-level subsystem. So, for example, while we generally want retransmissions to run end to end, in an 802.11 network there is a clear benefit that can be gained at low cost in the RTS/CTS and retransmission behaviors of that system. My precis would be: in deciding where functionality should be placed, do so in the simplest, cheapest, and most reliable manner when considered in the context of the entire network. That is usually close to the edge. Let's take a very specific algorithm. In the IP Internet, we do routing - BGP, OSPF, etc ad nauseum. Routing, as anyone who has spent much time with it will confirm, can be complex and results in large amounts of state maintained in the core. There are alternatives to doing one's routing in the core; consider IEEE 802.5 Source Routing for an example that occurred (occurs?) in thankfully-limited scopes. We could broadcast DNS requests throughout the Internet with trace-route-and-record options and have the target system reply using the generated source route. Or not... Sometimes, there is a clear case for complexity in the network, and state. Let me mention also a different consideration, related to business and operational impact. Various kinds of malware wander around the network. One can often identify them by the way that they find new targets to attack - they probe for them using ARP scans, address scans, and port scans. We have some fairly simple approaches to using this against them, such as configuring a tunnel to a honeypot on some subset of the addresses on each LAN in our network (a so-called grey net), or announcing the address or domain name of our honeypot in a web page that we expect to be
Nomcom 2007-8: Call for Nominations
Nomcom 2007-8 is accepting nominations. Please visit the following page for details: https://www3.tools.ietf.org/group/nomcom/07/ You may also send nominations to [EMAIL PROTECTED] thanks, Lakshminath ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2007-8: Members of the Committee
Folks, The following randomly selected volunteers have kindly accepted to serve as voting members of the Nomcom 2007-8: Simon Leinen Christopher Boulton Dan Wing Derek Atkins Steven Blake Ian Chakeres Thomas Walsh Attila Takacs Ole Jacobsen Craig White The non-voting members are: Lakshminath Dondeti (Chair) Andrew Lange (Advisor) Danny McPherson (IAB Liaison) Lars Eggert (IESG Liaison) Fred Baker (ISOC Liaison) The Nomcom can be reached at [EMAIL PROTECTED] The members of the committee are available for discussions during the Chicago meeting. The Nomcom office is PDR1. The office may not always be open due to the confidential nature of nomcom meetings. Please schedule an appointment. The voting members have been very accommodating in clearing up their calendars for nomcom business on a very short notice. The non voting members have been helping me ensure that all the things that needed to be done before the Chicago meeting have been done. Thanks everyone. Please talk to the nomcom members at the Chicago meeting and thank them for their service to the IETF. best regards, Lakshminath Nomcom 2007-8 Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2007-8: IAB Job Description
Folks, RFC 3777 says the following about the qualifications required for open IESG/IAB positions: The IESG and IAB are responsible for providing summary of the expertise desired of the candidates selected for their respective open positions to the Executive Director. The summaries are provided to the nominating committee for its consideration. 2. The nominating committee selects candidates based on its understanding of the IETF community's consensus of the qualifications required and advises each confirming body of its respective candidates. The following is the information provided by the IAB to the nomcom. The nomcom is now accepting the community's input on the qualifications required for the open IAB positions. Please send your notes, either as commentary on the following or independent notes to [EMAIL PROTECTED] Thank you. best regards, Lakshminath IAB Job Description The IAB Role The IAB is a chartered activity that works as a group within the IETF. The IAB acts as a source of advice and guidance concerning technical, architectural, and procedural matters pertaining to the Internet and its enabling technologies for the IETF and its associated organizations. 1.1 Architectural role The IAB develops and documents architectural insight for the Internet. It provides architectural input into IETF technical activities as well as sponsoring and organizing work in the IRTF. The IAB acts as a source of advice and guidance concerning technical, architectural, and procedural matters pertaining to the Internet and its enabling technologies. Finally, The IAB also has several procedural roles to support the operation of the IETF including being the formal channel for liaisons to the IETF. In terms of its architectural role, the IAB provides oversight of aspects of the architecture for the protocols and technical specifications as developed by the IETF as well as providing oversight for activities in the IRTF. While the IAB does draw on specific expertise as required, it is expected that the sum of the expertise of IAB members encompasses a broad range of technologies under IETF and IRTF study, and also encompasses a broad range of perspectives on these specifications, from research and academic study through development, deployment and operational experience. A major role of the IAB is to take a broad and long range perspective to offer input into the planning and coordination between different areas of IETF and IRTF activity. The IAB, both collectively and on an individual basis, is expected to pay attention to important long-term issues in the Internet, and to make sure that these issues are brought to the attention of the groups that are in a position to address them. As needed, the IAB works with ISOC to provide advice and guidance to the Board of Trustees and Officers of the Internet Society on technical, architectural, procedural, and (where appropriate) policy matters pertaining to the Internet and its enabling technologies. 1.2 Organizational role The IAB has some roles within the organizational functioning of the IETF. The IAB serves as an appeal board for complaints of improper execution of the standards process through acting as an appeal body in respect of an IESG standards decision. Besides, the IAB has formal roles such as being responsible for the RFC Editor function, providing direction for the administration of the IETF's protocol parameters registries, and being responsible for the IETF's interests in the area of liaison with other organizations that undertake activities that overlap or intersect with the IETF's activities. The IAB selects a chair of the Internet Research Task Force (IRTF) for a renewable two year term, and exercises an oversight role for the IRTF. Procedurally, the IAB has a role in the IETF Nominations Committee process. The IAB confirms the IETF Chair and the Area Directors. Besides, the IAB appoints a member of the IAOC and hears appeals on matters related to the IAOC and IAD. The IAB is the formal channel for liaisons between the IETF and other organizations that undertake activities that overlap or intersect with the IETF's activities including other standards development organizations. The IAB appoints liaison managers and deals with liaison matters of an architectural or general procedural nature. The IAB also appoints a member of the ICANN board to represent the IETF's interests within ICANN. 2. IAB Member Qualities It is not the case that all IAB members have matching attributes, qualifications and perspectives. Indeed the IAB is perhaps most effective when the group is composed of a diverse set of individuals with a broad range of qualities and perspectives. It is an advantage for the IAB when some number of IAB members have had technical leadership experience, operational management backgrounds, research backgrounds and implementation experience. However, the IAB also
Requirements for Open IESG Positions
RFC 3777 says the following about the qualifications required for open IESG/IAB positions: The IESG and IAB are responsible for providing summary of the expertise desired of the candidates selected for their respective open positions to the Executive Director. The summaries are provided to the nominating committee for its consideration. 2. The nominating committee selects candidates based on its understanding of the IETF community's consensus of the qualifications required and advises each confirming body of its respective candidates. The following is the information provided by the IESG to the nomcom. The nomcom is now accepting the community's input on the qualifications required for the open IESG positions. Please send your notes, either as commentary on the following or independent notes to [EMAIL PROTECTED] Thank you. best regards, Lakshminath This note describes the expertise desired in the candidates selected to fill the positions of the IESG members whose terms will expire during the first IETF Meeting in 2008. Under the Nominations Committee (NomCom) procedures defined in RFC 3777, the IESG is responsible for providing a summary of the expertise desired of the candidates selected for open IESG positions. This information is included below, and is suitable for publication to the community, along with the NomCom request for nominations. We realize that this is a long list of demanding qualifications, and that no one person will be able meet all of the requirements for a specific position. We trust that the NomCom will weigh all of these qualifications and choose IESG members who represent the best possible balance of these qualifications. GENERIC REQUIREMENTS IESG members are the managers of the IETF standards process. They they must understand the way the IETF works, be good at working with other people, be able to inspire and encourage other people to work together as volunteers, and have sound technical judgment about IETF technology and its relationship to technology developed elsewhere. Area Directors (ADs) select and directly manage the Working Group (WG) chairs, so IESG members should possess sufficient interpersonal and management skills to manage 15 to 30 part-time people. Most ADs are also responsible for one or more directorate or review teams. The ability to identify good leaders and technical experts, and then recruit them for IETF work is important. Having been a WG chair helps understand the WG chair role, and it will help when trying to resolve problems and issues that a WG chair may have. In addition, all IESG members should have strong technical expertise that crosses two or three IETF areas. Ideally, an IESG member would have made significant technical contributions in more than one IETF area, preferably authoring documents and/or chairing WGs in more than one area. (ADs are expected to personally review every Internet-Draft that they sponsor. For other Internet-Drafts, ADs must be satisified that adequate review has taken place.) It is very helpful for an IESG member to have a good working knowledge of the IETF document process and WG creation and chartering process. This knowledge is most likely to be found in experienced IETF WG chairs, but may also be found in authors of multiple documents. IESG members must also have strong verbal and written communications skills. They must have a proven track record of leading and contributing to the consensus of diverse groups. IESG members must deal with many technical topics, so a strong technical background is required, but an IESG members should also have strong management and communication skills. An IESG member should guide WGs to follow their charters and nurture new talent to fulfil IETF leadership roles in the future. A FEW COMMENTS ON THE IESG ROLE Serving on the IESG requires a substantial time commitment. The basic IESG activities consume between 25 and 40 hours per week (varying by area and by month, with the most time required immediately before IETF meetings). Most IESG members also participate in additional IETF leadership activities, further increasing the time commitment for those individuals. Even if they do not occupy formal liaison positions, ADs may also need to interact with external bodies such as other standards development organizations (SDOs), which may require travel. It is also imperative that IESG members attend all IETF meetings (typically arriving one or two days early) and attend one, and sometimes two, IESG retreats per year. Because of the large time and travel commitments, employer support for a full two year term is essential. Because of personal impact, including awkwardly timed conference calls, an IESG member's family must also be supportive. APPLICATIONS AREA The Applications Area has historically focused on three clusters of protocols. The first cluster contains application protocols
Nomcom 2007-8 will be collecting community input at the Chicago meeting
Folks, One of the first activities for the nomcom is to determine the IETF community's consensus of the qualifications required for each of the open positions (listed in https://datatracker.ietf.org/ann/nomcom/1234/). Nomcom 2007-8 will be collecting input from the community at the Chicago meeting. Please find one of the nomcom members (wearing an orange dot) at the meeting and share your thoughts. If you prefer to schedule an appointment, we can arrange that. Please respond to this email (reply only) or send a request to [EMAIL PROTECTED] We will make all efforts to accommodate your requests (on a first come first serve basis, based on availability). The nomcom office is PDR1. Of course, anyone is welcome to send input and feedback to the nomcom, [EMAIL PROTECTED], at any time during the selection process. thanks, Lakshminath Nomcom 2007-8 Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2007-8 Selection Results (Challenge Period closes on July 21, 2007 7:30 AM US ET)
Folks, Below are the results from the random selection for Nomcom 2007-8. As per our process, in the next few days, I will contact each of the members to verify their willingness and availability to serve. Please verify the results, and if anything is amiss you have until 7:30 AM US ET on July 21, 2007 to challenge the results (Please see RFC 3777 for applicable rules). Many thanks to the 108 people for volunteering. best regards, Lakshminath 57. Simon Leinen SWITCH 12. Christopher BoultonUbiquity Software Corporation 105. Dan Wing Cisco 5. Derek AtkinsPGP Corportation 11. Steven Blake Ericsson 18. Ian Chakeres Motorola 99. Thomas Walsh Juniper Networks 93. Attila Takacs Ericsson 43. Ole Jacobsen Cisco Systems 102. Craig White Juniper Networks [EMAIL PROTECTED]:~/Standards/IETF/Nomcom-07 ./nomcom-selection Type size of pool: (or 'exit' to exit) 108 Type number of items to be selected: (or 'exit' to exit) 20 Approximately 71.4 bits of entropy needed. Type #1 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 9 13 15 31 48 3 6 3 6 9 13 15 31 48 Type #2 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 61636147 61636147 Type #3 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 95231775 95231775 Type #4 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 7 39 41 48 53 21 7 21 39 41 48 53 Type #5 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. end Key is: 3.6.9.13.15.31.48./61636147./95231775./7.21.39.41.48.53./ indexhex value of MD5div selected 1 FDCBF106D7836E374F03324FF333F0EC 108 - 57 - 2 B0844A9C4293B2E69DFB592CA08F43CF 107 - 12 - 3 36AA36AB8964DD2AA40980AB1061F666 106 - 105 - 4 7489B8237D96521121FE5DE53F2ABCEC 105 - 5 - 5 8716278D7FA5B8A7E93E6480D0F72C19 104 - 11 - 6 7B2765CE61E3C56D81DB862C5E08193F 103 - 18 - 7 7AEDD1607FF2BD83C8B7DCC14E1CE803 102 - 99 - 8 2E892BC7D60C6C887FAC5B46EFA97EEB 101 - 93 - 9 DEEE51756F6E0C77C3DA9C0319A56E06 100 - 43 - 10 E7D25BCF9C3BC17BB130253402472102 99 - 102 - 11 1511321D49DF2C855836E76E50E25FAD 98 - 40 - 12 69D2C4891D880AC56B83A196AEA20ED2 97 - 14 - 13 0D430EFAA0F903B072A90CE659D5504B 96 - 84 - 14 BD9221D191A4121642FE4D44342349F1 95 - 28 - 15 25F3C973D35487DEA561BBF3CDA004BF 94 - 79 - 16 7EC9050953822AC45E4C1EEDB4A33653 93 - 60 - 17 A137F116C80DAE5165DC20C391937B89 92 - 72 - 18 E9B6A44665805A3ED3EB843181BDF126 91 - 75 - 19 D88B3ECCAC2B27301C6D77AEF1C06DA5 90 - 78 - 20 23ABD04F1F71FDB044177AF60A646027 89 - 89 - Done, type any character to exit. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2007-8: Ordered List of Volunteers and Date and Method of Random Selection
We have 108 (please see Note1 below) eligible volunteers this year. Many thanks to all of you for volunteering. Below is the sorted (by last name) list of volunteers. The numbering is final. Date of Random Selection: July 13, 2007. Method of Random Selection: RFC 3797 (Randomness sources are listed toward the end of the message). List of volunteers: 1. Bernard Aboba Microsoft 2. Alain Patrick Aina AfriNIC 3. Zafar Ali Cisco Systems 4. Chandra Appanna Cisco 5. Derek AtkinsPGP Corportation 6. Alia Atlas Google 7. Gabor Bajko Nokia 8. Mary Barnes Nortel 9. Richard Barnes BBN Technologies 10. Lou Berger LabN Consulting 11. Steven Blake Ericsson 12. Christopher BoultonUbiquity Software Corporation 13. Marcelo Bagnulo Braun Huawei Labs at UC3M 14. Scott Brim Cisco Systems 15. Stewart Bryant Cisco Systems 16. John Jason Brzozowski Comcast 17. Eric BurgerBEA Systems, Inc. 18. Ian Chakeres Motorola 19. Kwok Ho Chan Nortel 20. Tim Chown University of Southampton 21. Dave CROCKER Brandenburg InternetWorking 22. Spencer DawkinsHuawei Technologies 23. Hui Deng Hitachi 24. Vijay Devarapalli Azaire Networks 25. Keith DrageAlcatel-Lucent 26. John Drake Boeing Satellite Systems 27. Donald Eastlake 3rdMotorola 28. Don Fedyk Nortel Networks 29. Bill FennerATT Labs - Research 30. Miguel A. Garcia Nokia Siemens Networks 31. Randall GellensQualcomm 32. Dorothy GellertNokia 33. Gerardo Giaretta Qualcomm 34. Eric Gray Ericsson 35. Wassim Haddad Ericsson Research 36. Joel M. HalpernIndependent Consultant 37. Stephen Hanna Juniper Networks, Inc. 38. Jani HautakorpiEricsson 39. Bernie Hoeneisen SWITCH 40. Paul Hoffman VPN Consortium Cybersecurity Association 41. Avshalom Houri IBM 42. Markus Isomaki Nokia 43. Ole Jacobsen Cisco Systems 44. Joel Jaeegli Nokia 45. Robert Jaksa Huawei 46. Ed Jankiewicz SRI International 47. Ingemar Johansson Ericsson AB 48. Petri Jokela Ericsson 49. Stephen Kent BBN Technologies 50. Sohel Khan Comcast Cable Communications 51. Atif Khan Juniper Networks 52. T.J. Kniveton Nokia 53. Suresh KrishnanEricsson Research 54. Kari Laihonen TeliaSonera 55. Eliot Lear Cisco Systems GmbH 56. Yiu LeeComcast Cable 57. Simon Leinen SWITCH 58. Henrik Levkowetz Ericsson 59. Dan Li Huawei Technologies 60. Marco Liebsch NEC 61. Salvatore Loreto Ericsson 62. John Loughney Nokia 63. AC Mahendran QUALCOMM 64. Jukka MJ MannerUniversity of Helsinki 65. Xavier Marjou France Telecom 66. Enrico Marocco Telecom Italia 67. Luca Martini Cisco 68. David MeyerUniversity of Oregon/Cisco Systems 69. Brian Minard Certicom Corp. 70. Stephen Nadas Ericsson 71. Thomas D. Nadeau Cisco Systems, Inc. 72. Madjid NakhjiriHuawei USA 73. An Nguyen National Communications System (NCS) 74. Pekka Nikander Ericsson Research Nomadic Lab 75. Oscar Novo Ericsson 76. Karen O'Donoghue NSWCDD (US Navy) 77. Hamid Ould-Brahim Nortel 78. dimitri papadimitriou alcatel-lucent bell 79. Tom Phelan Sonus Networks 80. Juergen QuittekNEC 81. Yakov Rekhter Juniper Networks 82. Pete Resnick QUALCOMM 83. Michael Richardson Xelerance Corporation 84. Pasi Sarolahti Nokia 85. Benson Schliesser Savvis 86. Christian Schmidt Nokia Siemens Networks 87. Thomas Schmidt HAW Hamburg 88. John Scudder Juniper Networks 89. Martin Stiemerling NEC 90. Shinta Sugimoto(Nippon)Ericsson K.K. 91. Andrew SullivanAfilias Canada 92. George Swallow Cisco Systems 93. Attila Takacs Ericsson 94. Tina TSOU
Re: Nomcom 2007-8: Randomness Sources for review
Following up on this thread, if there are any objections to the randomness sources at this time (after taking my clarifications into consideration), please do let me know. I need to finalize this before the deadline tomorrow to stick to the timeline. thanks, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Nomcom 2007-8: Randomness Sources for review
Thanks Suresh. regards, Lakshminath (Speaking as nomcom chair in this thread) On 7/5/2007 8:27 AM, Suresh Krishnan wrote: Hi Lakshminath, In light of your clarifications, I have no further objections. Thanks Suresh Lakshminath Dondeti wrote: Following up on this thread, if there are any objections to the randomness sources at this time (after taking my clarifications into consideration), please do let me know. I need to finalize this before the deadline tomorrow to stick to the timeline. thanks, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Nomcom 2007-8: Final list of volunteers
Folks, If you have volunteered for Nomcom 2007-8, you should find your name and affiliation in the list below. If your name is missing, please let me know ASAP (email me and also please call and leave a voice mail with the information). I have, with the help of the secretariat (many thanks to them for timely assistance) and the volunteers themselves, verified eligibility of all the people below. If you think any of them are ineligible, please let me know. It is important, but as yet not as critical as missing names, if any. There are provisions to remove ineligible people later on in the process (there are no sitting IESG, IAB, and IASA members and ISOC Board members in the list to my knowledge). Please note that the publication of the Ordered list and Selection process is still pending. I shall do that soon (please see the timeline). thanks, Lakshminath Nomcom 2007-8 Chair +1 858.845.1267 Eric Gray Ericsson Bill FennerATT Labs - Research Kurt Zeilenga Isode Spencer DawkinsHuawei Technologies Henk UijterwaalRIPE NCC Kari Laihonen TeliaSonera dimitri papadimitriou alcatel-lucent bell Miguel A. Garcia Nokia Siemens Networks Christian Schmidt Nokia Siemens Networks Tina TSOU Huawei Technologies. Co. Ltd Simon Leinen SWITCH Tom Phelan Sonus Networks John Drake Boeing Satellite Systems Henrik Levkowetz Ericsson Paul Hoffman VPN Consortium Cybersecurity Association Eliot Lear Cisco Systems GmbH Robert Jaksa Huawei Olle ViktorssonEricsson David MeyerUniversity of Oregon/Cisco Systems Mary BarnesNortel Richard Barnes BBN Technologies JP Vasseur Cisco Systems Pekka Nikander Ericsson Research Nomadic Lab Stephen Kent BBN Technologies Vijay Devarapalli Azaire Networks Shinta Sugimoto(Nippon )Ericsson K.K. Pete Resnick QUALCOMM Samuel Weiler SPARTA Enrico Marocco Telecom Italia Christopher BoultonUbiquity Software Corporation Suresh KrishnanEricsson Research Stephen Hanna Juniper Networks, Inc. Wassim Haddad Ericsson Research Marcelo Bagnulo Braun Huawei Labs at UC3M Karen O'Donoghue NSWCDD (US Navy) Zafar Ali Cisco Systems Thomas D. Nadeau Cisco Systems, Inc. Ole Jacobsen Cisco Systems Attila Takacs Ericsson Lou Berger LabN Consulting Derek Atkins PGP Corportation Chandra AppannaCisco Dan Wing Cisco Donald Eastlake 3rdMotorola Luca Martini Cisco Randall GellensQualcomm Jani HautakorpiEricsson Joel M. HalpernIndependent Consultant Petri Jokela Ericsson Oscar Novo Ericsson Salvatore Loreto Ericsson Don Fedyk Nortel Networks Bernard Aboba Microsoft Keith DrageAlcatel-Lucent Yi ZhaoHuawei Technologies Stephan Wenger Nokia AC Mahendran QUALCOMM Stewart Bryant Cisco Systems John Jason Brzozowski Comcast Markus Isomaki Nokia Yakov Rekhter Juniper Networks Steven Blake Ericsson Eric BurgerBEA Systems, Inc. Gabor BajkoNokia Joel Jaeegli Nokia Avshalom Houri IBM Sohel Khan Comcast Cable Communications Hamid Ould-Brahim Nortel Ingemar Johansson Ericsson AB Bernie Hoeneisen SWITCH Martin Stiemerling NEC Xavier Marjou France Telecom Carl Williams Huawei USA Yiu LeeComcast Cable Dan Li Huawei Technologies Thomas Schmidt HAW Hamburg Stephen Nadas Ericsson Andrew Newton SunRocket, Inc. Juergen QuittekNEC Dave CROCKER Brandenburg InternetWorking Scott Brim Cisco Systems Dorothy GellertNokia Hui Deng Hitachi Matthias Waehlisch HAW Hamburg link-lab An Nguyen National Communications System (NCS) Ian Chakeres Motorola John Scudder Juniper Networks Alia Atlas Google Madjid NakhjiriHuawei USA Marco Liebsch
Re: Nomcom 2007-8: Randomness Sources for review
Thanks Suresh. Good question. My intention is to enter the numbers as I included in my email (and as they are published by the various sources). The source code in 3797 includes a sorting algorithm and that takes care of the randomness algorithm requirements; there is also an example in that RFC. If you are interested, please run the algorithm against the sample input; I can do the same and we can compare results (but that is not necessary though). thanks, Lakshminath On 7/4/2007 10:57 AM, Suresh Krishnan wrote: Hi Lakshminath, I think these sources are reasonable. I just require some clarification about the lottery numbers. From your examples, it was not clear to me how the lottery numbers will be entered as inputs to the 3797 algorithm. The algorithm recommends that the numbers be sorted in some order. Your example for Euromillions was =We input 11 16 17 22 34 5 6 This is not sorted in any order. Do you consider the star numbers to be different sources? Is the input order specified like this * normal numbers in ascending order followed by the stars in ascending order It would be nice to clarify this while announcing the sources. Cheers Suresh ** NOTE:(Original mail sent only to [EMAIL PROTECTED] Responding to ietf@ietf.org since the ietf announce list is moderated.) ORIGINAL MAIL Folks, As per the announced timeline (https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1231), which is 3777-compliant, the method of random selection was to be announced on July 6, 2007. I am presenting it earlier for your review. In the past few cycles, nomcom chairs have used Wall Street's trading volumes as the sources of randomness to RFC 3797 random selection process. However, I don't currently subscribe to the Wall Street Journal :) and besides RFC 3797 suggests that stock prices and/or volumes are a poor source of unambiguous data anyway, so I chose the following randomness sources; please review them and let me know if there are objections. The following dates assume that I can actually publish the list of volunteers on July 6th 2007 (as of today that has a high likelihood). 1. EuroMillions Fri July 13, 2007 Results: http://www.national-lottery.co.uk/player/p/results/results.do All 7 numbers (5 numbers from 1 - 50 and 2 Lucky Stars from 1 - 9) Results available online around 10 PM UK time. e.g., Fri Jun, 22 07 results 11 16 17 22 34 05 06 We input 11 16 17 22 34 5 6 2. US National debt (Debt Held by the Public), published by the Treasury department as of July 12, 2007 (Published on July 13, 2007) The system is updated daily with the previous day's data. The update typically takes place around 3:00 pm EDT. That according to -Will Web Development Branch Bureau of the Public Debt http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods from the Debt Held by the Public e.g., Fri June 22, 2007 4,950,586,161,721.14 We select 16172114 3. US National debt (Intragovernmental Holdings), published by the Treasury department as of July 12, 2007 (Published on July 13, 2007) http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods from the Intragovernmental Holdings e.g., Fri June 22, 20073,852,643,882,285.79 We select 88228579 4. Lottery again, Megamillions http://www.megamillions.com/winningpicks/last_25.asp All 6 numbers (including the Mega Ball) from the drawing on July 13, 2007 (at 11:00 pm US Eastern time). e.g., Fri June 22, 2007 result 11, 14, 21, 24, 31, 23 We input 11 14 21 24 31 23 All the inputs are to RFC 3797 selection algorithm. There is source code in that RFC and an example. regards, Lakshminath Nomcom 2007-8 Chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Nomcom 2007-8: Randomness Sources for review
Thanks Ole. You bring up a good point. I have taken it into consideration before selecting the randomness sources. Lottery results are archived for obvious reasons. It turns out the US Treasury department makes the archive since 1993 available. The archives are available at the following locations for time-delayed verifiability: http://www.national-lottery.co.uk/player/p/results/resultsHistory/resultsHistoryAction.do http://www.treasurydirect.gov/NP/BPDLogin?application=np http://www.megamillions.com/winningpicks/last_25.asp best, Lakshminath On 7/4/2007 11:42 AM, Ole Jacobsen wrote: I was under the impression that the use of WSJ data was adopted because it is easily verifiable and reproducable, after all there exists a PRINTED copy of the newspaper for any given day. I am not sure you could reproduce the national debt (for example) at a given point in time if someone disputed the result and wanted to run the algorithm themselves. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Nomcom 2007-8 Announcement: Timeline-Part 1 (Correction)
Folks, Please note the following correction to the Timeline posted on June 4th. The current plan is to send the call for nominations soon after the IETF meeting in Chicago. Aug 3, 2007 Send Call for nominations... Aug 3, 2007 Announce milestones and post Timeline-Part 2 before ... Aug 17, 2007 best regards, Lakshminath Nomcom 2007-8 Chair - Send call for nominations andAug 31, 2007 Announce milestones (Timeline-Part 2) best regards, Lakshminath ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2007-8: Final Call for Volunteers (Deadline: July 5, 2007 at 12:00 Noon ET, 16:00 UTC/GMT)
Folks, This is the final call for volunteers, the deadline for volunteering is July 5, 2007 at 12:00 Noon ET, 16:00 UTC/GMT. Please see https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1251 for details on how to volunteer and which positions are up for consideration at the moment. If you have already volunteered, your name should be below and you should have received an email saying that you are eligible (or you received a note saying that you are not eligible). thanks and regards, Lakshminath Nomcom 2007-8 Chair + Eric Gray Ericsson Bill FennerATT Labs - Research Kurt Zeilenga Isode Spencer DawkinsHuawei Technologies Henk UijterwaalRIPE NCC Kari Laihonen TeliaSonera dimitri papadimitriou alcatel-lucent bell Miguel A. Garcia Nokia Siemens Networks Christian Schmidt Nokia Siemens Networks Tina TSOU Huawei Technologies. Co. Ltd Simon Leinen SWITCH Tom Phelan Sonus Networks John Drake Boeing Satellite Systems Henrik Levkowetz Ericsson Paul Hoffman VPN Consortium Cybersecurity Association Eliot Lear Cisco Systems GmbH Robert Jaksa Huawei Olle ViktorssonEricsson David MeyerUniversity of Oregon/Cisco Systems Mary BarnesNortel Richard Barnes BBN Technologies JP Vasseur Cisco Systems Pekka Nikander Ericsson Research Nomadic Lab Stephen Kent BBN Technologies Vijay Devarapalli Azaire Networks Shinta Sugimoto(Nippon )Ericsson K.K. Pete Resnick QUALCOMM Samuel Weiler SPARTA Enrico Marocco Telecom Italia Christopher BoultonUbiquity Software Corporation Suresh KrishnanEricsson Research Stephen Hanna Juniper Networks, Inc. Wassim Haddad Ericsson Research Marcelo Bagnulo Braun Huawei Labs at UC3M Karen O'Donoghue NSWCDD (US Navy) Zafar Ali Cisco Systems Thomas D. Nadeau Cisco Systems, Inc. Ole Jacobsen Cisco Systems Attila Takacs Ericsson Lou Berger LabN Consulting Derek Atkins PGP Corportation Chandra AppannaCisco Dan Wing Cisco Donald Eastlake 3rdMotorola Luca Martini Cisco Randall GellensQualcomm Jani HautakorpiEricsson Joel M. HalpernIndependent Consultant Petri Jokela Ericsson Oscar Novo Ericsson Salvatore Loreto Ericsson Don Fedyk Nortel Networks Bernard Aboba Microsoft Keith DrageAlcatel-Lucent Yi ZhaoHuawei Technologies Stephan Wenger Nokia AC Mahendran QUALCOMM Stewart Bryant Cisco Systems John Jason Brzozowski Comcast Markus Isomaki Nokia Yakov Rekhter Juniper Networks Steven Blake Ericsson Eric BurgerBEA Systems, Inc. Gabor BajkoNokia Joel Jaeegli Nokia Avshalom Houri IBM Sohel Khan Comcast Cable Communications Hamid Ould-Brahim Nortel Ingemar Johansson Ericsson AB Bernie Hoeneisen SWITCH Martin Stiemerling NEC Xavier Marjou France Telecom Carl Williams Huawei USA Yiu LeeComcast Cable Dan Li Huawei Technologies Thomas Schmidt HAW Hamburg Stephen Nadas Ericsson Andrew Newton SunRocket, Inc. Juergen QuittekNEC Dave CROCKER Brandenburg InternetWorking Scott Brim Cisco Systems Dorothy GellertNokia Hui Deng Hitachi Matthias Waehlisch HAW Hamburg link-lab An Nguyen National Communications System (NCS) Ian Chakeres Motorola John Scudder Juniper Networks Alia Atlas Google Madjid NakhjiriHuawei USA Marco Liebsch NEC Benson Schliesser Savvis Craig WhiteJuniper Networks Jukka MJ MannerUniversity of Helsinki Andrew SullivanAfilias Canada Gerardo Giaretta Qualcomm Kwok Ho Chan Nortel ___ IETF-Announce mailing list
Nomcom 2007-8: Randomness Sources for review
Folks, As per the announced timeline (https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1231), which is 3777-compliant, the method of random selection was to be announced on July 6, 2007. I am presenting it earlier for your review. In the past few cycles, nomcom chairs have used Wall Street's trading volumes as the sources of randomness to RFC 3797 random selection process. However, I don't currently subscribe to the Wall Street Journal :) and besides RFC 3797 suggests that stock prices and/or volumes are a poor source of unambiguous data anyway, so I chose the following randomness sources; please review them and let me know if there are objections. The following dates assume that I can actually publish the list of volunteers on July 6th 2007 (as of today that has a high likelihood). 1. EuroMillions Fri July 13, 2007 Results: http://www.national-lottery.co.uk/player/p/results/results.do All 7 numbers (5 numbers from 1 - 50 and 2 Lucky Stars from 1 - 9) Results available online around 10 PM UK time. e.g., Fri Jun, 22 07 results 11 16 17 22 34 05 06 We input 11 16 17 22 34 5 6 2. US National debt (Debt Held by the Public), published by the Treasury department as of July 12, 2007 (Published on July 13, 2007) The system is updated daily with the previous day's data. The update typically takes place around 3:00 pm EDT. That according to -Will Web Development Branch Bureau of the Public Debt http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods from the Debt Held by the Public e.g., Fri June 22, 2007 4,950,586,161,721.14 We select 16172114 3. US National debt (Intragovernmental Holdings), published by the Treasury department as of July 12, 2007 (Published on July 13, 2007) http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods from the Intragovernmental Holdings e.g., Fri June 22, 20073,852,643,882,285.79 We select 88228579 4. Lottery again, Megamillions http://www.megamillions.com/winningpicks/last_25.asp All 6 numbers (including the Mega Ball) from the drawing on July 13, 2007 (at 11:00 pm US Eastern time). e.g., Fri June 22, 2007 result 11, 14, 21, 24, 31, 23 We input 11 14 21 24 31 23 All the inputs are to RFC 3797 selection algorithm. There is source code in that RFC and an example. regards, Lakshminath Nomcom 2007-8 Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2007-8: Second Call for Volunteers (Deadline: July 5, 2007 at 12:00 Noon ET, 16:00 UTC/GMT)
Folks, This is the Second Call for Volunteers. If you have attended 3 out of the past 5 IETF meetings, you are eligible to serve on Nomcom 2007-2008. Please volunteer and you may become one of the voting members of the committee that selects about half of the members to the IESG and IAB and one IAOC member. RFC 3777 describes the process and the responsibilities in detail. Below is the list of people from the IESG, IAB and IAOC whose terms end during the March 2008 IETF meeting. IAOC: Ed Juskevicius IAB: Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman David Oran Eric Rescorla IESG: Lisa Dusseault -- Applications Area Director Jari Arkko -- Internet Area Director Dan Romascanu -- Operations and Management Area Director Cullen Jennings -- Real-time Applications and Infrastructure Area Director Ross Callon --- Routing Area Director Sam Hartman -- Security Area Director Magnus Westerlund -- Transport Area Director Before volunteering, please think about whether you want to be considered for one of those positions instead. If you are already convinced, please send an email before 12:00 noon ET (16:00 UTC/GMT) on July 5, 2007 (otherwise, please read on) To: [EMAIL PROTECTED] Subject: Nomcom 2007-8 Volunteer Body: Your Full Name // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation // typically what goes in the Company field // in the IETF Registration Form [all email addresses used to Register for the past 5 IETF meetings] Preferred email address // Telephone number // For confirmation if selected Please expect an email response from me within 1-2 days stating whether you are qualified or not. If you don't receive anything, please re-send your email with the tag (duplicate) in the subject line. Not convinced yet? Please consider that nomcom members play an important role in shaping the leadership of the IETF. If you are a people person, you will enjoy meeting many of the active contributors to the IETF. If you prefer instead to read a lot of email, well, we have that too. Being a nomcom member is also an important responsibility: it requires adherence to confidentiality rules and some time commitment from the members. The term begins just prior to the Chicago meeting and we expect most of the work to be completed by January 2008. During this period, the nomcom members -- collect requirements from the community and interviews candidates during the Chicago and Vancouver IETF meetings -- review candidates' statements and weighs community feedback -- participate in candidate selection deliberations (weekly conferences calls) Nomcom members are selected following a publicly verifiable random selection method specified in RFC 3797. For the nomcom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. So please volunteer! thanks, Lakshminath ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2007-8: Interim list of volunteers
Folks, If you have volunteered for Nomcom 2007-8, you should find your name and affiliation in the (attached) list (below). If anything is amiss, please let me know. Thank you for volunteering. If you have not already done so, please volunteer now. See https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1234. thanks, Lakshminath Nomcom 2007-8 Chair Eric Gray Ericsson Bill FennerATT Labs - Research Kurt Zeilenga Isode Spencer DawkinsHuawei Technologies Henk UijterwaalRIPE NCC Kari Laihonen TeliaSonera dimitri papadimitriou alcatel-lucent bell Miguel A. Garcia Nokia Siemens Networks Christian Schmidt Nokia Siemens Networks Tina TSOU Huawei Technologies. Co. Ltd Simon Leinen SWITCH Tom Phelan Sonus Networks John Drake Boeing Satellite Systems Henrik Levkowetz Ericsson Paul Hoffman VPN Consortium Cybersecurity Association Eliot Lear Cisco Systems GmbH Robert Jaksa Huawei Olle ViktorssonEricsson David MeyerUniversity of Oregon/Cisco Systems Mary BarnesNortel Richard Barnes BBN Technologies JP Vasseur Cisco Systems Pekka Nikander Ericsson Research Nomadic Lab Stephen Kent BBN Technologies Vijay Devarapalli Azaire Networks Shinta Sugimoto(Nippon )Ericsson K.K. Pete Resnick QUALCOMM Samuel Weiler SPARTA Enrico Marocco Telecom Italia Christopher BoultonUbiquity Software Corporation Suresh KrishnanEricsson Research Stephen Hanna Juniper Networks, Inc. Wassim Haddad Ericsson Research Marcelo Bagnulo Braun Huawei Labs at UC3M Karen O'Donoghue NSWCDD (US Navy) Zafar Ali Cisco Systems Thomas D. Nadeau Cisco Systems, Inc. Ole Jacobsen Cisco Systems Attila Takacs Ericsson Lou Berger LabN Consulting Derek Atkins PGP Corportation Chandra AppannaCisco Dan Wing Cisco Donald Eastlake 3rdMotorola Luca Martini Cisco Randall GellensQualcomm Jani HautakorpiEricsson Joel M. HalpernIndependent Consultant Petri Jokela Ericsson Oscar Novo Ericsson Salvatore Loreto Ericsson Don Fedyk Nortel Networks Bernard Aboba Microsoft Keith DrageAlcatel-Lucent Yi ZhaoHuawei Technologies Stephan Wenger Nokia AC Mahendran QUALCOMM Stewart Bryant Cisco Systems John Jason Brzozowski Comcast Markus Isomaki Nokia Yakov Rekhter Juniper Networks Steven Blake Ericsson Eric BurgerBEA Systems, Inc. Gabor BajkoNokia Joel Jaeegli Nokia Avshalom Houri IBM Sohel Khan Comcast Cable Communications Hamid Ould-Brahim Nortel Ingemar Johansson Ericsson AB Bernie Hoeneisen SWITCH Martin Stiemerling NEC Xavier Marjou France Telecom Carl Williams Huawei USA Yiu LeeComcast Cable Dan Li Huawei Technologies Thomas Schmidt HAW Hamburg Stephen Nadas Ericsson Andrew Newton SunRocket, Inc. Juergen QuittekNEC Dave CROCKER Brandenburg InternetWorking Scott Brim Cisco Systems Dorothy GellertNokia Hui Deng Hitachi Matthias Waehlisch HAW Hamburg link-lab Mr. An Nguyen National Communications System (NCS) Ian Chakeres Motorola John Scudder Juniper Networks ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2007-8: Notes on Voting Member Time Commitment
Folks Some of you have asked for clarifications on the time commitments of voting members. BCP 10 has the details of the process and the role of the voting and non-voting members. Here are some notes for your quick reference on how it might be in practice: If all goes well with the selection process, the members begin their work at the Chicago IETF meeting. The plan is for the members to attend the Chicago and Vancouver IETF meetings to interview and/or gather feedback and input from the community, including people in leadership positions: WG and RG chairs, the IAOC, the IAB and the IESG. We can address exceptional circumstances on a case-by-case basis, but that is the general expectation. The Nomcom will then spend about a month (4-5 weeks) self-organizing. There will be 1-2 hrs per week of conference calls and BCP 10 as the reading assignment. As with anything IETF, there will be some email traffic too. Subsequent to that, the candidate selection phase begins which lasts about 4 months. During that phase there is a good amount of reading: especially candidate statements and community feedback. There will also be discussions and deliberations via 2 hrs per week of conference calls and email. That's under normal operating conditions. If there are interim openings, there will be slightly additional work. We (the entire nomcom) can make efforts to distribute the work evenly over that period of 5 months, so as to be as non-disruptive to our day jobs as possible. If you have any specific questions or requests for clarifications, please do not hesitate to contact me. thanks, Lakshminath Nomcom 2007-8 Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Reforming the BOF Process (was Declining the ifare bof for Chicago)
One of the things I have been doing and will continue to be doing is to bring work to the IETF that may be needed by other standards organizations and in some cases is needed by other organizations. I have done this or tried to do this in the AD sponsored route as an author and/or document shepherd as well as through the BoF process. I have had some successes and some failures. Here is a meta-issue from that experience. If a piece of work is proposed early, it may be dismissed in the category of who needs this? It is also difficult for proponents to communicate constraints specific to other organizations. Official communication channels are not possible since there may not be a work item. If it is brought just in time (the interest may be communicated via an official LS), the time constraints involved are hard on everyone. The consequence in either case is that people choose bad (in clear violation of an IETF BCP or RFC) alternatives in the other organizations with the simple reason of nothing better is available (from the IETF). The Study Group concept that Bernard proposes (with Dan's qualifications; I am sure we will IETFy it before it is all said and done) might be helpful in addressing the first category, i.e., bringing work early. As John notes it may introduce additional delay and that concerns me. Perhaps we should have the same evaluation process as now and the result of the process, if the proponents are also up for it could be a Study Group instead of go away. thanks, Lakshminath On 6/15/2007 3:53 AM, Jari Arkko wrote: Bernard, I think your proposal is worth thinking about. The current BOF process is very on/off in its nature. One of the problems that it is causing is that when work is not far enough, a BOF or WG cannot be established. This in turns leave the perception that the IETF is completely ignoring the topic. In reality, a denied WG/BOF might mean anything ranging from go away with your stupid idea to this is very important and interesting, but please do X first so that the WG can be chartered or BOF held. We try to give the right perception, of course, but sometimes its hard to convince people who can only observe the existence/non-existence of an official activity. Jari Romascanu, Dan (Dan) kirjoitti: */Bernard,/* *//* */Speaking as a participant in both the IETF and IEEE 802, there are many things that I like in the CFI / Study Group process of IEEE. Your proposal goes in the direction of solving one of the problems I perceive in the IETF processes which is the lack of repeatability and predictability (again speaking as a participant). I like it. Yet, there are some differences:/* *//* */- The five criteria in the IEEE would not apply as is. I am not sure that 'broad market potential' should be there at all, or should be as strong a factor as it is in the IEEE. Same with economic feasibility, which in the IEEE often refers to the costs of hardware based implementations/* */- 'Measuring interest' works differently in the IETF than in the IEEE which is very much physical participation based, and where participants and company votes are dully counted and registered in CFI meetings as proof of interest. /* *//* */Dan/* *//* *From:* Bernard Aboba [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, June 12, 2007 7:52 PM *To:* ietf@ietf.org *Subject:* Reforming the BOF Process (was Declining the ifare bof for Chicago) The recent discussion on the IFARE BOF has raised more fundamental issues about the IETF BOF process. Rather than letting discussion continue on the SAAG list, it would seem better for this discussion to occur on the IETF list. Speaking as a former AD, it can be a very tough call to say yes/no to a BOF. Unfortunately, there is often interest, but interest is most definitely not enough. There needs to be more than interest. It should be understood that this is a feature of the IETF process that is not necessarily held in common with other SDOs. For example, within IEEE 802 the initial meeting is termed a Call for Interest because the determination of interest is the major focus; writing a charter/PAR is not. Assuming that sufficient interest exists, a study group is formed, whose sole purpose is to write a Project Authorization Request (PAR) (equivalent of a charter), and demonstrate that the proposed work satisfies the 5 criteria: 1. Broad Market Potential a. Broad sets of applicability. b. Multiple vendors and numerous users. c. Balanced costs 2. Compatibility with existing standards. 3. Distinct Identity. 4. Technical feasibility a. Demonstrated system feasibility b. Proven technology, reasonable
