Re: Requirements for Open IESG Positions
Soininen == Soininen Jonne (NSN FI/Espoo) [EMAIL PROTECTED] writes: Soininen Hi, I just happened to read this mail today. I don't Soininen remember seeing such a mail during previous nomcom Soininen rounds (they might have come, but I just didn't notice Soininen them). I think this is a very good overview of the Soininen requirements needed for the IESG positions and gives a Soininen nice background to think about the people who would fit Soininen the positions. Soininen However, I think one of the areas is described a bit too Soininen much in detail and perhaps give a wrong impression about Soininen the job. The following extract is from the Security Soininen Area: Specific expertise required for a Security AD includes strong knowledge of IETF security protocols. To complement Tim Polk, the person selected as Security AD should have a working understanding of Kerberos, GSS-API, SASL, and how these relate to security protocols and to their use in applications and other security protocols. A basic understanding of IPsec, IKE, TLS, PKI would also be useful. Soininen I'm sure this is an oversight, but I think it is Soininen generally not according the IETF process to specific Soininen technologies and hard coding the division of work in Soininen an area. To my understanding, the Ads in an area are Soininen free to divide the work between themselves as they wish Soininen according their strengths. So, if the a possible new Soininen security AD would not be interested to look at these Soininen technologies, perhaps Tim would look at them - according Soininen the new division of work in the area. I tend to agree that this is not an ideal practice, but it has been going on for many years. The set of technologies listed there are things that I'm mostly doing these days with particular emphasis on things Tim doesn't have as much experience with. Last year, the description focused on areas Russ had the most experience in. It's kind of complicated to fix. If you stuck two security ads in with my experience or with Tim's experience it would not be ideal. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Requirements for Open IESG Positions
Done. At 06:29 PM 7/23/2007, Brian E Carpenter wrote: Also these descriptions have evolved from year to year (there is a version in the IESG wiki too, at http://www3.tools.ietf.org/group/iesg/trac/wiki/AreasDescription, maybe the IESG should bring it up to date...) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Streaming
On Jul 24, 2007, at 8:24 PM, Jeffrey Altman wrote: Joel Jaeggli wrote: The webpage for the streaming has been updated to reflect the schedule for monday and tuesday. http://videolab.uoregon.edu/events/ietf/ One addition is that we intend to record and broadcast the Sunday IEPG meeting located in the crystal ballroom from 1000-1200 CDT. Regards Joel Jaeggli This information really needs to be on the IETF69 Meeting page. its on the mainpage of the community wiki http://community.ietf.org/wiki/ regards ___ 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: Requirements for Open IESG Positions
Some additional comments on the topic: In particular, taking the security area requirements as an example, the description provided talks about expertise needed based on the current ongoing work in the security area. While this is one part, we want ADs that can bring in/ evaluate new work which may or may not be related to any of the ongoing work in the area. Especially in the security area, such relation to other work is very hard to predict. Personally, I don't think it is a requirement for an AD to have a deep understanding of all the protocols produced by the area; rather, for the security area, for example, I think it is important that the ADs are capable of analyzing threat models and evaulating the security implications of work happening in other areas, or have a sufficient security background to grasp issues raised by experts of a certain protocol, etc. I think it is much less important that the AD has a top-to-bottom understanding of TLS or Kerberos or IKEv2 or any one thing in particular. I provided this input last year as well and I think it is very important for us to select an area generalist as an AD over a specialist in a particular set of protocols. Vidya ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IAOC office hours
The IAOC will again be holding open office hours in Parlor A on Wednesday 16.00-17.00 Thursday 16.00-17.00 On behalf of the IAOC - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Requirements for Open IESG Positions
One important thing needs to be considered in the Security and OM Areas. There are two ADs, and they are expected to have somewhat different skill sets. For contrast, here are the requirements that were provided to NomCom2006 for these positions. Russ --- Operations Management Area: The primary technical areas covered by the Operations Management area include: Network Management, AAA, and various operational issues facing the Internet such as DNS operations, IPv6 operations, Routing operations. Unlike most IETF areas, the Operations Management area is logically divided into two separate functions: Network Management and Operations. David Kessens is currently responsible for the Operations portion of the OPS area, so specific expertise required for the open position would include a strong understanding of Internet operations, as well as the ability to step into Network Management issues when necessary. The Operations AD is largely responsible for soliciting operator feedback and input regarding IETF work. This is a challenging task that requires strong contacts in the operations community and a great deal of persistence. Another important role of the Operations AD is to identify potential or actual operational issues regarding IETF protocols and documents in all areas, and to work with the other areas to resolve those issues. This requires a strong understanding of how new and updated protocols may affect operations, and the ability to gather information from the operations community and translate that information into suggestions for protocol architecture and design within the IETF. It also requires a strong cross-area understanding of IETF protocol architecture and technologies. The Operations portion of the OPS area intersects most often with the Routing, Internet and Security areas. So, cross-area expertise in any of those areas would be particularly useful. --- Security Area: The WGs within the Security Area are primarily focused on security protocols. They provide one or more of the security services: integrity, authentication, non-repudiation, confidentiality, and access control. Since many of the security mechanisms needed to provide these security services are cryptographic, key management is also vital. Security ADs are expected to ensure that all IETF specifications are reviewed for adequate security coverage. They also manage a set of security resources that are available to most IETF areas and WGs. Specific expertise required for a Security AD would include a strong knowledge of IETF security protocols, particularly IPsec, IKE, and TLS, and a good working knowledge of security protocols and mechanisms that have been developed inside and outside the IETF, most notably including PKI. Also, a Security AD should understand how to weigh the security requirements of a protocol against operational and implementation requirements. We must be pragmatic; otherwise people will not implement and deploy the secure protocols that the IETF standardizes. The Security Area intersects with all other IETF areas, and its ADs are expected to read and understand the security implications of documents in all areas. So, broad knowledge of IETF technologies and the ability to assimilate new information quickly are imperative for a Security AD. At 02:44 PM 7/24/2007, Narayanan, Vidya wrote: Some additional comments on the topic: In particular, taking the security area requirements as an example, the description provided talks about expertise needed based on the current ongoing work in the security area. While this is one part, we want ADs that can bring in/ evaluate new work which may or may not be related to any of the ongoing work in the area. Especially in the security area, such relation to other work is very hard to predict. Personally, I don't think it is a requirement for an AD to have a deep understanding of all the protocols produced by the area; rather, for the security area, for example, I think it is important that the ADs are capable of analyzing threat models and evaulating the security implications of work happening in other areas, or have a sufficient security background to grasp issues raised by experts of a certain protocol, etc. I think it is much less important that the AD has a top-to-bottom understanding of TLS or Kerberos or IKEv2 or any one thing in particular. I provided this input last year as well and I think it is very important for us to select an area generalist as an AD over a specialist in a particular set of protocols. Vidya ___ 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: IETF Streaming
Marc Manthey wrote: On Jul 24, 2007, at 8:24 PM, Jeffrey Altman wrote: Joel Jaeggli wrote: The webpage for the streaming has been updated to reflect the schedule for monday and tuesday. http://videolab.uoregon.edu/events/ietf/ One addition is that we intend to record and broadcast the Sunday IEPG meeting located in the crystal ballroom from 1000-1200 CDT. Regards Joel Jaeggli This information really needs to be on the IETF69 Meeting page. its on the mainpage of the community wiki http://community.ietf.org/wiki/ and what good is that? The IETF69 Meeting web site is: http://www3.ietf.org/meetings/69-IETF.html Folks interested in the IETF meetings go to that page not the wiki to find out about the meetings. On that page is a section on Agenda and Presentations. In that section are links to the agenda, the meeting materials and the text conferencing. If I didn't know that there was audio streaming, how would I find out about it from the IETF69 meeting page? Why should I have to guess at looking at the Wiki for IETF 69 under the Tools and Ticketing section in order to determine that there is audio streaming? The link should be under the Agendas and Presentations. Even better would be links from the Meeting Agenda page to the audio streams, presentations, and Jabber rooms for the individual sessions. The current web site might be organizer friendly but it is not attendee friendly. smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Requirements for Open IESG Positions
Sam, Jonne, Its important to find the right balance between getting someone who fits exactly the current situation and getting someone who is the best candidate in a more long term view. The ADs in an area need to have an excellent understanding of the technology the area deals with. Typically, no one covers everything that we work in an area, so you end up wanting to have a pair that complements each other. Having said that, when a new BOF proposal comes in, you may learn that you suddenly need some new expertise. We also don't know how long the other AD in the pair continues to be in that position. Typically at least a year (given the cycles are on alternating years), but resignations and movements to other positions have been known to happen. And the two ADs can change how they divide the area between themselves. And there are different approaches to managing an area. Generalist vs. specialist, for instance. And you can use experts, directorates, etc. to help you in topics that you are not sufficiently good expert in. (I also thought that the SEC requirements were a bit too specific this year.) Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Streaming
I already have links to Agendas, Jabber-rooms, Meeting-materials, draft tarballs and room location on http://tools.ietf.org/agenda, so it seems like a good idea to add links to the audio streams, too (in addition to any mention which is added to the IETF69 Meeting page). seems to me that there should be a clear link on the meeting web page (http://www3.ietf.org/meetings/69-IETF.html) for both the audio and jabber services (unless the aim is to minimize use) Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Requirements for Open IESG Positions
Jari == Jari Arkko [EMAIL PROTECTED] writes: Jari (I also thought that the SEC requirements were a bit too Jari specific this year.) They are no more specific this year than they have been in the past. The only change is that they were at least specific in a direction that would actually compliment the sitting AD. I personally have never liked the way the security AD requirements were stated. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Requirements for Open IESG Positions
Sam, They are no more specific this year than they have been in the past. Ok -- I did not re-read the ones from past years. Just reacting on the current text. The only change is that they were at least specific in a direction that would actually compliment the sitting AD. That's fine. I personally have never liked the way the security AD requirements were stated. Hmm. Ok. Perhaps we should consider stating them in a better way then? Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Requirements for Open IESG Positions
Hi, I agree with Vidya. To be honest, I really thought this was an oversight and not intentional. If the Security area has a similar split as the OM area, I think this really should be discussed. To my understanding, we don't have such split documented to any other area and I think this kind of hard split should be discussed. Perhaps the split is right and I just wasn't aware of it. However, it seems other people were unaware of the split as well. BTW, are the explicit technologies Kerberos, GSS-API, and SASL representing the other half of the area. I'm asking, because I'm not a security expert and not active in the security area. Cheers, Jonne. On 7/25/07 1:12 AM, ext Narayanan, Vidya [EMAIL PROTECTED] wrote: I thought the requirements were too specific for the SEC area last year as well :) I do realize that the text has been largely reused from last year, but, I think we need to revisit some of these specific descriptions. We cannot expect the Nomcom to be familiar enough with all areas to use their judgment in addition to the requirements received. I think we need to get better at providing the requirements so that the Nomcom will really know what they are looking for in candidates. At the moment, I really think the SEC area requirements are misleading to the Nomcom and can use a revision. Vidya -Original Message- From: Russ Housley [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 2:01 PM To: Narayanan, Vidya Cc: ietf@ietf.org Subject: RE: Requirements for Open IESG Positions One important thing needs to be considered in the Security and OM Areas. There are two ADs, and they are expected to have somewhat different skill sets. For contrast, here are the requirements that were provided to NomCom2006 for these positions. Russ --- Operations Management Area: The primary technical areas covered by the Operations Management area include: Network Management, AAA, and various operational issues facing the Internet such as DNS operations, IPv6 operations, Routing operations. Unlike most IETF areas, the Operations Management area is logically divided into two separate functions: Network Management and Operations. David Kessens is currently responsible for the Operations portion of the OPS area, so specific expertise required for the open position would include a strong understanding of Internet operations, as well as the ability to step into Network Management issues when necessary. The Operations AD is largely responsible for soliciting operator feedback and input regarding IETF work. This is a challenging task that requires strong contacts in the operations community and a great deal of persistence. Another important role of the Operations AD is to identify potential or actual operational issues regarding IETF protocols and documents in all areas, and to work with the other areas to resolve those issues. This requires a strong understanding of how new and updated protocols may affect operations, and the ability to gather information from the operations community and translate that information into suggestions for protocol architecture and design within the IETF. It also requires a strong cross-area understanding of IETF protocol architecture and technologies. The Operations portion of the OPS area intersects most often with the Routing, Internet and Security areas. So, cross-area expertise in any of those areas would be particularly useful. --- Security Area: The WGs within the Security Area are primarily focused on security protocols. They provide one or more of the security services: integrity, authentication, non-repudiation, confidentiality, and access control. Since many of the security mechanisms needed to provide these security services are cryptographic, key management is also vital. Security ADs are expected to ensure that all IETF specifications are reviewed for adequate security coverage. They also manage a set of security resources that are available to most IETF areas and WGs. Specific expertise required for a Security AD would include a strong knowledge of IETF security protocols, particularly IPsec, IKE, and TLS, and a good working knowledge of security protocols and mechanisms that have been developed inside and outside the IETF, most notably including PKI. Also, a Security AD should understand how to weigh the security requirements of a protocol against operational and implementation requirements. We must be pragmatic; otherwise people will not implement and deploy the secure protocols that the IETF standardizes. The Security Area intersects with all other IETF areas, and its ADs are expected to read and understand the security implications of documents in all areas. So, broad knowledge of IETF technologies and the ability to assimilate new information
REVISED: WG Review: Recharter of Kerberos (krb-wg)
A modified charter has been submitted for the Kerberos (krb-wg) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list ([EMAIL PROTECTED]) by July 31. +++ Kerberos (krb-wg) === Current Status: Active Working Group Chair(s): Jeffrey Hutzelman jhutz at cmu.edu Larry Zhu lzhu at windows.microsoft.com Security Area Director(s): Tim Polk tim.polk at nist.gov Sam Hartman hartmans-ietf at mit.edu Security Area Advisor Sam Hartman hartmans-ietf at mit.edu Mailing Lists: General Discussion: ietf-krb-wg at anl.gov To Subscribe: majordomo at anl.gov In Body: subscribe ietf-krb-wg your_email_address Archive: ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/ Description of Working Group: Kerberos over the years has been ported to virtually every operating system. There are at least two open source versions, with numerous commercial versions based on these and other proprietary implementations. Kerberos evolution has continued in recent years, with the development of a new crypto framework, publication of a new version of the Kerberos specification, support for initial authentication using public keys, and numerous extensions developed in and out of the IETF. However, wider deployment and advances in technology bring with them both new challenges and new opportunities, particularly with regard to making initial authentication of users to the Kerberos system both convenient and secure. In addition, several key features remain undefined. The Kerberos Working Group will continue to improve the core Kerberos specification, develop extensions to address new needs and technologies related to improving the process of client authentication, and produce specifications for missing functionality. Specifically, the Working Group will: * Complete existing work: - ECC for PKINIT (draft-zhu-pkinit-ecc-03.txt) - Set/Change Password (draft-ietf-krb-wg-kerberos-set-passwd-05.txt) - Naming Constraints (draft-ietf-krb-wg-naming-02.txt) - Anonymity (draft-ietf-krb-wg-anon-03.txt) - Hash agility for GSS-KRB5 (draft-ietf-krb-wg-gss-cb-hash-agility-00.txt) - Hash agility for PKINIT (draft-ietf-krb-wg-pkinit-alg-agility-01.txt) - Referrals (draft-ietf-krb-wg-kerberos-referrals-08.txt) * Prepare and advance a specification for an updated, backward-compatible version of the Kerberos version 5 protocol which supports non-ASCII principal and realm names, salt strings, and passwords; insures that those portions of the protocol which are not encrypted are nonetheless authenticated whenever possible; and enables future protocol revisions and extensions. * Develop extensions which reduce or eliminate exposure of Kerberos clients' long-term keys to attack and enable the use of alternate mechanisms for initial authentication. This task will comprise the following items: - A model and framework for preauthentication mechanisms - A mechanism for providing a protected channel for carrying preauthentication data and/or a reply key between a Kerberos client and KDC, within the KDC_REQ/KDC_REP exchange. - Support for One-Time Passwords - Support for hardware authentication tokens - Support for using TLS to secure communications with Kerberos KDCs. * Examine issues related to the current cross-realm model, produce a list of problems to be solved, and evaluate approaches to solving them. * Develop extensions to Kerberos and a GSS-API mechanism (IAKERB) to enable Kerberos clients to communicate with a KDC by using a GSS-API acceptor as a proxy. * Produce a data model for information needed by the KDC, and an LDAP schema for management of that data. Goals and Milestones: --DONE-- TCP Extensibility to IESG JUL 2007 ECC for PKINIT to IESG JUL 2007 Set/Change Password to IESG JUL 2007 Naming Constraints to IESG JUL 2007 Anonymity to IESG JUL 2007 Hash agility for GSS-KRB5 to IESG JUL 2007 Hash agility for PKINIT to IESG JUL 2007 WGLC on STARTTLS JUL 2007 WGLC on Referrals AUG 2007 WGLC on data model AUG 2007 Choose direction for Kerberos v5.3 SEP 2007 WGLC on preauth framework SEP 2007 WGLC on cross-realm issues NOV 2007 WGLC on OTP NOV 2007 WGLC on hardware preauth MAR 2008 WGLC on Kerberos v5.3 MAR 2008 WGLC on IAKERB MAR 2008 WGLC on LDAP schema ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The Atom Publishing Protocol' to Proposed Standard
The IESG has approved the following document: - 'The Atom Publishing Protocol ' draft-ietf-atompub-protocol-17.txt as a Proposed Standard This document is the product of the Atom Publishing Format and Protocol Working Group. The IESG contact persons are Lisa Dusseault and Chris Newman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-17.txt Technical Summary The Atom Publishing Protocol HTTP-based protocol for publishing and editing web resources, and is particularly useful for (but not limited to) blogs. It supports ideas such as collections of multimedia items and categorization of items. It uses the Atom format (RFC 4287) for its messages. Working Group Summary The document went through many revisions and was discussed actively. Protocol Quality There are already many implementations of the spec from a wide variety of vendors, and many of those have been shown to interoperate. Lisa Dusseault reviewed this for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
