Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Joe Touch wrote: There's nothing in the quote above that says that the expired document will not be available *in the archive*. There's nothing that says it won't be available by Santa Claus delivery either. However, the document states how things will be made available, and how that will change upon expiration. While the 6-month timer (or any earlier I-D update!!) will, in fact, change how the *IETF* distributes and promotes a particular I-D (version), there is actually *NO* limitation in what folks downloading I-Ds with the URLs from the i-d-announce I-D Action: EMails do with any of the I-Ds that they download. When I startet mirroring I-Ds in 1995, I did so by processing the I-D announce Emails, rather than mirroring the IETF ftp server, because (a) I did want to retain old I-Ds of WG document that I was actively participating in, and I had no desire to obtain the tombstone files. Nobody is debating whether the IETF can/should have an archive. The question is whether that archive should be public - which effectively negates the concept of taking the doc out of the I-D repository. And I see you selectively omitted the rest of that paragraph: Such a request may be overridden; e.g., a chair of the working group associated with the I-D will be notified if an author requests unexpiration and may request that the action not occur. This request should be sent to internet-dra...@ietf.org (using the suggested subject line Resurrect I-D filename) and should come from an author, a working group chair, or an IESG member. This describes how _one_ very specific IETF document repository (of active I-Ds) is managed. I recognize the IETF might change this policy, but I want to be clear that I don't consider this is ambiguous to date. I *never* understood this to be any kind of polic, but rather a description of the current procedure, deliberatly chosen by the secretariat and server admin how to process and make available I-Ds for download. Since 1995, the location(favorite)protocol moved around a few times: ftp://ds.internic.net/ ftp://ftp.ietf.org/ http://www.ietf.org/internet-drafts/ http://www.ietf.org/id/ I never understood the submission of a successor I-D or creation of a tombstone I-D by the secretariat to imply un-publication or un-contribution of an earlier or expired I-D. Personally, I consider the possibility to diff arbitrary RFCs and I-D version from the past through the tools.ietf.org interface extremely useful. Similar to being able to browse IETF mailing list archives. Not being able to browse old IETF WG mailing list archives that have been hosted by other organizations is sometimes a problem. (there are many interesting discussions and information in the archives, many of which are still quite relevant today). If the IETF wants to put all old IDs on a public site, I consider that equivalent to unexpiration, and the authors must be given the right to opt-out. You're asking for an opt-out from Note Well here. I strongly object to such a change of IETF policy. Several I-Ds, and in particular abandoned/expired I-Ds were originally cometing proposals, and only one or a few of them was/were selected to become adopted/published as RFCs. That doesn't mean that the other proposals were useless, flawed or not being actively discussed on IETF mailing lists. Just the opposite. I-Ds are often regular parts of WG mailing list discussions, they're just managed/distributed in a fashion that differes from Mailing list archives. -Martin
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/12/2012 11:01 PM, Martin Rex wrote: While the 6-month timer (or any earlier I-D update!!) will, in fact, change how the*IETF* distributes and promotes a particular I-D (version), there is actually*NO* limitation in what folks downloading I-Ds with the URLs from the i-d-announce I-D Action: EMails do with any of the I-Ds that they download. At least one limitation is here: c. Pre-5378 Material. In some cases, IETF Contributions or IETF Documents may contain material from IETF Contributions or IETF Documents published or made publicly available before November 10, 2008 as to which the persons controlling the copyright in such material have not granted rights to the IETF Trust under the terms of RFC 5378 (“Pre-5378 Material”). If a Contributor includes the legend contained in Section 6.c.iii of these Legal Provisions on such IETF Contributions or IETF Documents containing Pre-5378 Materials, the IETF Trust agrees that it shall not grant any third party the right to use such Pre-5378 Material outside the IETF Standards Process unless and until it has obtained sufficient rights to do so from the persons controlling the copyright in such Pre-5378 Material. Where practical, Contributors are encouraged to identify which portions of such IETF Contributions and IETF Documents contain Pre-5378 Material, including the source (by RFC number or otherwise) of the Pre-5378 Material. Note that the standards process is defined in a way that includes archiving, but does not explicitly include publication: b. IETF Standards Process. The term IETF Standards Process has the meaning assigned to it in RFC 5378. In addition, the IETF Trust interprets the IETF Standards Process to include the archiving of IETF Documents in perpetuity for reference in support of IETF activities and the implementation of IETF standards and specifications. So it's not a slam dunk that you have the rights you think for every I-D; you definitely don't have those rights for IDs published before Nov 10, 2008 since the copyright was not transferred to the ISOC/IETF or their Trustees. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
--On Wednesday, September 12, 2012 23:13 -0400 Barry Leiba barryle...@computer.org wrote: ... There's nothing in the quote above that says that the expired document will not be available *in the archive*. It says that it will be removed *from the repository*, which it is... and the text you cite later goes on to talk about the tombstone file that replaced it in the repository, which we can easily see when we go to the datatracker entry for an expired I-D. And then the statement you cite further goes on to say this: An expired I-D may be unexpired when necessary to further the work ofthe IETF, including IETF liaison with other standards bodies. Suchaction will be taken by request of an IESG member, a chair of theworking group associated with the I-D, or one of the documentauthors. That *clearly* implies that it's not *gone*, else how could it be unexpired when necessary, by anyone's request? Barry, Without trying to figure out whether or not I agree with Joe, the key question has never been, IMO, whether or not the IETF has the right to _keep_ expired documents. Keeping them is clearly necessary to un-expire them, as you note, and has a number of other significant advantages and useful properties. As far as I know, a file of expired I-Ds have been maintained since I-Ds were introduced as a tool. But nothing in the above, nor in the text you cite, requires that _keep_ imply guarantee to have available for retrieval over the network by any interested party, with no requirement for a special request. It seems to me that it is only the latter that is of interest here and only the latter that is the subject of the proposed policy. Remove from public archive does not imply it is gone, forget it ever existed either, only making it inaccessible for retrieval except perhaps in response to other court orders or for other good causes that might be permitted. I don't have an opinion or intend to make any claim as to which this part of the discussion turned fishy, but the smell of red herring does not help advance discussions. john
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/12/2012 11:30 PM, John C Klensin wrote: But nothing in the above, nor in the text you cite, requires that _keep_ imply guarantee to have available for retrieval over the network by any interested party, with no requirement for a special request. It's interesting how this line of analysis entirely ignores pragmatics. It has been noted by a number of folk that public access has repeatedly been demonstrated to be... useful. That's why they were made accessible. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Fw: IETF 95 Date Change Proposal - Round 2
By my count that would put about 5 months between IETF 94 and 95, and just a bit more than 3 months separating 95 from 96. Leave it the way it was. On 09/12/2012 08:02 AM, kuor-hsin.ch...@us.elster.com wrote: 3 - 8 April 2016is good. - Forwarded by Kuor-Hsin Chang/USE/Elster on 09/11/2012 06:01 PM - From: IETF Administrative Director i...@ietf.org To: IETF Announcement List ietf-annou...@ietf.org, Cc: i...@ietf.org, i...@iab.org, ietf@ietf.org, wgcha...@ietf.org, i...@ietf.org Date: 09/06/2012 12:13 PM Subject:IETF 95 Date Change Proposal - Round 2 Sent by:ietf-announce-boun...@ietf.org All The IAOC is seeking community feedback on a proposed date change for IETF 95 originally scheduled for 27 March to 1 April 2016. After considering community feedback on a proposed change to 20 - 25 March 2016, the IAOC is proposing 3 - 8 April 2016 to avoid the impact on travel and attendance during the 20 - 25 March period. Comments appreciated to ietf@ietf.org by 20 September 2012. Ray Pelletier IETF Administrative Director __ This email has been spam and virus checked by Elster IT Services.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/13/2012 12:02 AM, Dave Crocker wrote: On 9/12/2012 11:30 PM, John C Klensin wrote: But nothing in the above, nor in the text you cite, requires that _keep_ imply guarantee to have available for retrieval over the network by any interested party, with no requirement for a special request. It's interesting how this line of analysis entirely ignores pragmatics. It has been noted by a number of folk that public access has repeatedly been demonstrated to be... useful. That's why they were made accessible. d/ PirateBay believes this too, and helps make movies available for public access, honoring pragmatics. Good luck with that line of reasoning. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from theIETF Web Site
When I read the original IESG statement, I thought it sloppily worded, since it did not use the same terminology as in http://www.ietf.org/ietf-ftp/1id-guidelines.txt which has been cited below. I then wondered if the sloppy, as I saw it, wording might reflect less than precise thinking in the semantics, and I think that the subsequent posts have born that out. There are a lot of not-so-corner cases that need considering. For me, the 'public I-D archive', as the statement calls it, is of great value; some I-Ds keep doing U-turns and I need to go back and see what has been there before. Also, I may want to incorporate some material from a years old I-D that never got adopted. And so on. So I believe that everything should stay in that archive unless there is a very good reason for it not to; court order but not that alone I would add either or both of IESG vote (as for the approval of an I-D, DISCUSS, ABSTAIN etc) and IETF Consensus. Tom Petch - Original Message - From: Barry Leiba barryle...@computer.org To: Joe Touch to...@isi.edu Cc: IETF ietf@ietf.org Sent: Thursday, September 13, 2012 4:13 AM Subject: Re: Draft IESG Statement on Removal of an Internet-Draft from theIETF Web Site I think it means no longer current for the purposes of work and discussion. Nothing in the Note Well, but there is specific text in the ID Guidelines (written by the IESG): http://www.ietf.org/ietf-ftp/1id-guidelines.txt 8. Expiring An Internet-Draft will expire exactly 185 days from the date that it is posted on the IETF Web site (http://www.ietf.org/id-info/) unless it is replaced by an updated version (in which case the clock will start all over again for the new version, and the old version will be removed from the I-D repository), or unless it is under official review by the IESG (i.e., a request to publish it as an RFC has been submitted)... I.e., this is not a matter of interpretation. 'tis, apparently, because you are still interpreting it differently to how I am. There's nothing in the quote above that says that the expired document will not be available *in the archive*. It says that it will be removed *from the repository*, which it is... and the text you cite later goes on to talk about the tombstone file that replaced it in the repository, which we can easily see when we go to the datatracker entry for an expired I-D. And then the statement you cite further goes on to say this: An expired I-D may be unexpired when necessary to further the work of the IETF, including IETF liaison with other standards bodies. Such action will be taken by request of an IESG member, a chair of the working group associated with the I-D, or one of the document authors. That *clearly* implies that it's not *gone*, else how could it be unexpired when necessary, by anyone's request? I'll also note, Joe, that you are the *only* one arguing this point. Does anyone agree with Joe? If not, it seems fair to say that it looks like you're well in the rough here. Barry
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
--On Thursday, September 13, 2012 00:19 -0700 Joe Touch to...@isi.edu wrote: On 9/13/2012 12:02 AM, Dave Crocker wrote: On 9/12/2012 11:30 PM, John C Klensin wrote: But nothing in the above, nor in the text you cite, requires that _keep_ imply guarantee to have available for retrieval over the network by any interested party, with no requirement for a special request. It's interesting how this line of analysis entirely ignores pragmatics. It has been noted by a number of folk that public access has repeatedly been demonstrated to be... useful. That's why they were made accessible. d/ PirateBay believes this too, and helps make movies available for public access, honoring pragmatics. Good luck with that line of reasoning. Let me try that a different way. Suppose someone were to propose that ISOC increase the subsidy to IETF sufficiently to drop all registration fees. That would certainly be useful. It would be useful to those who have to pay those fees out of their own pockets, increasing the costs of attendance and making it harder to attend. It would be useful to those who have to justify travel budgets and expenses. One might even suggest that it would be useful to everyone who wasn't interested in using the rising costs of IETF meetings to keep people out. It would perhaps be even more useful to offer a distance-based cash subsidy to anyone who has to travel more than, say, 3000 miles to an IETF meeting. That would not only be useful to individuals, but would be useful in balancing out the differential cost effects of meeting location choices and hence in improving geographical balance in meetings. Are there pragmatic reasons to not do either of these useful things? Sure there are. But they would definitely be pragmatically useful. The questions about the public archive aren't do people find this useful? but does the utility of having the archive public outweigh the costs and risks? And, if the answer to the second question is even only maybe, can we analyze the real needs and determine other ways to meet them, such as by keeping expired drafts available for a relatively short time after expiration rather than forever, with authors having an opt-out option?. best, john
copyright notices in RFC 6716
All, I noticed that the recent RFC 6716 contains some reference code that contain the copyright and licenses notice reproduced below. The IETF TLP [1] mandates a certain form of copyright notices and the TLP does not, as far as I can see, permit varying the boiler plate in any way. Note that both companies and organisations are mentioned in the copyright notice in RFC 6716, besides individuals. Does this indicate a policy change, a mistake with that document, or something else? Btw, kudos to the RFC 6716 authors for shipping reference code! I hope this will establish a best practice for standards in the future. /Simon [1] http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.htm Copyright 1994-2011 IETF Trust, Xiph.Org, Skype Limited, Octasic, Jean-Marc Valin, Timothy B. Terriberry, CSIRO, Gregory Maxwell, Mark Borgerding, Erik de Castro Lopo. All rights reserved. This file is extracted from RFC6716. Please see that RFC for additional information. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Joe == Joe Touch to...@isi.edu writes: Joe On 9/5/2012 7:51 AM, SM wrote: Joe ... Creating a perpetual I-D archive for the sake of rfcdiff is not a good idea as it goes against the notion of letting an I-D expire gracefully. Joe +1 Joe Let's not forget there was a reason for expiration. Joe I'm OK with the archive being public so long as at least the Joe authors can remove an ID *without needing to provide a reason*. Joe Yes, removal from the IETF site will not expunge copies from Joe the entire Internet, but the IETF site should set the example Joe here, and respect the original intent of allowing an ID to Joe expire. I find myself in agreement with Joe here. I'm kind of horrified that this discussion is still going on. If I write that super-offensive porn in the form of an i-d that Scott warned about can we all find something else to mail about?:-)
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I find the archives very useful, especially when you have your own I-D history and contribution to WG works perhaps. It helps to show different views, the synergism, the competitive engineering views, the history, etc behind the final development of WG work. Whenever I do find a need to reference them in the eDiscussion, I will make sure I parenthetically note they are expired information. My input is limited due to legal reasons and try to keep with public domain technology exchanges and communications. I can understand if an expired I-D touches base with some level of IP that may be conflictive in the future, i.e. someone does a patent search/research and finds prior art in an expired I-D and it may be advantageous to them to have it removed from the archives. However, this is what the lawyers and courts are for. I'm sure the IETF/IESG archive keepers can also make judgment calls but I don't think it will be harmful to keep them around until it became a legal issue and like everything else, dealt on a case by case basis. I will say that I like to believe (maybe I am naive) the IETF/IESG does represents the community at large and I like to believe it represent even the Small Guys that really is not interested in the politics and battles. John C Klensin wrote: --On Thursday, September 13, 2012 00:19 -0700 Joe Touch to...@isi.edu wrote: On 9/13/2012 12:02 AM, Dave Crocker wrote: On 9/12/2012 11:30 PM, John C Klensin wrote: But nothing in the above, nor in the text you cite, requires that _keep_ imply guarantee to have available for retrieval over the network by any interested party, with no requirement for a special request. It's interesting how this line of analysis entirely ignores pragmatics. It has been noted by a number of folk that public access has repeatedly been demonstrated to be... useful. That's why they were made accessible. d/ PirateBay believes this too, and helps make movies available for public access, honoring pragmatics. Good luck with that line of reasoning. Let me try that a different way. Suppose someone were to propose that ISOC increase the subsidy to IETF sufficiently to drop all registration fees. That would certainly be useful. It would be useful to those who have to pay those fees out of their own pockets, increasing the costs of attendance and making it harder to attend. It would be useful to those who have to justify travel budgets and expenses. One might even suggest that it would be useful to everyone who wasn't interested in using the rising costs of IETF meetings to keep people out. It would perhaps be even more useful to offer a distance-based cash subsidy to anyone who has to travel more than, say, 3000 miles to an IETF meeting. That would not only be useful to individuals, but would be useful in balancing out the differential cost effects of meeting location choices and hence in improving geographical balance in meetings. Are there pragmatic reasons to not do either of these useful things? Sure there are. But they would definitely be pragmatically useful. The questions about the public archive aren't do people find this useful? but does the utility of having the archive public outweigh the costs and risks? And, if the answer to the second question is even only maybe, can we analyze the real needs and determine other ways to meet them, such as by keeping expired drafts available for a relatively short time after expiration rather than forever, with authors having an opt-out option?. best, john -- HLS
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/12/12 11:19 PM, Joe Touch wrote: PirateBay believes this too, and helps make movies available for public access, honoring pragmatics. I'm not sure I understand this analogy. Are you saying that there are IPR issues related to making expired drafts available? Melinda
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
PirateBay believes this too, and helps make movies available for public access, honoring pragmatics. I'm not sure I understand this analogy. Are you saying that there are IPR issues related to making expired drafts available? And since we've had a public archive of expired drafts for quite awhile, where have the purported problems been, that would justify this lengthy thread? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Joe, So it's not a slam dunk that you have the rights you think for every I-D; you definitely don't have those rights for IDs We're NOT talking about rights that were transfered from the document author to arbitrary third parties here, but about rights that were given to the IETF (IETF contribution), and which have never been time-limited. So archival and making accessible I-D contributions past the expiration of an I-D is perfectly legal for the IETF, unless the I-D contains an explicit copyright notice to the contrary (most I-Ds from 199x do not seem to carry any copyright notice at all). Where you are _correct_ is, copypasting parts of such an old I-D or the whole document into new documents will in fact require contacting the original author(s)/copyright holder(s) and obtain permission, the Note Well provisions likely will not be sufficient, at least for those old I-Ds. (it is not just a matter of courtesy, but a requirement). I assume the latter is what rfc5378 is supposed to fix. -Martin
Re: copyright notices in RFC 6716
I was only peripherally involved in this and don't know all the in's and outs of this but let me try and provide a bit of information and hopefully someone from the IETF Trust or RFC Editor can correct me where I am wrong. The internet draft was done with the normal boiler plate that granted a bunch of rights to the IETF Trust. There was also text in the draft where the authors granted additional rights. The trust normally publishes the RFC with about the same license that is used in the draft however the Trust retains the rights to do whatever they want within the range of the license granted to them in the draft. In this case, the RFC was published with slightly different boiler plate than what was in draft. So no, I don't think the policy has changed, and no I don't think this was a mistake. I think the RFC Editor working with the IETF Trust and IETF legal advice made this change. My understanding of the reasons for the change was something like this makes it easier for some linux distribution to include the RFC with their distribution or something. Keep in mind this is a weird RFC in that it includes a huge amount of normative code in the RFC. Hope this helps - and amazed anyone noticed. Cullen PS - I may have this all wrong - I'm not the person that knows but I hope that provides some help. On Sep 13, 2012, at 8:18 AM, Simon Josefsson si...@josefsson.org wrote: All, I noticed that the recent RFC 6716 contains some reference code that contain the copyright and licenses notice reproduced below. The IETF TLP [1] mandates a certain form of copyright notices and the TLP does not, as far as I can see, permit varying the boiler plate in any way. Note that both companies and organisations are mentioned in the copyright notice in RFC 6716, besides individuals. Does this indicate a policy change, a mistake with that document, or something else? Btw, kudos to the RFC 6716 authors for shipping reference code! I hope this will establish a best practice for standards in the future. /Simon [1] http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.htm Copyright 1994-2011 IETF Trust, Xiph.Org, Skype Limited, Octasic, Jean-Marc Valin, Timothy B. Terriberry, CSIRO, Gregory Maxwell, Mark Borgerding, Erik de Castro Lopo. All rights reserved. This file is extracted from RFC6716. Please see that RFC for additional information. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Re: copyright notices in RFC 6716
Cullen Jennings (fluffy) flu...@cisco.com writes: I was only peripherally involved in this and don't know all the in's and outs of this but let me try and provide a bit of information and hopefully someone from the IETF Trust or RFC Editor can correct me where I am wrong. Thanks. Input from members of the Trust, if they were involved, would be appreciated. The internet draft was done with the normal boiler plate that granted a bunch of rights to the IETF Trust. There was also text in the draft where the authors granted additional rights. The trust normally publishes the RFC with about the same license that is used in the draft however the Trust retains the rights to do whatever they want within the range of the license granted to them in the draft. In this case, the RFC was published with slightly different boiler plate than what was in draft. That is not the case, draft -16 had the same license. So no, I don't think the policy has changed, and no I don't think this was a mistake. I think the RFC Editor working with the IETF Trust and IETF legal advice made this change. My understanding of the reasons for the change was something like this makes it easier for some linux distribution to include the RFC with their distribution or something. I don't believe that is the case here. The license used is the same as normal license, only the copyright header is different. Distributions rarely cares who the copyright holder is. IETF rules says additional copyright notices aren't permitted. /Simon Keep in mind this is a weird RFC in that it includes a huge amount of normative code in the RFC. Hope this helps - and amazed anyone noticed. Cullen PS - I may have this all wrong - I'm not the person that knows but I hope that provides some help. On Sep 13, 2012, at 8:18 AM, Simon Josefsson si...@josefsson.org wrote: All, I noticed that the recent RFC 6716 contains some reference code that contain the copyright and licenses notice reproduced below. The IETF TLP [1] mandates a certain form of copyright notices and the TLP does not, as far as I can see, permit varying the boiler plate in any way. Note that both companies and organisations are mentioned in the copyright notice in RFC 6716, besides individuals. Does this indicate a policy change, a mistake with that document, or something else? Btw, kudos to the RFC 6716 authors for shipping reference code! I hope this will establish a best practice for standards in the future. /Simon [1] http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.htm Copyright 1994-2011 IETF Trust, Xiph.Org, Skype Limited, Octasic, Jean-Marc Valin, Timothy B. Terriberry, CSIRO, Gregory Maxwell, Mark Borgerding, Erik de Castro Lopo. All rights reserved. This file is extracted from RFC6716. Please see that RFC for additional information. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I like the whole and +1 to it. I can see the pros and cons of make drafts actually go away but given it is impossible to get rid of a draft from the internet, all we end up with in the current situation are the cons and none of the pros. I do have one suggested change OLD An I-D will only be removed from the public I-D archive in compliance with a duly authorized court order. NEW The IETF Chair may decide to removed an I-D from the public I-D archive. We have better things to do than argue which courts we might accept court orders from or what a court order is so I suggest we just let the chair do the right thing. The chair will understand the goals of the IETF and have legal advice available to them. If the wrong thing happens, we can fix it after the fact by putting the ID back. On Sep 3, 2012, at 6:00 PM, IETF Chair ch...@ietf.org wrote: The IESG is considering this IESG Statement. Comments from the community are solicited. On behalf of the IESG, Russ --- DRAFT IESG STATEMENT --- SUBJECT: Removal of an Internet-Draft from the IETF Web Site Internet-Drafts (I-Ds) are working documents of the IETF, its Areas, and its Working Groups. In addition, other groups, including the IAB and the IRTF Research Groups, distribute working documents as I-Ds. I-Ds are stored in two places on the IETF web site. First, current ones are stored in the I-D directory. Second, current and past ones are stored in a public I-D archive. I-Ds are readily available to a wide audience from the IETF I-D directory. This availability facilitates informal review, comment, and revision. While entries in the I-D directory are subject to change or removal at any time, I-Ds generally remain publicly archived to support easy comparison with previous versions. Entries in the I-D directory are removed as part of normal process when it expires after six months, when it is replaced by a subsequent I-D, or when it is replaced by the publication of an RFC. In all of these situations, the I-D remains in the public I-D archive. An I-D will only be removed from the public I-D archive in compliance with a duly authorized court order. If possible, a removed I-D will be replaced with a tombstone file that describes the reason that the I-D was removed from the public I-D archive.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/13/2012 2:35 PM, Cullen Jennings (fluffy) wrote: OLD An I-D will only be removed from the public I-D archive in compliance with a duly authorized court order. NEW The IETF Chair may decide to removed an I-D from the public I-D archive. This defines the IETF Chair as Chief Censor, with no written policy guidance. That is, deletion is at the whimsy of the Chair. Is that really what we (and the Chair) want? Given possible legal implications of claimed unfair treatment of a document, that's pretty onerous exposure for the Chair. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
The IETF Chair may decide to removed an I-D from the public I-D archive. This defines the IETF Chair as Chief Censor, with no written policy guidance. That is, deletion is at the whimsy of the Chair. Is that really what we (and the Chair) want? I very much agree. I'm happy with the decision being the consensus of a board, but not giving it to an individual. Barry
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/13/2012 3:08 PM, Barry Leiba wrote: The IETF Chair may decide to removed an I-D from the public I-D archive. This defines the IETF Chair as Chief Censor, with no written policy guidance. That is, deletion is at the whimsy of the Chair. Is that really what we (and the Chair) want? I very much agree. I'm happy with the decision being the consensus of a board, but not giving it to an individual. Not that you've said something to exclude this, but I want to make sure we don't lose the second part: I believe we /do/ need a written policy that has been reviewed by legal counsel. Even with a group -- versus individual -- we should not create possible charges of censorship up to the personal whims of the moment. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Dave, On Thu, Sep 13, 2012 at 03:10:51PM -0700, Dave Crocker wrote: I believe we /do/ need a written policy that has been reviewed by legal counsel. I think the lengthy discussion that we have seen on this topic proofs that we should NOT have a written policy. Deal with this on a case-by-case basis seems the most efficient way until we hear that the IESG spends more time arguing on a particular case than the IETF community does on a written policy. David Kessens ---
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
David, On 9/13/2012 3:25 PM, David Kessens wrote: On Thu, Sep 13, 2012 at 03:10:51PM -0700, Dave Crocker wrote: I believe we /do/ need a written policy that has been reviewed by legal counsel. I think the lengthy discussion that we have seen on this topic proofs that we should NOT have a written policy. It shows a tendency of the active IETF discussants to resist doing the work of settling on policy for the IETF. That's quite different from demonstrating a lack of /need/. Essentially none of the enlightened discussion on this thread considered legal ramifications of potentially arbitrary censorship by a public group such as ourselves. In other words, I saw the /actual/ implication of the thread as making it crystal clear that we do /not/ want a collection of amateurs formulating ad hoc censorship policies on the fly. (Forgive me for underscoring this, but I think the original policy draft that was floated to the community was a good demonstration of this danger. Although I happened to like the details of what was floated, the fact that it had not been reviewed by counsel prior to being made public is quite troubling.) Deal with this on a case-by-case basis seems the most efficient way until we hear that the IESG spends more time arguing on a particular case than the IETF community does on a written policy. For an organization in the business of writing global standards, we are remarkably resistant to doing the thoughtful and deliberate policy work of writing standards for ourselves. Instead we tend to prefer the whimsy of personal adhoc-racy, with its typical dangers of inconsistency and incompleteness. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Dave, On Thu, Sep 13, 2012 at 03:43:01PM -0700, Dave Crocker wrote: Essentially none of the enlightened discussion on this thread considered legal ramifications of potentially arbitrary censorship by a public group such as ourselves. Aren't you going a little overboard in hyperbole here ? David Kessens ---
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/13/2012 3:54 PM, David Kessens wrote: On Thu, Sep 13, 2012 at 03:43:01PM -0700, Dave Crocker wrote: Essentially none of the enlightened discussion on this thread considered legal ramifications of potentially arbitrary censorship by a public group such as ourselves. Aren't you going a little overboard in hyperbole here ? you mean by claiming the discussion was enlightened? the rest was offered as an observation and reporting of what I believe to fact, in factual language. if you see hyperbole in any of it, please explain. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
--On Thursday, September 13, 2012 15:10 -0700 Dave Crocker dcroc...@bbiw.net wrote: On 9/13/2012 3:08 PM, Barry Leiba wrote: The IETF Chair may decide to removed an I-D from the public I-D archive. This defines the IETF Chair as Chief Censor, with no written policy guidance. That is, deletion is at the whimsy of the Chair. Is that really what we (and the Chair) want? I very much agree. I'm happy with the decision being the consensus of a board, but not giving it to an individual. Not that you've said something to exclude this, but I want to make sure we don't lose the second part: I believe we /do/ need a written policy that has been reviewed by legal counsel. Even with a group -- versus individual -- we should not create possible charges of censorship up to the personal whims of the moment. I'm not sure, Dave. I see the theoretical risk, but the number of times that problem has occurred in the past is, I believe, zero. I'd be more concerned about it if we were talking about removing active documents rather than taking something out of the publicly-available archive of expired documents. And a decision by the IESG to remove a document would presumably be, like all other IESG decisions, subject to appeal. If the IESG started taking down documents just because they didn't like them, I'd also think we'd quickly try out the recall procedure for the first time. But, again, the IESG has had many years of experience with I-Ds they don't like (and many such documents), during most of which time no one questioned their ability to remove a document from public view (active or archived) and, AFAIK, we have seen absolutely no abuse of that type. I'd be ok with a written policy that has been reviewed by legal counsel if I thought there were even reasonable odds of its adequately covering all the cases. But I fear that such a policy would exclude some important case and thereby get the IESG in trouble as we tried to work with (or work around, or revise on an emergency basis) a policy that turned out to prevent us (or even the IESG or IETF Trust) from exercising good sense and doing what is either obviously right or as advised by Counsel when Counsel is presented by a particular situation. Proposal: I think it would be fine to have a policy in which: (1) A document would be taken down as quickly as possible in response to a legitimate court order with approval of Counsel. (2) A document to which, in the opinion of Counsel, the IETF might not have clear copyright title, and for which a DCMA take-down notice or equivalent was received unless the IESG, with advice and consent of Counsel, advised against such a takedown. (3) The IESG could take anything else down for cause at its discretion after: (3.1) Seeking and receiving advice of Counsel (3.2) Announcing intention to do so, and the cause, on the IETF-announce list and allowing a brief period for objections. (3.3) Considering any advice and objections before making a final decision. (3.4) Subject to the above, the IESG is encouraged to look with favor on requests to remove already- expired documents from the public archive from the party responsible for the document (authors of individual drafts; WGs for WG drafts). We recognize that such removal doesn't cause the documents to disappear from the Internet, but responsible parties making such requests about their own documents presumably have reasons that we should treat respectfully. (4) Any of those actions would be subject to appeal if members of the community felt there were important issues that had not been considered. An appeal could request that the advice from Counsel be made available to the community. The IESG would be required to either comply with that request or explain why not. I don't like it --my personal position is much closer to Joe's or Sam's-- but, if there is consensus that we have to have a written policy, one like the above at least doesn't tie our hands when a situation arises that we haven't anticipated. While there is some possibility of DoS attacks embedded in it, it remains important that we haven't seen huge numbers of these requests (or even small numbers). Indeed, one of my fears about the amount of discussion we've had (and any formal policy at this point) is that it may encourage such requests. Too late to worry about that now. best, john
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I very much agree. I'm happy with the decision being the consensus of a board, but not giving it to an individual. So give it to the IESG and we can stop arguing about it. I have to say, the urge to post a few I-D's consisting of snuff porn is nearly irresistible. R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I believe we /do/ need a written policy that has been reviewed by legal counsel. Even with a group -- versus individual -- we should not create possible charges of censorship up to the personal whims of the moment. Censorship? Sheesh. The IETF is not the government. We have no obligation to anyone to publish anything, nor can we keep anyone from publishing anything on the 99.9% of the Internet that the IETF does not control. As I think I've said several times before, if we think the IESG would start gratuitously deleting stuff, we have much worse problems than any policy statement could solve. R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
It shows a tendency of the active IETF discussants to resist doing the work of settling on policy for the IETF. That's quite different from demonstrating a lack of /need/. The IETF has been around for 26 years, and has had, I gather, zero removal requests to date. If that doesn't demonstrate lack of need, what would? R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/13/2012 12:28 PM, Martin Rex wrote: Joe, So it's not a slam dunk that you have the rights you think for every I-D; you definitely don't have those rights for IDs We're NOT talking about rights that were transfered from the document author to arbitrary third parties here, but about rights that were given to the IETF (IETF contribution), and which have never been time-limited. The expires term and corresponding entire text of the ID submissions guidelines suggest otherwise. So archival and making accessible I-D contributions past the expiration of an I-D is perfectly legal for the IETF, unless the I-D contains an explicit copyright notice to the contrary (most I-Ds from 199x do not seem to carry any copyright notice at all). I've already pointed out text that, e.g., someone might use to make the case to the contrary. Finally, in the US, lawyer isn't who would decide this; a jury would. Where you are _correct_ is, copypasting parts of such an old I-D or the whole document into new documents will in fact require contacting the original author(s)/copyright holder(s) and obtain permission, the Note Well provisions likely will not be sufficient, at least for those old I-Ds. (it is not just a matter of courtesy, but a requirement). I assume the latter is what rfc5378 is supposed to fix. There are several variants of issues that apply, at least three I recall: pre 1994 1994-2008 2008-now This isn't the first time this issue has been discussed on this list. RFC 5378 is intended to address reuse of material, as you suggest - not whether that material can be publicly posted. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/13/2012 11:04 AM, Melinda Shore wrote: On 9/12/12 11:19 PM, Joe Touch wrote: PirateBay believes this too, and helps make movies available for public access, honoring pragmatics. I'm not sure I understand this analogy. Are you saying that there are IPR issues related to making expired drafts available? Yes. Depends on the IDs, when they were authored, and which version of the boilerplate they contain. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I'm not sure I understand this analogy. Are you saying that there are IPR issues related to making expired drafts available? Yes. Depends on the IDs, when they were authored, and which version of the boilerplate they contain. Can you give a concrete example of an I-D with this problem? I don't ever recall a time when the grant of rights to the IETF had a time limit. R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
There were times when there were no rights granted explicitly, at least. I indicated the three ranges in a previous mail. Joe On 9/13/2012 8:40 PM, John Levine wrote: I'm not sure I understand this analogy. Are you saying that there are IPR issues related to making expired drafts available? Yes. Depends on the IDs, when they were authored, and which version of the boilerplate they contain. Can you give a concrete example of an I-D with this problem? I don't ever recall a time when the grant of rights to the IETF had a time limit. R's, John
Weekly posting summary for ietf@ietf.org
Total of 150 messages in the last 7 days. script run at: Fri Sep 14 00:53:02 EDT 2012 Messages | Bytes| Who +--++--+ 12.67% | 19 | 11.73% | 116162 | to...@isi.edu 6.67% | 10 | 6.47% |64122 | jo...@taugh.com 5.33% |8 | 6.01% |59500 | john-i...@jck.com 4.67% |7 | 4.65% |46042 | barryle...@computer.org 4.67% |7 | 4.40% |43565 | melinda.sh...@gmail.com 4.67% |7 | 3.98% |39383 | d...@dcrocker.net 3.33% |5 | 4.62% |45769 | eric.g...@ericsson.com 3.33% |5 | 3.28% |32519 | l...@cisco.com 3.33% |5 | 3.06% |30300 | ned+i...@mauve.mrochek.com 3.33% |5 | 2.49% |24665 | ra...@psg.com 2.67% |4 | 2.10% |20831 | simon.perrea...@viagenie.ca 2.00% |3 | 2.77% |27395 | rdroms.i...@gmail.com 2.00% |3 | 2.04% |20188 | s...@resistor.net 2.00% |3 | 2.01% |19880 | m...@sap.com 2.00% |3 | 1.91% |18944 | c...@tzi.org 2.00% |3 | 1.86% |18424 | dcroc...@bbiw.net 1.33% |2 | 1.83% |18142 | flu...@cisco.com 1.33% |2 | 1.68% |16630 | si...@josefsson.org 1.33% |2 | 1.64% |16223 | daedu...@btconnect.com 1.33% |2 | 1.52% |15096 | brian.e.carpen...@gmail.com 1.33% |2 | 1.35% |13386 | glenz...@gmail.com 1.33% |2 | 1.20% |11892 | david.kess...@nsn.com 1.33% |2 | 1.18% |11664 | ch...@ietf.org 1.33% |2 | 1.11% |11000 | a...@anvilwalrusden.com 0.67% |1 | 1.65% |16355 | l...@netapp.com 0.67% |1 | 1.01% | 9976 | hsan...@isdg.net 0.67% |1 | 0.92% | 9118 | david.bor...@quantum.com 0.67% |1 | 0.86% | 8518 | chris.dearl...@baesystems.com 0.67% |1 | 0.84% | 8350 | nar...@us.ibm.com 0.67% |1 | 0.82% | 8072 | kuor-hsin.ch...@us.elster.com 0.67% |1 | 0.81% | 8034 | lizhong@zte.com.cn 0.67% |1 | 0.77% | 7660 | s...@internet2.edu 0.67% |1 | 0.77% | 7620 | fmar...@linkedin.com 0.67% |1 | 0.74% | 7323 | eburge...@standardstrack.com 0.67% |1 | 0.73% | 7185 | m...@sandelman.ca 0.67% |1 | 0.70% | 6907 | abdussalambar...@gmail.com 0.67% |1 | 0.69% | 6794 | l...@pi.nu 0.67% |1 | 0.67% | 6643 | david.bl...@emc.com 0.67% |1 | 0.65% | 6452 | y...@checkpoint.com 0.67% |1 | 0.65% | 6424 | bob.hin...@gmail.com 0.67% |1 | 0.64% | 6363 | roni.e...@mail01.huawei.com 0.67% |1 | 0.64% | 6313 | petit...@acm.org 0.67% |1 | 0.63% | 6247 | rob...@raszuk.net 0.67% |1 | 0.63% | 6223 | d...@dotat.at 0.67% |1 | 0.62% | 6100 | klen...@jck.com 0.67% |1 | 0.61% | 6017 | hartmans-i...@mit.edu 0.67% |1 | 0.60% | 5894 | stbry...@cisco.com 0.67% |1 | 0.59% | 5859 | hal...@gmail.com 0.67% |1 | 0.59% | 5811 | de...@ihtfp.com 0.67% |1 | 0.58% | 5720 | c...@a.org 0.67% |1 | 0.57% | 5606 | d...@fsround.org 0.67% |1 | 0.56% | 5520 | d3e...@gmail.com 0.67% |1 | 0.55% | 5463 | p...@frobbit.se 0.67% |1 | 0.54% | 5386 | s...@cs.columbia.edu 0.67% |1 | 0.53% | 5283 | rgolod...@infratection.com 0.67% |1 | 0.53% | 5249 | n...@inex.ie 0.67% |1 | 0.52% | 5146 | pe...@akayla.com 0.67% |1 | 0.52% | 5139 | wjh...@hardakers.net 0.67% |1 | 0.50% | 4904 | adr...@olddog.co.uk 0.67% |1 | 0.49% | 4847 | rbar...@bbn.com 0.67% |1 | 0.42% | 4168 | j...@mercury.lcs.mit.edu +--++--+ 100.00% | 150 |100.00% | 990411 | Total
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Joe Touch wrote: There were times when there were no rights granted explicitly, at least. I indicated the three ranges in a previous mail. In which case the Note Well concludently applies to the I-D contents, which seems to have first appeared on www.ietf.org around 2001, http://web.archive.org/web/20010413091132/http://ietf.org/overview.html and slightly extended in 2002: http://web.archive.org/web/20020605140239/http://ietf.org/overview.html primarily refering to the IETF process described in rfc2026 section 10: http://tools.ietf.org/html/rfc2026#section-10 10.2, 10.3, 10.3.1 (2), 10.3.1 (5), 10.3.1 (7) 10.3.1. All Contributions 7. The contributor represents that there are no limits to the contributor's ability to make the grants acknowledgments and agreements above that are reasonably and personally known to the contributor. By ratifying this description of the IETF process the Internet Society warrants that it will not inhibit the traditional open and *free access to IETF documents for which license and right have *been assigned according to the procedures set forth in this *section, including Internet-Drafts and RFCs. This warrant is *perpetual and will not be revoked by the Internet Society or its *successors or assigns. So which specific part of including Internet-Drafts and RFCs and This warrent is perpetual caused your impression that there was a time-limit on an I-D contribution? -Martin btw. rfc2026 10.3.1 (2) looks like an explicit non-policy for dissemmination or termination of dissemination to me: 2. The contributor acknowledges that the ISOC and IETF have no duty to publish or otherwise use or disseminate any contribution. I would be OK with a single person from (IESG member or IETF Chair) quickly decides about suspending dissemination of a document based on personal judgement and that the IESG wiggles out by themselves an informal procedure (rather than a formal policy) for safeguarding the process (from bias and abuse). This cuts into their time budget and seems to not be a concerningly frequent occurence to spend much polish on it at this point.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Note well, as you noted well, does not go back to the beginning of all IDs. I.e., this is a tangled mess of different copyrights, different note wells, etc., and it's not as simple as it's the IETF's right to do anything except - maybe - going forward with a new copyright statement for IDs. Joe On 9/13/2012 10:10 PM, Martin Rex wrote: Joe Touch wrote: There were times when there were no rights granted explicitly, at least. I indicated the three ranges in a previous mail. In which case the Note Well concludently applies to the I-D contents, which seems to have first appeared on www.ietf.org around 2001, http://web.archive.org/web/20010413091132/http://ietf.org/overview.html and slightly extended in 2002: http://web.archive.org/web/20020605140239/http://ietf.org/overview.html primarily refering to the IETF process described in rfc2026 section 10: http://tools.ietf.org/html/rfc2026#section-10 10.2, 10.3, 10.3.1 (2), 10.3.1 (5), 10.3.1 (7) 10.3.1. All Contributions 7. The contributor represents that there are no limits to the contributor's ability to make the grants acknowledgments and agreements above that are reasonably and personally known to the contributor. By ratifying this description of the IETF process the Internet Society warrants that it will not inhibit the traditional open and *free access to IETF documents for which license and right have *been assigned according to the procedures set forth in this *section, including Internet-Drafts and RFCs. This warrant is *perpetual and will not be revoked by the Internet Society or its *successors or assigns. So which specific part of including Internet-Drafts and RFCs and This warrent is perpetual caused your impression that there was a time-limit on an I-D contribution? -Martin btw. rfc2026 10.3.1 (2) looks like an explicit non-policy for dissemmination or termination of dissemination to me: 2. The contributor acknowledges that the ISOC and IETF have no duty to publish or otherwise use or disseminate any contribution. I would be OK with a single person from (IESG member or IETF Chair) quickly decides about suspending dissemination of a document based on personal judgement and that the IESG wiggles out by themselves an informal procedure (rather than a formal policy) for safeguarding the process (from bias and abuse). This cuts into their time budget and seems to not be a concerningly frequent occurence to spend much polish on it at this point.
CORRECTED: INSIPID WG Virtual Interim Meeting: October 4, 2012
The INSIPID WG will be holding a virtual interim meeting on 4th October 2012 at 9:00 AM Eastern Daylight Time (GMT-4:00). The duration will be 2 hours. The agenda will be posted to the INSIPID mailing list (http://www.ietf.org/mail-archive/web/insipid/current/maillist.html) pending further discussion on the list.
