Re: Diversity of IETF Leadership
On 19/03/2013 12:59, Margaret Wasserman wrote: On Mar 12, 2013, at 2:24 PM, Dan Harkins dhark...@lounge.org wrote: I'd love to get out of this rat hole. Perhaps the signatories of the open letter can restate the problem they see so it isn't made in terms of race and gender. The letter specifically mentioned the axes of race, gender, geographic location and corporate affiliation, so the letter was not only about race and gender. Other people have mentioned other pertinent axes in the e-mail discussion, such as industry segment and background/experience. I don't think it is possible for remove race and gender from the list of axes, though, since there is a notable lack of diversity in those areas. Margaret As I pointed out on an earlier thread, the relevant EU policy body, which I assume has a lot of expertise on this, defines the following protected characteristics, i.e. characteristics that you are NOT permitted to discriminate on in the EU: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. Stewart
Re: Diversity of IETF Leadership
On 03/19/2013 11:04 PM, Stewart Bryant wrote: Margret this is the IETF, it regularly sets aside law to create its own lies about what it is and is not capable of in a legal context - but that is all about to change I think... Todd On 19/03/2013 12:59, Margaret Wasserman wrote: On Mar 12, 2013, at 2:24 PM, Dan Harkins dhark...@lounge.org wrote: I'd love to get out of this rat hole. Perhaps the signatories of the open letter can restate the problem they see so it isn't made in terms of race and gender. The letter specifically mentioned the axes of race, gender, geographic location and corporate affiliation, so the letter was not only about race and gender. Other people have mentioned other pertinent axes in the e-mail discussion, such as industry segment and background/experience. I don't think it is possible for remove race and gender from the list of axes, though, since there is a notable lack of diversity in those areas. Margaret As I pointed out on an earlier thread, the relevant EU policy body, which I assume has a lot of expertise on this, defines the following protected characteristics, i.e. characteristics that you are NOT permitted to discriminate on in the EU: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. Stewart
RE: Getting rid of the dot
There's always some excuse as to why multi-homing is never done properly. On 03/19/13 20:38, Michael Richardson allegedly wrote: Actually, I'd just settle for a badge that wasn't always backwards. It costs a lot more to get lanyards that attach at two corners.
Re: Getting rid of the dot
On 19 Mar 2013 22:47, Ole Jacobsen o...@cisco.com wrote: I can just see the list of MUST, SHOULD and MAY have attributes, Tsk. RFC 2119 only applies to interoperability requirements, as you well know. So unless we're also swapping t-shirts...
Re: Getting rid of the dot
I agree with Brian. IETF has no king. If the badge said that somebody is a chair, it may imply that there has a king. dot is better ! Jiankang Yao - Original Message - From: Brian E Carpenter brian.e.carpen...@gmail.com To: Carsten Bormann c...@tzi.org Cc: ietf@ietf.org Sent: Tuesday, March 19, 2013 4:05 PM Subject: Re: Getting rid of the dot On 18/03/2013 22:10, Carsten Bormann wrote: I wouldn't mind replacing my blue dot with an indication *what* WG I chair, and in which area that is. Might be a bit more logistics when chairs change, but nothing that can't be solved with a DYMO labelmaker. I can only speak for myself, but I find badges hard enough to take in at a glance even with the current amount of dot clutter. I don't think that adding more detail is wise, and I think the notion that dot = knows what's going on is simple and useful, even without decoding the colour. Heresy: I'm *not* convinced that putting labels on newcomers is such a good idea, because it has exactly the opposite implication to a dot of any colour. Brian
Re: Mentoring
On 20/03/2013 01:23, Spencer Dawkins wrote: On 3/19/2013 8:01 PM, Ben Campbell wrote: I think this means we should closely consider the goals of a mentoring effort. Is it to help them navigate the IETF structure, personalities, and immune system to get something done? Is it to help them become the next generation of IETF leaders? I suspect those two goals do not lend themselves to the same approach. Yeah, I agree with Ben here. I'd go further and suggest that helping people get something done is a good thing, and at least some of the people who have gotten something done are more likely to to hang around, but if people want to be part of the next generation of IETF leadership without actually getting something done first, encouraging them may not take the IETF to a happy place. Correct, we wish to convert successful participants into long-term participants and future leaders, and the first step is converting new participants into successful participants [RFC4144]. However, I think an important part of that is ensuring that people do *not* focus exclusively on a specific target, even if they are busy people as Ben said. Brian
Re: [IAB] WCIT slides
Hi Arturo, Good points that you have made. However, I would like to just sharpen some of the things. There are many governments that do not understand how the Internet works. Well, there are a lot of people even in the IETF that might not really know how Internet works, and even bigger number outside the IETF. However, there is a growing number of government that does understand this at least on some level. This is due to the years of work that different people, and organizations (including ISOC, RIRs, ICANN, etc) that have put a lot of effort into this locally and internationally. So, there is proof even governments can be educated... ;) Therefore, that work has to continue, as you say, in all levels including technical and political. The I* organizations have to pull together to make this happen, and have done it already for a while. However, new people and new insight for the work is needed, always. Cheers, Jonne. On 3/19/13 10:32 PM, Arturo Servin arturo.ser...@gmail.com wrote: As I mentioned in the mic during the IAB-sponsored Discussion of WCIT, during the week I had the opportunity to talk and interact to some of the policy fellows invited by ISOC (in general were people from the national regulator or from the ministry of telecommunications -AFAIK-). I also had the opportunity (along with Marcelo Bagnulo) to have breakfast with them and to present a summary of the Internet ecosystem and its complexities. From my experience during the week and the IAB-sponsored Discussion of WCIT I have this comments that I said I was going to share in the list: - It seems that there is not much understanding for governments in how the Internet ecosystem works. - Governments believe (or believed) that ITU is/was the common place to discuss and try to resolve Internet matters. - The Internet is an open entity with many organizations interacting with each other and the relationships among them may be very complex. We need to communicate this to governments and help them to interact with all the Internet-stake-holders. - Everyone has a place and a role in the Internet open model. Even governments. We need to let them play, help them to find their place, teach them the rules of the game and avoid to step in each others feet (I used the example of an RIR standardizing protocols or the IETF trying to mandate national laws) - To solve many of the today's Internet problems requires interaction at several layers (technical, policy, government and the separation between them is very blur) and between a diverse set of actors. It requires communication and coordination among all parties. - The communication and dialogue has to be a common effort. Today it is not enough to say that the IETF or the X forum is open to everybody. Being open is a must, the next step is going out and create communication channels, not wait for them. - The Internet does not have a common API for governments and it may never have one. Local APIs do not exists or are complex. [1] - As technical community we need to inform governments which technological solutions we already have. This minimize or eliminate their desire to re-invent the wheel in closed forums or create pseudo-standards that contradict ours. I think that is all. I hope it helps for future discussion about the topic. Regards, as [1] I borrowed the idea of the Government API from John Curran. On 3/15/13 10:57 AM, Joel M. Halpern wrote: With apologies for the problems making these slides available, and thanks to Bernard for finding a work-around, for now the slides are available via links from http://www.iab.org/2013/03/14/wcit-what-happened-whats-next/ Yours, Joel M. Halpern Original Message Subject: Re: [IAB] WCIT slides Date: Fri, 15 Mar 2013 13:40:04 + From: Bernard Aboba bernard.ab...@gmail.com I have created a blog entry on the IAB website that points to the slides, agenda and session recording: http://www.iab.org/2013/03/14/wcit-what-happened-whats-next/
Re: [IPFIX] Last Call: draft-ietf-ipfix-flow-selection-tech-14.txt (Flow Selection Techniques) to Proposed Standard
Dear authors, While reviewing draft-ietf-ipfix-mediation-protocol, Rahul got some feedback that actually concerns draft-ietf-ipfix-flow-selection-tech. Can you please take this into account. Regards, Benoit Few comments. 1. Page 8: 1. The difference between Intermediate Selection Process and Intermediate Flow Selection Process is not clear. Is the first one selecting record purely on matching content (value of the fields) in the record and the second one selecting on matching attributes of the fields that are not part of the record in *addition* to matching content in the record? An example would help here. BC Granted, this is difficult to understand from the definitions only. There is some history behind these two separate definitions. Anyway, you get it right from your message above. I was thinking to add to a section 2.1 Differences between Intermediate Selection Process and Intermediate Flow Selection Process in the draft-ietf-ipfix-mediation-protocol draft. However, thinking about it some more, this section should really be done in draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion. There is already section 3. Difference between Intermediate Flow Selection Process and Packet Selection. Some more text should be added on the difference between Intermediate Selection Process and Intermediate Flow Selection Process When created, draft-ietf-ipfix-mediation-protocol will refer to that new section. 1. 1. Also in the example e.g., Filteringonly records from a given network to a given Collector - Does given network means source-ip/source-prefix of the exporter?. BC It means matching the flow records to a certain prefix/AS/you-name-it, and exporting those matched flow records to an exporter. See for example, section 6.1 in RFC 6183 This could be explained better in the new section in draft-ietf-ipfix-flow-selection-tech (See previous point) The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Flow Selection Techniques' draft-ietf-ipfix-flow-selection-tech-14.txt as 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 2013-04-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1540/ ___ IPFIX mailing list ip...@ietf.org https://www.ietf.org/mailman/listinfo/ipfix
Re: [IETF] back by popular demand - a DNS calculator
On 21 Feb 2013, at 02:46, Carlos M. martinez carlosm3...@gmail.commailto:carlosm3...@gmail.com wrote: Wasn't the 'evil bit' able to hold the value 2 ? Use all evil bits for IP addresses and we'll soon have no need for IPv6. Geoff Huston and I wrote a draft to use the evil bit to indicate the presence of IPv4 NATs. It could be used as a tie-breaker for Happy Eyeballs. It's expired, though. http://tools.ietf.org/html/draft-bellis-behave-natpresent-00 Ray
Re: Diversity of IETF Leadership
Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. I am not suggesting that we start collecting or publishing this information, just saying that it makes it hard to tell whether our leadership is reasonably representative of the community in some of these areas. Also, I think there are some area where diversity is important to the IETF that are not on this list, like geographic location, corporate affiliation and industry segment (vendor, operator, researcher, etc.). Margaret
Re: Diversity of IETF Leadership
On 20/03/2013 10:53, Margaret Wasserman wrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. I am not suggesting that we start collecting or publishing this information, just saying that it makes it hard to tell whether our leadership is reasonably representative of the community in some of these areas. Also, I think there are some area where diversity is important to the IETF that are not on this list, like geographic location, corporate affiliation and industry segment (vendor, operator, researcher, etc.). Margaret . There are methods of anonymously determining the profile of the IETF in the above terms, but to preserve the anonymity of such information, and understand its statistical significance this should probably be gathered by a specialist organization outside the IETF but on our behalf. The extended list needs further review and consideration. For example, perhaps we should take a leaf from the IEEE and consider who funds work items rather than simply use current affiliation as we do today. This makes things more transparent both at the corporate and the consulting level. Stewart
Re: Diversity of IETF Leadership
Let's not play Internet lawyers about this. How Jari's design team bring in real lawyers at the appropriate time?
Re: Diversity of IETF Leadership
On Wed, Mar 20, 2013 at 11:53 AM, Margaret Wasserman m...@lilacglade.orgwrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. I am not suggesting that we start collecting or publishing this information, just saying that it makes it hard to tell whether our leadership is reasonably representative of the community in some of these areas. I would say that in this case we are almost surely automatically fair: while one can suspect that gender or geographical origin could add a bias (even an unwanted one), if I do not know the, say, sexual orientation of a candidate, I cannot discriminate (even on a subconscious level) using that information. Also, I think there are some area where diversity is important to the IETF that are not on this list, like geographic location, corporate affiliation and industry segment (vendor, operator, researcher, etc.). Margaret
Re: Diversity of IETF Leadership
Margaret Wasserman wrote: On Mar 12, 2013, at 2:24 PM, Dan Harkins dhark...@lounge.org wrote: I'd love to get out of this rat hole. Perhaps the signatories of the open letter can restate the problem they see so it isn't made in terms of race and gender. The letter specifically mentioned the axes of race, gender, geographic location and corporate affiliation, so the letter was not only about race and gender. Other people have mentioned other pertinent axes in the e-mail discussion, such as industry segment and background/experience. I don't think it is possible for remove race and gender from the list of axes, though, since there is a notable lack of diversity in those areas. The monetary and time resources necessary to fill an I* position adequately appear quite significant to me, and I believe it would be hard to fill them without strong support from an employer which covers the monetary investment. Any lack of diversity in the IESG/IAB/IAOC of the IETF leadership is IMHO related to the lack of interest in longterm planning in the majority of management of large companies--those which can reasonably expect to still be around and still sell products in some area a few years into the future. -Martin
Re: Diversity of IETF Leadership
On Wed, Mar 20, 2013 at 5:40 PM, Riccardo Bernardini framefri...@gmail.comwrote: if I do not know the, say, sexual orientation of a candidate, I cannot discriminate (even on a subconscious level) using that information. Hi Riccardo, I hope you are not suggesting candidates to remain in closet, to not be discriminated? :D Dhruv
www.rfc-editor.org and www.ietf.org TCP window scaling
Hello. As far as I can tell, www.rfc-editor.org doesn't support TCP window scaling. It also doesn't support ftp on its IPv6 address: swmike@uplift:~$ telnet -4 www.rfc-editor.org 21 Trying 64.170.98.47... Connected to rfc-editor.org. Escape character is '^]'. 220 FTP Server Ready quit 221 Goodbye. Connection closed by foreign host. swmike@uplift:~$ telnet -6 www.rfc-editor.org 21 Trying 2001:1890:126c::1:2f... telnet: Unable to connect to remote host: Connection refused 14:00:38.045593 IP (tos 0x10, ttl 64, id 33826, offset 0, flags [DF], proto TCP (6), length 60) xxx.xxx.xxx.xxx.36300 64.170.98.47.21: Flags [SEW], cksum 0xc541 (correct), seq 1822128746, win 5840, options [mss 1460,sackOK,TS val 3080584776 ecr 0,nop,wscale 7], length 0 14:00:38.224653 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto TCP (6), length 56) 64.170.98.41.21 xxx.xxx.xxx.xxx.36300: Flags [S.], cksum 0x9c17 (correct), seq 831902177, ack 1822128747, win 5792, options [mss 1460,sackOK,TS val 332539598 ecr 3080584776], length 0 I get 124 kilobyte/s when I download ftp://ftp.rfc-editor.org/in-notes/tar/RFC-all.tar.gz. That seems quite slow by todays standards. Since I have 179ms delay, it doesn't really hit me as indicating 16 or 32 kilobyte window size, but somewhere in between. www.ietf.org doesn't seem to support TCP window scaling either: 13:58:13.565917 IP xxx.xxx.xxx.xxx.41603 12.22.58.30.80: Flags [SEW], seq 3844537042, win 5840, options [mss 1460,sackOK,TS val 3080548657 ecr 0,nop,wscale 7], length 0 13:58:13.746501 IP 12.22.58.30.80 xxx.xxx.xxx.xxx.41603: Flags [S.], seq 4206253981, ack 3844537043, win 5792, options [mss 1460,sackOK,TS val 357513706 ecr 3080548657], length 0 Any specific reason for this? My host connects with wscale 7. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Diversity of IETF Leadership
--On Wednesday, March 20, 2013 06:53 -0400 Margaret Wasserman m...@lilacglade.org wrote: ... I am not suggesting that we start collecting or publishing this information, just saying that it makes it hard to tell whether our leadership is reasonably representative of the community in some of these areas. Also, I think there are some area where diversity is important to the IETF that are not on this list, like geographic location, corporate affiliation and industry segment (vendor, operator, researcher, etc.). Margaret, While I am very much in favor of a more diverse IETF population and leadership, the above, especially when combined with Martin Rex's later comment, is part of the reason why I see the problem as terribly difficult and not yielding easily to petitions, design teams, instructions to confirming bodies (particularly problematic as other discussions have shown), or good intentions. As a specific example, I think the IETF would be considerably strengthened by more diversity in corporate affiliations and industry segments as you suggest above. As with gender diversity, my impression is that we are getting more homogeneous rather than more diverse. One of the problems is time commitment and associated costs. For many corporations, most startups, and a significant fraction of actual individual participants, service in leadership positions is feasible only if those positions are really part-time and significant attention is paid to either cost containment or spreading marginal costs around the community. Yet the IESG (and, to a slightly lesser extent, the IAB) have tended to assign more and more work and responsibility to themselves, If we want more diversity along corporate, role, and related economic axes, we need (as others have pointed out) to shrink the jobs. In the IESG's case, that may require reducing the number of WGs we think we can operate in parallel. Unfortunately, there are many reasons to continue to _expand_ the jobs: on a point basis, it will always be easier to add tasks to existing leaders than to consider whether those tasks are really necessary, to consider sunsetting other tasks, or to organize and manage alternate ways to get them done. It also isn't clear that the community cares: I note that the recent effort to allow the IAB and IESG to appoint people other than the Chairs to serve on the IAOC/Trust, and an earlier one to separate the IAOC and the Trust, went exactly nowhere. On the other hand, if we are serious, I think it needs to be something that Nomcoms are committed (preferably without more rules) to enforce by asking candidates their positions on job-shrinking and by retiring incumbents who contribute to job-expansion. Those expansions are perhaps also influenced by the observation that, if the incumbents have the time and support for an expanded role, such expansion doesn't seem to be harmful. That is part of a classic example of why already-homogeneous organizations tend to become even more homogeneous, at leat in the absence of disruptive changes. best, john
Re: Mentoring
On Mar 20, 2013, at 3:09 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: However, I think an important part of that is ensuring that people do *not* focus exclusively on a specific target, even if they are busy people as Ben said. Change the sense of ensuring to encouraging, and I agree. But as worded, that sounds a lot like making it harder for someone to focus on the work they are interested in. I think that's more likely to make people stop coming than making them generalize their work.
Re: Diversity of IETF Leadership
I would suggest John that the real diversity the IETF needs is transparency in its process and a competent IPR rule set which meets the same set of legal hurdles people do in the commercial world so to speak. I would also suggest that the idea of splitting all of these contractually binding practices into a set of technical publications is inherently insane and has lead to the fiasco that we have today. What the IETF needs is a simple set of documents that do not require a free wall to post the various components on to develop a proper reliance map. Just my own two cents though. Todd On 03/20/2013 06:30 AM, John C Klensin wrote: --On Wednesday, March 20, 2013 06:53 -0400 Margaret Wasserman m...@lilacglade.org wrote: ... I am not suggesting that we start collecting or publishing this information, just saying that it makes it hard to tell whether our leadership is reasonably representative of the community in some of these areas. Also, I think there are some area where diversity is important to the IETF that are not on this list, like geographic location, corporate affiliation and industry segment (vendor, operator, researcher, etc.). Margaret, While I am very much in favor of a more diverse IETF population and leadership, the above, especially when combined with Martin Rex's later comment, is part of the reason why I see the problem as terribly difficult and not yielding easily to petitions, design teams, instructions to confirming bodies (particularly problematic as other discussions have shown), or good intentions. As a specific example, I think the IETF would be considerably strengthened by more diversity in corporate affiliations and industry segments as you suggest above. As with gender diversity, my impression is that we are getting more homogeneous rather than more diverse. One of the problems is time commitment and associated costs. For many corporations, most startups, and a significant fraction of actual individual participants, service in leadership positions is feasible only if those positions are really part-time and significant attention is paid to either cost containment or spreading marginal costs around the community. Yet the IESG (and, to a slightly lesser extent, the IAB) have tended to assign more and more work and responsibility to themselves, If we want more diversity along corporate, role, and related economic axes, we need (as others have pointed out) to shrink the jobs. In the IESG's case, that may require reducing the number of WGs we think we can operate in parallel. Unfortunately, there are many reasons to continue to _expand_ the jobs: on a point basis, it will always be easier to add tasks to existing leaders than to consider whether those tasks are really necessary, to consider sunsetting other tasks, or to organize and manage alternate ways to get them done. It also isn't clear that the community cares: I note that the recent effort to allow the IAB and IESG to appoint people other than the Chairs to serve on the IAOC/Trust, and an earlier one to separate the IAOC and the Trust, went exactly nowhere. On the other hand, if we are serious, I think it needs to be something that Nomcoms are committed (preferably without more rules) to enforce by asking candidates their positions on job-shrinking and by retiring incumbents who contribute to job-expansion. Those expansions are perhaps also influenced by the observation that, if the incumbents have the time and support for an expanded role, such expansion doesn't seem to be harmful. That is part of a classic example of why already-homogeneous organizations tend to become even more homogeneous, at leat in the absence of disruptive changes. best, john
Re: Diversity of IETF Leadership
On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.orgwrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. What records *do* exist regarding the identify of IETF leadership? Is there a central repository of at least names/companies of IESG members and/or WG leaders?
Re: Diversity of IETF Leadership
IESG, with name/area: http://www.ietf.org/iesg/past-members.html IAB, with name/affiliation: http://www.iab.org/about/history/ On Wed, Mar 20, 2013 at 10:16 AM, Jorge Contreras cntre...@gmail.comwrote: On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.orgwrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. What records *do* exist regarding the identify of IETF leadership? Is there a central repository of at least names/companies of IESG members and/or WG leaders?
Re: Diversity of IETF Leadership
On Wed, Mar 20, 2013 at 9:16 AM, Jorge Contreras cntre...@gmail.com wrote: On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.org wrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) [MB] I agree 100%. IETF is not at all qualified to define hiring criteria or practices. Unfortunately, they do it all the time. The model in place IMHO would not stand up to the scrutiny of any major US company's HR dept. And, of course, the HR departments are the ones responsible for ensuring the laws in a specific area are met. [/MB] While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. What records *do* exist regarding the identify of IETF leadership? Is there a central repository of at least names/companies of IESG members and/or WG leaders?
Re: Diversity of IETF Leadership
I do not really think the legal angle is helpful in resolving this problem. (Which country's laws do we need to comply with?) Let's treat these legal ideas as considerations that we should be thinking about, not something where we should be striving for strict compliance. --Richard On Wed, Mar 20, 2013 at 10:27 AM, Mary Barnes mary.ietf.bar...@gmail.comwrote: On Wed, Mar 20, 2013 at 9:16 AM, Jorge Contreras cntre...@gmail.com wrote: On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.org wrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) [MB] I agree 100%. IETF is not at all qualified to define hiring criteria or practices. Unfortunately, they do it all the time. The model in place IMHO would not stand up to the scrutiny of any major US company's HR dept. And, of course, the HR departments are the ones responsible for ensuring the laws in a specific area are met. [/MB] While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. What records *do* exist regarding the identify of IETF leadership? Is there a central repository of at least names/companies of IESG members and/or WG leaders?
Re: Diversity of IETF Leadership
Going a bit over-the-top: is there an interaction between sex and sexual orientation? Can one count as the other? On Mar 20, 2013, at 8:10 AM, Riccardo Bernardini framefri...@gmail.com wrote: On Wed, Mar 20, 2013 at 11:53 AM, Margaret Wasserman m...@lilacglade.org wrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. I am not suggesting that we start collecting or publishing this information, just saying that it makes it hard to tell whether our leadership is reasonably representative of the community in some of these areas. I would say that in this case we are almost surely automatically fair: while one can suspect that gender or geographical origin could add a bias (even an unwanted one), if I do not know the, say, sexual orientation of a candidate, I cannot discriminate (even on a subconscious level) using that information. Also, I think there are some area where diversity is important to the IETF that are not on this list, like geographic location, corporate affiliation and industry segment (vendor, operator, researcher, etc.). Margaret
Re: Mentoring
On 20/03/2013 13:42, Ben Campbell wrote: On Mar 20, 2013, at 3:09 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: However, I think an important part of that is ensuring that people do *not* focus exclusively on a specific target, even if they are busy people as Ben said. Change the sense of ensuring to encouraging, and I agree. But as worded, that sounds a lot like making it harder for someone to focus on the work they are interested in. I think that's more likely to make people stop coming than making them generalize their work. Yes, my phrasing was careless. But we really do need to encourage cross-currents. For me personally, that's one of the main benefits of the IETF format and it would be sad to be too inward looking. Brian
Re: IETF 86 Admin Plenary Minutes
On 3/19/2013 1:20 PM, S Moonesamy wrote:
Merely to offer an example notation:
Sean Turner mentioned that a year ago someone asked him how to become
a WG chair. Asking is the first step! He thinks that if people want to
actively participate, they need to volunteer to write drafts etc.
{guidance/leadership}
The above lists asking as the first step. Most people would not ask as
it is awkward to do so.
From the 20 seconds that I used to look for examples, it was
immediately clear that there are at least two kinds of items to note.
One, of course, is direct questions and requests. One other is 'topics'
that are raised, unresolved, and seem worthy of follow-up. They might
or might not turn into questions/requests, but at least they are
noteworthy (literally).
The larger issue goes beyond annotation methodology. Namely an open-mic
environment that seeks to produce an exchange that is actionable, rather
than a tone that is primarily for venting.
A tone that encourages constructive action tends to be common in working
group discussion. So we know it's possible and we are all experienced
with it. So the change we need for open-mic sessions is (simply to)
move more towards developing specific questions and suggestions; this is
a change on the dais, as well as at the microphone...
d/
ps. I've skipped the substantive issue you pursue, concerning the
problematic selection processes, only because here I want to focus on
making open-mic sessions more productive.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Re: Diversity of IETF Leadership
On 03/20/2013 08:13 AM, Martin Rex wrote: The monetary and time resources necessary to fill an I* position adequately appear quite significant to me, and I believe it would be hard to fill them without strong support from an employer which covers the monetary investment. Agreed. But this is a huge problem for IETF. Far too often, our standards aren't serving the Internet community so much as serving the interests of a few large companies. I'd actually guess that this is IETF's biggest problem. Keith
R: [IPFIX] Last Call: draft-ietf-ipfix-flow-selection-tech-14.txt (Flow Selection Techniques) to Proposed Standard
Dear Benoit, Will do. Kind regards, Salvatore Da: Benoit Claise [mailto:bcla...@cisco.com] Inviato: mercoledì 20 marzo 2013 09:36 A: draft-ietf-ipfix-flow-selection-t...@tools.ietf.org Cc: IETF-Discussion list; Rahul Patel; ip...@ietf.org Oggetto: Re: [IPFIX] Last Call: draft-ietf-ipfix-flow-selection-tech-14.txt (Flow Selection Techniques) to Proposed Standard Dear authors, While reviewing draft-ietf-ipfix-mediation-protocol, Rahul got some feedback that actually concerns draft-ietf-ipfix-flow-selection-tech. Can you please take this into account. Regards, Benoit Few comments. 1. Page 8: 1. The difference between Intermediate Selection Process and Intermediate Flow Selection Process is not clear. Is the first one selecting record purely on matching content (value of the fields) in the record and the second one selecting on matching attributes of the fields that are not part of the record in *addition* to matching content in the record? An example would help here. BC Granted, this is difficult to understand from the definitions only. There is some history behind these two separate definitions. Anyway, you get it right from your message above. I was thinking to add to a section 2.1 Differences between Intermediate Selection Process and Intermediate Flow Selection Process in the draft-ietf-ipfix-mediation-protocol draft. However, thinking about it some more, this section should really be done in draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion. There is already section 3. Difference between Intermediate Flow Selection Process and Packet Selection. Some more text should be added on the difference between Intermediate Selection Process and Intermediate Flow Selection Process When created, draft-ietf-ipfix-mediation-protocol will refer to that new section. 1. 1. Also in the example e.g., Filtering only records from a given network to a given Collector - Does given network means source-ip/source-prefix of the exporter?. BC It means matching the flow records to a certain prefix/AS/you-name-it, and exporting those matched flow records to an exporter. See for example, section 6.1 in RFC 6183 This could be explained better in the new section in draft-ietf-ipfix-flow-selection-tech (See previous point) The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Flow Selection Techniques' draft-ietf-ipfix-flow-selection-tech-14.txt as 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 2013-04-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1540/ ___ IPFIX mailing list ip...@ietf.org https://www.ietf.org/mailman/listinfo/ipfix _ Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2013.0.2904 / Database dei virus: 2641/6186 - Data di rilascio: 18/03/2013
Re: Diversity of IETF Leadership
On 03/20/13 15:16, Jorge Contreras allegedly wrote: I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. Or don't generate it at all. Trying to have a complete list of human attributes to diversify to looks like an engineer's reflex. We know what we want to do in principle.
Re: Diversity of IETF Leadership
On 03/20/2013 07:16 AM, Jorge Contreras wrote: On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.org mailto:m...@lilacglade.org wrote: Jorge - did I miss something here - isnt this your job? If not why are you here? Let me respond that further - I believe that there are any number of both privacy and transparency counsel's in the movement so to speak who would love to work with such a body to create a transparent set of participation rules UNDER THE CURRENT PARTICIPATION MODELS AS BROKEN AS THEY ARE... Didnt you file an ID yourself not to long ago? In fact I am betting Professor you know any number of Grad Students who would love such a job if you catch my drift. Todd Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com mailto:stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. What records *do* exist regarding the identify of IETF leadership? Is there a central repository of at least names/companies of IESG members and/or WG leaders?
Re: Diversity of IETF Leadership
On Wed, March 20, 2013 7:16 am, Jorge Contreras wrote: On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.orgwrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) Great, now the lawyers are getting involved. A sure sign this has gone way too far. The factors listed above are those that an employer cannot discriminate on. It says nothing about diversity or the alleged benefits that diversity brings to a group. For example, a company is prohibited from not hiring someone because he or she is Catholic but it does not mean that the company must work to have some arbitrary percentage of Catholics in leadership positions or among the general workforce. Absent any evidence of discrimination there is Disparate Impact Theory which says that the mere fact that a process produces a result that does not satisfy an arbitrary goal with respect to a protected group is justification for actively discriminating in favor of that protected group to balance it all out. I really, really hope that is not where we are going in the IETF. It would wreck this organization if we had a committee that performed such a blatantly political activity. If that is not where the IETF is going, then the categories listed above should not have anything to do with selection of candidates for leadership positions. It doesn't matter to the IETF if the candidate is a disabled, pregnant, lesbian, Wiccan. What matters to the IETF is whether the candidate is qualified. Dan.
Re: Diversity of IETF Leadership
As I understand it, Jorge is highlighting that he is not an expert in employment and Equal opportunity law. That is a specific expertise. On Wed, Mar 20, 2013 at 10:20 AM, tsg tglas...@earthlink.net wrote: On 03/20/2013 07:16 AM, Jorge Contreras wrote: On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.org wrote: Jorge - did I miss something here - isnt this your job? If not why are you here? Let me respond that further - I believe that there are any number of both privacy and transparency counsel's in the movement so to speak who would love to work with such a body to create a transparent set of participation rules UNDER THE CURRENT PARTICIPATION MODELS AS BROKEN AS THEY ARE... Didnt you file an ID yourself not to long ago? In fact I am betting Professor you know any number of Grad Students who would love such a job if you catch my drift. Todd Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. What records *do* exist regarding the identify of IETF leadership? Is there a central repository of at least names/companies of IESG members and/or WG leaders?
Re: Diversity of IETF Leadership
On 3/20/2013 4:33 AM, Eliot Lear wrote: Let's not play Internet lawyers about this. How Jari's design team bring in real lawyers at the appropriate time? Or not. There's an important choice between focusing on the sufficiency of representation from a defined set of population groups, versus focusing on the need for true diversity and the means of achieving it. The former is a numbers game and produces soulless mechanics that can't possibly be constructive, in a group as small and specialized as ours. The latter is a culture game and actively seeks as a rich range of perspectives as practical, knowing that it can't get /all/ perspectives. d/ ps. A small point to watch for, if there is a focus on a defined list of groups, is the difference between discriminating /against/, versus ensuring representation /from/. Active prohibition vs. active solicitation. The exchange between Margaret and Stuart seemed to mix these. We need to be careful about the distinction. -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Diversity of IETF Leadership
I don't think anyone is asking for strict compliance to a particular country's laws, although, one could debate that since ISOC is the mother organization for IETF that it might be reasonable to look at the laws in the regions where ISOC is incorporated. My understanding, however, is that since IETF is a non-profit, there is no requirement for them to comply with any of these laws (at least in the US), although one could debate the fact that the US DoD provides funds to ISOC such might be required. Given that folks are still debating whether this years nominees reflected a reasonable diversity (there were 9 women out of 37 nominees), it does seem that finding a description of diversity criteria that is considered by other professional organizations is not a bad idea.However, given the direction of most of these threads, I'm beginning to be of the same mindset as John: https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=68058tid=1363793904 Regards, Mary. On Wed, Mar 20, 2013 at 9:34 AM, Richard Barnes r...@ipv.sx wrote: I do not really think the legal angle is helpful in resolving this problem. (Which country's laws do we need to comply with?) Let's treat these legal ideas as considerations that we should be thinking about, not something where we should be striving for strict compliance. --Richard On Wed, Mar 20, 2013 at 10:27 AM, Mary Barnes mary.ietf.bar...@gmail.com wrote: On Wed, Mar 20, 2013 at 9:16 AM, Jorge Contreras cntre...@gmail.com wrote: On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.org wrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) [MB] I agree 100%. IETF is not at all qualified to define hiring criteria or practices. Unfortunately, they do it all the time. The model in place IMHO would not stand up to the scrutiny of any major US company's HR dept. And, of course, the HR departments are the ones responsible for ensuring the laws in a specific area are met. [/MB] While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. What records *do* exist regarding the identify of IETF leadership? Is there a central repository of at least names/companies of IESG members and/or WG leaders?
Re: Diversity of IETF Leadership
Hi Dave, On Wed, March 20, 2013 8:35 am, Dave Crocker wrote: ps. A small point to watch for, if there is a focus on a defined list of groups, is the difference between discriminating /against/, versus ensuring representation /from/. Active prohibition vs. active solicitation. The exchange between Margaret and Stuart seemed to mix these. We need to be careful about the distinction. I have been viewing this as the difference between discriminating against versus discriminating for. And I am against discrimination, even that done for the best of intentions. Active solicitation is all well and good but how do you _ensure_ representation of members from a defined list of groups if your active solicitation does not result in the favored mix? Dan. -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Diversity of IETF Leadership
I'm somewhat worried at the lurch this thread has taken into the land of protected classes, legal advice, etc. I hope we do not go there. Having said that ... since Eric asked ... On 3/20/2013 9:57 AM, Eric Burger wrote: Going a bit over-the-top: is there an interaction between sex and sexual orientation? Can one count as the other? I'm not answering as an IAB member, but as co-president of PFLAG Dallas (Parents, Families and Friends of Lesbians, Gays, Bisexuals and Transgenders) ... PFLAG includes sexual orientation under sexual orientation, gender identity and expression. Each of these terms means something different, and all of these can be distinct from birth gender. So, PFLAG would suggest that we treat gender and sexual orientation, gender identity and expression interchangeably. Spencer (www.pflag.org)
Re: Diversity of IETF Leadership
On 03/20/2013 11:41 AM, Mary Barnes wrote: Given that folks are still debating whether this years nominees reflected a reasonable diversity (there were 9 women out of 37 nominees), I actually don't think that the number of female nominees is relevant.What is relevant is the number of qualified female nominees who had the willingness, the availability, the required expertise, and the support necessary to fill the position. On several occasions in the past decade I've been asked if I were willing to be nominated to serve on IESG again, even though I didn't have either sufficient time or support to devote to the task, just so that nomcom would have a slate of candidates to compare. I thought on those occasions, and still think, that it's a bit silly to ask nomcom to investigate candidates who don't have the time or support to do the job. But I still agreed to be nominated because I could also see some value in having nomcom compare several candidates. (Just like when shopping for a new car, it doesn't hurt to look at models that you know that you're probably not going to buy, just to get a sense of whether you really want what you think you want). So I guess I've formed the impression that merely being nominated for a position doesn't really mean that a person is available. Keith
Re: Diversity of IETF Leadership
On Wed, Mar 20, 2013 at 11:10 AM, Keith Moore mo...@network-heretics.com wrote: On 03/20/2013 11:41 AM, Mary Barnes wrote: Given that folks are still debating whether this years nominees reflected a reasonable diversity (there were 9 women out of 37 nominees), I actually don't think that the number of female nominees is relevant. What is relevant is the number of qualified female nominees who had the willingness, the availability, the required expertise, and the support necessary to fill the position. [MB] Sure. But, I know of at least two that I don't think or would hope anyone would debate were qualified in all the areas you suggest. Both have contributed significantly to IETF in a variety of leadership positions. I do not believe at least one of the choices would have stood up against scrutiny by my own HR dept. Certainly, you have opinions, as does the IETF population that is in the majority, as to what makes one qualified. One concept that is not very well understood, however, is the basic fact that women work differently than men and thus expecting us to fit the cookie cutter of IETF leaders isn't quite appropriate. To be told by a nomcom voting member, when I mention this fact, that this just isn't so because IETF is a meritocracy is insulting and shows a sheer lack of respect for the value that diversity brings to an organization. [/MB] On several occasions in the past decade I've been asked if I were willing to be nominated to serve on IESG again, even though I didn't have either sufficient time or support to devote to the task, just so that nomcom would have a slate of candidates to compare. I thought on those occasions, and still think, that it's a bit silly to ask nomcom to investigate candidates who don't have the time or support to do the job. But I still agreed to be nominated because I could also see some value in having nomcom compare several candidates. (Just like when shopping for a new car, it doesn't hurt to look at models that you know that you're probably not going to buy, just to get a sense of whether you really want what you think you want). So I guess I've formed the impression that merely being nominated for a position doesn't really mean that a person is available. [MB] You have to keep in mind in the past that the there were dummies in the nominee pool before open list. I was explicitly told by this year's nomcom chair that they were not doing that. Thus, I would anticipate that the majority of those in the pool this year were willing and able.[/MB] Keith
Re: Diversity of IETF Leadership
On 3/20/2013 11:21 AM, Mary Barnes wrote: On Wed, Mar 20, 2013 at 11:10 AM, Keith Moore mo...@network-heretics.com wrote: So I guess I've formed the impression that merely being nominated for a position doesn't really mean that a person is available. [MB] You have to keep in mind in the past that the there were dummies in the nominee pool before open list. I was explicitly told by this year's nomcom chair that they were not doing that. Thus, I would anticipate that the majority of those in the pool this year were willing and able.[/MB] Both of you are right, of course. Before OpenList, the list of nominees willing to be considered was treated as confidential. Nomcoms that wanted to ask for input on specific people sent out lists of nominees that were padded, as Keith says, so that there were dummies (usually described as ringers), and theoretically no one outside Nomcom knew precisely who was being considered. When we approved http://www.rfc-editor.org/rfc/rfc5680.txt in 2009, it added this text to RFC 3777: The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential. The NomCom may disclose a list of names of nominees who are willing to be considered for positions under review to the community, in order to obtain feedback from the community on these nominees. The list of nominees disclosed for a specific position should contain only the names of nominees who are willing to be considered for the position under review. The NomCom may choose not to include some names in the disclosed list, at their discretion. The NomCom may disclose an updated list, at their discretion. For example, the NomCom might disclose an updated list if the NomCom identifies errors/omissions in a previously disclosed version of the disclosed list, or if the NomCom finds it necessary to call for additional nominees, and these nominees indicate a willingness to be considered before the NomCom has completed its deliberations. Nominees may choose to ask people to provide feedback to the NomCom, but should not encourage any public statements of support. NomComs should consider nominee-encouraged lobbying and campaigning to be unacceptable behavior. IETF community members are encouraged to provide feedback on nominees to the NomCom, but should not post statements of support/ non-support for nominees in any public forum. So, the assumption before 2009 was that lists were padded, and the assumption after 2009 is that lists aren't padded. The Nomcom can do what seems right, of course. Spencer
Re: Diversity of IETF Leadership
On Wed, Mar 20, 2013 at 09:01:01AM -0700, Dan Harkins wrote: On Wed, March 20, 2013 8:35 am, Dave Crocker wrote: ps. A small point to watch for, if there is a focus on a defined list of groups, is the difference between discriminating /against/, versus ensuring representation /from/. Active prohibition vs. active solicitation. The exchange between Margaret and Stuart seemed to mix these. We need to be careful about the distinction. I have been viewing this as the difference between discriminating against versus discriminating for. And I am against discrimination, even that done for the best of intentions. This is certainly the biggest challenge of any intent to include diversity (of any form) in the mix. In general, we want the best people in the job in question. What is best depends on the position (chair, I*, etc.) but as a technical organization that runs on documents, several things will bubble to the top: - Technical clue in the matter at hand. - Reasonable administrative skills. - Ability to work with others. - Solid communication skills. For candidates wherein the above things are roughly equal - or have exceeded the requirements - diversity is a possible tie-breaker. If the intent is to emphasize diversity (for some metric) over one of the core skills, that's certainly possible. The primary challenge then is making sure there is a diverse candidate pool that satisfies the minimum core skills needed for the positions. See prior discussion on mentoring. (Note that the above observations were things I had intended to say at the administrative plenary, but I appeared to be standing at the invisible mic.) -- Jeff
Re: Diversity of IETF Leadership
On 3/20/2013 10:01 AM, Jeffrey Haas wrote: In general, we want the best people in the job in question. What is best depends on the position (chair, I*, etc.) but as a technical organization that runs on documents, several things will bubble to the top: - Technical clue in the matter at hand. - Reasonable administrative skills. - Ability to work with others. - Solid communication skills. Note the 3 of the 4 items on your list are not a matter of technical skill. Also note that your list is missing something that was raised earlier in the thread, namely the difference between local optimization versus 'global'. There are benefits in having a group mixture that can be far more important than the attributes of the group members taken individually. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Diversity of IETF Leadership
On Wed, Mar 20, 2013 at 10:09:41AM -0700, Dave Crocker wrote: On 3/20/2013 10:01 AM, Jeffrey Haas wrote: In general, we want the best people in the job in question. What is best depends on the position (chair, I*, etc.) but as a technical organization that runs on documents, several things will bubble to the top: - Technical clue in the matter at hand. - Reasonable administrative skills. - Ability to work with others. - Solid communication skills. Note the 3 of the 4 items on your list are not a matter of technical skill. Agreed, although it is probably understood that technical clue tends to be pretty high on the list in terms of weight. The overlap of those (IMO) core skills and diversity (for some metric thereof) is present. Regardless of the reason someone has a given skill, the skill itself is the functional requirement. Also note that your list is missing something that was raised earlier in the thread, namely the difference between local optimization versus 'global'. There are benefits in having a group mixture that can be far more important than the attributes of the group members taken individually. Probably because I don't buy wholly into that argument - or at least the argument it makes us smarter. A broader source of opinions is always a good thing and I believe that is one of the things that diversity brings us. To draw a very geekish analogy, I tend to find that diversity helps only a little on the intelligence of a group. It does wonders for the wisdom of the group. :-) -- Jeff
Re: Diversity of IETF Leadership
On 03/20/2013 12:21 PM, Mary Barnes wrote: On Wed, Mar 20, 2013 at 11:10 AM, Keith Moore mo...@network-heretics.com wrote: On 03/20/2013 11:41 AM, Mary Barnes wrote: Given that folks are still debating whether this years nominees reflected a reasonable diversity (there were 9 women out of 37 nominees), I actually don't think that the number of female nominees is relevant. What is relevant is the number of qualified female nominees who had the willingness, the availability, the required expertise, and the support necessary to fill the position. [MB] Sure. But, I know of at least two that I don't think or would hope anyone would debate were qualified in all the areas you suggest. Both have contributed significantly to IETF in a variety of leadership positions. Sure, but that doesn't mean that they have sufficient time or employer support to do the job now. And there's no way that someone like you or me can reliably know whether that's the case. That has to be something that's kept confidential between the nominee and the nomcom. One concept that is not very well understood, however, is the basic fact that women work differently than men and thus expecting us to fit the cookie cutter of IETF leaders isn't quite appropriate. To be clear: I wasn't arguing about that aspect at all, just about whether it's reasonable to look at a slate of nominees and compare that to the slate of people selected and make inferences about the role of gender in the nomcom's decision process. I'm also not presuming that just because there were no women in the latest set of appointees to IESG, that it's because the current nomcom didn't think that women could fit the cookie cutter. I don't have and don't pretend to have the ability to read their minds. In general I think that presumptions that require the ability to read specific people's minds should be dismissed out-of-hand as irrelevant and perhaps insulting. People can imagine or project what they like, but what people imagine or project should never be confused with reality. To be told by a nomcom voting member, when I mention this fact, that this just isn't so because IETF is a meritocracy is insulting and shows a sheer lack of respect for the value that diversity brings to an organization. Respectfully disagree. We expect the nomcom to balance lots of different considerations when choosing IESG and other appointees, AND we expect them to keep their deliberations confidential. Gender is definitely a valid consideration, but it's only one consideration, and at least a dozen others have been mentioned. To look at the nomcom result through the aperture of only one or two of those considerations, and then make a statement about the nature of their imagined gender bias strikes me as pure speculation. I certainly hope that the nomcom doesn't believe that women can't do the jobs. Our community has ample evidence and decades of experience that they can. I served with several women when I was on IESG and found all of them to be capable and professional in every respect. Note also that the process for selecting the nomcom is inherently gender-neutral, at least to the extent that the requirement for nomcom attendance at prior IETF meetings doesn't impose a gender barrier. [MB] You have to keep in mind in the past that the there were dummies in the nominee pool before open list. I was explicitly told by this year's nomcom chair that they were not doing that. Thus, I would anticipate that the majority of those in the pool this year were willing and able.[/MB] That helps a bit, but I still don't think it supports an assertion of gender bias in the nomcom's process. Keith
Re: Diversity of IETF Leadership
On 3/20/2013 10:53 AM, Jeffrey Haas wrote: On Wed, Mar 20, 2013 at 10:09:41AM -0700, Dave Crocker wrote: Also note that your list is missing something that was raised earlier in the thread, namely the difference between local optimization versus 'global'. There are benefits in having a group mixture that can be far more important than the attributes of the group members taken individually. Probably because I don't buy wholly into that argument - or at least the argument it makes us smarter. Then I encourage you to do more reading. It's not a marginal or controversial point, among folk who do research in the relevant fields. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Diversity of IETF Leadership
On Wed, March 20, 2013 10:01 am, Jeffrey Haas wrote: On Wed, Mar 20, 2013 at 09:01:01AM -0700, Dan Harkins wrote: On Wed, March 20, 2013 8:35 am, Dave Crocker wrote: ps. A small point to watch for, if there is a focus on a defined list of groups, is the difference between discriminating /against/, versus ensuring representation /from/. Active prohibition vs. active solicitation. The exchange between Margaret and Stuart seemed to mix these. We need to be careful about the distinction. I have been viewing this as the difference between discriminating against versus discriminating for. And I am against discrimination, even that done for the best of intentions. This is certainly the biggest challenge of any intent to include diversity (of any form) in the mix. In general, we want the best people in the job in question. What is best depends on the position (chair, I*, etc.) but as a technical organization that runs on documents, several things will bubble to the top: - Technical clue in the matter at hand. - Reasonable administrative skills. - Ability to work with others. - Solid communication skills. For candidates wherein the above things are roughly equal - or have exceeded the requirements - diversity is a possible tie-breaker. If the intent is to emphasize diversity (for some metric) over one of the core skills, that's certainly possible. By that, I take it you mean it's certainly possible to discriminate in favor some metric of diversity and against a core skill. So? Is that the intent? There is quite a bit of dancing around this subject and it would be nice to say what we all mean here. If you're proposing that IETF start the practice of discriminating against certain people then say so. The primary challenge then is making sure there is a diverse candidate pool that satisfies the minimum core skills needed for the positions. See prior discussion on mentoring. You snipped my other question. So let me ask again. What do we do if, after ensuring that there's a diverse candidate pool that satisfies the minimum core skills needed for positions, the end result is more white men? Do we stop with the pretense of ensuring diversity of opportunity and just proceed to diversity of result? Do we enshrine the soft bigotry of low expectations? Dan.
Re: Please review draft-housley-rfc2050bis-00.txt
On Mar 19, 2013, at 9:30 PM, David Farmer far...@umn.edu wrote: I wonder if it wouldn't be appropriate to at least provide some suggestions for how this is to be accomplished. Maybe request that future RFCs related to these technical and operational considerations include an applicability statement as to the Internet Numbers Registry System, either in a separate section or maybe as a sub-section of the IANA Considerations. This evolution is discussed in Section 4. Maybe a forward pointer is needed. Did you not find Section 4 sufficient? I saw that, it says; In addition, in the cases where the IETF sets technical recommendations for protocols, practices, or services which are directly related to IP address space or AS numbers, such recommendations must be taken into consideration in Internet Numbers Registry System policy discussions regardless of venue. This is good, but I read it as saying the IR system, and the RIR's in particular, are obligated to consider the technical recommendations of the IETF when making policy. That is only part of the equation. I was looking for the other side, the IETF is obligated to maintain clear, relevant, and up to date technical recommendations for the IR system, including how such recommendations are intended to apply to the IR system. David - Two points: 1) Language along the lines of the IETF is obligated to ... really isn't going to work, as the point of the RFC2050 revision is to document existing relationships supporting the Internet Numbers Registry System, using pointers to existing source documents to the greatest extent possible. Even if there were 100% agreement to the concept, it would not be appropriate to establish it via this document which is intended for Informational publication. 2) More importantly, who is the IETF in such a construct? Would such a task (of periodically pondering if these recommendations need updating) fall to the IAB or IESG? (I hadn't realized that they needed extra work... ;-) I believe that when you consider that we each individually are the IETF (i.e. all of the folks who participate in the working groups and writing drafts) then it is clear that any obligation to update these technical recommendations periodically would fall to those with an interest in keeping them current. You might even say that's what Russ, David, Geoff, and I are finally getting around to doing via this draft, at least for one of the key documents. FYI, /John Disclaimers: My views alone. If you are reading this email long after publication, this email may be out-of-date and I do not commit to updating its contents. ;-)
Re: [IETF] Getting rid of the dot (was: Mentoring)
On Mar 19, 2013, at 11:19 AM, Carsten Bormann c...@tzi.org wrote: On Mar 19, 2013, at 13:22, Michael Richardson m...@sandelman.ca wrote: Instead of getting a new badge every meeting, maybe we should just get an IETF86 dot on a badge we keep from meeting to meeting. I want my badge on a shiny embossed metal plate with the words protocol police on it. Where do I have to apply? Will increase your meeting fee by ~$45, but here you go… http://www.visualbadge.com/BuildBadge_ViewPic2.aspx?badge=FB46base=silvertextfont=blocktextcolor=blacktext1=I.E.T.Ftext2=PROTOCOLtext3=text4=POLICEtext5=BCP38text6=seal=C998Mtextsep=NONEaff=A128back=finish=NICKEL+ELECTROPLATEqtyb=1etype=SOFT+(REGULAR)att=BADGE+ONLY+(PIN+BACK)sh=CURVEDspecins=price=39.50l=pricel=qtyl=0textsep=NONEbsize=Dimensions+(w+x+h)%3a+1.25''+X+1.75''limpr=-LEAVE+BLANK-centertype=MULTI+COLOR W Grüße, Carsten -- Go on, prove me wrong. Destroy the fabric of the universe. See if I care. -- Terry Prachett
Re: Diversity of IETF Leadership
Part of what I meant when I signed the diversity letter was to state a belief that within a pool of qualified candidates, I believe diversity is important enough that it is valuable to select for diversity even if this does not maximize the skills that you enumerated (tech skill, admin skill, works with others and something else).
Less Corporate Diversity
How much is the concentration of corporate participation in the IETF a result of market forces, like consolidation and bankruptcy, as opposed to nefarious forces, like a company hiring all of the I* leadership? We have mechanisms to deal with the latter, but there is not much we can do about the former. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Less Corporate Diversity
On 03/20/2013 12:18 PM, Eric Burger wrote: How much is the concentration of corporate participation in the IETF a result of market forces, like consolidation and bankruptcy, as opposed to nefarious forces, like a company hiring all of the I* leadership? We have mechanisms to deal with the latter, but there is not much we can do about the former. Sure you can - you can put in place formal requirements for disclosure and actually make licenses which are recallable for frauds or other bad acts in the process. The issue isnt whether the goal of the IETF is a laudable one or not - it clearly is, the issue is whether the IETF itself is responsible for actions which its infrastructure is used to control are allowed or not and what the issues for threshold of damages are. Bluntly this IETF has no statistical idea on any of these things because it has intentionally put in place controls which are either too complex to implement or are glad-handed and ignored like the BCP78/79 rules which say All parties speak regularly with their sponsors legal departments to keep them abreast on changes or things of interest in the standards process... (yeah right...). No really - its about time everything here got locked down so everything is open and a little-guy really can submit and promulgate a technology through standardization. Todd
Re: Diversity of IETF Leadership
On Wed, Mar 20, 2013 at 12:01:41PM -0700, Dan Harkins wrote: For candidates wherein the above things are roughly equal - or have exceeded the requirements - diversity is a possible tie-breaker. If the intent is to emphasize diversity (for some metric) over one of the core skills, that's certainly possible. By that, I take it you mean it's certainly possible to discriminate in favor some metric of diversity and against a core skill. So? Is that the intent? There is quite a bit of dancing around this subject and it would be nice to say what we all mean here. If you're proposing that IETF start the practice of discriminating against certain people then say so. Have care, you're close to putting words in my mouth. :-) If what you mean is that emphasizing diversity over a core skill with respect to selection of people for positions of responsibility is a form of discrimination, that's how some people have presented it. I.e. affirmative action. If you're asking for my personal opinion, I think we should stick to meeting core criteria minimums and that among candidates that meet those requirements consider diversity as one of the criteria. You snipped my other question. So let me ask again. What do we do if, after ensuring that there's a diverse candidate pool that satisfies the minimum core skills needed for positions, Good start for a presumption. the end result is more white men? I believe you, and many others, are inferring over much with regard to diversity from the black box that is NomCom. Unfortunately that is a big ugly part of this whole discussion. Part of the perception here is the the NomCom is fed a candidate pool and the output mostly matches beliefs that diversity is not an input. It's like any other job interview - you only know you don't get the job. You may know who did. Without getting someone on the hiring committe to talk about why the person in question is selected, you can only speculate as to why you weren't selected. If instead you (or someone else) is going to argue that given an input of a set of candidates that match some crtieria of diversity that it is a requirement that the output include something that meets that diversity criteria, then pick your word for that result. Do we stop with the pretense of ensuring diversity of opportunity and just proceed to diversity of result? Do we enshrine the soft bigotry of low expectations? Or we define our requirements for the outputs of the process and stop speculating about the black box. C.f. the tsvarea discussion on what they want out of an AD. -- Jeff
Re: Please review draft-housley-rfc2050bis-00.txt
Hi, Russ. Two points: On Tue, 2013-03-19 at 22:30 -0500, David Farmer wrote: snip Rereading things again, I have another suggestion; 4) Split the Goals of the Internet registry system out of the Introduction. The Intro starts out talking about the document, its goals, and what is in scope and out of scope of the document. Then transitions to talking about the goals of the Internet registry system. I think the goals of the Internet registry system should be a separate section from the Introduction. And, the Introduction should be expanded to better describe the purpose of the document. I agree fully with this comment. The first para of s1 needs a rewrite and a little expansion to match up with the abstract to form a proper intro. The goals do belong in a separate section Also regarding the first para of s4: This contains some woolly hand-waving weasel words at the end: Over the years, the Internet Numbers Registry System has developed mechanisms by which the structures, policies, and processes of the Internet Numbers Registry System itself can evolve to meet the changing demands of the global Internet community. Further evolution of the Internet Numbers Registry System is expected to occur in an open, transparent, and broad multi-stakeholder manner. ^^^ Who are these stakeholders? Is this (just) the organisations named in the document (I think that would be ICANN/IANA, IETF, *IRs - a large number!) or is the community to be consulted? and governments? So do we have a view as to how all these people are to be informed that some evolution is needed? Regards, Elwyn
Re: Please review draft-housley-rfc2050bis-00.txt
I interpret it as anybody. ISPs, cctlds, governments, gtlds, IETF, RIRs, ICANN, ISOC, you, me. /as On 3/20/13 4:43 PM, Elwyn Davies wrote: This contains some woolly hand-waving weasel words at the end: Over the years, the Internet Numbers Registry System has developed mechanisms by which the structures, policies, and processes of the Internet Numbers Registry System itself can evolve to meet the changing demands of the global Internet community. Further evolution of the Internet Numbers Registry System is expected to occur in an open, transparent, and broad multi-stakeholder manner. ^^^ Who are these stakeholders? Is this (just) the organisations named in the document (I think that would be ICANN/IANA, IETF, *IRs - a large number!) or is the community to be consulted? and governments? So do we have a view as to how all these people are to be informed that some evolution is needed?
Re: Diversity of IETF Leadership
On 3/20/13 12:17 PM, Scott Brim wrote: On 03/20/13 15:16, Jorge Contreras allegedly wrote: I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. Or don't generate it at all. Trying to have a complete list of human attributes to diversify to looks like an engineer's reflex. We know what we want to do in principle. +1 Please, do not go to bureaucracy and legal side of this. Let's keep it simple and based on our principles and not in legalities. as
Re: Diversity of IETF Leadership
On Wed, Mar 20, 2013 at 03:13:01PM -0400, Sam Hartman wrote: Part of what I meant when I signed the diversity letter was to state a belief that within a pool of qualified candidates, I believe diversity is important enough that it is valuable to select for diversity even if this does not maximize the skills that you enumerated (tech skill, admin skill, works with others and something else). Maximize overstates my position. My belief is once the base requirements are met that diversity is an appropriate tie-breaker. Maximizing the four I mentioned is different. -- Jeff
Re: Please review draft-housley-rfc2050bis-00.txt
On 3/20/13 14:04 , John Curran wrote: On Mar 19, 2013, at 9:30 PM, David Farmer far...@umn.edu wrote: I wonder if it wouldn't be appropriate to at least provide some suggestions for how this is to be accomplished. Maybe request that future RFCs related to these technical and operational considerations include an applicability statement as to the Internet Numbers Registry System, either in a separate section or maybe as a sub-section of the IANA Considerations. This evolution is discussed in Section 4. Maybe a forward pointer is needed. Did you not find Section 4 sufficient? I saw that, it says; In addition, in the cases where the IETF sets technical recommendations for protocols, practices, or services which are directly related to IP address space or AS numbers, such recommendations must be taken into consideration in Internet Numbers Registry System policy discussions regardless of venue. This is good, but I read it as saying the IR system, and the RIR's in particular, are obligated to consider the technical recommendations of the IETF when making policy. That is only part of the equation. I was looking for the other side, the IETF is obligated to maintain clear, relevant, and up to date technical recommendations for the IR system, including how such recommendations are intended to apply to the IR system. David - Two points: 1) Language along the lines of the IETF is obligated to ... really isn't going to work, as the point of the RFC2050 revision is to document existing relationships supporting the Internet Numbers Registry System, using pointers to existing source documents to the greatest extent possible. Even if there were 100% agreement to the concept, it would not be appropriate to establish it via this document which is intended for Informational publication. xxx is obligated to ... wasn't intended as a suggestions for text, but like I paraphrased the text from the draft above, and I intended it to paraphrase the the text that needs to be added. The text above quoted from the draft such recommendations must be taken into consideration... and I agree with that. I'll note the care in how it is worded, but it seems to flow only IETF to IR Sys 2) More importantly, who is the IETF in such a construct? Would such a task (of periodically pondering if these recommendations need updating) fall to the IAB or IESG? (I hadn't realized that they needed extra work... ;-) I believe that when you consider that we each individually are the IETF (i.e. all of the folks who participate in the working groups and writing drafts) then it is clear that any obligation to update these technical recommendations periodically would fall to those with an interest in keeping them current. You might even say that's what Russ, David, Geoff, and I are finally getting around to doing via this draft, at least for one of the key documents. FYI, /John Disclaimers: My views alone. If you are reading this email long after publication, this email may be out-of-date and I do not commit to updating its contents. ;-) -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
Thank you to Monique Morrow for her service as ITU-T NGN liaison manager
Next time you see Monique, please thank her for he service the the Internet community. From: IAB Chair [iab-ch...@iab.org] Sent: Tuesday, March 12, 2013 5:04 PM To: Monique Morrow Subject: Thank you for your service as NGN liaison manager Dear Monique, The IETF relies on members of the community to volunteer for key roles in our organization. You have provided a great example for this spirit of volunteerism through your role as the IETF liaison manager for Next Generation Networking (NGN) to the ITU-T. You provided the ITU-T program valuable information about activities in study groups 11 and 13, and provided us the opportunity to engage the appropriate people to address early on areas of mutual interest to both organizations, in a way that avoided conflict. The IAB thanks you for this service and we hope that you may be called upon in the future for other roles. On behalf of the IAB, Bernard Aboba IAB Chair
Re: Please review draft-housley-rfc2050bis-00.txt
Whops, that escaped. Sorry. Lets start over. On 3/20/13 15:51 , David Farmer wrote: On 3/20/13 14:04 , John Curran wrote: On Mar 19, 2013, at 9:30 PM, David Farmer far...@umn.edu wrote: I wonder if it wouldn't be appropriate to at least provide some suggestions for how this is to be accomplished. Maybe request that future RFCs related to these technical and operational considerations include an applicability statement as to the Internet Numbers Registry System, either in a separate section or maybe as a sub-section of the IANA Considerations. This evolution is discussed in Section 4. Maybe a forward pointer is needed. Did you not find Section 4 sufficient? I saw that, it says; In addition, in the cases where the IETF sets technical recommendations for protocols, practices, or services which are directly related to IP address space or AS numbers, such recommendations must be taken into consideration in Internet Numbers Registry System policy discussions regardless of venue. This is good, but I read it as saying the IR system, and the RIR's in particular, are obligated to consider the technical recommendations of the IETF when making policy. That is only part of the equation. I was looking for the other side, the IETF is obligated to maintain clear, relevant, and up to date technical recommendations for the IR system, including how such recommendations are intended to apply to the IR system. David - Two points: 1) Language along the lines of the IETF is obligated to ... really isn't going to work, as the point of the RFC2050 revision is to document existing relationships supporting the Internet Numbers Registry System, using pointers to existing source documents to the greatest extent possible. Even if there were 100% agreement to the concept, it would not be appropriate to establish it via this document which is intended for Informational publication. xxx is obligated to ... wasn't intended as a suggestions for text, but like I paraphrased the text from the draft above, and I intended it to paraphrase the the text that needs to be added. The text above quoted from the draft ...such recommendations must be taken into consideration... and I agree with that. I'll note the care in how it is worded, but it seems to flow only from IETF to IR System. Maybe I'm just being overly sensitive to the must in ...such recommendations must be taken into consideration But, it seems to me that this says IR System must defer judgements on technical issues to the IETFs technical recommendations, even if they are old, crufty, and been left in dust by the march of technology. 2) More importantly, who is the IETF in such a construct? Would such a task (of periodically pondering if these recommendations need updating) fall to the IAB or IESG? (I hadn't realized that they needed extra work... ;-) I believe that when you consider that we each individually are the IETF (i.e. all of the folks who participate in the working groups and writing drafts) then it is clear that any obligation to update these technical recommendations periodically would fall to those with an interest in keeping them current. You might even say that's what Russ, David, Geoff, and I are finally getting around to doing via this draft, at least for one of the key documents. This is a common problem of community based, we are them they are us, type pseudo-organizations. FYI, /John Disclaimers: My views alone. If you are reading this email long after publication, this email may be out-of-date and I do not commit to updating its contents. ;-) All I ask is you admit you changed you mind, you have the right to do that. But, when the IETF changes it's mind by changing its consensus, then it needs to deprecate its old technical recommendations, or make sure everyone else is free to ignore the recommendations. -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
Re: Less Corporate Diversity
On Wed, Mar 20, 2013 at 03:18:24PM -0400, Eric Burger wrote: How much is the concentration of corporate participation in the IETF a result of market forces, like consolidation and bankruptcy, as opposed to nefarious forces, like a company hiring all of the I* leadership? We have mechanisms to deal with the latter, but there is not much we can do about the former. Having started in the IETF at a much smaller vendor, it's less a nefarious thing than it is a money thing. When you're talking about participation at the conferences, the cost of flying someone to the venue, paying for the conference fee and covering hotel can be a big burden for smaller companies. They then have to pick and choose which groups it makes sense to get a human to attend. Even on-the-list participation can be a financial burden. Someone has to spend a chunk of their time doing standards work instead of other things like code. I* leadership is even messier. IETF is effectively asking for half or more of the time of those people. They are effectively being given a form of patronage to do IETF work. -- Jeff
Re: Please review draft-housley-rfc2050bis-00.txt
At 12:43 20-03-2013, Elwyn Davies wrote: This contains some woolly hand-waving weasel words at the end: I looked up the meaning of weasel words and found the following: words and phrases aimed at creating an impression that something specific and meaningful has been said, when in fact only a vague or ambiguous claim, or even a refutation has been communicated. I might as well comment quickly about draft-housley-rfc2050bis-00. The draft is a good effort but it might need more work in my humble opinion. The intended status is Informational. Is there a reason for that? Why does the document obsolete RFC 2050? There is no explanation for that in the Abstract or the Introduction section. In Section 2: The Internet Assigned Numbers Authority (IANA) is the traditional name for the technical team making and publishing the assignments of Internet protocol technical parameters, including Internet Protocol (IP) address space. Is there a reference for that? As a result of a Memorandum of Understanding (MOU)[RFC2860] between the IETF, IAB, and ICANN, the technical work of the Internet Assigned Numbers Authority (IANA) is now performed by ICANN. According to RFC 2860: The memo is exclusively to define the technical work to be carried out by the Internet Assigned Numbers Authority on behalf of the Internet Engineering Task Force and the Internet Research Task Force. That does not match the as a result text. Today, IANA administers IP address space and AS numbers according to global number resource policies as developed per the agreement between ICANN and the Regional Internet Registries [ASOMOU] and documented in [ICANNv4], [ICANNv6], and [ICANNASN]. I don't see what the above has to do with structure (see section title). In Section 3: Reverse DNS: In situations where reverse DNS was used, the policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements posed by reverse DNS zone delegation [RFC3172]. According to RFC 5855: The choice of operators for all nameservers concerned is beyond the scope of this document and is an IANA function that falls under the scope of Section 4 of the MoU between the IETF and ICANN [RFC2860]. Maybe referencing RFC 5855 would be better. It may be easier not to say anything about reverse DNS. Public WHOIS: The policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements for supporting WHOIS services [RFC3013]. The specification for Whois is RFC 3912. I vaguely recall that the policy text in the previous specification was viewed as problematic by the IETF. Per the delineation of responsibility for Internet address policy issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions regarding the evolution of the Internet Numbers Registry System structure, policy, and processes are to take place within the ICANN framework and will respect ICANN's core values [ICANNBL]. These core values encourage broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making, as well as the delegation of coordination functions and recognition of the policy roles of other responsible entities that reflect the interests of affected parties. The discussions regarding Internet Numbers Registry evolution must also continue to consider the overall Internet address architecture and technical goals referenced in this document. Could someone please translate the above in plain English? What's the IETF angle in all that? What action is required from IANA in Section 7? Why should I read RFC 6484 to understand draft-housley-rfc2050bis-00? Regards, -sm
Re: Less Corporate Diversity
I think it is mostly market forces and historical reasons, and the development of the IETF to focus on more particular core aspects of the Internet (like routing) as opposed to what the small shops might work on. But I think we are missing a bit of the point in this discussion. I do not feel that we need to prove we are somehow no worse than industry average. The point is that *if* we had more diversity along many of the discussed lines, we'd be far better off. For instance, having people from multiple organisations provide input to a last would be preferable to just a few. Similarly with the other dimensions of diversity. When I talked to some of the ISOC fellows last week, I realised peering is very different on different continents. Even if there may be less economic activity on networking on those continents, it would be good for us to understand the real situations around the world, as opposed to thinking the whole world is like where we live. Diversity = good in most cases, and increasing that goodness should be the goal. Jari
Re: Please review draft-housley-rfc2050bis-00.txt
On Mar 20, 2013, at 3:25 PM, David Farmer far...@umn.edu wrote: xxx is obligated to ... wasn't intended as a suggestions for text, but like I paraphrased the text from the draft above, and I intended it to paraphrase the the text that needs to be added. The text above quoted from the draft ...such recommendations must be taken into consideration... and I agree with that. I'll note the care in how it is worded, but it seems to flow only from IETF to IR System. The IETF defines the protocols, including the parameter fields. While the application of the protocols is up to the community, the IETF does also on occasional state known technical recommendations or constraints in usage of its technical standards. The original RFC2050 specified such technical constraints, the RIR/operator community has generally respected them over time, and hence they've been included in the revised text. Maybe I'm just being overly sensitive to the must in ...such recommendations must be taken into consideration But, it seems to me that this says IR System must defer judgements on technical issues to the IETFs technical recommendations, even if they are old, crufty, and been left in dust by the march of technology. We have existence proof that the Internet Number Registry system is quite capable of determining when circumstances have changed and while generally considering important advice, e.g. hierarchical assignment, the registries have indeed evolved policy as necessary and specified by the community. Note also that that the actual text does not at all say defer judgements on technical issues to the IETF's technical recommendations, but instead that those recommendations must be considered in policy discussions: In addition, in the cases where the IETF sets technical recommendations for protocols, practices, or services which are directly related to IP address space or AS numbers, such recommendations must be taken into consideration in Internet Numbers Registry System policy discussions regardless of venue. I understand that you're seeking assurances that the IETF will dynamically update any documents that affects the Internet Number Registry System, but reality is that it takes specific efforts to make that happened (and they don't always converge with productive output.) This effort to update RFC2050 is at least a step towards getting better alignment than we have today. FYI, /John Disclaimers: My views alone. No header fields were harmed in the making of this email.
Re: Less Corporate Diversity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/20/13 2:37 PM, Jeffrey Haas wrote: On Wed, Mar 20, 2013 at 03:18:24PM -0400, Eric Burger wrote: How much is the concentration of corporate participation in the IETF a result of market forces, like consolidation and bankruptcy, as opposed to nefarious forces, like a company hiring all of the I* leadership? We have mechanisms to deal with the latter, but there is not much we can do about the former. Having started in the IETF at a much smaller vendor, it's less a nefarious thing than it is a money thing. When you're talking about participation at the conferences, the cost of flying someone to the venue, paying for the conference fee and covering hotel can be a big burden for smaller companies. They then have to pick and choose which groups it makes sense to get a human to attend. Even on-the-list participation can be a financial burden. Someone has to spend a chunk of their time doing standards work instead of other things like code. I* leadership is even messier. IETF is effectively asking for half or more of the time of those people. They are effectively being given a form of patronage to do IETF work. +1 When I worked at a small vendor, I attended IETF meetings only when there was work happening directly related to what my company care about. I *might* have been able to be a WG chair, but there is no way I could have been an area director until after our small company was acquired by Cisco. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRSkK+AAoJEOoGpJErxa2pKAoP/ibKBeI4RBuP8dGnuFqOqALX JhgeStw0SMainyQ2YvLXXlFueQzAn3+mMpLa4OsnsvaBSZMhX/hvxDbRD5OA9rFT Jock8WteQHJwi9pj4GIVA5Ck9JctxHeHXpe33tDVlDcoqYyGafO9Y+r+JZqnwjYo Ao6iNLz6MMOXnhZwbWcnLjP5AcA72R0oevdB6h01F00gqhi2E90Pao/2Lup6V7q8 6qP6S5ZqCxnio/pSMMorv3tyDl3FvARn03vLhyx1E1BAT0Dyz8aikhr3uG/ajqE0 2b51YxJdfnvnAyEEkAAtpk7RMkgTV3be5ghB0cMQMwAClwKcbQ0VUtlUEEemi0rO LFEWHQxEuk+phTC93NJN/a5topZAQ2401uTl+prye8niT05H/aSx+7oGXOlLNjXQ 5SCmCExcFzitVDx3O3vUaBbmLKdK0l3Tn7kBGAV4XRhLRXkDaY7lA9+ML19olK7J x9jvqvJs2CaD3+iJoss2LqNJikIjQ0MOeECwVa8RKZzXCaW35WxP/QQC44teHw3S lhra+sglrCiiElW7dBp62Jm8o9Qj+wsLBHL881R/rDAm10QmpJ+onbRc2AM0mgVM JY/S4wpLjtEqDVoj9f80DuuTAEMj4FfhaKAcImLVOMJCQ8oas7fPZ9K/t2abus9j wWCL8CONclaQ81gZHrEt =X3gZ -END PGP SIGNATURE-
Re: Less Corporate Diversity
Jari Arkko wrote: But I think we are missing a bit of the point in this discussion. I do not feel that we need to prove we are somehow no worse than industry average. The point is that *if* we had more diversity along many of the discussed lines, we'd be far better off. For instance, having people from multiple organisations provide input to a last would be preferable to just a few. Similarly with the other dimensions of diversity. When I talked to some of the ISOC fellows last week, I realised peering is very different on different continents. I'm far from convinced that the IETF would be better off with strong diversity (company-wise and cultural-wise). This probably begs for clarification how we define better off in the first place. The more diverse the culture, the higher the probability for miscommunication (misunderstanding and taking offense). The more more diverse the (interests) of the affiliations of IETF participants and IETF leadership, the hotter the dicussions typically burn on contentious issues (ratholing). That is at least my very personal perception (over the past 18 years, but admittedly from just a few WGs in the security area, that are probably not representative of the IETF in general). This does *NOT* mean that that I am opposed to diversity in any way. But I do not believe that more diversity will unconditionally improve the situation. http://4.bp.blogspot.com/_W7qnSgy4xWo/TI_htYJ9pqI/ADM/AdNqCzCBz14/s640/Too+many+cooks+spoil+the+broth.jpg While I agree that it helps avoiding a few big vendors bias. is this really a significant problem _today_, adversely affecting a non-marginal amount of the current IETF output, and in a fashion where simply more diversity in the I* leadership would bring a noticable improvement--without that same change adversely affecting the amount and quality of the *other* IETF output? -Martin
Re: Less Corporate Diversity
On 3/20/13 3:20 PM, Martin Rex wrote: While I agree that it helps avoiding a few big vendors bias. is this really a significant problem _today_, adversely affecting a non-marginal amount of the current IETF output, and in a fashion where simply more diversity in the I* leadership would bring a noticable improvement--without that same change adversely affecting the amount and quality of the *other* IETF output? I think it would improve the quality of stewardship and review, and the understanding of what's going on in the industry and where the needs and priorities are. I also think that the very distinct western bias in the leadership means that there's a distinct lack of familiarity with deployment and management models being used (or assumed) by a growing portion of IETF participants. I also expect that I am not the only participant who's a consultant and at least partly self-funded and regularly coming to meetings, but there will always be folks saying that we don't exist, even as people seem to not want to acknowledge that there were a lot of women who'd accepted IESG nominations this cycle. But, I do think that given our decision-making structures and so on, and given the speed with which people I thought knew better zoomed over to the NO QUOTAS! place when the issue was raised, this situation is basically irreparable. Melinda
Re: Please review draft-housley-rfc2050bis-00.txt
On Mar 20, 2013, at 4:04 PM, SM s...@resistor.net wrote: I might as well comment quickly about draft-housley-rfc2050bis-00. The draft is a good effort but it might need more work in my humble opinion. The intended status is Informational. Is there a reason for that? The RFC is not intended to establish anything new, only to recognize the existing agreements and practices of the IETF in this area. Why does the document obsolete RFC 2050? There is no explanation for that in the Abstract or the Introduction section. The explanation is in Section 5 (Summary of Changes Since RFC 2050); isn't that usual practice for an RFC which replaces another in entirety? In Section 3: Reverse DNS: In situations where reverse DNS was used, the policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements posed by reverse DNS zone delegation [RFC3172]. According to RFC 5855: The choice of operators for all nameservers concerned is beyond the scope of this document and is an IANA function that falls under the scope of Section 4 of the MoU between the IETF and ICANN [RFC2860]. Maybe referencing RFC 5855 would be better. It may be easier not to say anything about reverse DNS. The text in RFC 5855 that you reference is with respect only to the two top-level reverse domains, i.e. all nameservers concerned is preceded by: 1. IN-ADDR-SERVERS.ARPA to the nameservers listed in Section 2; 2. IP6-SERVERS.ARPA to the nameservers listed in Section 3. Per the delineation of responsibility for Internet address policy issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions regarding the evolution of the Internet Numbers Registry System structure, policy, and processes are to take place within the ICANN framework and will respect ICANN's core values [ICANNBL]. These core values encourage broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making, as well as the delegation of coordination functions and recognition of the policy roles of other responsible entities that reflect the interests of affected parties. The discussions regarding Internet Numbers Registry evolution must also continue to consider the overall Internet address architecture and technical goals referenced in this document. Could someone please translate the above in plain English? What's the IETF angle in all that? It looks to be plain English to me... can you be more specific about what part of the text which is problematic? Why should I read RFC 6484 to understand draft-housley-rfc2050bis-00? I believe this is a trailing reference that should be deleted at this point. Thanks for the comments! /John Disclaimers: My views alone. Use care in opening; contents may have shifted during electronic flight.
Re: Less Corporate Diversity
Melinda Shore wrote: Martin Rex wrote: While I agree that it helps avoiding a few big vendors bias. is this really a significant problem _today_, adversely affecting a non-marginal amount of the current IETF output, and in a fashion where simply more diversity in the I* leadership would bring a noticable improvement--without that same change adversely affecting the amount and quality of the *other* IETF output? I think it would improve the quality of stewardship and review, and the understanding of what's going on in the industry and where the needs and priorities are. I also think that the very distinct western bias in the leadership means that there's a distinct lack of familiarity with deployment and management models being used (or assumed) by a growing portion of IETF participants. I'm having difficulties to follow (but I'm also new to diversity discussions). It is my understanding that work in the IETF is done by individual participants within Working Groups or as individuals. Review seems to happen within WGs, and the review work(load) seems to have significantly shifted from ADs to Directorates. The IETF rough consensus model with its (1- or 2-level) Last Calls is intended to ensure resolution of objections or technical concerns, even when raised by only one single IETF participant. My impression of todays IESG role, in particular taking their balloting rules and their actual balloting results into account, is more of a confirming body of work that happened elsewhere (primarily in the IETF, typically in IETF WGs, but also individual or interest groups submissions from elsewhere, though the latter mostly for (re)publication as informational). IMHO, the IESG is not (and maybe never was?) a committee where _each_ member reviews _all_ of the work, where _each_ forms his very own opionion, and where all of them caste a VOTE at the end, so that the diversity within that committee would be vitally beneficial (to anything). But, I do think that given our decision-making structures and so on, and given the speed with which people I thought knew better zoomed over to the NO QUOTAS! place when the issue was raised, this situation is basically irreparable. The leadership in the IETF is not limtied to I* positions. To me, it appears that WG chairs (can) have (if they so desire)at least as much impact on actual work that happens in WGs as the responsible AD, and directorate review of documents is at least as relevant as reviews of individual ADs (if not more), and both of these functions (WG Chair) and directorate participation seem to require much less timemonetary investments from IETF participants than I* functions, and the positions outnumber the I* positions probably by a magnitude. -Martin
Re: Less Corporate Diversity
On 3/20/13 4:51 PM, Martin Rex wrote: I'm having difficulties to follow (but I'm also new to diversity discussions). It is my understanding that work in the IETF is done by individual participants within Working Groups or as individuals. Review seems to happen within WGs, and the review work(load) seems to have significantly shifted from ADs to Directorates. With all due respect, I can't find any RFCs you've authored or working groups you've chaired. Or, for that matter, any current internet drafts. I absolutely could have missed something and I hope that if I'm wrong you'll correct me. However, if I'm not wrong, you haven't been through the process of bringing work into the IETF, socializing it, and trying to get it published or adopted, in which case you're missing a lot. Melinda
RE: [apps-discuss] Last Call: draft-ietf-appsawg-webfinger-10.txt (WebFinger) to Proposed Standard
Alissa, It was suggested that we remove the word implicit. I'm OK with removing it. If we did that, would you want to add this new sentence or a modified version of it? Paul -Original Message- From: apps-discuss-boun...@ietf.org [mailto:apps-discuss- boun...@ietf.org] On Behalf Of Alissa Cooper Sent: Monday, March 18, 2013 11:31 AM To: ietf@ietf.org Cc: apps-disc...@ietf.org Subject: Re: [apps-discuss] Last Call: draft-ietf-appsawg-webfinger- 10.txt (WebFinger) to Proposed Standard Given how little control Internet users already have over which information about them appears in which context, I do not have a lot of confidence that the claimed discoverability benefits of WebFinger outweigh its potential to further degrade users' ability to keep particular information about themselves within specific silos. However, I'm coming quite late to this document, so perhaps that balancing has already been discussed, and it strikes me as unreasonable to try to stand in the way of publication at this point. Two suggestions in section 8: s/personal information/personal data/ (see http://tools.ietf.org/html/draft-iab-privacy-considerations- 06#section-2.2 -- personal data is a more widely accepted term and covers a larger range of information about people) The normative prohibition against using WebFinger to publish personal data without authorization is good, but the notion of implicit authorization leaves much uncertainty about what I imagine will be a use case of interest: taking information out of a controlled context and making it more widely available. To make it obvious that this has been considered, I would suggest adding one more sentence to the end of the fourth paragraph: Publishing one's personal data within an access-controlled or otherwise limited environment on the Internet does not equate to providing implicit authorization of further publication of that data via WebFinger. Alissa On Mar 4, 2013, at 3:24 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'WebFinger' draft-ietf-appsawg-webfinger-10.txt as 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 2013-03-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ No IPR declarations have been submitted directly on this I-D. ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss
RE: Less Corporate Diversity
An ad-hominem argument, Melinda? really? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Melinda Shore [melinda.sh...@gmail.com] Sent: 21 March 2013 01:01 To: m...@sap.com Cc: ietf@ietf.org Subject: Re: Less Corporate Diversity On 3/20/13 4:51 PM, Martin Rex wrote: I'm having difficulties to follow (but I'm also new to diversity discussions). It is my understanding that work in the IETF is done by individual participants within Working Groups or as individuals. Review seems to happen within WGs, and the review work(load) seems to have significantly shifted from ADs to Directorates. With all due respect, I can't find any RFCs you've authored or working groups you've chaired. Or, for that matter, any current internet drafts. I absolutely could have missed something and I hope that if I'm wrong you'll correct me. However, if I'm not wrong, you haven't been through the process of bringing work into the IETF, socializing it, and trying to get it published or adopted, in which case you're missing a lot. Melinda
RE: [apps-discuss] Last Call: draft-ietf-appsawg-webfinger-10.txt (WebFinger) to Proposed Standard
Hannes, I was hoping that some of the remarks that I provided last year (e.g., http://www.ietf.org/mail-archive/web/oauth/current/msg08965.html) would help to clarify the content of the document. That didn't quite happen... Yeah, I wasn't copied. In earlier versions of the document I had the impression that the acct: URI scheme always had to be used as input to the lookup process but as Section 4.5 explains this is not necessary. The resource parameter may contain other URIs as well. Section 4.5 does not give a lot of description of when certain URIs are utilized. Correct, any URI might be used. That does not mean that the server will respond for every URI, but some wanted acct and email and tel URIs, for example. Also, using an HTTP URI could be used to return additional information about a URI. For example, in Section 3.1 the example talks about a user receiving an email from b...@examle.com and this email address is then used by WebFinger but the request example shows an acct: URI scheme (rather than a mailto URI). It seems that there is the unstated assumption (at least in that example) that the mailto URI is the same as the acct: URI, which of course isn't necessarily the case. I believe it would be good to state these assumptions to avoid confusing the reader. Fair point. How about immediately following the example, we add: 'Note the assumption made in above example that there is an acct URI for the given mailto URI. This is not always the case.' Think about it: If you receive a SIP URI (which also has an email alike structure with a username @ domain part) that does not mean either that you can use this as an email address either. In some rare cases you might. That's definitely true. However, this is one reason for encouraging the use of the acct URI scheme, though. In general (though not always), there is account associated with the user. The SIP URI, mailto URI, etc., each have a user part. I believe it is a reasonable assumption that there *may be* an 'acct' URI for the user. If not, WF will return nothing. We intended WF to be useful to humans, too, which means that if a user sees pau...@packetizer.com, the user will assume that might be a means of reaching paulej at packetizer.com using any number of tools (email, XMPP, H.323, etc.). They would be correct for most. Thus, there is encouragement for WF servers to use the acct URI. If you believe that everyone would get the difference anyway (because the URI scheme determines the semantic of the identifier) then have a look at the Google WebFinger page (see http://code.google.com/p/webfinger/). At least these guys don't understand the difference either. There was even a proposal that we use no URI scheme at all and merely have the user@domain identifier. However, there is value in using a proper URI with WF, since querying h323:pau...@packetizer.com might return the address of my Gatekeeper, for example, versus the information that would be returned for my account. In general, I am wondering whether there are additional assumptions implied about the URI scheme associated with the identifier in the lookup mechanism. For example, the text in Section 3.3 talks about email client configuration and it seems that the requestor is interested in receiving information about the email configuration based on the resource=mailto... URI scheme usage. If I use a different URI scheme (like a aaa: URI scheme) would my response look different? Yeah, it might look different. What a WF server wishes to return for a given URI is really up to the administrator. It might be that the same information is returned for any given URI scheme having the same user@domain part, but the server could return different responses. Then, there is a question about the lack of privacy considerations in the document. We do have quite a bit of text in the security considerations section. This will be called out more clearly with sub-sections, but there are at least three full paragraphs on privacy, even going to the point of providing the example that sharing location information might put a person in danger from someone who wishes to inflict harm on them. Personally, I thought that went a bit overboard, but that text was requested, so it's there. The usage of the WebFinger mechanism requires the requestor to have access to the full username@domain identifier. While this may be OK in some cases when the response relates very much to the specific user account it may be a problem in other cases. For example, in the OAuth case there is the idea that the user identifier may be hidden from the relying party but you have just required that identifier to be provided to the relying party to start the entire OAuth exchange (in the discovery). WF is not for use with every protocol, so I cannot address OAuth generically. However, WF *is* used as a part of OpenID Connect. So, yes, the
Re: Please review draft-housley-rfc2050bis-00.txt
Hi John, This is an individual comment. At 16:38 20-03-2013, John Curran wrote: The RFC is not intended to establish anything new, only to recognize the existing agreements and practices of the IETF in this area. Ok. I'll defer to the learned individuals of the IETF in respect to the intended status. It is my understanding that the document also aims to replace BCP 12. The explanation is in Section 5 (Summary of Changes Since RFC 2050); isn't that usual practice for an RFC which replaces another in entirety? I can only express an individual opinion and not what is usual practice for an RFC. The few drafts I have read usually had an explanation in the Introduction section to help the reader. I don't feel strongly about this. I am more interested in seeing whether the IESG will file a DISCUSS about this. By the way the summary of changes is very short. The text in RFC 5855 that you reference is with respect only to the two top-level reverse domains, i.e. all nameservers concerned is preceded by: 1. IN-ADDR-SERVERS.ARPA to the nameservers listed in Section 2; 2. IP6-SERVERS.ARPA to the nameservers listed in Section 3. I preferred not to quote RFC 5855 in its entity. My reading of that document and the discussions leading to it is that it is up to the IAB to provide technical guidance to ICANN about .arpa (re. reverse DNS). I don't see any mention of Internet Numbers Registry System in RFC 3172 or RFC 5855. I can only say that in my opinion the omission of the finer details does not have any negative consequences for the RIRs. It looks to be plain English to me... can you be more specific about what part of the text which is problematic? Per the delineation of responsibility for Internet address policy issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions regarding the evolution of the Internet Numbers Registry System structure, policy, and processes are to take place within the ICANN framework and will respect ICANN's core values [ICANNBL]. How does the above affect the IETF, e.g. what process changes happened between RFC 2050 and draft-housley-rfc2050bis-00? Why is it even relevant to the IETF? These core values encourage broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making, as well as the delegation of coordination functions and recognition of the policy roles of other responsible entities that reflect the interests of affected parties. I do not understand what the above means in practice. The IETF is having a lengthy discussion about diversity. The IETF community might learn from ICANN if it shares its experience of how it has successfully tackled cultural diversity. The discussions regarding Internet Numbers Registry evolution must also continue to consider the overall Internet address architecture and technical goals referenced in this document. After reading draft-housley-rfc2050bis-00 it is my understanding that the Internet Numbers Registry is out of scope for the IETF. I read the above as meaning that the IETF is telling RIRs and ICANN that they must also follow technical guidance from the IETF in respect to the Internet address archtecture. The foregoing does not alter the IETF's continued responsibility for the non-policy aspects of Internet addressing such as the architectural definition of IP address and AS number spaces and specification of associated technical goals and constraints in their application, assignment of specialized address blocks, and experimental technical assignments as documented in RFC 2860. The above sounds like something from the legal department. I unfortunately cannot hire a lawyer to tell me whether that text matches the text in RFC 2860. I don't see how one can expect informed participation when the text to be read might be unclear to the people from the rest of the world. As an off-topic comment, it seems like there hasn't been careful review of an IANA policy for ASNs. The wise members of the IESG would have caught the bug. By the way I read my previous message [1] again and the reply [2] I received and I noticed that there wasn't any response to two of the questions. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg78135.html 2. http://www.ietf.org/mail-archive/web/ietf/current/msg78141.html
Re: Less Corporate Diversity
--On Wednesday, March 20, 2013 23:36 +0100 Jari Arkko jari.ar...@piuha.net wrote: I think it is mostly market forces and historical reasons, and the development of the IETF to focus on more particular core aspects of the Internet (like routing) as opposed to what the small shops might work on. I mostly agree. However, I see lots of activity in Apps and RAI, very little of which would seem to be core aspects of the Internet. Also, given the cost factor, the length of time it usually seems to take us to spin up a WG and get anything done is probably also a significant barrier: a small shop who could afford to send someone to a meeting or three might have neither the people-resources nor travel and meeting budget to commit to a few years of meetings. But I think we are missing a bit of the point in this discussion. I do not feel that we need to prove we are somehow no worse than industry average. The point is that *if* we had more diversity along many of the discussed lines, we'd be far better off. For instance, having people from multiple organisations provide input to a last would be preferable to just a few. Similarly with the other dimensions of diversity. When I talked to some of the ISOC fellows last week, I realised peering is very different on different continents. I have run across another example fairly often that was, I think, mentioned briefly last week. Most of us are used to network connections of very high bandwidth and quality. Our protocol designs and implementations are developed and tested on those networks and, usually, on the very latest and most powerful equipment. The IETF would almost certainly benefit from vigorous input from people whose environments are characterized by longer delays, serious congestion, packet fragmentation, and so on. Without them, I fear that implementations of a lot of our work, and maybe the work itself, will not be acceptable in lower-end or more congested networks or from computer systems more typical of that average Internet user and that they will not have the level of robustness that ought to be one of the Internet's strengths. Even if there may be less economic activity on networking on those continents, it would be good for us to understand the real situations around the world, as opposed to thinking the whole world is like where we live. Diversity = good in most cases, and increasing that goodness should be the goal. Indeed. And, taking the comment above a step further, one need only go to a sufficiently rural area in many developed countries --one that is served exclusively by overloaded high orbit satellite links (with the delay times that implies) -- to encounter the problem even though people from other continents are more likely to be articulate about the issues and easier to get to the IETF then those rural users. john
Re: Please review draft-housley-rfc2050bis-00.txt
On Mar 20, 2013, at 8:45 PM, SM s...@resistor.net wrote: Ok. I'll defer to the learned individuals of the IETF in respect to the intended status. It is my understanding that the document also aims to replace BCP 12. Excellent question; it's my belief that obsoleting RFC2050 would do that, but perhaps it would be best to make that point more specific in this document? I can only say that in my opinion the omission of the finer details does not have any negative consequences for the RIRs. IN-ADDR maintenance is explicitly in RFC 2050, and has not been overtaken by events to my knowledge, hence it is included in this successor document. Per the delineation of responsibility for Internet address policy issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions regarding the evolution of the Internet Numbers Registry System structure, policy, and processes are to take place within the ICANN framework and will respect ICANN's core values [ICANNBL]. How does the above affect the IETF, e.g. what process changes happened between RFC 2050 and draft-housley-rfc2050bis-00? Why is it even relevant to the IETF? The IETF/IAB signed an MOU with ICANN for performance of certain IANA tasks, including a framework which recognized that ICANN would be dealing with policy issues related to the domain name system and the IP address system. At the same time, the Regional Internet Registries worked with ICANN to perform the community- based regional and global IP policy development coordinated with ICANN's overall framework. This is clearly a different way of establishing IP address policy than described in the current RFC2050, and hence material to the IETF. These core values encourage broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making, as well as the delegation of coordination functions and recognition of the policy roles of other responsible entities that reflect the interests of affected parties. I do not understand what the above means in practice. There are lots of folks over in the DNS world wondering that same question... ;-) Seriously, one could write volumes about ICANN, its structure, processes oversight role, etc., but at the end of the day you'd be creating a fixed copy of what is an evolving organization. The IETF does not decide today when and which new top-level domains are added to the DNS root, that is an example of a question which requires broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making. The discussions regarding Internet Numbers Registry evolution must also continue to consider the overall Internet address architecture and technical goals referenced in this document. After reading draft-housley-rfc2050bis-00 it is my understanding that the Internet Numbers Registry is out of scope for the IETF. I read the above as meaning that the IETF is telling RIRs and ICANN that they must also follow technical guidance from the IETF in respect to the Internet address archtecture. The IETF defines the architecture of the Internet Protocol, and this includes the IP address space. Regardless of whether policy development has been delegated to the RIRs under the ICANN framework, the address architecture is still established by the IETF. The foregoing does not alter the IETF's continued responsibility for the non-policy aspects of Internet addressing such as the architectural definition of IP address and AS number spaces and specification of associated technical goals and constraints in their application, assignment of specialized address blocks, and experimental technical assignments as documented in RFC 2860. The above sounds like something from the legal department. I unfortunately cannot hire a lawyer to tell me whether that text matches the text in RFC 2860. I don't see how one can expect informed participation when the text to be read might be unclear to the people from the rest of the world. To my knowledge, it does correctly represent the terms in RFC 2860, but I understand that the language is rather dense and may be hard to parse. We do not want to repeat the entirety of RFC 2860 here, but it is useful for readers to know that per that MOU, there is a has a delineation of responsibilities between the IETF and the ICANN/RIR system. By the way I read my previous message [1] again and the reply [2] I received and I noticed that there wasn't any response to two of the questions. Agreed. I commented on those aspects where my remarks may add value to the discussion; there are others on this list with greater experience and knowledge which may help with other questions you have raised. Thanks for the feedback - I hope I've helped explain at least some of the
Re: Diversity of IETF Leadership
On Wed, Mar 20, 2013 at 03:59:34PM -0400, Jeffrey Haas wrote: On Wed, Mar 20, 2013 at 03:13:01PM -0400, Sam Hartman wrote: Part of what I meant when I signed the diversity letter was to state a belief that within a pool of qualified candidates, I believe diversity is important enough that it is valuable to select for diversity even if this does not maximize the skills that you enumerated (tech skill, admin skill, works with others and something else). Maximize overstates my position. My belief is once the base requirements are met that diversity is an appropriate tie-breaker. Maximizing the four I mentioned is different. I think that diversity is already taken into account much more than just as a tie-breaker. Nomcon does look at a lot of the factors influenced by the candidates background / diversity stats already as actual job qualifications: Knowlege/presence of geographic regions, collaborative influencing leadership stle, ability to engage with other cultures, etc. pp. Cheers Toerless
Re: Less Corporate Diversity
On 3/20/2013 3:18 PM, Eric Burger wrote: How much is the concentration of corporate participation in the IETF a result of market forces, like consolidation and bankruptcy, as opposed to nefarious forces, like a company hiring all of the I* leadership? We have mechanisms to deal with the latter, but there is not much we can do about the former. I am not catching the question. Are you concern there is an increasing potential for a conflict of interest loophole the IETF may no longer afford to manage and control? We will always have Cooperative Competition. The IETF damage can only be to sanction the standardization of a problematic method or technology and/or the straggle hold of a market direction. Generally, the market will speak for itself. We need the market and technology leaders for the rest to follow, but the IETF role should continue to be the gatekeeper and watchdog for open and public domain standards. -- HLS
Last Call: draft-ietf-dnsext-dnssec-algo-signal-09.txt (Signaling Cryptographic Algorithm Understanding in DNSSEC) to Proposed Standard
The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Signaling Cryptographic Algorithm Understanding in DNSSEC' draft-ietf-dnsext-dnssec-algo-signal-09.txt as 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 i...@ietf.org mailing lists by 2013-04-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/ballot/ No IPR declarations have been submitted directly on this I-D.
New Non-WG Mailing List: aqm -- Active Queue Management
A new IETF non-working group email list has been created. List address: a...@ietf.org Archive: http://www.ietf.org/mail-archive/web/aqm/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/aqm Purpose: This list is for discussing requirements, recommendations, algorithms, evaluation techniques, and other topics related to active queue management algorithms and methods for protecting flows from one another at a bottleneck. For additional information, please contact the list administrators.
Thank you to Monique Morrow for her service as ITU-T NGN liaison manager
Next time you see Monique, please thank her for he service the the Internet community. From: IAB Chair [iab-ch...@iab.org] Sent: Tuesday, March 12, 2013 5:04 PM To: Monique Morrow Subject: Thank you for your service as NGN liaison manager Dear Monique, The IETF relies on members of the community to volunteer for key roles in our organization. You have provided a great example for this spirit of volunteerism through your role as the IETF liaison manager for Next Generation Networking (NGN) to the ITU-T. You provided the ITU-T program valuable information about activities in study groups 11 and 13, and provided us the opportunity to engage the appropriate people to address early on areas of mutual interest to both organizations, in a way that avoided conflict. The IAB thanks you for this service and we hope that you may be called upon in the future for other roles. On behalf of the IAB, Bernard Aboba IAB Chair
RFC 6880 on An Information Model for Kerberos Version 5
A new Request for Comments is now available in online RFC libraries. RFC 6880 Title: An Information Model for Kerberos Version 5 Author: L. Johansson Status: Standards Track Stream: IETF Date: March 2013 Mailbox:le...@sunet.se Pages: 14 Characters: 28121 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-krb-wg-kdc-model-16.txt URL:http://www.rfc-editor.org/rfc/rfc6880.txt This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a Kerberos 5 Key Distribution Center (KDC). This document describes the services exposed by an administrative interface to a KDC. This document is a product of the Kerberos WG Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6884 on RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)
A new Request for Comments is now available in online RFC libraries. RFC 6884 Title: RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) Author: Z. Fang Status: Standards Track Stream: IETF Date: March 2013 Mailbox:zf...@qualcomm.com Pages: 21 Characters: 43207 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-avt-rtp-evrc-nw-10.txt URL:http://www.rfc-editor.org/rfc/rfc6884.txt This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email. This document is a product of the Audio/Video Transport Payloads Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6893 on A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF)
A new Request for Comments is now available in online RFC libraries. RFC 6893 Title: A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF) Author: P. Higgs, P. Szucs Status: Informational Stream: IETF Date: March 2013 Mailbox:paul.hi...@ericsson.com, paul.sz...@eu.sony.com Pages: 8 Characters: 12403 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-higgs-oipf-urn-00.txt URL:http://www.rfc-editor.org/rfc/rfc6893.txt This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications. Example resources include technical documents and specifications, eXtensible Markup Language (XML) schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the OIPF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6903 on Additional Link Relation Types
A new Request for Comments is now available in online RFC libraries. RFC 6903 Title: Additional Link Relation Types Author: J. Snell Status: Informational Stream: Independent Date: March 2013 Mailbox:jasn...@gmail.com Pages: 6 Characters: 10452 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-snell-additional-link-relations-07.txt URL:http://www.rfc-editor.org/rfc/rfc6903.txt This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6906 on The 'profile' Link Relation Type
A new Request for Comments is now available in online RFC libraries. RFC 6906 Title: The 'profile' Link Relation Type Author: E. Wilde Status: Informational Stream: Independent Date: March 2013 Mailbox:erik.wi...@emc.com Pages: 8 Characters: 18469 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-wilde-profile-link-04.txt URL:http://www.rfc-editor.org/rfc/rfc6906.txt This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
