Re: IETF Diversity
From: Doug Barton do...@dougbarton.us their work has been ignored and/or shouted down since it doesn't fit the narrative. The usual fate of those who care more about the data than the herd-meme of the moment. For a good example of this in action, those who are unfamiliar with the work of Barbara McClintock should try looking her up. (She actually stopped publishing because the reception given to her work was so negative.) (In honour of the thread, I have carefully picked a female example. Is that being sensitive, or patronizing? Left as an exercise for the reader...) Noel
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
I'm fine with this text. Either with eap-lower-layer as a MUST or the more complex version.
Re: Reducing Internet Latency Workshop
Hi Matt, I currently writing a position paper but I'm travel tomorrow and over the weekend and am not sure if I will be able to finish the paper today. Is it maybe possible to submit the paper a couple days later? Mirja On Friday 14 June 2013 10:42:43 Matthew Ford wrote: Possibly of interest. (Short) Position paper deadline is 23rd June. Regards, Mat Workshop on Reducing Internet Latency = 25 - 26 September 2013 London, England Latency tends to have been sacrificed in favour of headline bandwidth in the way the Internet has been built. This two-day invitation-only workshop aims to galvanise action to fix that. All layers of the stack are in scope. Latency is an increasingly important topic for networking researchers and Internet practitioners alike. Data from Google, Microsoft, Amazon and others indicate that latency increases for interactive Web applications result in less usage and less revenue from sales or advertising income. Whether trying to provide platforms for Web applications, high-frequency stock trading, multi-player online gaming or 'cloud' services of any kind, latency is a critical factor in determining end-user satisfaction and the success of products in the marketplace. Consequently, latency and variation in latency are key performance metrics for services these days. But latency reduction is not just about increasing revenues for big business. Matt Mullenweg of WordPress motivates work on latency reduction well when he says, My theory here is when an interface is faster, you feel good. And ultimately what that comes down to is you feel in control. The [application] isn’t controlling me, I’m controlling it. Ultimately that feeling of control translates to happiness in everyone. In order to increase the happiness in the world, we all have to keep working on this. Invitations to attend the workshop will depend on receipt of a position paper. In a spirit of co- ordination across the industry, submissions are encouraged from developers and network operators as well as the research and standards communities. A wide range of latency related topics are in scope including, but not limited to: - surveys of latency across all layers - analyses of sources of latency and severity/variability - the cost of latency problems to society and the economy, or the value of fixing it - principles for latency reduction across the stack - solutions to reduce latency, including cross-layer - deployment considerations for latency reducing technology - benchmarking, accreditation, measurement and market comparison practices Submissions --- This is an invitation-only workshop. Prospective participants must submit short (up to 2 pages) position papers outlining their views on a specific aspect of the overall scope. The emphasis here is on relevance and brevity - you do not need to write a lot of text, just demonstrate that you have thought about the problem space and have something interesting to say on the topic. Please send position papers in PDF format to: late...@isoc.org Participant numbers will be limited to focus on discussion and identifying actions rather than slideware. Accepted position papers will be made public. A report on the workshop will be published after participants have agreed the content. Therefore, it will be possible to state views during the workshop without them being publicly attributed. Important Dates --- Position paper submission deadline: 23 June 2013 Paper acceptance notification: 28 June 2013 Workshop dates: 9am, Wednesday 25th – 5pm, Thursday 26th September 2013 Program committee - Mat Ford, Internet Society, co-chair Bob Briscoe, BT, co-chair Gorry Fairhurst, University of Aberdeen Arvind Jain, Google Jason Livingood, Comcast Andrew McGregor, Google Workshop venue and other details Venue: Hilton London Paddington Hotel, 146 Praed Street, LONDON W2 1EE, UK Registration fee: There is no registration fee for the workshop. Recommended accommodation: Hilton London Paddington, registration link will be supplied to accepted participants. The workshop is sponsored by the Internet Society, the RITE project, Simula Research Labs and the TimeIn project. The Internet Society will host a workshop dinner on the Wednesday evening.
Re: IETF Diversity
On Thu, Jun 20, 2013 at 3:12 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote: From: Doug Barton do...@dougbarton.us their work has been ignored and/or shouted down since it doesn't fit the narrative. The usual fate of those who care more about the data than the herd-meme of the moment. For a good example of this in action, those who are unfamiliar with the work of Barbara McClintock should try looking her up. (She actually stopped publishing because the reception given to her work was so negative.) But she won huge praise in the end, which says something ultimately good about the process of science, that it can overcome the shortcomings of its practitioners. (In honour of the thread, I have carefully picked a female example. Is that being sensitive, or patronizing? Yes.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On Jun 19, 2013, at 9:29 AM, joel jaeggli joe...@bogus.com wrote: Given that this document was revved twice and had it's requested status change during IETF last call in response to discussion criticism and new contribution I am going to rerun the last call. I reviewed this version and I think this is a fine document that I support. In particular the document goes out of its way to address the issues raised in prior IETF last call to the extent possible. The document is going to be the specification of two DNS RRtypes that have been allocated via expert review, we (DNS community) want to encore that any such allocations be published as RFC's for future references. This document is not a product of any working group. Olafur (DNSEXT co-chair)
JOSE Virtual Interim 6/17 mixup
There was an intent to have a virtual meeting of the JOSE WG on 2013-06-17. The announcement never made it to the IETF announce list. Because of this that virtual meeting is considered a design team meeting and not an official virtual interim meeting. As such, all output is subject to approval, rejection or modification by the WG as a whole. The minutes of that design team have been posted here: http://www.ietf.org/proceedings/interim/2013/06/17/jose/minutes/minutes-interim-2013-jose-2 Note that the next virtual interim was properly announced: http://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=934k2=12075tid=1371735805 spt
Re: Is the IETF is an international organization? (was: IETF Diversity)
Keep in mind that you're talking to an organisation that believes that Vancouver qualifies as Asia. On 19/06/2013, at 12:07 PM, SM s...@resistor.net wrote: Hi Aaron, At 11:40 19-06-2013, Aaron Yi DING wrote: Relating to the statement above(I assume Phillip is addressing the US Academia), not quite sure are we still discussing the same topic? sorry, I am bit confused .. since IETF is an international organization. I changed the subject line as I am as confused as to whether the IETF is an international organization. There was a mention of First the Civil Rights act, then Selma... ;). I assume that the act is an Act for the United States of America. Harvard was also mentioned. I did a quick search and I found out that Harvard University is an American private Ivy League research university. Regards, -sm -- Mark Nottingham http://www.mnot.net/
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Olafur, Based on reviewing the current draft and the handling of my objections and other of others to the prior ones, I agree that the document is ready for publication. However, I feel a need to comment on one of your observations below because it seems to lie at the core of why this particular document took up so much IETF list time and correspondence. Most of that could have been avoided, IMO, and I think there is something to be learned from it to which I hope you, the DNSEXT WG, and Ted (as responsible AD) will pay attention. --On Thursday, June 20, 2013 09:39 -0400 Olafur Gudmundsson o...@ogud.com wrote: The document is going to be the specification of two DNS RRtypes that have been allocated via expert review, we (DNS community) want to encore that any such allocations be published as RFC's for future references. The IETF has historically had strong opinions about change control, consensus, and the nature of recommendations. Personally, I hope those opinions will continue and, if anything, get stronger. It seems to me that it is reasonable to say we want a lightweight registration procedure that imposes few if any requirements on allocating an RR TYPE or you can say want to ensure RFC publication but that you don't get to say both at once, especially when Standards Track or the IETF Stream are involved. If you (and DNSECT) want the very lightweight registration procedure, then you should reasonably expect to make sure that any documents are clearly informational (in content and category) and to take your chances about publication: Informational in either the IETF Stream or the Independent Submission Stream could result in a no answer or, more likely, requirements to justify the design decisions behind the RRTYPEs as a condition of publication. You can't ensure anything because the relevant groups really do get to evaluate both document quality and appropriateness for use. By contrast, if the WG really does want to ensure... then it would be appropriate to change the registration procedure so that the I-Ds are posted and RFC publication is agreed to before the RRTYPEs are registered so everyone can be sure that the two match.That could be coupled with some sort of provisional arrangement while document review is in progress, if the WG thought that was necessary. Howver the bottom line, IMO, is that, if you want RFCs and want those RFCs to accurately describe an RRTYPE and there is going to be open review during the RFC development process, you can't have lightweight registration and then insist that an RFC be published to match... at least IMO and, if the discussions of the recent Last Calls are indicative, a significant part of the the community may share that view. So some review of the DNSEXT-specified procedures and expectations may be in order. regards, john
RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
I think this is ok, but my email client isn't distinguishing the new vs. old text. If it's just changes to produce this new bullet, I have a small edit: o Channel binding MUST be used for all application authentication. The EAP server MUST either require that the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication. MUST either require that -- MUST require that either Thanks, --David From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] Sent: Wednesday, June 19, 2013 7:23 PM To: Black, David Cc: stefan.win...@restena.lu; General Area Review Team; ab...@ietf.org; ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thanks for the text, some revision to address On Jun 18, 2013, at 12:34 PM, Black, David david.bl...@emc.commailto:david.bl...@emc.com wrote: [Joe] Good points, the text can be more specific: In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For application authentication, the EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All network access EAP peer implementations SHOULD use channel bindings including the EAP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. This is looking good, modulo Sam's comment on EAP lower-layer vs. something else that I'll leave to you and he to sort out. I have a suggested rewrite, mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and to reformat into a structured bullet list of requirements (this is not intended to change any requirements from what you wrote): In environments where EAP is used for purposes other than network access authentication: o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings. o Channel binding MUST be used for all application authentication. The EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data for application authentication. o Channel binding MUST be used for all application authentication. The EAP server MUST either require that the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication. o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication. o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. Thanks, --David -Original Message- From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.comhttp://cisco.com] Sent: Tuesday, June 18, 2013 1:47 PM To: Black, David Cc: stefan.win...@restena.lumailto:stefan.win...@restena.lu; General Area Review Team; ab...@ietf.orgmailto:ab...@ietf.org; ietf@ietf.orgmailto:ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 I think we could state this a bit better as something like: In environments where EAP is used for applications authentication and network access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD support channel binding to explicitly identify the reason for authentication. Any new usage of EAP MUST support channel bindings to prevent confusion with network access usage. That text is an improvement, and it's headed in the same direction as Sam's comment - application bindings MUST be present in application authentication is a MUST use requirement, not just a MUST implement requirement. OTOH, I'm not clear on what application bindings means, as that term's not in the current draft. Specifically, I'm a bit unclear on application bindings MUST be absent in network authentication - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an application binding, whatever that is? [Joe] Good points, the text can be more specific: In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote: So some review of the DNSEXT-specified procedures and expectations may be in order. I encourage you, then, to organize the BOF session that will spin up the WG to achieve this. DNSEXT is only still alive because our last document hasn't been published. But more generally, as a practical matter it is better that people register their stuff with us than that they don't. We have, in the wild, a used EDNS0 option code that is all over the Internet. It is undocumented, and the code point isn't actually registered. That state of affairs is surely worse than that the IETF didn't get to provide good advice to authors. DNSEXT already tried to be the DNS cops, and has failed miserably, partly because of the usual get-off-my-lawn crowd and partly because people unfamiliar with the IETF find its procedures a little arcane. My view is that we need to be more pragmatic. A -- Andrew Sullivan a...@anvilwalrusden.com
NOMCOM 2013 - UPDATE of validated volunteers list so far
Below is the current validated list of volunteers for Nomcom 2013. If your name has a *, I'm waiting for a message back from you. Big thanks to everyone who has volunteered! Now what are the rest of you waiting for? We still need quite a few to get up to 200 volunteers. Please reply and volunteer - include in the email: your First Name, Last Name, email addresses you've used in the last few years in registering for IETF meetings, preferred email address, primary affiliation, and a contact phone number for use if you're selected. Thanks, Allison Mankin Nomcom 2013 Chair 1 John Scudder 2 Stephen Hanna 3 Wassim Haddad 4 Russ White 5 Stephan Wenger 6 ZHAO Yi 7 Eric Gray 8 Steve Kent 9 Toerless Eckert 10 Alia Atlas 11 Victor Kuarsingh 12 Yizhou LI 13 Gonzalo Salgueiro 14 Gang CHEN 15 Ning KONG 16 Marcelo Bagnulo 17 SHEN Shuo 沈烁 (Sean) 18 Fernando Gont 19 Glen Zorn 20 Reinaldo Penno 21 Klaas Wierenga 22 Pascal Thubert 23 Mehmet Ersue 24 Ole Troan 25 Jouni Korhonen 26 Giles Heron 27 Gunter Van de Velde 28 Arturo Servin 29 Eric Vyncke 30 Cullen Jennings 31 Tina Tsou 32 Dhruv Dhody 33 Hongyu LI (Julio) 34 Scott Mansfield 35 John Drake 36 Andrew McLachlan 37 Derek Atkins 38 Suhas Nandakumar 39 Eric Rescorla 40 Karen Seo 41 Stig Venaas 42 Stan Ratliff 43 Ignas Bagdonas 44 Peter Yee 45 Donald Eastlake 46 ZHOU Qian (Cathy) 47 Sam Hartman 48 Lixia Zhang 49 Teemu Savolainen 50 Alvaro Retana 51 Terry Manderson 52 Bill VerSteeg 53 Melinda Shore 54 IJsbrand Wijnands 55 Karen O'Donoghue 56 Benson Schliesser 57 Ari Keränen 58 Fangwei HU 59 Mach CHEN 60 Hui Deng 61 LIU Dapeng 62 Jaap Akkerhuis 63 Magnus Westerlund 64 Zehn CAO 65 Zaheduzzaman Sarker 66 Bhumip Khasnabish 67 Andrew Chi 68 Thomas Nadeau 69 Steven C (Craig) Whilte 70 Orit Levin 71 Sam Aldrin 72 Paul Ebersman 73 Christopher Liljenstolpe 74 Uma Chunduri 75 Suresh Krishnan 76 Varun Singh 77 Ron Bonica 78 Bill (William) Manning 79 Radia Perlman 80 Daniele Ceccarelli 81 Deborah Brungard 82 Kostas Pentikousis 83 Gregory Mirsky 84 Dave Sinicrope 85 Thomas Walsh 86 Zhaohui (Jeffrey) ZHANG 87 Xian ZHANG 88 Mark Townsley 89 Hannes Gredler 90 Brian Trammell 91 Carlos Martinez 92 Peter Koch 93 Daniel Migault 94 Yi (Aaron) Ding 95 Michael Richardson 96 Sohel Khan 97 John Bradley 98 Huaimo Chen 99 Matthew Campagna 100 Keith Drage 101 Chris Bowers 102 Jakob Heitz 103 Tomofumi Okubo 104 Emil Ivov 105 Timothy B. Terriberry 106 JIANG Yuanlong 107 Luigi Iannone 108 Damien Saucez 109 Lou Berger 110 Yana Stamcheva 111 Ondřej Surý 112 Marcin Pilarski 113 Michael StJohns 114 Wes George 115 Christian O'Flaherty 116 Uwe Rauschenbach 117 Olafur Gudmundsson 118 Shwetha Subray Bhandari* 119 Tobias Gondrom 120 Christer Holmberg 121 Susan Hares 122 Kiran Kumar Chittimaneni 123 Donald Fedyk 124 Stephen Botzko* 125 Li Xue* 126 John Sauer*
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 06/20/2013 09:36 AM, Andrew Sullivan wrote: On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote: So some review of the DNSEXT-specified procedures and expectations may be in order. I encourage you, then, to organize the BOF session that will spin up the WG to achieve this. DNSEXT is only still alive because our last document hasn't been published. But more generally, as a practical matter it is better that people register their stuff with us than that they don't. We have, in the wild, a used EDNS0 option code that is all over the Internet. It is undocumented, and the code point isn't actually registered. That state of affairs is surely worse than that the IETF didn't get to provide good advice to authors. DNSEXT already tried to be the DNS cops, and has failed miserably, partly because of the usual get-off-my-lawn crowd and partly because people unfamiliar with the IETF find its procedures a little arcane. My view is that we need to be more pragmatic. I agree with at least a little of what each of Olafur, John, and Andrew have said; but I think there's a middle ground between throw the doors wide open and everything we have tried before didn't work. At least I hope there is. Perhaps we could have a non-WG mailing list so that people could submit proposals for review prior to the expert review process. Even some of the get off my lawn crowd offered good suggestions for this EUI case (make 1 record with a size field rather than 2 records) that could have made this whole process a lot smoother. Doug
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On Jun 20, 2013, at 1:04 PM, Doug Barton do...@dougbarton.us wrote: Perhaps we could have a non-WG mailing list so that people could submit proposals for review prior to the expert review process. Even some of the get off my lawn crowd offered good suggestions for this EUI case (make 1 record with a size field rather than 2 records) that could have made this whole process a lot smoother. You mean like namedroppers?
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 6/20/13 10:04 AM, Doug Barton wrote: I agree with at least a little of what each of Olafur, John, and Andrew have said; but I think there's a middle ground between throw the doors wide open and everything we have tried before didn't work. At least I hope there is. Well recall that we still have DNSOP, which along with the dnsext mailing list once the wg is closed is probably a reasonable place to get/look for feedback. Perhaps we could have a non-WG mailing list so that people could submit proposals for review prior to the expert review process. Even some of the get off my lawn crowd offered good suggestions for this EUI case (make 1 record with a size field rather than 2 records) that could have made this whole process a lot smoother. My impression of the outcome of the procedure change for the registry is the wg didn't feel that there should be any particular obstacle beyond expert review for registration. It is possible that reasonable people should disagree on the application of given rr-types and that they should be registered anyway. In 30 years we've allocated ~120 rrtypes most of which we don't use anymore. Doug
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On Thu, Jun 20, 2013 at 10:04:54AM -0700, Doug Barton wrote: Perhaps we could have a non-WG mailing list so that people could submit proposals for review prior to the expert review process. The WG list isn't going away with the WG. The list is explicitly called out as a good place to try out proposals, so people can in fact do that today. Best, A -- Andrew Sullivan a...@anvilwalrusden.com
namedroppers (wasRe: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard)
On Thu, Jun 20, 2013 at 05:10:20PM +, Ted Lemon wrote: You mean like namedroppers? If only we still had that list. Alas, it was the victim of politics. Perhaps Randy Bush will bring it back to life. A -- Andrew Sullivan a...@anvilwalrusden.com
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 06/20/2013 10:27 AM, Andrew Sullivan wrote: On Thu, Jun 20, 2013 at 10:04:54AM -0700, Doug Barton wrote: Perhaps we could have a non-WG mailing list so that people could submit proposals for review prior to the expert review process. The WG list isn't going away with the WG. The list is explicitly called out as a good place to try out proposals, so people can in fact do that today. I would argue that a fresh start here might be appropriate, although I wouldn't argue it strongly, and wouldn't object to using dnsext@ if that was the consensus.
Re: Conclusions on South American IETF Meeting
Thank you Bob and the IAOC for taking the time to analize the possiblities of a meeting outside North America, Europe and Asia. Independently of the result, I think it had been a good opportunity for many of us to take advantage of the momentum and to initiate some actions to promote the IETF. Regards, as On 6/21/13 1:00 AM, The IAOC wrote: The IAOC would like to thank all the people who commented on the IETF list and responded to the survey. It was very helpful to the IAOC in identifying issues and interest. As of 17 June 2013, the survey had 656 responses. This was more responses than for any other survey we have done, and is more than half of the number of people who usually attend an IETF meeting. Of the unfiltered data, 72.3% said they would very likely or likely attend a meeting in Buenos Aires. 13.3% said unlikely or very unlikely. Of these 17.1% have not attended an IETF meeting and 38.7% are not on a committee, WG chair, I-D author, or full time student. In this group 169 people (25.7%) were from South America, Latin America, or the Caribbean. The unfiltered survey results can be found at: http://iaoc.ietf.org/documents/SurveySummary_Unfiltered_06172013.pdf Applying a filter of only looking at the most active participants (that is, IESG, IAB, IAOC, NomCom members, WG chairs, and I-D authors) the Likely and Very Likely is 71.8% indicated they will attend, and 13.8% said they were unlikely or very unlikely. In this group 26 people (7.0%) were from South America, Latin America, or the Caribbean. Also, this group of the most active participants was Likely or Very Likely to attend London at 85.9% (higher than South America) and Yokohama at 68.4% (lower than South America). The filtered survey results can be found at: http://iaoc.ietf.org/documents/SurveySummary_Active_06172013-1.pdf Based on these survey results, we conclude there would be good attendance at a meeting in Buenos Aires overall, good attendance from people in the region, and that most active participants will attend. Active participants would attend at similar rates to their attendance at other IETF meetings. From this viewpoint, holding a meeting in Buenos Aires appears to be similar holding it in other locations around the world. The results from the survey by itself do not mean we should have an IETF meeting in Buenos Aires, but it does eliminate several reasons why we should not have a meeting there. The harder questions as discussed on the IETF list relate to if we should have a meeting in Buenos Aires. The first part of this relates to whether having a single meeting in South America will increase IETF participation from that region and increase the diversity in the IETF. This was discussed a lot on the IETF list. We agree that a single meeting isn't sufficient. We have been talking with the Internet Society (ISOC) about programs and events that could be held in the region leading up to and following an IETF meeting in the region. They said that ISOC is planning to hold a series of events and programs in South America. This would include: - Increasing the IETF Fellows and policy makers from the region - Local meetings about IETF technologies - Local meetings about Internet deployment approaches - Local meetings with general information on how the IETF works and how to participate The more detailed plan we received from ISOC can be found at: http://iaoc.ietf.org/documents/ISOC%20Activities%20supporting%20IETF%20in%20LAC.pdf The IAOC thinks that scheduling an IETF meeting in Beunos Aires and announcing a series of events will increase the participation from this region and may improve the IETF's cultural diversity. The other general questions raised on the list are why should we do this and will having a meeting in South America really help with the issues we see relating to advancing the IETF in political and international circles. Some people expressed skepticism that this would really help. We don't think we can prove this factually, it is a judgment call to a large extent, but we think the combination of the IETF meeting and the ISOC events in the region will help. The IAOC will proceed with planning a single meeting in Buenos Aires based on what we have heard from the community, the survey, and our discussions with ISOC regarding organizing events in South America. We will also continue to track attendance from participants in all regions. We thank you for providing feedback on the IETF list and for responding to the survey. Bob Hinden IAOC Chair
Re: Conclusions on South American IETF Meeting
+1! On 6/20/13 3:13 PM, Arturo Servin wrote: Thank you Bob and the IAOC for taking the time to analize the possiblities of a meeting outside North America, Europe and Asia. Independently of the result, I think it had been a good opportunity for many of us to take advantage of the momentum and to initiate some actions to promote the IETF. Regards, as On 6/21/13 1:00 AM, The IAOC wrote: The IAOC would like to thank all the people who commented on the IETF list and responded to the survey. It was very helpful to the IAOC in identifying issues and interest. As of 17 June 2013, the survey had 656 responses. This was more responses than for any other survey we have done, and is more than half of the number of people who usually attend an IETF meeting. Of the unfiltered data, 72.3% said they would very likely or likely attend a meeting in Buenos Aires. 13.3% said unlikely or very unlikely. Of these 17.1% have not attended an IETF meeting and 38.7% are not on a committee, WG chair, I-D author, or full time student. In this group 169 people (25.7%) were from South America, Latin America, or the Caribbean. The unfiltered survey results can be found at: http://iaoc.ietf.org/documents/SurveySummary_Unfiltered_06172013.pdf Applying a filter of only looking at the most active participants (that is, IESG, IAB, IAOC, NomCom members, WG chairs, and I-D authors) the Likely and Very Likely is 71.8% indicated they will attend, and 13.8% said they were unlikely or very unlikely. In this group 26 people (7.0%) were from South America, Latin America, or the Caribbean. Also, this group of the most active participants was Likely or Very Likely to attend London at 85.9% (higher than South America) and Yokohama at 68.4% (lower than South America). The filtered survey results can be found at: http://iaoc.ietf.org/documents/SurveySummary_Active_06172013-1.pdf Based on these survey results, we conclude there would be good attendance at a meeting in Buenos Aires overall, good attendance from people in the region, and that most active participants will attend. Active participants would attend at similar rates to their attendance at other IETF meetings. From this viewpoint, holding a meeting in Buenos Aires appears to be similar holding it in other locations around the world. The results from the survey by itself do not mean we should have an IETF meeting in Buenos Aires, but it does eliminate several reasons why we should not have a meeting there. The harder questions as discussed on the IETF list relate to if we should have a meeting in Buenos Aires. The first part of this relates to whether having a single meeting in South America will increase IETF participation from that region and increase the diversity in the IETF. This was discussed a lot on the IETF list. We agree that a single meeting isn't sufficient. We have been talking with the Internet Society (ISOC) about programs and events that could be held in the region leading up to and following an IETF meeting in the region. They said that ISOC is planning to hold a series of events and programs in South America. This would include: - Increasing the IETF Fellows and policy makers from the region - Local meetings about IETF technologies - Local meetings about Internet deployment approaches - Local meetings with general information on how the IETF works and how to participate The more detailed plan we received from ISOC can be found at: http://iaoc.ietf.org/documents/ISOC%20Activities%20supporting%20IETF%20in%20LAC.pdf The IAOC thinks that scheduling an IETF meeting in Beunos Aires and announcing a series of events will increase the participation from this region and may improve the IETF's cultural diversity. The other general questions raised on the list are why should we do this and will having a meeting in South America really help with the issues we see relating to advancing the IETF in political and international circles. Some people expressed skepticism that this would really help. We don't think we can prove this factually, it is a judgment call to a large extent, but we think the combination of the IETF meeting and the ISOC events in the region will help. The IAOC will proceed with planning a single meeting in Buenos Aires based on what we have heard from the community, the survey, and our discussions with ISOC regarding organizing events in South America. We will also continue to track attendance from participants in all regions. We thank you for providing feedback on the IETF list and for responding to the survey. Bob Hinden IAOC Chair
Re: Is the IETF is an international organization? (was: IETF Diversity)
At 08:02 20-06-2013, Mark Nottingham wrote: Keep in mind that you're talking to an organisation that believes that Vancouver qualifies as Asia. That should be added to the Tao. :-) At 08:24 20-06-2013, John C Klensin wrote: Political convenience and expedience trumps geographical reality every time :-) The question I would ask is how many continents are there. Regards, -sm
IAOC Website Updated
One of the IAOC goals for 2013 was to update the IAOC website to improve consistency, organization, linkage, and ease of use. I am pleased to announce that the IAOC site has been updated and is available now for your use at http://iaoc.ietf.org/. On the home page see a video of an Overview of the IAOC given by Chair Bob Hinden in Orlando that includes a discussion of venue selection and IETF finances. Also on the home page are recent announcements, as well as reports from IANA, the RFC Editor, the IETF Chair, the NomCom Chair, and more. The navigation bar makes it easy to find financial statements, minutes, meeting sponsorship opportunities, and much more. We hope you find this helpful, the IAOC as more transparent, and of course we welcome your feedback. Ray IETF Administrative Director PS: Going to IETF 87 in Berlin? The IAOC will be doing another overview session there, Sunday July 28 at 3:00 PM. Hope to see you there!
Policy makers (was: Conclusions on South American IETF Meeting)
At 11:00 20-06-2013, The IAOC wrote: series of events and programs in South America. This would include: - Increasing the IETF Fellows and policy makers from the region I don't see any policy makers reviewing Internet-Drafts. I don't see any policy makers writing IETF RFCs. Policy makers do not usually participate in IETF discussions. During the diversity discussions it has been pointed out that it would be useful if there were more network operators and people who can write code participating in the IETF. What the IAB seems to be have recommended instead is to increase the number of policy makers attending IETF meetings. I am reminded of a sentence from Patrik Fältström: And to some degree there might be parties that see the lack of progress as a good thing I hope that the IAB is not one of these parties as it might be seen as using the IETF for its political convenience. Regards, -sm
Re: namedroppers (wasRe: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard)
You mean like namedroppers? If only we still had that list. any reports of its death are from questionable sources it was the victim of politics. like much of life randy
Re: Is the IETF is an international organization? (was: IETF Diversity)
On Jun 20, 2013, at 11:26 AM, SM s...@resistor.net wrote: At 08:02 20-06-2013, Mark Nottingham wrote: Keep in mind that you're talking to an organisation that believes that Vancouver qualifies as Asia. That should be added to the Tao. :-) At 08:24 20-06-2013, John C Klensin wrote: Political convenience and expedience trumps geographical reality every time :-) The question I would ask is how many continents are there. One. The rest are islands. Asia, by the way, is a peninsula sticking out from Europe. Now that we've cleared that up...
Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-thornburgh-adobe-rtmfp-07 Reviewer: Ben Campbell Review Date: 2013-06-20 IETF LC End Date: 2013-06-25 Summary: This draft is almost ready for publication as an informational RFC. However, I have some concerns about the purpose and intended status of the document that I think should be considered prior to publication. Note: This is an informational draft that describes what I understand to be an existing protocol as implemented by commercial products. Therefore, this review does not attempt to evaluate the protocol itself. I assume the protocol is what it is, and it is not up to the IETF to agree or disagree with it. *** Major issues: -- Why does this need to be published as an IETF stream RFC? If I understand correctly, this documents an existing protocol as implemented by commercial products. I agree with Martin's comment that there is value in publishing this sort of thing, but I applaud the Adobe and the author for publishing it so other implementations can interoperate with their products. But that could have done that in an independent stream document, or even in an Adobe published document. (Perhaps even in a prettier format ;-) ) If we publish this as an IETF stream document, then I think it needs stronger clarification that it is not an IETF consensus doc than just its informational status. Along those lines: -- Is this document the authoritative specification? (I suspect not.) Who owns change control? I assume that to be Adobe and/or the authors. What expectation do readers of this draft have that it represents the current version of RTMFP at any point in time? -- Under what circumstances would one desire to implement this? I can infer that from the introduction, but it would be nice to see some sort of applicability statement making it explicitly clear that this is not an IETF protocol, and that one would implement it in order to interoperate with certain Adobe products. I know that some of this may be implied by the fact that this is informational rather than standards track. But I don't expect readers who are not IETF insiders to understand that subtlety without some explicit words to that effect. In particular, it would be good to clarify the difference between this and the many not quite accepted as standards track by some working group nature of a number of our informational RFCs that describe protocols. That all being said, this is overall a well written document. The rest of my comments are mostly pedantic nits. *** Minor issues: -- section 1.2: I find the use of MUST ONLY confusing. I gather it means you are _allowed_ to do X only under certain conditions rather than you are _required_ to do X under certain conditions. If correct, I think the words MAY ONLY would be more clear. If not, then I think the construct would be better handled using existing 2119 language. -- section 3.2: Do I understand correctly that all endpoints are expected to be able to present certificates? Do you find that common in the field? I realize the nature of the certs will depend on the security profiles. -- sections 3.2 and 5 Do I assume correctly that endpoints need a common crypto profile to communicate? Is there a repository where one might find crypto profile documentation? Is there a commonly implemented one to which this draft could refer? -- section 3.2: Multiple endpoints SHOULD NOT have the same identity. Why not MUST? Will things not break if two endpoints do have the same identity? -- Authenticity MAY comprise verifying an issuer signature chain in a public key infrastructure Is that really normative, or just an observation of fact? -- Canonical Endpoint Discriminators for distinct identities SHOULD be distinct. What if they are not? Do things break? It might be worth making this a MUST, or adding some additional guidance about what might happen if the SHOULD is violated. -- A comparison function MAY comprise performing a lexicographic ordering... Is that really normative, or just an example of something one might do? -- A test SHOULD comprise testing whether the certificates are identical. What if it doesn't? Also, what constitutes identical? All fields match values? Bitwise match? Is it simply including the same identity or identities? Maybe an identity function provided by the crypto profile? -- 3.5, last paragraph: Can you offer guidance on reasonable buffer size and number ranges? -- 3.5.1.1.1, 3rd paragraph: What are the consequences of having a tag with less than 8 bytes of length? Is the SHOULD reasonable here? -- 3.5.1.1.1 throughout, and following sections: Does the upper case AND have special meaning? -- 3.5.1.4, Deployment Note:
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Thursday, June 20, 2013 12:36 -0400 Andrew Sullivan a...@anvilwalrusden.com wrote: On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote: So some review of the DNSEXT-specified procedures and expectations may be in order. ... But more generally, as a practical matter it is better that people register their stuff with us than that they don't. We have, in the wild, a used EDNS0 option code that is all over the Internet. It is undocumented, and the code point isn't actually registered. That state of affairs is surely worse than that the IETF didn't get to provide good advice to authors. DNSEXT already tried to be the DNS cops, and has failed miserably, partly because of the usual get-off-my-lawn crowd and partly because people unfamiliar with the IETF find its procedures a little arcane. My view is that we need to be more pragmatic. Andrew, Just to be clear, I completely agree. I thought that should have been clear from the context of my note (context that you omitted above). I think that what I have referred to as the lightweight registration procedure is just fine. What I have objected to since the first time a Last Call on the present document was initiated is any assertion that, because something is registered, it is entitled to be documented in the RFC Series. I object even more strongly to any implication that such a registered RRTYPE should be accepted as a Standards Track document without any further review because it is registered already. I thought that issue had been settled for this document by reclassifying its intended status to Informational and clarifying the relationship of the RRTYPEs to other consideration, particularly privacy ones. IMO, that clarification along makes it worth publishing as an RFC, but the notion of entitlement was, I thought, put to rest. Consequently, I was mildly astonished when Olafur's comment (which included the information that he is co-chair of DNSEXT) included ...we (DNS community) want to encore [sic] that any such allocations be published as RFC's for future references. So, once again and in short sentences: (1) The present registration procedure does nothing to ensure any such thing. (2) There is nothing else in either IETF or RFC Editor procedures that ensures RFC publication. If a document describing an already-registered RRTYPE is submitted and some AD wants to sponsor it for publication as an individual submission and puts it into a Last Call on that basis, the community may pick at it, insist on changes, or even reach consensus that it should not be published. (3) I think the above is fine. If someone (else) thinks that RFC publication should be ensured for any RRTYPE allocation, then they need to persuade whomever needs to be persuaded to modify the registration procedure. I would, personally, oppose that change if it eliminated the possibility of quick, lightweight, registrations but my opinion probably doesn't count for much relative to the DNS community for which Olafur and/or you are speaking. best, john
Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07
-- Why does this need to be published as an IETF stream RFC? If I understand correctly, this documents an existing protocol as implemented by commercial products. I agree with Martin's comment that there is value in publishing this sort of thing, but I applaud the Adobe and the author for publishing it so other implementations can interoperate with their products. But that could have done that in an independent stream document, or even in an Adobe published document. (Perhaps even in a prettier format ;-) ) If we publish this as an IETF stream document, then I think it needs stronger clarification that it is not an IETF consensus doc than just its informational status. FWIW, the IESG has discussed this in the context of other documents, and is looking at boilerplate that does not say that the document is a product of the IETF, and makes it clear that the content is not a matter of IETF consensus. If that sort of boilerplate was used, do you think that would be sufficient? Barry
Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07
--On Thursday, June 20, 2013 22:14 -0400 Barry Leiba barryle...@computer.org wrote: FWIW, the IESG has discussed this in the context of other documents, and is looking at boilerplate that does not say that the document is a product of the IETF, and makes it clear that the content is not a matter of IETF consensus. If that sort of boilerplate was used, do you think that would be sufficient? FWIW, many IETF Stream Info documents definitely are matters of IETF consensus, even more so when those documents are the consequence of a WG request to publish. IMO, if a document really isn't an IETf product in any way and has no relationship to IETF consensus, it would be far more reasonable for ADs to simply decline to sponsor it --leaving the document to the Independent Submission Editor or outside the RFC Series-- rather than trying to diddle around with boilerplate... especially since we know that people rarely pay attention to stock boilerplate. The option of sponsoring individual submission informational documents is one that the community granted the IESG in order to give you folks a reasonable way to deal with circumstances that were more or less unusual. You don't need to use it. john p.s. I started a much more detailed response to Ben, but I think the essence of it is above. IMO, a discussion that amounts to whether or not an AD used bad judgment by choosing to sponsor an individual Informational submission (or whether ADs should have that power at all) should not become part of evaluating a particular document's appropriateness.
Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07
On Jun 20, 2013, at 9:14 PM, Barry Leiba barryle...@computer.org wrote: -- Why does this need to be published as an IETF stream RFC? If I understand correctly, this documents an existing protocol as implemented by commercial products. I agree with Martin's comment that there is value in publishing this sort of thing, but I applaud the Adobe and the author for publishing it so other implementations can interoperate with their products. But that could have done that in an independent stream document, or even in an Adobe published document. (Perhaps even in a prettier format ;-) ) If we publish this as an IETF stream document, then I think it needs stronger clarification that it is not an IETF consensus doc than just its informational status. FWIW, the IESG has discussed this in the context of other documents, and is looking at boilerplate that does not say that the document is a product of the IETF, and makes it clear that the content is not a matter of IETF consensus. If that sort of boilerplate was used, do you think that would be sufficient? I think that would help, depending on the specific language. My concerns about change control, authoritative specs, etc might still apply depending on the boilerplate details. Thanks! Ben.
Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07
On Jun 20, 2013, at 10:12 PM, John C Klensin john-i...@jck.com wrote: p.s. I started a much more detailed response to Ben, but I think the essence of it is above. IMO, a discussion that amounts to whether or not an AD used bad judgment by choosing to sponsor an individual Informational submission (or whether ADs should have that power at all) should not become part of evaluating a particular document's appropriateness. I certainly didn't mean this to be a discussion of AD judgement. I suspect this would not be the first time the IETF has published an informational RFC that describes a non-IETF protocol, so there's probably precedent for doing so. It might be worth discussing whether that's a good precedent. I also recognize that the authors have done a _lot_ of work on this draft, so this entire discussion is probably a bit unfair to them. I actually do hope it gets published somewhere. Thanks! Ben.
NOMCOM 2013 - UPDATE of validated volunteers list so far
Below is the current validated list of volunteers for Nomcom 2013. If your name has a *, I'm waiting for a message back from you. Big thanks to everyone who has volunteered! Now what are the rest of you waiting for? We still need quite a few to get up to 200 volunteers. Please reply and volunteer - include in the email: your First Name, Last Name, email addresses you've used in the last few years in registering for IETF meetings, preferred email address, primary affiliation, and a contact phone number for use if you're selected. Thanks, Allison Mankin Nomcom 2013 Chair 1 John Scudder 2 Stephen Hanna 3 Wassim Haddad 4 Russ White 5 Stephan Wenger 6 ZHAO Yi 7 Eric Gray 8 Steve Kent 9 Toerless Eckert 10 Alia Atlas 11 Victor Kuarsingh 12 Yizhou LI 13 Gonzalo Salgueiro 14 Gang CHEN 15 Ning KONG 16 Marcelo Bagnulo 17 SHEN Shuo 沈烁 (Sean) 18 Fernando Gont 19 Glen Zorn 20 Reinaldo Penno 21 Klaas Wierenga 22 Pascal Thubert 23 Mehmet Ersue 24 Ole Troan 25 Jouni Korhonen 26 Giles Heron 27 Gunter Van de Velde 28 Arturo Servin 29 Eric Vyncke 30 Cullen Jennings 31 Tina Tsou 32 Dhruv Dhody 33 Hongyu LI (Julio) 34 Scott Mansfield 35 John Drake 36 Andrew McLachlan 37 Derek Atkins 38 Suhas Nandakumar 39 Eric Rescorla 40 Karen Seo 41 Stig Venaas 42 Stan Ratliff 43 Ignas Bagdonas 44 Peter Yee 45 Donald Eastlake 46 ZHOU Qian (Cathy) 47 Sam Hartman 48 Lixia Zhang 49 Teemu Savolainen 50 Alvaro Retana 51 Terry Manderson 52 Bill VerSteeg 53 Melinda Shore 54 IJsbrand Wijnands 55 Karen O'Donoghue 56 Benson Schliesser 57 Ari Keränen 58 Fangwei HU 59 Mach CHEN 60 Hui Deng 61 LIU Dapeng 62 Jaap Akkerhuis 63 Magnus Westerlund 64 Zehn CAO 65 Zaheduzzaman Sarker 66 Bhumip Khasnabish 67 Andrew Chi 68 Thomas Nadeau 69 Steven C (Craig) Whilte 70 Orit Levin 71 Sam Aldrin 72 Paul Ebersman 73 Christopher Liljenstolpe 74 Uma Chunduri 75 Suresh Krishnan 76 Varun Singh 77 Ron Bonica 78 Bill (William) Manning 79 Radia Perlman 80 Daniele Ceccarelli 81 Deborah Brungard 82 Kostas Pentikousis 83 Gregory Mirsky 84 Dave Sinicrope 85 Thomas Walsh 86 Zhaohui (Jeffrey) ZHANG 87 Xian ZHANG 88 Mark Townsley 89 Hannes Gredler 90 Brian Trammell 91 Carlos Martinez 92 Peter Koch 93 Daniel Migault 94 Yi (Aaron) Ding 95 Michael Richardson 96 Sohel Khan 97 John Bradley 98 Huaimo Chen 99 Matthew Campagna 100 Keith Drage 101 Chris Bowers 102 Jakob Heitz 103 Tomofumi Okubo 104 Emil Ivov 105 Timothy B. Terriberry 106 JIANG Yuanlong 107 Luigi Iannone 108 Damien Saucez 109 Lou Berger 110 Yana Stamcheva 111 Ondřej Surý 112 Marcin Pilarski 113 Michael StJohns 114 Wes George 115 Christian O'Flaherty 116 Uwe Rauschenbach 117 Olafur Gudmundsson 118 Shwetha Subray Bhandari* 119 Tobias Gondrom 120 Christer Holmberg 121 Susan Hares 122 Kiran Kumar Chittimaneni 123 Donald Fedyk 124 Stephen Botzko* 125 Li Xue* 126 John Sauer*
Conclusions on South American IETF Meeting
The IAOC would like to thank all the people who commented on the IETF list and responded to the survey. It was very helpful to the IAOC in identifying issues and interest. As of 17 June 2013, the survey had 656 responses. This was more responses than for any other survey we have done, and is more than half of the number of people who usually attend an IETF meeting. Of the unfiltered data, 72.3% said they would very likely or likely attend a meeting in Buenos Aires. 13.3% said unlikely or very unlikely. Of these 17.1% have not attended an IETF meeting and 38.7% are not on a committee, WG chair, I-D author, or full time student. In this group 169 people (25.7%) were from South America, Latin America, or the Caribbean. The unfiltered survey results can be found at: http://iaoc.ietf.org/documents/SurveySummary_Unfiltered_06172013.pdf Applying a filter of only looking at the most active participants (that is, IESG, IAB, IAOC, NomCom members, WG chairs, and I-D authors) the Likely and Very Likely is 71.8% indicated they will attend, and 13.8% said they were unlikely or very unlikely. In this group 26 people (7.0%) were from South America, Latin America, or the Caribbean. Also, this group of the most active participants was Likely or Very Likely to attend London at 85.9% (higher than South America) and Yokohama at 68.4% (lower than South America). The filtered survey results can be found at: http://iaoc.ietf.org/documents/SurveySummary_Active_06172013-1.pdf Based on these survey results, we conclude there would be good attendance at a meeting in Buenos Aires overall, good attendance from people in the region, and that most active participants will attend. Active participants would attend at similar rates to their attendance at other IETF meetings. From this viewpoint, holding a meeting in Buenos Aires appears to be similar holding it in other locations around the world. The results from the survey by itself do not mean we should have an IETF meeting in Buenos Aires, but it does eliminate several reasons why we should not have a meeting there. The harder questions as discussed on the IETF list relate to if we should have a meeting in Buenos Aires. The first part of this relates to whether having a single meeting in South America will increase IETF participation from that region and increase the diversity in the IETF. This was discussed a lot on the IETF list. We agree that a single meeting isn't sufficient. We have been talking with the Internet Society (ISOC) about programs and events that could be held in the region leading up to and following an IETF meeting in the region. They said that ISOC is planning to hold a series of events and programs in South America. This would include: - Increasing the IETF Fellows and policy makers from the region - Local meetings about IETF technologies - Local meetings about Internet deployment approaches - Local meetings with general information on how the IETF works and how to participate The more detailed plan we received from ISOC can be found at: http://iaoc.ietf.org/documents/ISOC%20Activities%20supporting%20IETF%20in%20LAC.pdf The IAOC thinks that scheduling an IETF meeting in Beunos Aires and announcing a series of events will increase the participation from this region and may improve the IETF's cultural diversity. The other general questions raised on the list are why should we do this and will having a meeting in South America really help with the issues we see relating to advancing the IETF in political and international circles. Some people expressed skepticism that this would really help. We don't think we can prove this factually, it is a judgment call to a large extent, but we think the combination of the IETF meeting and the ISOC events in the region will help. The IAOC will proceed with planning a single meeting in Buenos Aires based on what we have heard from the community, the survey, and our discussions with ISOC regarding organizing events in South America. We will also continue to track attendance from participants in all regions. We thank you for providing feedback on the IETF list and for responding to the survey. Bob Hinden IAOC Chair
IAOC Website Updated
One of the IAOC goals for 2013 was to update the IAOC website to improve consistency, organization, linkage, and ease of use. I am pleased to announce that the IAOC site has been updated and is available now for your use at http://iaoc.ietf.org/. On the home page see a video of an Overview of the IAOC given by Chair Bob Hinden in Orlando that includes a discussion of venue selection and IETF finances. Also on the home page are recent announcements, as well as reports from IANA, the RFC Editor, the IETF Chair, the NomCom Chair, and more. The navigation bar makes it easy to find financial statements, minutes, meeting sponsorship opportunities, and much more. We hope you find this helpful, the IAOC as more transparent, and of course we welcome your feedback. Ray IETF Administrative Director PS: Going to IETF 87 in Berlin? The IAOC will be doing another overview session there, Sunday July 28 at 3:00 PM. Hope to see you there!
Protocol Action: 'MPLS Generic Associated Channel (G-ACh) Advertisement Protocol' to Proposed Standard (draft-ietf-mpls-gach-adv-08.txt)
The IESG has approved the following document: - 'MPLS Generic Associated Channel (G-ACh) Advertisement Protocol' (draft-ietf-mpls-gach-adv-08.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-gach-adv/ Technical Summary The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. Working Group Summary There is good support in the working group for this draft. There were no significant controversies in progression of the document. Last call comments were constructive technical comments and the document has been updated accordingly. . Document Quality: For this document we seem to have an chicken and egg problem. We know of intended implementations, it seems that since the implementation delta is rather small the implementers in this case has decided to wait for the allocation of the ACh code point before implementing. The document received extensive (agressive?) review from the responsible AD and has been updated to address all comments raised. Personnel: Loa Andersson (l...@pi.nu) is the document shepherd. Adrian Farrel (adr...@olddog.co.uk) is the responsible AD. RFC Editor Note Please update the 2119 boilerplate to include NOT RECOMMENDED --- Section 6.1: OLD: the following values MAY supported NEW: the following values MAY be supported
