Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On Thu, 5 Sep 2013, Dean Willis wrote: This is bigger than the perpass list. I suggested that the surveillance/broken crypto challenge represents damage to the Internet. I'm not the only one thinking that way. an additional call to action can be found here: http://www.newamerica.net/pressroom/2013/statement_oti_statement_on_new_leaks_of_nsa_defeating_encryption_technology_3 In the interim, technologists need to take a hard look at how to reengineer the Internet to avoid this type of massive undermining of our privacy rights. Our current trajectory is toward a more fractured, less safe Internet, and only major, meaningful reforms will restore trust and prevent even more detrimental outcomes. I'd like to share the challenge raised by Bruce Schneier in: http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying To quote: --- We need to know how exactly how the NSA and other agencies are subverting routers, switches, the internet backbone, encryption technologies and cloud systems. I already have five stories from people like you, and I've just started collecting. I want 50. There's safety in numbers, and this form of civil disobedience is the moral thing to do. Two, we can design. We need to figure out how to re-engineer the internet to prevent this kind of wholesale spying. We need new techniques to prevent communications intermediaries from leaking private information. We can make surveillance expensive again. In particular, we need open protocols, open implementations, open systems – these will be harder for the NSA to subvert. The Internet Engineering Task Force, the group that defines the standards that make the internet run, has a meeting planned for early November in Vancouver. This group needs dedicate its next meeting to this task. This is an emergency, and demands an emergency response. The gauntlet is in our face. What are we going to do about it? -- Dean Willis
Re: Comments for Humorous RFCs or uncategorised RFCs or dated April the first
On Mon, 8 Apr 2013, Wes Beebee (wbeebee) wrote: If the date is special then thoes RFCs SHOULD be *historical*. I thought they should be classified as hysterical. there is an echo (echo) ((echo) ) in here (here) ((here)) - Wes
Re: Making the Tao a web page
On Mon, 4 Jun 2012, Dave Crocker wrote: On 6/4/2012 12:36 AM, SM wrote: At 14:33 01-06-2012, Russ Housley wrote: So, I am left with a few questions: - What is the similar forcing function if we use a wiki? - Will the number of people that can make updates eliminate the need for such a forcing function? - Who designates the editor-in-chief of the wiki? ... ... Instead of discussing the above questions it is easier to create an Wiki page and leave it to anyone with a tools login who cares to update it. In effect, the wiki construct becomes a form of incrementally-updatable internet draft. For documents involving procedures rather than products, this well might be a better working base than I-Ds... But with the I-D model superimposed. That is, perhaps what makes this workable is imposing an editor role onto the wiki and assign responsibility for monitoring changes to the editors? (It might even be worth integrating it into the rest of the I-D administration environment?) Note that this still leaves a place for published snapshots as RFCs. I like the idea of moving towards a more lively version of the Tao and I agree with all those who've voiced concerns about using to open of a process for group editing. I have an alternate suggestion which tries to walk the middle way. What is we create the Tao as a web page with one lead editor (an a possible second author as needed) who is responsible for regular review and updates and then spin up an etherpad version of the text which can be edited by anyone with a tools login? The editor could then track and incorporate suggested changes into the canonical web page and notify the list when major updates occur. This would use some familiar elements of our current document production process and tools we already have in place and would give the editor a way to contact those with suggested changes if further dialogue was needed. One question for the Tools team - can etherpad handle a long lived document? - Lucy d/
Re: A or B [was Trust membership]
On Thu, 22 Sep 2011, Bob Braden wrote: 1986 Internet Activities Board 1992 Internet Architecture Board I think this is incorrect. The earliest IAB was created by the ARPA program manager Vint Cert in 1981. (In fact, I probably have some scribbled notes from the first IAB meeting). Vint chose the name Activities to prevent a rush of people wanting to join. ;-) Its function was in fact advisory, to give Vint advice on the technical course of the Internet research project I do not recall (without digging into my files) when/if the official IAB name expansion was changed to Internet Advisory Board. V Cerf seems to think... https://tools.ietf.org/html/rfc1120 In January, 1983, the Defense Communications Agency, then responsible for the operation of the ARPANET, declared the TCP/IP protocol suite to be standard for the ARPANET and all systems on the network converted from the earlier Network Control Program (NCP) to TCP/IP. Late that year, the ICCB was reorganized by Dr. Barry Leiner, Cerf's successor at DARPA, around a series of task forces considering different technical aspects of internetting. The re-organized group was named the Internet Activities Board. - Lucy separation. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On Mon, 19 Sep 2011, Spencer Dawkins wrote: Hi, Dave, Anything that the IETF can do, to make the IAB and IETF Chair positions less of a full-time (or more) job, is a good thing. Anything? I believe you do not believe that statement, but I think it accurately summarizes the focus of this thread, so far. Thanks for the wake-up call, of course. Now, it's Monday AFTERNOON in my time zone. I am carefully reading the notes that were posted after I posted. I noticed that John Klensin says not JUST an offload proposal - and I get that - and I hadn't fully grokked the fiduciary responsibility point Marshall made. So, yes, I overspoke. Like I said - I'm fine being in the rough on this proposal, but I would like us to think about if not this, what gets offloaded? As a former IAOC chair there is another set of questions I would ask here: Who picks up the load? How might this change community dynamics and expectations around IAOC/Trust related work items? Some of the business related decisions that the IAOC must make are already quite contentious and delegation won't help. Finding volunteers willing to step up to chair like responsibility is already hard. I suspect that this will put additional pressure on the IAOC and IETF Trust chairs as well as the volunteers who step into the IETF/IAB seats. For better or worse the IAOC is seen as a housekeeping function but, as Jonne and Marshall have pointed out, there are serious responsibilities and major assets under management here. The existing balance of leadership and community participation has worked well. Swapping in other IESG or IAB members may serve as well, but this just adds load to another set of over-burdened folk. Moving to a system that is largely drawn from the broader community may have unexpected results for both the IAOC and the volunteers. If the community adopts this new model we must also be willing to ensure that the very best candidates have an incentive to pick up the administrative burdens. There is not a lot of glory and a fair amount of pain associated with the IAOC work and we could quickly find ourselves with a shortage of folks willing to do the dishes unless we find ways to support and reward this kind of community service. - Lucy Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On Sat, 16 Apr 2011, John C Klensin wrote: snip At the risk of agreeing violently with Dave, I think the series of comments above, and referenced above, are missing something. None of this familiy of delegation or someone else proposals requires that the IAB or IESG Chairs not serve on the IAOC. If they think that is sensible and they have the time, they are free to do that. We might even strongly encourage it. However, if those people conclude that limited available time is better spent in other ways or that, if they take the IAOC position, they would not be able to devote adequate attention to it, aren't we better off giving them the flexibility and discretion to make that decision? Similarly, if someone tells the appointing body I have the time and resources to take on the IAB Chair or IETF Chair position but only if that position does not include the responsibility of sitting on the IAOC isn't it better to give those bodies the option of considering that person rather than limiting the choices to those who can sign up for all of the job? I'm not arguing that any of the IETF/IAB/etc hat wearers are inexhaustible resources, I'm saying that the AdminRest process looked hard at the composition and duties of the IAOC and if the needs have changed, or the community concerns have shifted, we should approach the current problems in a holistic manner and not engineer short term solutions on the fly. I'll point you at your own last paragraph here; http://www.ietf.org/mail-archive/web/ietf/current/msg33932.html At least from my perspective, broadening the flexibility available to already-appointed IAB and IETF Chairs and to the bodies that appoint them is the real issue here. _Requiring_ that they serve on the IAOC does not create more time or resources, it just limits the range of people who can take those positions or, more likely, raises the odds of getting someone onto the IAOC who won't be able to pay full (or even adequate) attention. certainly one possible outcome So. in addition to the questions Dave posed, the question I would address to you and Bob is whether, given a hypothetical choice of someone sitting on the IAOC ex-officio but not being able to really pay attention because he or she concludes that there are more pressing priorities and having someone representing the IAB or IESG who really can pay attention, which one you would pick. In the worst case, if you prefer to have the Chairs nominally present but not paying complete attention, then keep insisting that they are the only ones who can possibly occupy the IAOC slot. I would of course prefer full attention and skilled participation. I'd also like the full confidence of the community in the process. As part of that, figure out how you are going to convince the Nomcom and the IAB that selecting people for the Chair roles should have will give IAOC first priority regardless of their judgment about the importance of other aspects of their roles as an absolute criterion and/or how you are going to convince the community to recall anyone in the Chair roles who does not give the IAOC that priority. New/old problem that may require additional revision on several fronts - not just the IAOC. - Lucy best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On Fri, 15 Apr 2011, Dave CROCKER wrote: On 4/14/2011 9:51 AM, Bob Hinden wrote: My concern is that this proposed change would likely make the IAOC work worse. That is, I think it would have a negative impact on the operations of the IETF and that is why I am concerned. Bob, That is a concrete and basic assertion. Please put some flesh on its bones so that the basis for your view can be understood better. Let me take a run at this. Back in the pre-history of BCP 101 we had very little control over many of the administrative functions that support the actual work of the IETF. We had a single long term relationship with an organization that run the meetings and collected fees on behalf of the the IETF and performed many of the secretariat functions. Over time, this relationship had frayed considerably (on both sides) and the community become increasingly restive, looking for more autonomy and a better understanding of our own internal business processes. There were a number of drivers for the (extended) discussions about process and one of these was overload on the volunteers in the leadership roles. Among the solutions crafted up were the creation of the IASA and the hiring of our first paid employee (IAD). We also ended our relationship with the existing secretariat and moved to a process of contracting for services through the IAD with over site from what became the IAOC. The termination of our relationship with CNRI then spawned the creation of the IETF Trust. All of this took an enormous amount of community time and energy and a lot of tough questions had to be asked and answered. I'll just highlight a couple: - an all volunteer organization hired it's first paid employee. note that this can be a slippery and expensive slope and there was always a risk that this might change the volunteer culture - the IASA/IAOC/IETF Trust were tasked with stewardship for the administrative health of the IETF. - the Trust formalized the future disposition of IETF assets and allowed an orderly transition from claims from previous administrations. My belief at the time was that the primary concerns in all of this were a desire for greater transparency and organizational autonomy. There was a clear demand from many that the IETF own it's own processes. The implication is that the people sitting in the positions of IAB Chair and IETF Chair are essential to the good operation of the IAOC/Trust. Someone else from their groups or even someone else that they appoint from outside cannot perform the task of IAOC/Trust member adequately. I think this is the wrong question. I don't think this is about the people who sit on the IAOC or the Trust, it is about the roles. Their participation is part of the chain of accountability to the community. The IAOC was crafted to include both the IAB and IETF Chairs as well as the ISOC CEO in their respective roles and not as Fred, Harold, and Lynn (as members of the IETF community). Why? What are the specific contributions (insights and skills) that these roles regularly perform, in the conduct of the IAOC/Trust that cannot be performed adequately by others? see above. One more point here: as a former Chair of the IAOC (IAB appointed member from the community) I'm sympathetic the the overload arguments but I'll note that absent the IAB/IETF chairs the work of the IAOC chair and the weight put on that role may increase in unexpected ways. I agree with many of the points that Bob, Brian, Leslie, and Jari have made in earlier posts and think that we need to take a broader view of the problems we're trying to solve here. Role overload is an on-going problem but I'm not sure we solve this by moving the administrative accountability we gained through BCP 101 to additional volunteers. - Lucy d/ ps. Reminder: I've just joined the IAOC/Trust, which means I've attended a few meetings and seen some operation. As always, my comments have nothing to do with the individuals; this is about organizational design. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Where to find IETF recommendations?
On Mon, 28 Feb 2011, Richard L. Barnes wrote: As far as I know, what you're looking for doesn't exist, although it would probably be good if it did! One thing that does crop up here and there are hitchhiker's guide RFCs, such as this one: http://tools.ietf.org/html/rfc5411 Beyond that, the best way I know of to look for IETF recommendations on a subject is using the search feature on the tools pages: http://tools.ietf.org/html/ Although they can quite intimidating, I'm fond the the dependency graphs the accompany the WG pages on tools.ietf.org The link is at the very bottom of the page - http://tools.ietf.org/wg/v6ops/ Take a look at: http://www.fenron.net/~fenner/ietf/deps/viz/v6ops.pdf kind of makes your head hurt. - Lucy On Feb 28, 2011, at 5:35 AM, Shane Kerr wrote: Bob, Are recommendations actually published as BCP? I only see one BCP with IPv6 in the title, published back in 2004. Compared to this, the ipv6ops working group alone has produced dozens of informational RFCs: https://datatracker.ietf.org/wg/v6ops/ At least one of these are even explicitly recommendations: https://datatracker.ietf.org/doc/rfc4890/ Some are targeted at protocol developers, some at vendors, some at operators. It's quite a mixed bag. :) I'm not complaining, I just want to know if I am missing an obvious place. -- Shane On Mon, 2011-02-28 at 12:10 +0200, Bob Hinden wrote: Shane, Like this one, aren't recommendations usually published as BCPs? Bob On Feb 28, 2011, at 11:44 AM, Shane Kerr wrote: All, I just happened to notice this document on ietf-announce today: http://datatracker.ietf.org/doc/draft-ietf-intarea-server-logging-recommendations/ It seems quite reasonable. My question is... how is this advice expected to trickle out into actual use? There are more than 6000 RFCs, and they don't seem to be organized in a useful way that I can find. I ask because I was going to forward this to an IPv6 operations list, and thought hm... what about the rest? and I realized I did not know, and did not even know how to find out. Any advice would be appreciated. Thanks! -- Shane ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Final IPv4 Unicast Address Allocations
On Thu, 3 Feb 2011, IETF Chair wrote: You have probably already heard the news, but just to make sure no one is left out of the loop, I am posting this note. snip To the universal deployment of IPv6, Hear Hear. It seems a bit odd to down a shot of single malt at 11:56am PST but it *is* special occasion. A toast to everyone in the IETF who struggled through the long process to get us here and to the universal deployment of IPv6... - Lucy Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] Badges and blue sheets
On Tue, 16 Nov 2010, JORDI PALET MARTINEZ wrote: I just realized something ... Note that I'm not saying that volunteer NOC is not good, but, if they are waived from the registration fee ... Why IESG members not ? Jordi - With respect, this is a more subtle problem set then you're seeing. I'm a NOC volunteer and I paid on own way this time and have for most meetings. Back when I worked for the University of Oregon and volunteering I had my registration covered for a couple of meetings when I traveled on my own dime to help get me to the meeting (and the NOC). My current contributions are not core to getting the network up, so I just figure out how manage my day job, the IETF, and the NOC on my own. At least once as an IAOC member I paid my own registration and travel as the UO didn't see any value in the process role. I used vacation time and could manage the expense on my own, so I did. - Lucy Is that we valuate less the effort of the IESG members, which is across all the time in the year, than NOC that is may be 6-7 weeks per year (assuming 2 weeks or so needed per meeting) ? I think we really need to have a balance on this. Regards, Jordi From: JORDI PALET MARTINEZ jordi.pa...@consulintel.es Reply-To: jordi.pa...@consulintel.es Date: Sun, 14 Nov 2010 06:38:16 +0800 To: IETF discussion list ietf@ietf.org Cc: i...@ietf.org i...@ietf.org Subject: Re: [IAOC] Badges and blue sheets I'm still not convinced. If you accept to be waived, you should accept that the waiver is made public. It is not a matter of privacy, you're not forced to. Moreover, and this needs to be answered, or we have a problem. What is the RFC that allows this waiver ? Regards, Jordi From: Marshall Eubanks t...@americafree.tv Reply-To: t...@americafree.tv Date: Fri, 12 Nov 2010 13:24:49 -0500 To: Yoav Nir y...@checkpoint.com Cc: i...@ietf.org i...@ietf.org, IETF discussion list ietf@ietf.org, jordi.pa...@consulintel.es jordi.pa...@consulintel.es Subject: Re: [IAOC] Badges and blue sheets On Nov 12, 2010, at 4:08 AM, Yoav Nir wrote: On Nov 12, 2010, at 7:36 AM, JORDI PALET MARTINEZ wrote: Hi Henk, I don't agree. If there is people essential to the meeting but can't pay, as we all pay for that, we have the right to know. I disagree with that. There is a privacy issue here. If x can't pay his way, and needs a comp ticket, it's enough that the IETF chair knows about this. It's not our right to know of their financial situation. +1 Marshall This is an open organization right ? I will be VERY concerned if we don't have this information being made public immediately. It sounds really really strange to me. You pay for everything the Spanish government does, which, I assume, includes some kinds of welfare like unemployment benefits. You don't get a list of all people who get these benefits, do you? Is it documented in any RFC ? Moreover, if I'm in between jobs, or need a new job, or whatever, I think is good for me that others know, in case I can get some new offers. People look for jobs in various ways at their discretion. Being from Spain, there are only 6 more of your countrymen at the Beijing meeting. How many relevant job offers would you get? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org
Re: An archive for nerdy t-shirts
On Thu, 28 Oct 2010, Paul Hoffman wrote: http://ascii.textfiles.com/archives/2731 Those of you with a good collection of old IETF t-shirts (and other schwag; did anyone keep the phone cards MCI gave us at IETF 34?) might consider having them archived by Jason. I always get a small jolt when I see some homeless guy in Eugene wearing a NANOG or IETF shirt - maybe I should start documenting my sitings? - Lucy --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Above market hotel room rates
On Wed, 24 Mar 2010, Samuel Weiler wrote: On Wed, 24 Mar 2010, David Morris wrote: If you care about hotel pricing, there is no excuse for complaining about IETF rates in a location like Anaheim with dozens of alternatives within walking distance. So far, I haven't complained (at least not on this list). I've just provided data. :-) That said, I think it is fair to complain about rates at the meeting venue. There is a benefit to being on-site, and it's reasonable for us to be interested in the rates at the venue property. It may well be that the IAD is making the right set of tradeoffs here, as Spencer's note highlights. for a nice birds eyes view of the complexities of meeting planning see: http://conference.archimuse.com/blog/dbear/ In the last year I've attended at least conference where I paid a package price (room/registration/catering/social) - so, no choices to make and a one size fits all price. The current IAOC balancing act actually allows for some choice (which I appreciate). - Lucy hilton.com rates of right now have no relation to the rates which you might have found 4 weeks ago ... any business with inventory like hotel rooms, airline seats, etc. will frequently sharply discount for very near term dates when they are below capacity. You typically don't see airline tickets drop very much in price. And if they drop by more than the amount of the change fee (if any), one expects to see people cancel and rebook to take advantage of the lower fare. And if it happens often enough, people learn not to pay the premium for booking early, and the airline can't get early bookings. Hence the pressure on revenue management folks to make good projections and not need to drop prices late. Similarly, I've rarely seen transparent hotel rates vary by this much[1]. To be clear: we're now seeing a walk-up rate at this hotel which is $75/night lower than our group rate. (Put another way, the group rate is 63% higher than the walk-up rate.) The magnitude of the difference in this case seems worthy of being called out. In addition, in some convention situations, room rates subsidize the cost of meeting facilities. Don't know if that applies here. I'm certain that it does. -- Sam [1] More typically, hotels offer lower rates through opaque channels like Priceline and Hotwire. As an example, the San Francisco Hilton was selling rooms on Hotwire for $89 during the week of our meeting there last year. Our group rate was $235. Their transparent rate (walk-up) was about $209. Less than our group rate, but not by as much as the opaque rate. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gentle drumming before plenaries this week...
On Wed, 24 Mar 2010, Spencer Dawkins wrote: If you brought small hand drums to IETF 77, please join me for a few minutes before each plenary (in many cultures, drumming is part of a tradition of healing :-) If you did not - I brought about four small frame drums/headed tamborines and will have them at the plenary. I know Ben Campell is coming, and I will still have a couple of drums to share. If you'd like to join us and want to be sure that you have something to drum on - the ice buckets in your room (at least, at the Hilton) are surprisingly serviceable ;-) I thought I had a small number of shakers/rattles, but I don't - anything from a decent-sized key chain on up would work fine! I should emphasize that there is no audition for this - I believe Darwin joined us, about a year ago... which I take to be a signal honor for the drum circle folk and and a comment on Darwin's musical abilities. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Internet Society joins Liberty Alliance Management Board: Why?
On Sat, 28 Feb 2009, Hannes Tschofenig wrote: I would like to hear a bit more background about these activities, see https://www.projectliberty.org/news_events/press_releases/internet_society_j oins_liberty_alliance_management_board Hannes - ISOC hat on As stated in the press release, ISOC has joined the the Liberty Alliance Board. Our participation here is directly related to the ISOC initiative on Trust and Identity (T/Id). Our primary interest is not just the Liberty Alliance itself but a proposed transition to a broader organization. This effort is currently called either IDTBD or NewOrg in the community discussions. The intent is to open participation to new entrants and technologies and NewOrg will also help represent emerging identity management work to end-users, policymakers, enterprise adopters, and others. ISOC has been actively reaching out to many of the current identity technology communities as part of our effort to understand what managed identity will mean for end users. We also have some interest in how the frameworks and use cases developing in user managed identity communities may overlap and inform more traditional networked identity/identifier problems. I believe that ISOC support for this move to an open community lead forum will help bring this important work to a broader audience and will encourage greater participation and interoperability (high priorities for T/Id work: http://www.isoc.org/isoc/mission/initiative/trust.shtml). The transition to a NewOrg is still in process, and the founding documents: by-laws, operating procedures, IPR considerations, etc., were reviewed at the recent Liberty Alliance Plenary and continue to progress. (see: http://groups.google.com/group/idtbd) - Lucy Thanks! Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Internet Society joins Liberty Alliance Management Board: Why?
snip So I do not think IETF should be the slightest worried ISOC is doing something here without coordination. And without visibility to the IETF. And the more people in IETF is interested on this more meta-level-work than bits on the wire, the higher the quality will be of the work ISOC does. Just contact Lucy! Regards, Patrik Yes please! lynch @ isoc.org or find me in SF and I'd be happy to chat. - Lucy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
As I remember it, the flood in the NOC was much more exciting then the DNSSEC bits. - Lucy On Nov 27, 2008, at 8:49 PM, Matthew Ford wrote: After all the years of FUD surrounding DNSSEC deployment, I feel quite strongly that having the IETF do as you suggested and then be able to point to 'no discernible impact' on the network would be a significant milestone. Data point: IETF65 (Dallas) had a DNSSEC enabled recursive nameserver (and, if I recall well, signed reverse zones). No impact noticed whatsoever. I wonder how many people actually knew. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 @ IETF-71, especially Jabber
On Fri, 29 Feb 2008, Stephane Bortzmeyer wrote: On Fri, Feb 29, 2008 at 03:34:41PM +0100, Iljitsch van Beijnum [EMAIL PROTECTED] wrote a message of 35 lines which said: What's going on with the preparations to turn off IPv4 at IETF-71? It's been really quiet surrounding that topic since the initial discussion. Because IPv6-only events are already banal? Hardly that. My understanding is that the IETF experiment is designed to give additional experience with configuration options as the NANOG and Apricot events were focused on v6only and v4v6 via NAT-PT. We're still learning new things with each v6 hour and I (for one) hope to see these experiments carried out in a number of venues as the real world experience helps inform on-going work. http://www.civil-tongue.net/clusterf/ see: http://www.civil-tongue.net/clusterf/wiki/APRICOT2008-Handout http://www.civil-tongue.net/clusterf/wiki/APRICOT2008-Lessons for some the the details of the last go-round. - Lucy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Presentation on IP address shortage
On Wed, 13 Feb 2008, Henning Schulzrinne wrote: I'm looking for a reasonably recent presentation on the state of IP address allocation that would be suitable for a class I'm teaching. Henning - Duane Wessels of The Measurement Factory has created some great maps of current v4 allocations: http://maps.measurement-factory.com/ and he kindly provides the heatmap software if you want a hands on the data project: http://maps.measurement-factory.com/software/index.html For example, Roy Arends did some (insanely fun) additional work for the last IEPG: http://www.iepg.org/2007-12-ietf70/3dheatmaps.pdf - Lucy Thanks. Henning ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Let's look at it from an IETF oldie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary
On Wed, 19 Dec 2007, Bob Braden wrote: Here is my understanding: 1. The shortage of IPv4 addresses will increasingly cripple the communication effectiveness of the Internet, either directly or indirectly through ubiqitous NATting. 2. As a replacement for IPv4, IPv6 is the only game in town. We did it. 3. Unless we want the ITU to eat our dogfood, the IETF needs to get serious about discovering and solving the remaining technical problems implicit in IPv6 deployment. 4. In recent years, a large fraction of IETF activity has moved from our original and core concern, the network and transport layers, to (more profitable?) issues at the application layer and layer 2.5. It is time to take the network layer seriously again. 5. The recent messages containing reasoned calls for advance planning and coordination of an IPv6 connectathon are all important and need to be heeded. 6. There is a social engineering as well as a technical engineering problem here. 7. This discussion has already been useful. What he said! As an old multicast warrior and a long time NOC volunteer I'd point out that we've been eating our own dog food for years. The world didn't end and the network never melted completely ;-). All the fine folks involved in *hard* technologies like DNSSEC, DKIM, mobility, multicast, new routing solutions, etc. should be following this discussion with a mixture of dread and befuddlement. Why are we crafting new technologies and advanced solutions to Internet architectural problems if we're unwilling to use them ourselves? I, for one, am ready to leave all the polyhedral turnings required to add one more frill to v4 behind and move on to the next billion net. It will take v6 to get there. http://www.georgehart.com/virtual-polyhedra/turnings.html - Lucy Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NAT+PT for IPv6 Transition Operator Feedback generally
On Wed, 14 Nov 2007, Iljitsch van Beijnum wrote: On 14 nov 2007, at 14:19, RJ Atkinson wrote: There is an opportunity in all of this mess for some folks to initiate work to develop a replacement RFC for NAT+PT. As near as I can tell, operators aren't particularly worried whether that RFC is on the standards-track or not, but they do want to have an open specification for the function. Please note that Brian Carpenter recently wrote a draft with a new take on NAT+PT: http://www.ietf.org/internet-drafts/draft-carpenter-shanti-01.txt Alain Durand's draft suggests an IPv4(public)-IPv6-IPv4(private) mechanism: http://www.ietf.org/internet-drafts/draft-durand-v6ops-natv4v6v4-00.txt And I wrote a draft proposing several modifications/additions to existing NAT-PT: http://www.ietf.org/internet-drafts/draft-van-beijnum-modified-nat-pt-00.txt There was a lively discussion on this topic on the v6ops list that immediately stopped when I posted my draft... Margaret Wasserman brought up: Exactly what types of operational problems exist that we need to solve? Why aren't the existing v4/v6 transition mechanisms sufficient to resolve those problems? Where are the gaps that needs to be filled? There are several collection efforts going on - you might take a look at: http://www.civil-tongue.net/clusterf http://www.ipv6-to-standard.org/ http://ipv6.internet2.edu/ most of these are well advertised in the (Ran defined) Ops community. - Lucy It would be good to have answers to those questions from the operational community along with the signal that NAT±PT is required. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Audio Streaming - IETF69 Chicago Illinois USA July 22nd-27th
On Thu, 19 Jul 2007, Philip Matthews wrote: The detailed information on streams and times seems to be missing from http://videolab.uoregon.edu/events/ietf/ All I see is background information. And the IETF 69 Playlist link seems to be broken. Joel is in transit, the IETF69 network isn't up yet, and streaming starts Sunday - look for links once the resources are in place. - Lucy - Philip On 15-Jul-07, at 19:13 , Joel Jaeggli wrote: Greetings, This initial announcement is late but the time line should be as per normal. All 8 parallel tracks will be broadcast starting with the commencement of working group sessions on Monday July 23rd at 0900 CDT (1400 GMT) and continue until Friday at 1130 CDT... Because I have been asked several times in the past, note that if you wish to use the rooms that are being recorded for impromptu meeting during unscheduled sessions or lunch breaks that you can invite remote participants to tune in to the appropriate stream. Recording cannot be guaranteed for unscheduled sessions. Conversely, it should never be assumed that recording isn't occurring on open microphones, they are after all connected to the Internet. The links for streaming sources and the schedule will be available thanks to the continued support of the Network Startup Resource Center in their traditional location: http://videolab.uoregon.edu/events/ietf/ I Look forward to seeing some of you in Chicago and hope, that this facility remains useful for remote participants in and observers of the IETF Process. Regards Joel Jaeggli ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Correctly crediting BGP Wedgies
On Wed, 21 Mar 2007, Spencer Dawkins wrote: I mentioned Randy Bush when I was at the plenary mike tonight. According to ftp://ftp.rfc-editor.org/in-notes/rfc4264.txt, it's Tim Griffin and Geoff Huston. I was at NANOG when Randy presented TIM'S slides - http://www.nanog.org/mtg-0405/griffin.html. So I inadvertently mis-spoke. I've slept since 2004, apparently. My apologies, which I can only offer along with encouragement for people who haven't read the presentation and/or RFC to check it out. Tim's doing some interesting stuff now around routing policy and what he calls metarouting. Just for fun see: Towards a Unified Theory of Policy-Based Routing http://www.cl.cam.ac.uk/~ckc25/papers/INFOCOM06.pdf head hurts now. going to lie down. - Lucy Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC Editor RFP update
All The IAOC believes it is very close to agreement with USC on a two year RFC Editor services contract. Agreement should be reached by the end of the current contract extension date (March 31st). The IAOC has informed the two other bidders and asked them to consider re-bidding when the next RFP process cycles through. Should we fail to reach a signed contract with our current preferred bidder, we will be re-opening the RPF process. This process has taken longer than expected, mostly due to issues involving IPR and the older RFCs. We continue to believe that agreement with USC is in the best interests of the IETF at this time. In future however, we may find there are advantages to a split of the RFC Editor and RFC Publisher functions. Over the coming months we look forward to participating in an IAB-led discussion of potential new models and in 14-16 months will will RFP(s) for the model as adopted by the community. For additional information on publication related issues see: www.ietf.org/rfc/rfc4714.txt www.ietf.org/internet-drafts/draft-iab-publication-00.txt www.ietf.org/internet-drafts/draft-iab-rfc-independent-00.txt The IAOC will keep you informed of the contract negotiations. Lucy Lynch IAOC Chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IASA related reports available
All - Please see: http://iaoc.ietf.org/ and watch this site for updates. See you in Prague! - Lucy _ llynch @civil-tongue.net llynch on jabber.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Request for input (patchwork RFCs) (fwd)
All - This is just an up-date on my own request for input: I've heard from a few folk on the list, and a few more off list and the collective feedback indicates that an IAOC approved ION would be the best way to handle the disposition of these tasks. We (the IAOC) will approve and issue an ION derived from the existing draft and I'll let the draft time out. Thanks to all who took the time to respond. - Lucy _ llynch @civil-tongue.net llynch on jabber.org -- Forwarded message -- Date: Fri, 16 Feb 2007 13:39:14 -0800 (PST) From: Lucy Lynch [EMAIL PROTECTED] To: ietf@ietf.org Cc: ipr-wg@ietf.org Subject: Request for input (patchwork RFCs) All - At the behest of the IAOC, I recently published a draft: Tasks previously assigned to the IETF Executive Director http://www.ietf.org/internet-drafts/draft-lynch-execd-tasks-00.txt Which was intended to tidy up some issues left over from our pre-BCP 101 days: BCP 101 [RFC4071] requires the IETF Administrative Oversight Committee to designate, in consultation with the IAB and the IESG, the person or people who carry out the tasks that other IETF process documents say are carried out by the IETF Executive Director. The purpose of this document is to document the agreed designations. The RFCs updated by this document are all those that have not already been obsoleted which assign tasks to the IETF Executive Director (sometimes abbreviated as ExecD). Note that there is no relationship to the IAB Executive Director. In general the tasks concerned are well defined and closely linked to other duties of the IETF Secretariat. Therefore, in what follows, almost all of them are re-assigned to the Secretariat. It is expected that they will normally be performed by the person occupying the role of Head of Secretariat. The document kicked off a short discussion about patchwork RFCs in the IPR-WG: http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04642.html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04643.html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04647.html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04649.html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04650.html Which we (the IAOC) thought had value. We consulted with Jorge Contreras who opined thusly: First, I think we all agree that BCP 101 gives IAOC sufficient authority to redesignate the ExecD's functions to others. I also agree that the redesignations outlined in your draft ID all seem reasonable and inoffensive. The question (I think) is whether this redesignation should be memorialized in an RFC (which would need to go through the community consensus process), or whether IAOC could make such redesignations in a less formal matter, either ad hoc or through publication of an administrative document (are these now called IONs?). Now, the recently published RFC 4693: IETF Operational Notes http://www.rfc-editor.org/rfc/rfc4693.txt says: This document series is intended to capture the set of procedures that the IETF follows, but for which the RFC process is an inappropriate documentation vehicle. So, my question to the community, as the author of this admittedly pitiful draft is: Should I withdraw the draft and publish it as an IAOC approved ION? This seems cleaner to me, but I'd like your input. Thanks - - Lucy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Prague
On Wed, 7 Mar 2007, John C Klensin wrote: --On Wednesday, 07 March, 2007 10:54 -0500 Edward Lewis [EMAIL PROTECTED] wrote: I will attest to Prague being survivable. I have been there once already and suffered no ill effects and was not robbed. I.e., don't panic. Location for location, the IETF (only) goes to the tamest and most accessible places in the world. Compare it to other Internet organizations. At 14:52 -0500 3/6/07...: ... Under the entry for taxis from the airport they say Warning: Prague's taxi drivers ... Ed, I have not suggested don't go to Prague, and certainly don't want to set off a panic -- any more than I would have suggested avoiding Paris. I am just suggesting that the IASA apparatus, including the Secretariat and the IAD, should be taking a little more responsibility for both the decisions and for informing the community about good and bad alternatives than has been the case here... and, in the longer term, for making sure that all of these issues are considered as part of the decision. In choosing Prague here are the factors I considered: We had willing and eager local folks who could provide both transit and local hands. They are warm, smart, and hardworking folk who traveled to San Diego and worked in the NOC there in order to be prepared to help host. We knew they understood the IETF, understood the technical requirements, and really wanted to welcome us to their country. Thanks go to both CZ.NIC and CESNET: http://www.nic.cz/en/ http://www.ces.net/ We had a very nice hotel, capable of holding the IETF and the meeting as a one-roof venue AND it helps meet our Hilton contact threshold. It's an EU venue and we're loaded with US/NA meetings. Both hotel costs and flights are reasonable and connections to the city are pretty good. We had a host (thanks Neustar!) who was willing to step up to the added costs of an EU meeting and they were happy to work with our local transit providers. Factors I didn't anticipate: - folks with no insurance are tempted to go to a country with socialized medicine and never leave, causing said country to require proof of insurance from non-citizens - changes in US passport laws clogging our system Factors I didn't consider - pick pockets - badly behaved taxi drivers but then, I used to live on the lower east side of New York (pre-gentrification), so I think every taxi driver is suspect. - Lucy john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Request for input (patchwork RFCs)
All - At the behest of the IAOC, I recently published a draft: Tasks previously assigned to the IETF Executive Director http://www.ietf.org/internet-drafts/draft-lynch-execd-tasks-00.txt Which was intended to tidy up some issues left over from our pre-BCP 101 days: BCP 101 [RFC4071] requires the IETF Administrative Oversight Committee to designate, in consultation with the IAB and the IESG, the person or people who carry out the tasks that other IETF process documents say are carried out by the IETF Executive Director. The purpose of this document is to document the agreed designations. The RFCs updated by this document are all those that have not already been obsoleted which assign tasks to the IETF Executive Director (sometimes abbreviated as ExecD). Note that there is no relationship to the IAB Executive Director. In general the tasks concerned are well defined and closely linked to other duties of the IETF Secretariat. Therefore, in what follows, almost all of them are re-assigned to the Secretariat. It is expected that they will normally be performed by the person occupying the role of Head of Secretariat. The document kicked off a short discussion about patchwork RFCs in the IPR-WG: http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04642.html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04643.html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04647.html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04649.html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04650.html Which we (the IAOC) thought had value. We consulted with Jorge Contreras who opined thusly: First, I think we all agree that BCP 101 gives IAOC sufficient authority to redesignate the ExecD's functions to others. I also agree that the redesignations outlined in your draft ID all seem reasonable and inoffensive. The question (I think) is whether this redesignation should be memorialized in an RFC (which would need to go through the community consensus process), or whether IAOC could make such redesignations in a less formal matter, either ad hoc or through publication of an administrative document (are these now called IONs?). Now, the recently published RFC 4693: IETF Operational Notes http://www.rfc-editor.org/rfc/rfc4693.txt says: This document series is intended to capture the set of procedures that the IETF follows, but for which the RFC process is an inappropriate documentation vehicle. So, my question to the community, as the author of this admittedly pitiful draft is: Should I withdraw the draft and publish it as an IAOC approved ION? This seems cleaner to me, but I'd like your input. Thanks - - Lucy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Request for input (patchwork RFCs)
On Fri, 16 Feb 2007, John C Klensin wrote: Lucy, It seems to me that anything that the IAOC feels able to do without formally asking for community consensus is a candidate for an ION unless its significance is so broad that permanent/ archival RFC documentation is appropriate. I believe that IAOC should be able to make that decision, ideally announcing it in a way that would permit an appeal if someone felt the decision was seriously out of whack. For this particular draft, I think that translates into you decide. If I were deciding I would recommend ION, but that is just because I aspire to be a charter member of the keep unnecessary administrative clutter out of the RFC Series club. Sign me up! Is there a secret handshake? Do I get to wear a fez? john --On Friday, February 16, 2007 13:39 -0800 Lucy Lynch [EMAIL PROTECTED] wrote: All - At the behest of the IAOC, I recently published a draft: Tasks previously assigned to the IETF Executive Director http://www.ietf.org/internet-drafts/draft-lynch-execd-tasks-00 .txt Which was intended to tidy up some issues left over from our pre-BCP 101 days: BCP 101 [RFC4071] requires the IETF Administrative Oversight Committee to designate, in consultation with the IAB and the IESG, the person or people who carry out the tasks that other IETF process documents say are carried out by the IETF Executive Director. The purpose of this document is to document the agreed designations. The RFCs updated by this document are all those that have not already been obsoleted which assign tasks to the IETF Executive Director (sometimes abbreviated as ExecD). Note that there is no relationship to the IAB Executive Director. In general the tasks concerned are well defined and closely linked to other duties of the IETF Secretariat. Therefore, in what follows, almost all of them are re-assigned to the Secretariat. It is expected that they will normally be performed by the person occupying the role of Head of Secretariat. The document kicked off a short discussion about patchwork RFCs in the IPR-WG: http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04642. html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04643. html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04647. html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04649. html http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04650. html Which we (the IAOC) thought had value. We consulted with Jorge Contreras who opined thusly: First, I think we all agree that BCP 101 gives IAOC sufficient authority to redesignate the ExecD's functions to others. I also agree that the redesignations outlined in your draft ID all seem reasonable and inoffensive. The question (I think) is whether this redesignation should be memorialized in an RFC (which would need to go through the community consensus process), or whether IAOC could make such redesignations in a less formal matter, either ad hoc or through publication of an administrative document (are these now called IONs?). Now, the recently published RFC 4693: IETF Operational Notes http://www.rfc-editor.org/rfc/rfc4693.txt says: This document series is intended to capture the set of procedures that the IETF follows, but for which the RFC process is an inappropriate documentation vehicle. So, my question to the community, as the author of this admittedly pitiful draft is: Should I withdraw the draft and publish it as an IAOC approved ION? This seems cleaner to me, but I'd like your input. Thanks - - Lucy ___ Ipr-wg mailing list Ipr-wg@ietf.org https://www1.ietf.org/mailman/listinfo/ipr-wg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Second call for nominations: IAOC position selected by the IAB
On Mon, 4 Dec 2006, Leslie Daigle wrote: The IAB is making a call for nominations for the IETF Administrative Oversight Committee (IAOC), as described in BCP 101 (RFC 4071) and BCP 113 (RFC 4333). The IESG and the IAB each select one person for a two-year IAOC term in alternate years. This year, the IAB will select one person for a term ending in spring 2009. The incumbent is Lucy Lynch, who was selected by the IAB for an initial two year term expiring in spring 2007. For the record - the incumbent is stepping down, which means that this is your opportunity to step up and be part of the IASA process. I highly recommend the job - it's hard work, but fun and the rest of the team are great to work with. If you have questions about the work, feel free to contact me directly. - Lucy Candidates for these IAOC positions should have knowledge of the IETF, knowledge of contracts and financial procedures, and familiarity with the administrative support needs of the IAB, the IESG, and the IETF standards process. The candidates are also expected to be able to understand the respective roles and responsibilities of the IETF and ISOC in this activity, and be able to articulate these roles within the IETF community. The candidates will also be expected to exercise all the duties of an IAOC member, including being prepared to undertake any associated responsibilities. These include, but are not limited to, the setting of administrative support policies, oversight of the administrative operations of the IETF, and representing the interests of the IETF to the IAOC. The candidates must be able to undertake full participation in all Committee meetings and Committee activities. The IAB-selected member of the IAOC does not directly represent the IAB. The IAB and IESG selected members are accountable directly to the IETF community. Candidates do not need to be current members of the IAB or IESG, and in fact we prefer nominations and volunteers from the rest of the community. If you are interested in one of these positions, or know of someone who may be a good fit for this position, please send the name and email address to Phil Roberts, Executive Director of the IAB at [EMAIL PROTECTED]. The IAB will respond with a questionnaire, asking for the candidates' qualifications and willingness to serve. The names of all people who declare themselves willing to serve will be made public on the ietf-announce@ietf.org list after the end of the solicitation period (December 22). The IAB expects to make a decision on or before January 29 (prior to the expected date at which the Nomcom will select its IAOC nominee). Leslie Daigle, for the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IASA Reports - IETF 67, San Diego
All - Reports from the IAOC, the IAD, IANA, and the RFC Editor can be found here: http://iaoc.ietf.org/ Members of the IAOC will be available during our open office hours in Marina Room 2: Wednesday, November 8th, 1610-1650 PST Thursday, November 9th, 1610-1650 PST Please drop by if you have questions, comments, or concerns. Lucy Lynch IAOC Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: nomcom and confidentiality
On Tue, 7 Nov 2006, Harald Alvestrand wrote: I think some of Laksminath's concern is valid. But I think the solution to the problem is simple: Make it publicly known who is on the technical staff that supports the Nomcom, and make it clear that these people: 1) May learn Nomcom information as a side effect of their technical work to support Nomcom 2) Have promised not to reveal that information to others, and have promised not to take any other action based on that information (apart from fixing technical problems) This is analogous to the role of an email postmaster: He *can* read any mail on the system, if he really wants to, but we trust him to not *do* it - or, if he has to during debugging, we trust him to forget what he's read. I trust that Henrik thought this was so obvious it didn't need mentioning. Completely sensible - and in the interest of elegance, I'd reduce this personally to I trust Henrik. - Lucy Harald --On 7. november 2006 00:39 -0800 Lakshminath Dondeti [EMAIL PROTECTED] wrote: Fred, When I saw a non-nomcom member having access to what I thought was nomcom-confidential, I was very concerned and now doubt the entire process. I was told that it is secure, but it has not been verified as far as I can tell. At this point, no offense to the tools team, I remain unconvinced. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
lost and found
All - Found a headset in the hallway - identify to claim. - Lucy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IASA Reports - IETF 67, San Diego
All - Reports from the IAOC, the IAD, IANA, and the RFC Editor can be found here: http://iaoc.ietf.org/ Members of the IAOC will be available during our open office hours in Marina Room 2: Wednesday, November 8th, 1610-1650 PST Thursday, November 9th, 1610-1650 PST Please drop by if you have questions, comments, or concerns. Lucy Lynch IAOC Chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
