Re: Query to the community -- An additional IETF Meeting event?
I have two comments on this. 1) I am in favor of allowing the IAOC to experiment with an event (or two) like this for the purposes of developing running code with the associated pros, cons and economics. 2) I would attend such an additional event if the gear on display was related to technology I am personally interested in (e.g. commerically available IPv6 Ready gear). Regards, Ed J. On Fri, Mar 16, 2012 at 3:49 PM, IAOC Chair bob.hin...@gmail.com wrote: The IESG and IAOC are considering an addition to the IETF meeting week, and we would like your views before we develop the idea further. At NANOG, there is a Beer and Gear reception one evening. There are exhibitor tables with product vendors (hardware and software) and service providers (registries, registrars, ISPs, ESPs, etc.) and anyone else interested in face time with NANOG participants. They show their equipment and services. There is bar in the center of the room serving beer, wine, and soft drinks. There are hors d'oeuvres scattered around the room. QUESTION: What do you think about doing a Beer and Gear style of event on an evening that does not conflict with other IETF activities? This would be an opportunity for free food and drink for attendees, for vendors and service providers to talk with IETF participants, and for additional revenue to the IETF. Obviously, attendance would be optional. Technical people are at the tables, not sales or marketing staff. Vendors know that the audience is very technical, so they send the people that can communicate with that audience. We would charge for exhibit tables, to raise additional funds for the IETF. A stronger base of opportunities for IETF sponsorship distributes our funding, making it less fragile; this could make it less likely that we would have last-minute scrambles for additional sponsors, including hosts. A successful Beer-and-Gear like event would not solve this but it would help. In the past, the IETF has avoided vendor exhibits and demonstrations. However it is clear that NANOG has found a balance that works and that NANOG participants and the vendors consider the event valuable. We believe this could translate well to the IETF. We are considering some test events, hopefully to be held at IETF 84 (Vancouver, July 2012) and IETF 85 (Atlanta, November 2012). The kinds of evaluation criteria we are considering could include: - Did participants enjoy the event? - Did vendors consider the event successful? - Did the IETF raise additional funds? - Did the event steal potential sponsors away from other aspects of the meeting? So, what do you think? Is this something that we should try? Please respond on the ietf@ietf.org mail list. On behalf of the IESG and the IAOC, Russ Housley Bob Hinden
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
I also recall a Plenary presentation during IETF 57 in Vienna which suggested a reversal in the IETF's previous stance on this topic. http://www.ietf.org/proceedings/57/slides/plenary-10.pdf If my memory serves me correctly, I believe the logic was along the lines of Law enforcement agencies require some capabilities that are aking to backdoors. Given this, it would be better if we (who know what we are doing) designed these capabilities, rather than leave it to others do so. Regards, Ed J. On Wed, Mar 9, 2011 at 10:50 AM, Harald Alvestrand har...@alvestrand.nowrote: Actually, this discussion has been going on for longer than so-far referenced docs show. One of my favourite RFCs on the subject: RFC 2804 IETF Policy on Wiretapping. IAB, IESG. May 2000. The Internet Engineering Task Force (IETF) has been asked to take a position on the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is no, and what that answer means. On 03/06/11 21:52, Dean Willis wrote: Marc suggested: I any case, may I suggest a Bar BOF in Prague? Plotting revolutions in coffeehouses is a very old tradition. Excellent idea. Perhaps this should be plotted over jasmine tea instead of coffee... The point I really want to stress is that we must stop deliberately designing privacy, integrity, and obscurity weakness into our protocols, and where we can't avoid weakness we should at least consider its implications. We have a real lack of understanding of these issues in the community. For example, if Alice and Bob have a communications session, IETF has never clued onto the fact that Alice and Bob might want intermediary Charlie not jut to be unable to read the data of their session, but to not even be able to know that they have one. We might not be able to hide the fact that Alice has a session with SOMEBODY from her next-door neighbor Allen, or the fact that Bob has a session from his next-door neighbor Burt, but even if Allen and Burt are working together, we should be able to hide the Alice-Bob relationship. What do I mean by not designing weakness into our protocols? I give you SIP, for example. After twelve years of work, I have yet to make a real call using the optional sips signaling model. Why? It's optional. Nobody uses it. Actually, I'm having a hard time using even basic SIP any more -- it looks like Google just pulled-the-plug on my telephony ISP service, which had been provided by the Gizmo Project. But that's another problem. -- Dean ___ 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: Poster sessions
+1 Regards, Ed J On 1/6/11, Marshall Eubanks t...@americafree.tv wrote: On Jan 6, 2011, at 5:16 AM, Yoav Nir wrote: On Jan 6, 2011, at 11:26 AM, Alessandro Vesely wrote: I've never attended an IETF meeting. Why? Because it seems to me quite unlikely to have a chance to say something useful by going there. I mean useful with respect to a problem that I consider important. That is, not just a minimal contribution to an already scheduled session that I may happen to attend. Perhaps, I should request a session... Problems are often expressed in the form of tentative solutions. Such solutions may occasionally happen to be discussed, refined, and agreed upon by a group of individuals. Implementation, standardization, and adoption may eventually follow --not necessarily in this order. Isn't this how the IRTF and the IETF should work? A poster session would be a sort of plenary, lasting a couple of hours or so, with posters hanged on numbered hardboard panels arranged along a walkway. A poster may be sized A0, or ~50 in, or consist of an equivalent number of smaller sheets. Posters may stay exposed for a few hours before/after the scheduled time period. During the session time, however, authors should stand beside their posters and thus have their chance to talk to any interested ietfers, one by one or in small knots, informally. A few dozens of posters per session may provide for adequate gathering. IME, this way of participating is easier and less binding for both authors and attendees. A poster would suit subjects for which it's difficult to carve a niche within a hosting WG's session, but it may also work as a means to achieve consensus on a given topic before raising it in a more official discussion. Opinions/suggestions? Hi Alessandro. Following the Maastricht meeting, there was a lively discussion of a similar issue. The way things are, you need a lot of support to present an idea at a BoF, so the usual way to present new things has become to publish a bar BoF and present there. Despite the name, the modern bar BoF is not held in a bar, but rather in the empty conference rooms during lunch time and late in the evening. Understandably, people don't like this much. There have been a few suggestions for alternate ways of presenting and gathering supporters. One such suggestion is in this draft: http://tools.ietf.org/html/draft-nir-non-wg-presentations-01 A poster session sounds cool, but it works well when the presenters are companies, rather than individuals. To get a good A0 poster, you need access to printing services (which are not cheap, but doable) and graphic design talent, which is neither cheap nor common in IETF attendees. To get such a poster up, I would need either my company's sponsorship, or else use my own talents in graphic design: Hmm, #12FF12. Now there's a nice shade of green for a background. As for fonts, let's go with Mistral, because http://www.cracked.com/funny-5647-fonts . I am neutral on the overall idea, but in many (most?) academic conferences in a poster session you get a pin board (hopefully with a bunch of pins), which lends itself well to pinning up a set of printed out slides. I have seen many fine poster session presentations from people with very little money, so I don't agree it unduly favors the well sponsored. And it has one great advantage... Seriously, though, most of the presentation slides you see in an IETF meeting are either black-on-white with way too much text, ... in that you can read the slides with too much text at your leisure if you want to, rather than having them flash by unread. I am not sure it would fit well with the IETF ecosystem, as it takes time to scan through a bunch of posters, and it takes time to stand by your poster and answer any questions, and time is always short at an IETF. Maybe we could just have them in the halls and call them a hall-BOF. Regards Marshall sometimes adding some default design from the software, or else they're extremely well designed, where you know there's been some company sponsorship. Some of the Internet-of-Things presentations in recent IETF meetings are examples of the latter. I think that's too high a bar to set for new ideas that still don't have much traction. It could be done with some booths instead of the posters - maybe some desks arranged around a room. Yoav ___ 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: Why not use on-line tool to track each working group's attendees?
IEEE802 uses formal voting (during its meetings) to determine issues and to accept proposals (or motions) to add or delete text from documents that are being developed. In addition, IEEE802 has rules for how many meetings a person has to attend to develop voting rights, and thereafter, how many meetings the person needs to keep attending to retain voting rights. I can understand why IEEE802 developed an electronic tracking system for their attendees. Keeping track of all the above via paper-based sign-in sheets was a lot of work, and also fairly easy to game or exploit. The IETF WG process is very different from IEEE802, and that (for me) is reason enough to suggest that a system built for the IEEE802 may not be appropriate for IETF. There are lots of other reasons too ... Regards, Ed J. On Fri, Aug 6, 2010 at 10:25 AM, Linda Dunbar ldun...@huawei.com wrote: I understand that Blue Sheet has been the tradition of IETF to track the attendees to each working group. But people’s hand writing is all different, it takes some work to track the names and contact information on Blue Sheet. IEEE802 has moved to On-Line attendee log ( https://seabass.ieee.org/imat/index). It will be easier for every one if an on-line attendee tool is used. Best Regards, Linda Dunbar ___ 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] Proposed IAOC Administrative Procedures
Bob, is this a *new* Administrative Procedures document (for the IAOC), or a proposed revision to an existing document that was produced some number of years ago? If the former, then perhaps the message that launched this thread should have said something like the IAOC is considering an update to its administrative procedures, and would like community feedback on the proposed revisions. Just wondering ... Regards, Ed J. On Wed, Jun 2, 2010 at 11:11 PM, Doug Barton do...@dougbarton.us wrote: On 06/02/10 10:50, Bob Hinden wrote: The IAOC's intent in creating these proposed IAOC administrative procedures was to write down what we were doing in areas where we thought BCP101 wasn't clear to us or didn't specify anything, and then get feed back from the community. We were not trying to revise or alter BCP101. We wanted this to be transparent to the community. From the comments received so far, I think this wasn't clear enough and we will try to have the next version make this clearer. Regarding the minutes, what can I say except mea maxima culpa. We have fallen behind and will try hard to get caught up between now and Maastricht. Bob, I think it's probably safe to assume that your actual goal in this effort was to promote transparency. Given that as a goal, one wonders if there are any activities in that category that should have a higher priority than producing thorough and up to date minutes, which the community has repeatedly asked for, and which you have promised to produce. Put another way, given that there are only so many hours in the day I have a hard time imagining why you would choose to spend some of them working on this document instead of working on the minutes. Of course, if there was some overwhelming demand from the community for an administrative procedures document that I'm not aware of, I'd appreciate a pointer so that I can get up to speed. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/http://supersetsolutions.com/ ___ 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: On Day Passes..
I might be talked into agreeing with most of your points, but I am not convinced that if you buy a day pass, you should certainly be nomcom eligible. How about replacing should certainly with may? Regards, Ed J. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Danny McPherson Sent: March-24-10 10:00 PM To: The IETF Subject: On Day Passes.. Figured I'd be the one to kick a thread off on this fascinating topic :-) I like the idea of day passes, it's not just about the cost of the day pass and all it avails, if someone is only coming to the IETF meeting for a day (e.g., they only want a day pass because they have a time constraining day job or actual fiscal constraints), then why should they be required to pay a fee to subsidize meeting costs for the entire week? The work happens on the mailing lists, consensus is judged on the mailing list, and remote participation is encouraged as well. And if you buy a day pass, you should certainly be nomcom eligible. -danny ___ 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: ANNOUNCEMENT: New FAQ on IETF Copyright Policy available (FYI)
Simon, Thank you for your message. ... is there any particular reason why IETF Trust documents aren't written using the excellent xml2rfc tool? Actually ... no. This is a good suggestion. Best Regards, Ed On Tue, Mar 24, 2009 at 3:56 AM, Simon Josefsson si...@josefsson.orgwrote: Ed Juskevicius edj@gmail.com writes: FYI, a well-written new FAQ has just been posted to the IETF Trust website. Thank you! This may sound as nit-picking, but is there any particular reason why IETF Trust documents aren't written using the excellent xml2rfc tool? I find the output from xml2rfc is more readable. These documents could also be submitted as proper I-D's, to provide better archival, searching, and cross-referencing of the documents. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
ANNOUNCEMENT: New FAQ on IETF Copyright Policy available (FYI)
FYI, a well-written new FAQ has just been posted to the IETF Trust website. The title of the FAQ is: * IETF Trust *Copyright Policy and Trust Legal Provisions (TLP) This FAQ was created in response to some uncertainty within the community about the RFCs, BCPs, and Trust policies that govern copyrights in IETF (and other) documents. The FAQ was prepared by Jorge Contreras (IETF Trust Legal Counsel), at the request of Ray Pelletier (IAD) and the IETF Trustees. I believe the FAQ is informative, relevant and well worth the 10 minutes it takes to read it. I encourage you to review it. The FAQ is available at: http://trustee.ietf.org/faqs.html Regards, Ed Juskevicius IETF Trust Chair edj@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FW: ANNOUNCEMENT: The IETF Trustees Announce the start of a new 30-day Community Review ...
The purpose of this message is to announce the start of a 30-day community review period for a proposed revision to the IETF Trust's Legal Provisions Relating to IETF Documents (TLP) policy. The intended purpose of this TLP revision is to delete the hard requirement for copyright boilerplate text to appear on the first page of every IETF document. This is in response to recent suggestions from the community and discussion amongst the Trustees. The details of the proposed revision to the TLP are as follows: - delete the requirement that copyright text must appear on the first page of every new IETF Document, - add text to say the IESG will specify where copyright and other legal boilerplate text should appear in Internet Drafts, and - add text that the RFC Editor will specify the manner and location of copyright text for RFCs The new text is for the start of Section 6 in the TLP document. The proposed text is as follows: 6.Text To Be Included in IETF Documents. The following text must be included in each IETF Document so as to give reasonable notice of the claim of copyright. The IESG shall specify the manner and location of such text for Internet Drafts. The RFC Editor shall specify the manner and location of such text for RFCs. A marked-up version of the TLP document is available on the IETF Trust website under the heading: Draft Policies and Procedures for IETF Documents at http://trustee.ietf.org/policyandprocedures.html Please accept this message as a formal request by the IETF Trustees for your review and feedback on the proposed revision to the TLP document. Today marks the beginning of a 30-day community review period. I expect the Trustees will appreciate all comments and suggestion received during this review period, and then decide on whether to adopt this revision shortly after April 15th, 2009. Regards, and Thanks in advance, Ed Juskevicius IETF Trust Chair edj@gmail.com ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
FW: ANNOUNCEMENT: The IETF Trustees Announce the start of a new 30-day Community Review ...
The purpose of this message is to announce the start of a 30-day community review period for a proposed revision to the IETF Trust's Legal Provisions Relating to IETF Documents (TLP) policy. The intended purpose of this TLP revision is to delete the hard requirement for copyright boilerplate text to appear on the first page of every IETF document. This is in response to recent suggestions from the community and discussion amongst the Trustees. The details of the proposed revision to the TLP are as follows: - delete the requirement that copyright text must appear on the first page of every new IETF Document, - add text to say the IESG will specify where copyright and other legal boilerplate text should appear in Internet Drafts, and - add text that the RFC Editor will specify the manner and location of copyright text for RFCs The new text is for the start of Section 6 in the TLP document. The proposed text is as follows: 6.Text To Be Included in IETF Documents. The following text must be included in each IETF Document so as to give reasonable notice of the claim of copyright. The IESG shall specify the manner and location of such text for Internet Drafts. The RFC Editor shall specify the manner and location of such text for RFCs. A marked-up version of the TLP document is available on the IETF Trust website under the heading: Draft Policies and Procedures for IETF Documents at http://trustee.ietf.org/policyandprocedures.html Please accept this message as a formal request by the IETF Trustees for your review and feedback on the proposed revision to the TLP document. Today marks the beginning of a 30-day community review period. I expect the Trustees will appreciate all comments and suggestion received during this review period, and then decide on whether to adopt this revision shortly after April 15th, 2009. Regards, and Thanks in advance, Ed Juskevicius IETF Trust Chair edj@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Abstract on Page 1?
+1. I agree. Regards, Ed Juskevicius -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Julian Reschke Sent: March 7, 2009 3:46 AM To: Scott Lawrence Cc: John C Klensin; ietf@ietf.org Subject: Re: Abstract on Page 1? Scott Lawrence wrote: ... This is a trivial change for the generation tools to make - at worst it will make one generation of diffs slightly more difficult (and I'd be happy to trade one generation of poor diffs for this, so for me just don't worry about fixing the diff tools). ... At this point, no change to the boilerplate is trivial anymore. For xml2rfc, we need to - define how to select the new behavior (date? ipr value? rfc number?); if the behavior is not explicitly selected in the source, we need heuristics when to use the old one and when to use the new one (keep in mind that the tools need to be able to generate historic documents as well) - add new test cases - add documentation So, I'm not against another re-organization, but, in this time, PLEASE: - plan it well (think of all consequences for both I-Ds and RFCs) - make the requirements precise and actually implementable (remember: must be on page 1 :-) - give the tool developers sufficient time; optimally let *then* decide when the cutover date should be BR, Julian ___ 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: IASA irresponsibility? (was: Re: [IAB] [Trustees] LastCall for Comments: Proposed work-around to the Pre-5378 Problem)
John, this is to respond to one of your points, below: As far as the where does it go question, the answer may be clear to you, but it apparently was not clear to the Trustee Chair (and poster of the announcement) who, according to comments on the XML2RFC list, apparently indicated that it would be ok to put it at the end. For the record, I received a question on January 23rd about whether it might be better to move all of the copyright and associated boilerplate text required on Contributions from the first page, to the back of every document. The basis of the question was that the length of the legal statements needed on documents was growing, and it might not all fit neatly at the front. I replied on the same day. I thanked the sender for the question, and took an action to discuss this with the Trustees. Please note that I did not post this on the XML2RFC list, so you may be the victim of here-say in this case. Many things have transpired since January 23rd. One is that I failed to explicitly close the loop with the person who asked me if the legal text might be moved to back matter. We have had four revisions to the Legal Provisions policy since the first call for community comments was posted on January 6th. Two versions of the draft were posted before January 23rd, two more were posted afterwards, and then the last (fifth) revision is the one that was approved on February 12th, and made Effective as of February 15th. The guidance with respect to where legal text in Contributions is to appear was consistent in all of these drafts. Legal text is to appear in the front matter of Contributions. Regards, Ed Juskevicius -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: February 20, 2009 4:07 PM To: Ray Pelletier Cc: Trustees; wgcha...@ietf.org; ietf@ietf.org; i...@iab.org; i...@ietf.org; rfc-edi...@rfc-editor.org Subject: IASA irresponsibility? (was: Re: [IAB] [Trustees] LastCall for Comments: Proposed work-around to the Pre-5378 Problem) Ray, The expectation in that January discussion was that the Trustees and IAOC were going to be proactive about this and take responsibility to make sure things got done. I don't consider your notifying the volunteers and asking for a schedule to be consistent with that. They are, after all, volunteers. Indeed, if the IASA were taking this seriously, I would have expected that you would approach the various maintenance groups and said look, we know that text is going to need to go in, and go into this place, we just aren't sure about the text yet, obtained the source code and patching instructions, and then arranged for either the Secretariat or someone on a short-term contract to be on standby to get those changes made. Perhaps I'm the only one in the community who feels that way, but I'd be a little surprised. As far as the where does it go question, the answer may be clear to you, but it apparently was not clear to the Trustee Chair (and poster of the announcement) who, according to comments on the XML2RFC list, apparently indicated that it would be ok to put it at the end. I hope that there is real testing going on to verify that the none of the relevant servers and connections will fail when the load hits. That is real testing, and additional configurations if needed, not your sending out a note indicating that people should be aware of the risk. Please recall that the supposed purpose of the IASA and its current organizational model was to protect the IAB, IESG, and the community from having to deal with these sorts of administrative problems, and even more to protect against depending on mad scrambles by volunteers to get things done in order to prevent administrative meltdowns. If this is an example, I don't think that is working out very well but, again, maybe I'm the only member of the community who feels that way. john --On Friday, February 20, 2009 15:46 -0500 Ray Pelletier rpellet...@isoc.org wrote: On Feb 20, 2009, at 3:20 PM, John C Klensin wrote: ... So the announcement was made and, despite those commitments, the ducks obviously were not lined up, the tools were not ready, and we still can't, in practice, post drafts that need the workaround text. So, the Trustees went through a process of community review of the changes to the TLP posted on 6 January that resulted in some good suggestions that led to iterations and posting of changes on 22 Jan, 5 Feb, 9 Feb and finally 12 Feb. They even caught where a change was unintentionally made. On 11 Feb I notified the 5 volunteers maintaining the tools and templates that the Trustees were voting on what I expected to be the last set of changes; advised them of the changes and asked if they could have the changes completed in a few days, e.g, 14 Feb. I asked for estimated delivery dates. Not all were able to get the changes made. And as I said above I am uncertain
Re: Last Call for Comments: Proposed work-around to the Pre-5378 Problem
I am pleased to announce that the IETF Trustees have just finished work on a revision to our Legal Provisions Relating to IETF Documents policy. The revision includes optional new legend text in Section 6.c.iii of the policy to serve as a work-around for people experiencing the pre-5378 problem. Please note the newly approved policy is dated 2009-02-12. Please also note that the Effective Date of this revised policy has been set to 2009-02-15. The old policy (effective from November 10, 2008) remains in force until 00h00 UTC on February 15th. The approved text is available now on IETF Trust website at http://trustee.ietf.org/policyandprocedures.html Please look for the document dated 2009-02-12, just below the heading labeled DRAFT Policy and Procedures Being Developed. On or shortly after February 15th, the Trust website will be updated so as to archive all of the recent draft versions of the new policy, and to make it easier to navigagte to the newly approved policy. Please review the new policy so you are aware of the latest copyright statements and other boilerplate legend text that will be required on all contributions to the IETF starting on February 15, 2009. Regards, and Thanks in advance, Ed Juskevicius, on behalf of the IETF Trustees edj@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call for Comments: Proposed work-around to the Pre-5378 Problem
I am pleased to announce that the IETF Trustees have just finished work on a revision to our Legal Provisions Relating to IETF Documents policy. The revision includes optional new legend text in Section 6.c.iii of the policy to serve as a work-around for people experiencing the pre-5378 problem. Please note the newly approved policy is dated 2009-02-12. Please also note that the Effective Date of this revised policy has been set to 2009-02-15. The old policy (effective from November 10, 2008) remains in force until 00h00 UTC on February 15th. The approved text is available now on IETF Trust website at http://trustee.ietf.org/policyandprocedures.html Please look for the document dated 2009-02-12, just below the heading labeled DRAFT Policy and Procedures Being Developed. On or shortly after February 15th, the Trust website will be updated so as to archive all of the recent draft versions of the new policy, and to make it easier to navigagte to the newly approved policy. Please review the new policy so you are aware of the latest copyright statements and other boilerplate legend text that will be required on all contributions to the IETF starting on February 15, 2009. Regards, and Thanks in advance, Ed Juskevicius, on behalf of the IETF Trustees edj@gmail.com ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RE: how to contact the IETF
Noel wrote: Rather than adopt indirect measures (such as requiring people to be registered users of a list), I would go straight to the heart of the matter, and adopt a formal policy that a mass email campaign should count _against_ the position taken by that campaign, precisely to dis-incentivize such campaigns. A formal policy would require some clear definition of what a mass email campaign is. How would/could we draw a line and define that term? Would 100 people sending more or less the same text to a list in less than 24 hours constitute a mass email campaign? I would say 'yes'. What about 50 people over 2 days? Maybe still 'yes'. How about 20 people over a week, or 10 people recited the same cut and pasted text during a longer last-call timeframe? I am not trying to pour cold water on your idea here, but rather I am wondering how something like this could be formalized, versus handled as an exceptional case when and if it occurs. Regards, Ed J. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Noel Chiappa Sent: February 10, 2009 11:21 AM To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: Re: how to contact the IETF From: Andrew Sullivan a...@shinkuro.com This means that those driving by have to be tolerated, I think. Ah, no. Because if organizing an email campaign works for the FSF, next thing you know, BigCorp X will be telling everyone who works for it 'we want standard Q approved, please send email to the IETF list about that'. If we allow ourselves to be influenced by a mass email campaign, all we are doing is virtually guaranteeing that we will get more. So I think we have an active interest is responding _negatively_ to such campaigns. Rather than adopt indirect measures (such as requiring people to be registered users of a list), I would go straight to the heart of the matter, and adopt a formal policy that a mass email campaign should count _against_ the position taken by that campaign, precisely to dis-incentivize such campaigns. Noel ___ 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: how to contact the IETF
Melinda wrote: I don't really how understand count against would work in practice. I agree. This would be another important consideration for any policy, and (I suspect) not very easy to define. Regards, Ed -Original Message- From: Melinda Shore [mailto:msh...@cisco.com] Sent: February 10, 2009 11:36 AM To: Ed Juskevicius; 'Noel Chiappa' Cc: ietf@ietf.org Subject: Re: how to contact the IETF On 2/10/09 11:34 AM, Ed Juskevicius edj@gmail.com wrote: I am not trying to pour cold water on your idea here, but rather I am wondering how something like this could be formalized, versus handled as an exceptional case when and if it occurs. I don't really how understand count against would work in practice. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Last Call for Comments: Proposed work-around to thePre-5378 Problem
Cullen, in answer to your question, Yes. A penultimate draft of the proposed changes to the Legal Provisions document is available from the IETF Trust website at http://trustee.ietf.org/policyandprocedures.html Please look at the version labelled: Draft Legal Provisions Relating to IETF Documents after Community Last Call (2009-02-09) FYI this draft is currently before the Trustees, for a decision by end of tomorrow. If the Trustees accept this draft, then two final edits will be required to formally adopt this policy document. The edits will be: 1) To finalize and identify the Effective Date in the title on page 1, and 2) To insert the effective date into the header information of pages 2-7 of the document. Regards, Ed Juskevicius On Tue, Feb 10, 2009 at 1:10 PM, Cullen Jennings flu...@cisco.com wrote: I've gotten a bit lost on all the changes. Would it be possible to send to the list a single email that summarizes the current proposed changes to the document published on the web sight? or just a new copy of the document? On Feb 9, 2009, at 5:41 PM, Contreras, Jorge wrote: -Original Message- From: Thomas Narten [mailto:nar...@us.ibm.com] Sent: Monday, February 09, 2009 6:23 PM To: Marshall Eubanks Cc: Contreras, Jorge; Trustees; SM; ietf@ietf.org Subject: Re: [Trustees] Last Call for Comments: Proposed work-around to thePre-5378 Problem NEW PROPOSED c. Derivative Works and Publication Limitations. If a Contributor desires to limit the right to make modifications and derivative s/desires/needs/ I don't think that desires is appropriate here - as John pointed out, the contributor has no discretion here, except for their judgement as to whether rights are available. Actually, in this case, it is the submitters choice, since we are talking about case (i) or (ii) (and not (iii) which has been the challenging case). And desires is the wording that has been used here for a while. But that said, a more neutral term is fine by me, since the motivations for needing to select this may vary. How about chooses? Thomas chooses is fine with me ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Trustees mailing list trust...@ietf.org https://www.ietf.org/mailman/listinfo/trustees ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call for Comments: Proposed work-around to the Pre-5378 Problem
Alfred, I apologize for not having PDF versions of the last call documents on the IETF Trust website before now. Thank you for noticing this problem. Please be advised we have now resolved the issue. PDF versions of the 'marked-up' and the 'clean' version of the 2009-02-05 document are now available at: http://trustee.ietf.org/policyandprocedures.html Best Regards, Ed Juskevicius edj@gmail.com -Original Message- From: Alfred HÎnes [mailto:a...@tr-sys.de] Sent: February 6, 2009 5:47 AM To: edj@gmail.com Cc: ietf@ietf.org Subject: Last Call for Comments: Proposed work-around to the Pre-5378 Problem Hello, could you please post a version of the draft that can be read by notorious non-users of M$ systems (there are!) ? It is a rather unexpected precedent that an important IEFT document is not made available in one of the document formats commonly used in the IETF. Kind regards, Alfred HÎnes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call for Comments: Proposed work-around to the Pre-5378 Problem
The IETF Trustees met via telechat on February 5th to decide on some proposed revisions to the Legal Provisions Relating to IETF Documents policy, based on comments received from the community in the last two weeks. Please recall this work is being done to provide a work-around for authors having the 'pre-5378 problem'. The telechat was productive. The Trustees reached consensus to do the following: 1) Clarify the copyright text at the beginning of the BSD license in Section 4.1 to read as follows: Copyright (c) insert year IETF Trust and the persons identified as its authors. All rights reserved. 2) Replace the word and by the word or in one place so that the last sentence of Section 6.c.iii becomes: Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 3) Fix some nits with respect to the inappropriate use of square brackets '[' and ']' in two places. The IETF Trust website has been updated with a new version of the draft Legal Provisions Relating to IETF Documents including the changes described in this message. Please look for the documents dated 2009-02-05 at: http://trustee.ietf.org/policyandprocedures.html . If you have any final comments on this, please post them before the end of February 7th. This is the last call for comments. Regards, Ed Juskevicius, on behalf of the IETF Trustees edj@gmail.com ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call for Comments: Proposed work-around to the Pre-5378 Problem
The IETF Trustees met via telechat on February 5th to decide on some proposed revisions to the Legal Provisions Relating to IETF Documents policy, based on comments received from the community in the last two weeks. Please recall this work is being done to provide a work-around for authors having the 'pre-5378 problem'. The telechat was productive. The Trustees reached consensus to do the following: 1) Clarify the copyright text at the beginning of the BSD license in Section 4.1 to read as follows: Copyright (c) insert year IETF Trust and the persons identified as its authors. All rights reserved. 2) Replace the word and by the word or in one place so that the last sentence of Section 6.c.iii becomes: Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 3) Fix some nits with respect to the inappropriate use of square brackets '[' and ']' in two places. The IETF Trust website has been updated with a new version of the draft Legal Provisions Relating to IETF Documents including the changes described in this message. Please look for the documents dated 2009-02-05 at: http://trustee.ietf.org/policyandprocedures.html . If you have any final comments on this, please post them before the end of February 7th. This is the last call for comments. Regards, Ed Juskevicius, on behalf of the IETF Trustees edj@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Document posting schedule pragmatics (was: Re: ANNOUNCEMENT: The IETF Trustees invite your comments on revised proposed legend text to work-around the Pre-5378 Problem)
John Klensin wrote: As a partial alternative, would it be possible to squeeze the comments by Feb 7, decision by February 15 schedule somewhat? Yes, I think the interval after Feb 7th could be squeezed by a few days. Our commitment (as Trustees) is to reach a decision and to communicate it to the community no later than February 15th. My personal hope is that we can reach consensus several days before the 15th, but certainly not before the 7th. February 7th the hard-coded end of the 30-day window for community review and comments. With respect to your other point: Can the community safely assume that ... xml2rfc servers, submission servers, the manual submission process, etc., are all up to the load of having both the queue of documents that have been accumulating since shortly after IETF 73 and the usual pre-IETF rush hitting them at once? Good question! Thanks for asking. I'll ask our IAD to look into this and report back. Best Regards, Ed Juskevicius edj@gmail.com -Original Message- From: John C Klensin [mailto:john-i...@jck.com] Sent: January 23, 2009 12:37 PM To: Ed Juskevicius; ietf@ietf.org; wgcha...@ietf.org; i...@iab.org; i...@ietf.org; rfc-edi...@rfc-editor.org Cc: 'Trustees'; 'Contreras, Jorge' Subject: Document posting schedule pragmatics (was: Re: ANNOUNCEMENT: The IETF Trustees invite your comments on revised proposed legend text to work-around the Pre-5378 Problem) Hi. I apologize for cluttering up these lofty discussions of IPR theory and statements with a question about getting work done, but... --On Friday, January 23, 2009 0:29 -0500 Ed Juskevicius edj@gmail.com wrote: ... Please recall that some I-D authors have experienced difficulty implementing RFC5378 since it was published on November 10, 2008. An example of the difficulty is summarized below: - an author wants to include pre-5378 content in a new submission or contribution to the IETF, but ... The Trustees will meet again in early February to decide on whether to revise the Trust License Policy based on the ... The Trustees need to decide on whether to adopt the proposed legend text, and then communicate our decision to you on or before February 15th. The first I-D posting cutoff is March 2nd. Assuming that the Trustee's decision is communicated on February 15 and that it is clear enough to be immediately implemented, that leaves two weeks in which all of the new (00) documents that are presumably ready now (except for a bad case if IPR-induced-constipation) to get posted and three weeks for revised documents. Even those periods are likely to be somewhat shorter in practice unless the IAOC has arranged for various tool maintainers to be waiting, fingers poised over keyboards, for the decision and text on Sunday the 15th. Can the community safely assume that the Trustees (wearing their IAOC hats), the IAD, and the Secretariat have made plans to be sure that xml2rfc servers, submission servers, the manual submission process, etc., are all up to the load of having both the queue of documents that have been accumulating since shortly after IETF 73 and the usual pre-IETF rush hitting them at once? I would assume that such plans would include some fairly extensive load-testing of existing systems to determine whether additional servers, links, and staff assignments are needed... and adding and testing the needed facilities and arrangements RSN. The observation that, at present, we are running with one xml2rfc server does not inspire confidence if we expect it to be hit by a giant document glut (or even a normal pre-IETF glut). However, I'm equally concerned about the submission servers and back-end posting systems and anywhere else that a bottleneck could occur, not just that one. As a partial alternative, would it be possible to squeeze the comments by Feb 7, decision by February 15 schedule somewhat? I think it is safe to assume that almost everyone in the community who is likely to be concerned about these issues is (and has been) watching the various lists and that few of us will be better able to make comments (or able to make better comments) in two weeks than we could, e.g., sometime next week. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Eric, Thank You for your comments and for your suggestions (below) I like your proposal for how to clarify and improve the wording of the draft legend text. Best Regards, Ed J. -Original Message- From: trustees-boun...@ietf.org [mailto:trustees-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: January 12, 2009 6:17 PM To: Russ Housley Cc: trust...@ietf.org; ietf@ietf.org Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem Ed, I'd like to thank the Trustees for working to resolve this situation. Unfortunately, after reviewing the new text, I don't think it's really adequate. To recap, the the old text required the contributor to affirm (and consequently to verify) that adequate permissions had been obtained to publish legacy (pre-5378) material under the 5378 rules. This was impractical both because of the difficulty of obtaining such permissions and the difficulty of tracing every portion of the document. This new text, reproduced below, solves the first problem, but not the second: This document contains material from IETF Documents or IETF Contributions published before November 10, 2008 and, to the Contributor?s knowledge, the person(s) controlling the copyright in such material have not granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC and to translate it into languages other than English. The first problem here is the phrase and, to the Contributor's knowledge, the person(s) controlling the copyright in such material have not granted the IETF Trust the right As I read this, I am directly affirming my belief that there are copyright holders who have not granted these rights. This is all fine if I know exactly who the original copyright holders are and that they have not given permission, but the more likely case is that I don't know one way or the other, and am simply unwilling to affirm the converse. However, I am equally unwilling to affirm my knowledge and belief that the persons controlling the copyright have not made grants. I simply don't know. This text should be rewritten as: This document contains material from IETF Documents or IETF Contributions published before November 10, 2008. Some material may be subject to copyright claims for which the holders have not granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. In addition, the final sentence Without obtaining... seems overly strong. It's phrased as if it were a condition imposed by the contributor, i.e., I the contributor doesn't license you to use this document unless you obtain adequate permission from the original copyright holders (with the contributor to be the judge of adequate, perhaps). But that's not what's in play here. Rather, it's that I the contributor can't give me license to material I don't control. So, this sentence serves as advice, not a license restriction and should be rewritten accordingly. Perhaps: Modification or creation of derivative works outside of the scope of RFC 4978 may require obtaining a license from the person(s) controlling the copyright on the relevant sections of the document. Best, -Ekr ___ Trustees mailing list trust...@ietf.org https://www.ietf.org/mailman/listinfo/trustees ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
John Klensin wrote: The intent, as ekr and I understand it and as I think your and Ed's note indicated, was to eliminate the requirement that authors make any assertions at all about work other than their own, much less requiring that they guarantee those assertions. Correct! That is indeed the purpose of the proposed work-around legend text. So I strongly support the general thrust of ekr's proposed modified text rather than the text as posted. Thank You. This is good feedback. Regards, Ed J. -Original Message- From: trustees-boun...@ietf.org [mailto:trustees-boun...@ietf.org] On Behalf Of John C Klensin Sent: January 12, 2009 7:01 PM To: Russ Housley Cc: trust...@ietf.org; ietf@ietf.org Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem --On Monday, January 12, 2009 17:24 -0500 Russ Housley hous...@vigilsec.com wrote: John: I think that the cover note from the Chair of the IETF Trust, Ed Juskevicius, included the vast bulk of the information that you are requesting. Russ, I think your note addresses several more of the issues I was concerned about than Ed's note did. Assuming that your note represents the consensus of the Trustees where that is relevant, I don't see any reason to quibble about that point. More to the point, while I think I disagree with parts of your analysis, the disagreements, if any, are in areas that should not block progress at this point, i.e., I can live with your interpretation without any need to dispute those differences. I do have a comment on (3) in context... (3) with the advice of Counsel, we believe that this fix represents a competent, best-efforts, legal-text representation of that principle and nothing else. The cover note does not address all of these points. The Trustees did seek legal advice, and Counsel fully support this work-around. As you might imagine, Counsel was heavily involved in the discussions as well as the words themselves. The Trustees are trying to provide a near-term work-around within the current BCPs and nothing else. Good. However, what I was looking for was assurance from Counsel that he had done an in-depth analysis of the language and concluded that it was both necessary and sufficient to address and solve (or work around) the problem. That is different from supporting the work-around, involved in the discussions, etc. Ekr's recent note points out part of the problem that I believe that Counsel should have caught (and would have caught if asked the right question). The intent, as ekr and I understand it and as I think your and Ed's note indicated, was to eliminate the requirement that authors make any assertions at all about work other than their own, much less requiring that they guarantee those assertions. Perhaps, for a document some of whose text predates 5378, I am certain about the origins of all of the text and can make assertions about it and about whether or not everyone has signed off. But, if I am not, I should not be required to make assertions, one way or the other, that require that I claim and take responsibility for, complete knowledge. Even if I am willing to take responsibility for identify all of the relevant Contributors, unless there is a compelling reason that I haven't heard yet, we should not be requiring authors to search the Trust's archives to determine who has signed off, who has not, and whether the statements they made in signing off are sufficient to meet the conditions of 5378 as modified by the workaround. So I strongly support the general thrust of ekr's proposed modified text rather than the text as posted. If a change is made that is consistent with the general principle that authors who know that they are working on documents that contain pre-5378 text, text about which others might make claims, do not need to make any affirmative assertions at all about the IPR status of that other work. john ___ Trustees mailing list trust...@ietf.org https://www.ietf.org/mailman/listinfo/trustees ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
Todd, Thank You for your comments. I've read them. Carefully. Three times. I'm not sure if we are on the same page. For example, you wrote: Which brings us back to the issue of that the Trust MAY not rewrite licenses for any IP that the IETF processed under RFC2026 unless ALL of the parties - the people who wrote those drafts, the IP owners of that work and anyone who has relied on a SW or systems product fabricated under those licenses. The IETF Trust is not looking for a way to rewrite licenses for IP processed under RFC2026. That is not the objective or the driver of the proposed revision to the Trust's Legal Provisions document. You also wrote: ... If work-product A contained specific IP then the used of that IP cannot exceed the original licenses including being given to the Trust which RFC2026 doesn't provide for in any form. That means that the IETF may not in fact convey those document's to the Trust at all. Could you please point me to text in RFC2026 that pertains to the above? When I read 2026, I see the following: 10. INTELLECTUAL PROPERTY RIGHTS 10.3. Rights and Permissions 10.3.1. All Contributions l. Some works (e.g. works of the U.S. Government) are not subject to copyright. However, to the extent that the submission is or may be subject to copyright, the contributor, the organization he represents (if any) and the owners of any proprietary rights in the contribution, grant an unlimited perpetual, non-exclusive, royalty-free, world-wide right and license to the ISOC and the IETF under any copyrights in the contribution. This license includes the right to copy, publish and distribute the contribution in any way, and to prepare derivative works that are based on or incorporate all or part of the contribution, the license to such derivative works to be of the same scope as the license of the original contribution. I believe the text (above) is quite broad and does permit an author (today) to prepare a derivative work from a pure 2026 licensed work, and then submit that derived work into the IETF process. RFC 5378 is the current BCP with respect to rights in IETF Contributions; it replaces all of the text in Section 10 from RFC 2026. 5378 requires new author(s) to make some clear statements about rights to and for the IETF Trust. The issue for some authors today is that they may not be able to assert that the original licenses (covering some earlier work that they may be using) would allow for use of the new work outside of the IETF process. Sam Hartman identified this concern during the IETF Plenary in November 2008, and that was a trigger for the work-around proposal which the Trustees sent out for review to everyone a few hours ago. BCP78 is not, in my personal opinion, garbage. Rather, I think it is incomplete with respect to providing guidance on how pre-5378 content in new contributions should be handled. That issue is the driver for the proposed (and temporary) work-around (per below), and it is also the reason I said that a permanent solution may require new work by the IETF community to update RFC 5378. Regards, Ed J. -Original Message- From: TSG [mailto:tglas...@earthlink.net] Sent: January 8, 2009 6:21 PM To: Ed Juskevicius Cc: 'IETF Discussion'; ietf-annou...@ietf.org; i...@ietf.org; i...@iab.org; rfc-edi...@rfc-editor.org; wgcha...@ietf.org; 'Trustees' Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem Ed Juskevicius wrote: Ed - you nor the rest of this list is going to like this retort but I would ask that you read all of it prior to flushing the response. The purpose of this message is twofold: 1) To summarize the issues that some members of our community have experienced since the publication of RFC 5378 in November 2008, and 2) To invite community review and discussion on a potential work-around being considered by the IETF Trustees. Some I-D authors are having difficulty implementing RFC 5378. An example of the difficulty is as follows: - an author wants to include pre-5378 content in a new submission or contribution to the IETF, but - s/he is not certain that all of the author(s) of the earlier material have agreed to license it to the IETF Trust according to RFC 5378. Then the submission of such an assertion would be a criminal act of fraud by wire... and that is not a joke. If an I-D author includes pre-5378 material in a new document, then s/he must represent or warrant that all of the authors who created the pre-5378 material have granted rights for that material to the IETF Trust. Something which by the way is physically impossible because of how the RFC2026 licensing model was setup. Hell even BCP78 and 79 exist under RFC2026 rules since they had to be published as such to get them into the channel to review
RE: Announcement: New Boilerplate Text Required for all new Submissions to IETF
Can't we just get rid of this nonsense in our drafts and have only a pointer? Unfortunately, no. Sorry! Best Regards, Ed J. -Original Message- From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2008 10:17 AM To: Tim Chown Cc: Juskevicius, Ed (CAR:1A12); IETF Discussion Subject: Re: Announcement: New Boilerplate Text Required for all new Submissions to IETF On 12 nov 2008, at 16:12, Tim Chown wrote: It would be great if the ietf list could be reminded when the new version of the rather excellent xml2rfc tool is issued, so we don't need to keep checking back for it. Can't we just get rid of this nonsense in our drafts and have only a pointer? 30% of my 6 page draft is boiler plate. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Announcement: New Boilerplate Text Required for all new Submissions to IETF
Greetings. This message is to draw your attention to the significance of the publication of RFC5377 and RFC5378 earlier today. * RFC5377 is Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents * RFC5378 is Rights Contributors Provide to the IETF Trust Note that RFC5378 is also BCP0078. RFC5378 is an update to RFC2026, and RFC5378 obsoletes both RFC3978 and RFC4748. Coincident with the above, the IETF Trustees have posted a new policy document with guidance to the community on: * Legal Provisions Relating to IETF Documents at http://trustee.ietf.org/license-info/ Taken as a set, the documents listed above specify changes that are now required in all new submissions into the IETF. Henrik Levkowetz has updated the idnit tool and AMS have updated the Internet-Draft submission tool to reflect the new requirements. An update to the xml2rfc has been requested. Please review the Legal Provisions Relating to IETF Documents and RFC5378 to discover the new boilerplate text that is now required. Please also take action to update the tools you use for creating your documents. New submissions using either the old or the new boilerplate text will be accepted starting today, until 01h00 UTC on December 16th, 2008. After this cutoff date, all new submissions will be required to use ONLY the new boilerplate text. All submissions using old boilerplate text after the cutoff date will be rejected. Regards and FYI. Ed Juskevicius IETF Trust Chair [EMAIL PROTECTED] p.s. - Don't be surprised if you see periodic reminders about this as we approach December 16th. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call for comments on IETF Trust Legal Provisions (dated 09-19-08)
This message is an update for the community on the IETF Trustee's progress towards adopting a policy on Legal Provisions for IETF Documents, pursuant to the last two remaining I-Ds from the IPR WG. The Trustees met via telechat last Thursday. We reviewed the draft policy (as posted to the Trustees website on 09-08-08), plus all of the good comments and suggestions which you posted to the IPR-WG list, and/or sent directly to the Trustees. Thank You!. I am pleased to report that we are almost (finally) finished. By the end of last week's meeting, the Trustees reached consensus on all of the text in the draft policy except for one paragraph that describes what is (or is not) intended with respect to the license for code components which may be in a Contribution. Jorge Contreras was actioned to develop new text to clarify this. The old text was in Section 4.c and read as follows: c. License. When Code Components are copied, published, displayed or distributed as part of a document that is intended to be read or referenced by persons, and not for direct processing by a computer, they are licensed under the terms set forth in Section 3 of these Legal Provisions. When Code Components are copied, published, displayed or distributed for direct processing by a computer, they are hereby licensed to each person who wishes to receive such a license on the terms of the BSD License There has been a lot of discussion on the list about the intended meaning of the above words. As a result, the last item on the Trustee's work plan for the policy is to reach closure on unambiguous text for Section 4.c. The intent is to clearly identify that code components, if extracted from an IETF Contribution or an IETF Document under the terms of the BSD license as set forth in Section 4.c, may be freely modified and that the code and those modifications are unrestricted with respect to how they can be used and distributed. This is important because we understand that code components taken from IETF documents are to be treated differently from what can be done with any other text extracted from IETF Contributions and IETF Documents. The following paragraph contains the new text which we are now proposing to replace the old wording (from above). c. License. In addition to the licenses granted under Section 3, Code Components are also licensed to each person who wishes to receive such a license on the terms of the BSD License ( http://opensource.org/licenses/bsd-license.php ), as described below. If a licensee elects to apply the BSD License to a Code Component, then the additional licenses and restrictions set forth in Section 3 and elsewhere in these Legal Provisions shall not apply thereto. ** Do these new words for Section 4.c convey our meaning clearly, and (equally importantly) do they reflect the consensus of the community? Please let us know. The Trustees want to reach closure on this within the next two weeks. We want to adopt a policy we can all use starting October 2008. Please view this message as the last call for comments. A complete version of the proposed policy, including the new text for Section 4.c has been posted to the Trustee's website at: http://trustee.ietf.org/policyandprocedures.html . The vintage of the documents being last-called is 09-19-08. Best Regards, and Thanks in advance, Ed Juskevicius, on behalf of the Trustees [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call for Comments on Legal Provisions Related to IETF Documents
This is to announce that the IETF Trustees have just posted a revised version of a draft policy on Legal Provisions Related to IETF Documents dated 08-05-08 at: http://trustee.ietf.org/policyandprocedures.html This draft includes all of the changes agreed during the July 31st meeting of the IPR working group held in Dublin. On behalf of the IETF Trustees, we invite your review and final comments and suggestions on this policy. The IETF Trustees will meet via telechat on Aug 21st with the goal of finalizing this policy. If you have any final comments, please post them on the IPR WG mailing list. Best Regards, and Thanks in advance, Ed Juskevicius Ray Pelletier Chair Trustee IETF Trust IETF Administrative Director ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: ISSN for RFC Series under Consideration
Hi - What would it take to get them cataloged individually? Randy I believe that getting each RFC cataloged individually would not be possible using an ISSN, so we would need to employ ISBNs. My understanding of ISBNs is as follows: In the US, the ISBN Agency is Bowker http://www.bowker.com/index.php/index.php/component/content/article/1/2. Their faq http://www.bowker.com/index.php/supportfaq-isbn/49-support-isbn/350-faqs -isbn-general defines the products eligible for an ISBN and standards do fit in the definition. This faq also discusses the purpose and why/when an ISBN should be used. To apply ISBNs to RFC, the process would need to be something like: - obtain a block of ISBN numbers (e.g. 1,000 of them) - note that a block of 1,000 is $1570 per https://commerce.bowker.com/standards/cgi-bin/isbn.asp - then assign an ISBN number to each RFC before it publication, and register each not-yet-published RFC against the ISBN per http://www.bowker.com/index.php/supportfaq-isbn/49-support-isbn/381-faqs -isbn-howtouse Setting this up take work and a modest on-going budget. Once in place, the ongoing effort would be less. That being said, ISBN numbers are not free, so I think we'd need to identify some tangible benefits to really doing this, before deciding to proceed. Regards, Ed Juskevicius ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: ISSN for RFC Series under Consideration
Steve: Every so often someone suggests RFCs are not first class documents and hence not comparable to, say, real standards documents. Getting traditional identifiers attached to them might squelch some of this nonsense. I have the impression that we would be pioneering the use of an ISSN to identify a standards' series, if we choose to do this. The real standards from other organizations seem to be identified with individual ISBNs. Would the purveyors of nonsense be squelched by an ISSN, or emboldened? Some might cite our decision as yet another example of the IETF doing something different and 'non-standard'. Marshall, to your point: It is easy to find RFC's now, but it may not be in a century. This may seem silly, but I think that RFCs will still have relevance in a century and, having experience searching for 100+ year old astronomical publications and data, in my opinion, RFC's need to be cataloged in libraries. Libraries have running code for the maintenance of intellectual property over centuries; the IETF does not. I agree with you 100%. I think this is indeed a tangible and desirable objective. Best Regards, Ed J. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Proposed Revisions to IETF Trust Administrative Procedures
John, you wrote: Then recommend to the community that the Trust Agreement be changed. The Trustees are not talking about changing the terms of the Trust Agreement, so this should not be necessary. I am worried about the IAOC and/or Trustees adopting procedures that are inconsistent with the Trust Agreement. Me too! It is not the intention of the Trustees to adopt procedures that are inconsistent with the Trust Agreement. if anything is going to be said, it needs to be consistent with the Trust Agreement _and_ reflect the desires and intent of the community. I agree. Regards, Ed Juskevicius -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John C Klensin Sent: Wednesday, April 09, 2008 1:39 PM To: Marshall Eubanks Cc: Leslie Daigle; Harald Alvestrand; IETF Discussion Subject: Re: Proposed Revisions to IETF Trust Administrative Procedures --On Wednesday, 09 April, 2008 10:24 -0400 Marshall Eubanks [EMAIL PROTECTED] wrote: How, precisely, would the IAOC cease to exist ? Marshall, this is nearly irrelevant. The point is that there is language covering that case in the Trust Agreement and there is language in the procedures developed by the Trustees, and they are not consistent. If they all resign or die, the IETF (IESG, IAB, ISOC) would appoint more. If BCP 101 was changed, the new document would undoubtedly cover the treatment of the Trust by the IAOC replacement, or allow for direct appointments, or whatever. At any rate, that should be worried about then, not now. Then recommend to the community that the Trust Agreement be changed. If the ability to make this sort of change somehow got negotiated away... well, I guess we live with that, but it is still no reason to have a procedural document inconsistent with the Trust agreement. This wording is, in my opinion, purely to account for the case of the IETF ceasing to exist, in which case I think Brian's wording is appropriate. My imagination is paranoid enough to think of at least one more case, but I would suggest that the principle remains and that, were the IETF to abruptly go out of business, the former members of the former IAOC might not be the best people to act as receivers of the Trust and controllers of its remaining assets. Note that, with the way the new IPR documents are drawn, the Trust has some long-term responsibilities to the Internet community whether the IETF exists or not. (And, of course, if there is no IETF, there would presumably also be no IESG, so they could not appoint more.) The Trust Agreement, IIR, says IESG or its successor. Whether the various arrangements now in place are adequate to designate a successor to the IESG if they and IETF go out of business, I don't know. But I do know that isn't the problem of the Trust or IAOC (although either could make a proposal about what to do about it). One of the parties of the Trust agreement was worried about this. I am not. I'm not particularly worried about the conditions that would trigger any of these provisions occurring. I am worried about the IAOC and/or Trustees adopting procedures that are inconsistent with the Trust Agreement. Given what the Trust Agreement says, I don't believe the procedures actually need to say a word on this topic. Not saying a word would be, I believe, consistent with your worried about then, not now suggestion. But, if anything is going to be said, it needs to be consistent with the Trust Agreement _and_ reflect the desires and intent of the community. john ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Proposed Revisions to IETF Trust Administrative Procedures
Leslie wrote: Giving the Trust a chair is at least a step towards acknowledging it as a separate organization ... I suppose you could interpret things this way, but that is not my view. Since its creation back in December 2005, all meetings of IETF Trustees have been convened and chaired by the IAOC Chair. As such, I think we have always had execute an administrative role of chairing IETF Trust meetings, and we've generally referred to that person as the Trust Chair in minutes and on the IETF Trust website. The recent posting of some new words for the Trust Administrative Procedures was an attempt to bring that document up to date, to reflect a desire amongst the current IAOC to load share the running of IAOC meetings and IETF Trust meetings by having two different people convene those meetings, and drive progress. That's it. Our intent is absolutely not to encourage mission creep. The above being said, it is quite clear from the excellent comments posted by several people on this topic that the Trustees have more work to do before the job of revising the text on the Administrative Procedures document is done. For example, John Klensin commented on some of the text in paragraph 12 that says If at any time the IAOC ceases to exist, the Trustees then in office shall remain in office That text is not new nor a proposed change to any existing Trust procedure. Those words are original text from December 2005. I am happy John took note of them in this round of discussions, as I don't think they exactly express what the Trustees intended for this clause to say. Best Regards, Ed Juskevicius -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leslie Daigle Sent: Tuesday, April 08, 2008 4:15 PM To: Russ Housley; IETF Discussion Cc: Harald Alvestrand Subject: Re: Proposed Revisions to IETF Trust Administrative Procedures Russ, The IETF Trust was set up as an instrument -- a naturally limited scope. The specific task you identify below (paying attention to items) could reasonably be addressed as Harald suggested. Giving the Trust a chair is at least a step towards acknowledging it as a separate organization (beyond instrument), and one could then examine whether the IAOC members are, in fact, the right people to populate it (for example). It certainly opens the doors to mission creep. My point, which I think is in line with something John Klensin said earlier, is that even though the current IAOC _intends_ this as a simple administrative change, the fact is it's a structural change that is open to be taken many places by future IAOCs and IETF communities, also of good intent. Given that, it would be nice to understand 1/ that the IAOC has considered this, and 2/ why other solutions are not considered viable. Leslie. P.S.: Also -- good luck with ever having a small meeting -- with 4 Chairs in the room, you'll be looking for end-tables pretty soon ;-) --On April 7, 2008 3:45:16 PM -0400 Russ Housley [EMAIL PROTECTED] wrote: The IAOC and the IETF Trust have different focus. The idea behind the separate chair is to make sure that someone is paying attention to the items that need to be handled by each body in a timely manner. It is simply a mechanism to help ensure that noting is falling between the cracks. Russ --On April 4, 2008 11:50:23 AM +0200 Harald Alvestrand [EMAIL PROTECTED] wrote: After considering the comments so far, I think I disagree with having a separate Trust chair. The idea behind making the IAOC be the Trustees was, among other things, to make sure that we didn't create yet another nexus of control in the labyrinth of committees; I understood the legal existence of the Trustees as something different (in name) from the IAOC to be strictly something we did for legal purposes If the IAOC chair is overburdened by having to manage the IAOC in two different contexts, get him (or her) a secretary. I agree with John's comment that leaving the current trustees in charge on dissolution of the IAOC is inappropriate; for one thing, that also removes all the recall mechanisms. Figure out something else to do in this case. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary
What if someone took the initiative to organize a new newbie training session on Sunday in Philadelphia, entitled something like getting your laptop ready for the planned IPv4 outage experiment on Wednesday night ? Would that reduce the potentially negative perspectives that newbies would take home after the meeting? Just a thought ... Regards, Ed Juskevicius [EMAIL PROTECTED] From: Dan York [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 12:54 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org Subject: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary I have resisted adding anything to this debate about the IPv4 outage because people have already stated many of the good points. I particularly agreed with the points made that from a PR point-of-view this was not a great idea. Let me, though, add another perspective. What about all the newbies? What are they going to do during this time? At IETF 70, there was a question raised in one of the plenaries asking How many of you are here for the first time? and a significant number of hands went up. So let's look at this proposed IPv4 outage *during the plenary* from their perspective. Now, these newcomers may or may not have been subscribed to IETF mailing lists. They may or may not have attended the Sunday intro to IETF for newcomers session. They may or may not in fact be technical folks. They are probably still trying to figure out how all this works and why these people are humming, etc. So now we go into one of the plenary sessions and it is announced that we will now shut down IPv4 and use only IPv6. The newcomer notices that: 1. A good percentage of the audience now dive into their laptops and become engrossed in diagnosing how their system works with IPv6. Side conversations are starting everywhere and occasional shouts of Aha! emerge from random groups. 2. Another percentage gets up and leaves in search of cookies. 3. Some percentage who missed reading the emails are suddenly upset because they lost their IPv4 connectivity. 4. Some percentage pops in their EVDO/EDGE/whatever cards and continues along as they were before doing their work and completely ignoring the plenary speakers. 5. Some percentage never showed up at the plenary because they went to join Richard Shockey at a local steak house. 6. Non-technical users or others who did not subscribe to IETF mailing lists are sitting there dumbfounded with a deer-caught-in-the-headlights look wondering what the heck is going on and if this has anything to do with the hums. 7. NO ONE is paying attention to the speaker(s) in front of the room during this part of the plenary. Now maybe the newcomer is all excited about IPv6 and so plunges into the technical troubleshooting. Maybe they go look for cookies or steak. Maybe they sit there dumb-founded. Probably they are left wondering what the point of this IETF plenary session really was. I don't dispute that such an exercise could be an interesting experiment in IPv6 connectivity (and one in which I would join), although in many cases I think we can already know the outcome. I just question the wisdom of doing it during the *plenary*. It would seem to me to be a great exercise to do at some other point during the week when the people who care can attend and identify issues, work through them, etc. Or we do as Ted suggested and just run an entire event with only IPv6 wireless. (and count how many people are using EVDO/EDGE cards!) It goes back to a more fundamental question - what is the purpose of the plenary? What information do we want to get across to attendees to the session? (And if we *do* plan an IPv4 outage, what is going to be talked about during the time of the outage?) My 2 cents, (now worth less than when I lived in Canada) Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
An Absolutely Fantastic IETF Meeting Network - Redux
To echo Harald's words from Dallas: - Just wanted to state what's obvious to all of us by now:- This time the wireless WORKED, and Just Went On Working.- THANK YOU! In addition, I want to extend my personal compliments to our Ericsson,Combat Networks and the entire NOC teamfor a very good job. Best Regards, Ed Juskevicius ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Meeting Survey - Last Call
Earlier today, Ray suggested that only a small fraction of everyone who went to Dallas has taken the 10 minutes needed to provide feedback on the meeting. I am posting this message to ask Why so little response? Is it because only two hundred people read the IETF discussion list? If so, then maybe we have all the response we can expect, and should be happy with it. If, on the other hand, we know a thousand people monitor the list, then I return to Why so little response? Are we surveyed-out, or did the survey ask too many questions, or what? For the record, and for transparency, I did the survey last week. Doing it was relatively painless, and I don't think it took more than 10 minutes. Regards, Ed Juskevicius -Original Message- From: Ray Pelletier [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 26, 2006 6:48 AM To: ietf@ietf.org Subject: IETF Meeting Survey - Last Call All; More than 1,250 of you attended IETF 65 in Dallas and many others attended sessions remotely. Yet only 155 of you have responded to a survey intended to make future meeting experiences more successful. There are only 74 days left before IETF 66 in Montreal, only 74 days during which there may be the opportunity to effect improvements. Again, your participation is anonymous and your candor is most welcome. You can help by taking this short survey at: http://www.surveymonkey.com/s.asp?u=649182049947 At the end of the survey you will be able to see the survey results to date. I do appreciate the help. Thanks Ray Pelletier IETF Administrative Director [EMAIL PROTECTED] ___ 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: LAST NomCom Announcement: IAB Call for Nominations
The IAB Job Description (on the referenced webpage) is informative, but very generalized. Given that NomCom just finished recommending the new slate of IAB members for 2006, I am hoping you could provide some additional (e.g. more specific) guidance on unique skills or technical expertise/perspective that you need to backfill for Pekka. Can you? Thanks in advance, Ed J. -Original Message- From: Ralph Droms [mailto:[EMAIL PROTECTED] Sent: Monday, March 20, 2006 7:12 PM To: ietf@ietf.org; ietf-announce@ietf.org Subject: LAST NomCom Announcement: IAB Call for Nominations The NomCom has been asked to fill the seat on the IAB now vacant as a result of the resignation of Pekka Nikander from his seat on the IAB. Therefore, the NomCom is accepting nominations for a seat on the IAB, to fill the remaining one year of the term of the vacant IAB seat. Nominations will close at 1700EST on Tuesday, March 21. More information about serving on the IAB is available at http://www.iab.org/documents/docs/2004-10-21-iab-quals.html Please send nominations, including the nominee's name, e-mail address and telephone number (if available) to [EMAIL PROTECTED] If you were nominated for a seat on the IAB during the previous nomination process, please contact me at [EMAIL PROTECTED] to renominate yourself for this new search. - Ralph Droms Chair, 2005-2006 IETF Nominating Committee ___ 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: IAB Response to Appeal from Jefsey Morfin
Bernard Aboba wrote: it is also possible that the situation could be addressed without any documents at all, just by a clear set of guidelines and a statement of policy That would work for me! Regards, Ed Juskevicius -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard Aboba Sent: Tuesday, January 31, 2006 8:51 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org Subject: RE: IAB Response to Appeal from Jefsey Morfin Speaking for myself -- As noted in the appeal, quite a few documents relate to the revocation of posting rights. They cover different types of lists, authorized enforcers, potential behaviors, remedies, and procedures. At this point, the major issue seems to be non-WG lists. I don't think that the full set of documents needs to be replaced to clarify most of the questions. That would be quite an undertaking and the IETF needs a clear, consistent set of guidelines in the meantime. So it is possible that a glue document would do the job; it is also possible that the situation could be addressed without any documents at all, just by a clear set of guidelines and a statement of policy The major issue is whether the policy is clearly stated, widely understood and agreed to by the community and fairly administered. From: Gray, Eric [EMAIL PROTECTED] To: 'Bernard Aboba' [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] CC: [EMAIL PROTECTED], iesg@ietf.org, ietf@ietf.org Subject: RE: IAB Response to Appeal from Jefsey Morfin Date: Tue, 31 Jan 2006 16:40:29 -0500 Bernard, The way I interpret your statement is that you feel that replacement of the existing set of documents - possibly with a single new document - is preferred to writing one or more new documents with the intent to just glue the current set back together. Is that a correct interpretation? -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On -- Behalf Of Bernard Aboba -- Sent: Tuesday, January 31, 2006 2:59 PM -- To: [EMAIL PROTECTED]; [EMAIL PROTECTED] -- Cc: [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org -- Subject: Re: IAB Response to Appeal from Jefsey Morfin -- -- My personal perspective is that on a subject as sensitive as -- banning, it is very important to have clear, well documented -- procedures dictating the -- process and who is allowed to initiate the ban. Creation -- of more documents -- may not be the solution to this problem, particularly since the -- applicability and overlap of the existing documents is -- already somewhat -- unclear. -- -- -- From: Leslie Daigle [EMAIL PROTECTED] -- To: Sam Hartman [EMAIL PROTECTED] -- CC: IAB [EMAIL PROTECTED], Iesg (E-mail) iesg@ietf.org, -- ietf@ietf.org -- Subject: Re: IAB Response to Appeal from Jefsey Morfin -- Date: Tue, 31 Jan 2006 14:42:24 -0500 -- -- Sam, -- -- One IAB member's perspective: no, the expectation is not BCP upon -- BCP upon BCP. -- -- The devil is, of course, in the details. Even community commented -- on published operational procedures should not be at odds with our -- general or specific process documents, or else that seems to -- suggest the process documents need updating. And we have a -- community-defined process for that (which seems to result in a -- BCP). -- -- Again -- that's just one person's perspective. -- -- Leslie. -- -- Sam Hartman wrote: -- -- So, a clarification request: -- -- Am I correctly understanding that the clear and public -- requirement does not always imply a process RFC? In particular, -- John -- Klensin has -- made an argument that there are a wide variety of matters that -- are better handled by operational procedures made available -- for community -- comment than by BCP document. -- -- It's my reading that the IAB is interested in making sure that -- the processes and rules are clear and public, not that they are -- all codified in BCP. -- -- -- I'm not looking for a formal response from the IAB but would -- appreciate comments from its members. -- -- --Sam -- -- -- -- -- -- -- ___ -- 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: IETF65 hotel location
Dave Crocker write: the questionnaire will not serve to understand the needs of people who are *unable to attend* Perhaps we should ask a more open-ended question (i.e. B below): A) Did you attend IETF-65? B) If not, why not? Regards, Ed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Sunday, January 29, 2006 9:26 PM To: Marshall Eubanks Cc: ietf@ietf.org Subject: Re: IETF65 hotel location However, to be constructive, I would like to suggest adding two yes or no questions to the next meeting questionnaire : A.) Do you feel that the venue chosen for the meeting was too remote, in terms of accessibility of restaurants, bars, your or other hotels, etc. ? B.) (If A is answered yes.) Would having another IETF meeting in a site that is similarly remote make it less likely that you would attend ? Asking questions like this could be quite useful. The challenge is in making sure that the right people get asked. If the questions are asked of people who already attended the meeting, then the sampling is of people with the resources to accommodate the current style of meeting arrangement. While some might grouse about one characteristic or another of the current choices, the questionnaire will not serve to understand the needs of people who are *unable to attend* IETF meetings because of current costs, due to remoteness, hotel fees, or the like. (By the way, the what will make it less likely you will attend type of question is often interesting to ask, but is usually not a good predictor of actual behavior.) d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ 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: Meeting Survey Results
I also learn from a previous email the reasons why b/g are not so good in our meeting, and may be thru our liaison with IEEE we need to make some noise over there, so the market use a better technology. From the perspective of RF attenuation (and signals not going through air walls in hotels), 802.11a is actually a better technology. The spectrum used is at a higher frequency, and the standard includes more channels which can be used to deploy a WLAN in tight quarters (like an IETF meeting). If making noise would help, I think petitioning Apple to include 802.11a in their machines would be more effective in the market than asking IEEE802 to develop yet another WLAN standard (imho). However, I agree with your observation that using 802.11a may not be a choice for a lot of people in Dallas, at IETF 65. Regards, Ed J. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JORDI PALET MARTINEZ Sent: Wednesday, January 25, 2006 7:40 AM To: ietf@ietf.org Subject: Re: Meeting Survey Results Hi David, Don't want to start a new useless thread here, my point was basically to show that b/g has a wider adoption and 75% of the laptops don't have built-in a, so it makes sense to make additional effort to get it working. I also learn from a previous email the reasons why b/g are not so good in our meeting, and may be thru our liaison with IEEE we need to make some noise over there, so the market use a better technology. I also got some folks confirming that a cards where available also in previous meetings, but probably that was not properly advertised, may be ? Regards, Jordi De: David Kessens [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 24 Jan 2006 20:38:51 -0800 Para: JORDI PALET MARTINEZ [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: Meeting Survey Results Jordi, On Tue, Jan 24, 2006 at 02:44:15PM -0400, JORDI PALET MARTINEZ wrote: I'm not sure if I got it. My MUST was on the other way around: We really need to warrantee good coverage for b/g to 75% of the participants. We hope to offer good connectivity to the other 25% of the participants as well. You can help us by bringing a configured 802.11a card. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com 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://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: jabber rooms
Gents ... Could you send me a quick note on what sessions (day, time, room) you had the most recent problems in? I was scribe (on jabber) during the Techspec BOF this morning, and nobody had problems there. I will pass along any specifics you can give me to the NOC team. Thanks in advance, Ed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Hinden Sent: Wednesday, November 09, 2005 12:30 PM To: John C Klensin Cc: IETF discussion list Subject: Re: jabber rooms John, reminders may not have been noticed -- I've only occasionally found the network stable enough in the meeting sessions to make use of jabber rooms effective and useful in following what is going on. I agree. In the IPv6 w.g. session our jabber scribe couldn't do anything useful. Bob ___ 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
What you should wear to tonight's IETF64 Social
Title: What you should wear to tonight's IETF64 Social -- Posted on behalf of Denise Dziubaniuk -- All, The IETF Social event is now sold out. Thanks to everyone for your interest. For those of you with tickets, you can enjoy most of the Aquarium sights from inside. However, some of the sights are best viewed from the outside. You should dress for the weather and wear your coat. We have made arrangements for tents to be set up in the main areas to keep people dry. There is a short (less than one minute) walk from the bus to the entrance that will not be covered. However, if you don't want the weather to limit your Aquarium experience, you may wish to bring an umbrella! Shuttle buses will depart the Westin Bayshore Hotel, starting at 7pm. Buses will run continuously throughout the evening between the Bayshore and the Aquarium. The last bus will depart the Aquarium at 11:15pm. Return buses will stop at the Marriott Pinnacle, approximately every half hour, starting at 9pm. Please look for the buses with Marriott sign. Be sure to wear your name badge with your Beluga sticker attached. The Beluga sticker is required to get on the bus and enter the Aquarium. Don't forget your drink tickets!! Enjoy your evening! See you there, Denise [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Taxi, nearby restaurants in Vancouver
There are some other restaurants at Robson street ... FYI, there are many (many) more excellent restaurants just a bit further away, in Gastown and in Chinatown. http://www.gastown.org/ http://vancouverchinatown.ca/ Regards, and Welcome to Vancouver ! Ed J. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Update to IETF 64 Social Event plan for November 8th
I have been receiving questions about the IETF 64 Social, planned for Tuesday evening November 8th. This message contains a mini-FAQ on the recurring themes. Regards, and FYI ... Ed Juskevicius [EMAIL PROTECTED] - - - - - START - - - - - 1) NOW THAT IETF PRE-REGISTRATION IS CLOSED, DO I HAVE TO WAIT UNTIL IETF 64 TO BUY A TICKET FOR THE SOCIAL? No. Social tickets may still be purchased on-line (until 11h00 PST on Sunday November 6th) at https://www.meetinghq.com/group/101004751?wslid=nortel_ietf2005social Tickets will also be available for purchase in Vancouver, until they are all sold. 2) THE SOCIAL BEGINS AT 19h30. THE IETF 64 AGENDA HAS MEETINGS UNTIL 19h50 ON NOVEMBER 8th. WHY IS THERE AN OVERLAP? The Social team assumed the agenda for IETF 64 would be like all previous North American meetings. We thought all sessions would be finished by 18h00 on Tuesday, so it would be OK to organize a Social on Tuesday evening. When the first draft IETF agenda was published (two weeks ago), we discovered a potential overlap with the last two afternoon sessions on Tuesday. This resulted in a redesign of the Social which reduced the overlap with the IETF schedule. Given the late date, there was no way to completely eliminate all overlap without canceling the event completely. 3) WHAT HAS BEEN DONE TO MITIGATE THE OVERLAP? The start and end of the Social will be 1/2 hour later than originally planned, and the bus schedule will be adjusted accordingly. As a result, there is no overlap with 1740-1840 Afternoon Session III, and the overlap with the last session of the day has been reduced. 4) WHAT IF MY LAST IETF SESSION ON TUESDAY IS 1740-1840 Afternoon Session III? You may take an early bus to the Social. The first bus will leave from the Westin Bayshore hotel at 19h00. 5) CAN I STILL ATTEND THE SOCIAL IF I ATTEND 1850-1950 Afternoon Session IV? Yes. Buses will continue to run from the Westin Bayshore to the Social until at least 20h30. 6) WILL FOOD STILL BE AVAILABLE IF I ARRIVE LATER (e.g. by 21h00)? Yes. Dinner will be served, buffet-style, from five different food stations until at least 21h30. 7) WHAT ABOUT THE MARINE BOFs? The schedule of BoFs at the Marine Science Centre has been reworked to correspond with people arriving at the Social throughout the evening. Most of the BoFs will run twice to accommodate both early and later arrivals. Please see the Social webpage for the revised BoF times and descriptions. - - - - - END - - - - - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Meeting Venue Selection Criteria
It is interesting that essentially all public discussion of these sorts of stategic issues and the criteria for pursuing them almost always focuses on what is easy or already established, rather than what will work best for achieving the desired result. In particular, negative implications appear to be entirely ignored, such as the one Eric Rosen just pointed out, about encouraging participation by professional standards goers. So, where would you like to convene IETF 66 and 67? AFAI, the venues for these meetings have not been selected as of yet. Regards, Ed J. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Thursday, October 20, 2005 11:44 AM To: Brian E Carpenter Cc: ietf@ietf.org Subject: Re: IETF Meeting Venue Selection Criteria Brian, What is the evidence that we will not gain that new participation without hurting current participation by primary contributors? It's very hard to get those data... There is no objective way to identify 'primary contributors' other than by assuming the regular attendees are also contributors. ... Which, BTW, means income that we badly need. ... We also badly need hosts for financial reasons. Unfortunately, the ultimate and practical meaning, of these kinds of conclusions about venue selection, is that we do not place productivity as a high priority. We have a collection of other priorities that take precedence, for a collection of reasons. This means that the impact of face-to-face meetings, on productivity and quality, is almost entirely a matter of luck. I should note that this is a similar problem with respect to Nomcom member selection: We use highly indirect criteria, because they are easy to administer, but which are certain to have poor correlation with member expertise about IETF management -- although IETF management is what is being chosen -- and then we hope for the best. It is interesting that essentially all public discussion of these sorts of stategic issues and the criteria for pursuing them almost always focuses on what is easy or already established, rather than what will work best for achieving the desired result. In particular, negative implications appear to be entirely ignored, such as the one Eric Rosen just pointed out, about encouraging participation by professional standards goers. For an organization that claims to care about the quality of its work product, this all seems a rather strange approach to its management. I suspect that organizations rarely achieve their primary goals by making strategic and tactical decisions that ignore those goals. d/ p.s. Primary contributors could be operationally defined as previous IETF attendees who are authors or chairs of current work. One might always want to factor in mailing list activity levels for some individuals, but that's also an indirect measure. However, all involve objective data that are available. An additional approach is a variation on something that is already done: Currently, some participants are queried for schedule conflicts within the IETF week. That could be extended to venue conflicts which would prevent them from attending at all.And the primary point behind my making these suggests is to point out that it is easy to give up on pursuing criteria that are not trivial to enforce, but that that is not always warranted... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Meeting Venue Selection Criteria
Just to respond to the suggestion that Montreal and Toronto could be good destinations ... In theory - Yes. Both venues have a lot to offer. This being said, I know my company looked at both cities last November before deciding to propose Vancouver for IETF 64. Toronto and Montreal were already fully booked for November 2005 when we started looking in November 2004. Twelve month's of lead-time was not enough to get into either of these venues! I don't know about July 2006 or November 2006, but I would be surprised to learn they have room for us. If we seriously want to have IETF meetings in Montreal or Toronto, we might have to wait until 2007 - if we start planning now :-( Regards, Ed -Original Message- From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED] Sent: Thursday, October 20, 2005 4:27 PM To: [EMAIL PROTECTED]; Juskevicius, Ed [CAR:1A12:EXCH] Cc: ietf@ietf.org Subject: Re: IETF Meeting Venue Selection Criteria On Thursday, October 20, 2005 09:22:40 AM -0700 Dave Crocker [EMAIL PROTECTED] wrote: The criteria reduced to: Major city with excellent international flight connectivity and appropriate meeting facilities in an area with good support facilities, so the venue is not some sort of limited-access ghetto. One default on the North American west coast, one on the East. One in Europe and one in Asia. I believe that the current realities of travel to the U.S. by non-citizens makes the U.S. a problematic venue for IETF participation. I also believe that non-North American travel for primary IETF contributors is frequently problematic. So for the majority of IETF meetings, Canada looks extremely attractive. That means Vancouver for the West (though perhaps Calgary works) and Toronto or Montreal for the East. Or we could just default all North American meetings to Minneapolis. :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Meeting Venue Selection Criteria
The ideal venue (if there is such a thing) would enable both: - good participation from WG primary contributors AND - lots of local participation The second factor is important, imho, because a fraction of local newbies are going to be impressed by their IETF experience, and will want to participate again in the future. The may well become primary contributors themselves down the road. Regards, Ed Juskevicius [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Wednesday, October 19, 2005 2:09 PM To: Brian E Carpenter Cc: ietf@ietf.org Subject: Re: IETF Meeting Venue Selection Criteria Brian, Unfortunately, that won't help us broaden IETF participation to bring in people from countries that currently don't have many participants. On the contrary, it will tend to freeze our participation profile where it is today. On a long term basis, that would not be good for the IETF, IMHO. Worrying about expanding the diversity of participation in IETF meetings made quite a lot of sense when the IETF was initially expanding, along with global adoption of the Internet's technology. It is far less clear why that is a significant factor in current venue choices. Productivity of working groups would seem to be far, far more important. An implication of this is that a venue which gets lots of local participation, but which winds up getting LESS participation among the primary contributors to working groups, would be a poor choice. Statistics about attendance seem to focus on total numbers, rather than participation by primary contributors. d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Meeting Venue Selection Criteria
Is that hope for future participation by new attendees an acceptable basis for making venue choices that hurt current participation by primary contributors? What is the evidence that we will not gain that new participation without hurting current participation by primary contributors? Maybe I am an optimist. I believe the world is a big place, and are lots of venues where the IETF has not yet met, which would work for all of us, and attract a lot of local participation. My sense of why we are discussing venue selection criteria is that we wish to encourage people to volunteer to be local hosts for future IETF meetings. To make the best use of the prospective local hosts' time, it would help if we could articulate the venues that would be acceptable, versus ones that would not 'meet' (pardon the pun) our venue selection criteria. Regards, Ed -Original Message- From: Dave Crocker [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 19, 2005 3:05 PM To: Juskevicius, Ed [CAR:1A12:EXCH] Cc: ietf@ietf.org Subject: Re: IETF Meeting Venue Selection Criteria Ed Juskevicius wrote: The ideal venue (if there is such a thing) would enable both: - good participation from WG primary contributors AND - lots of local participation The second factor is important, imho, because a fraction of local newbies are going to be impressed by their IETF experience, and will want to participate again in the future. The may well become primary contributors themselves down the road. Is that hope for future participation by new attendees an acceptable basis for making venue choices that hurt current participation by primary contributors? What is the evidence that we will not gain that new participation without hurting current participation by primary contributors? d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Vancouver IETF Social
Title: Message FYI, information about the social in Vancouver has just been posted on the IETF-64 meeting page. http://www1.ietf.org/meetings/IETF-64.html Regards, Ed Juskevicius ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
