Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
On Oct 8, 2013, at 3:38 PM, Ted Lemon ted.le...@nominum.com wrote: On Oct 8, 2013, at 4:30 PM, Cullen Jennings (fluffy) flu...@cisco.com wrote: Part of why you can't do this with DHCP is that clients are written so that when an IP address fails to work for an application connection, the application re does the DNS and gets the new address (assuming TTL had been moved down during the move). Applications can not tell the OS to redo DHCP when they fail an application level connection. This use case is a good example of when to use an FQDN format for a DHCP option. However, it's not a great example of when to use a DHCP option—configuring SIP servers with DHCP is generally a bad idea, because if your device is connected to a new network, it will blindly take the SIP server IP address or FQDN information from the DHCP server and use it, and that SIP server might well perform an MitM attack or the like. So it's only in the very restricted use case of a Cisco IP phone permanently installed on a desktop and connected to a trusted network that (a) configuring SIP via DHCP makes sense, and (b) using the FQDN is a good idea. Of course it's possible that my limited understanding of how SIP works is preventing me from seeing why it's safe to configure SIP service using DHCP, but I'm assuming that that's not the case in this argument; please feel free to correct me. Nah, it's not quite like that - Long story how that it but the security mechanism make sure you authenticate both ends to stop that. We've actually been having this same conversation on the iesg mailing list, and I asserted that SIP was something you ought not to configure with DHCP; your use case is the one case where it sort of makes sense. Can you think of similar use cases where it actually makes sense to configure these parameters via DHCP? Possibly the right solution is to update the document to talk about this sort of restricted use case as one where FQDNs actually do make sense. The document certainly doesn't say you _can't_ use FQDNs, but we see people wanting to use them a lot in cases where they really don't make sense, hence the advice. Historically I don't think we bothered to make this distinction when defining new DHCP options, but it seems like a useful distinction to make. Help educate me on this a bit - I don't see all the things that get requested of DHCP. What are some examples of things where people are request FQDN where IP would be better. I think having some real examples that have come up would make it easier to see what advice is needed.
Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
(Dear OPs ADs, please read … ) I disagree with the advice in section 8. Cisco IP phones have been deployed with DHCP options that use FQDN and with options that use IP addresses. For this type of use case the FQDM turned out to be much better from an operational and administration point of view. IT departments are used to making sure that changes of IP addresses on servers are well coordinated with changes to the DNS - they are good at doing that and that and have good tools for it. Conversely, they are not used to coordinating server changes with DHCP changes and do not have good tools for that. Part of why you can't do this with DHCP is that clients are written so that when an IP address fails to work for an application connection, the application re does the DNS and gets the new address (assuming TTL had been moved down during the move). Applications can not tell the OS to redo DHCP when they fail an application level connection. For nearly every case in the real world, the power and RTT and reliability issues are simply not relevant - regardless of which way you do it, the application is unlikely to work if DNS is down, the extra RTT make no speed difference the user can percieve and the power difference over a day of use of the application is so small it is not measurable. FQDN allow usage of things like DNS SRV for load balancing, happy eye balls for v6 transition, and make it easier to get things to geographically close servers. I don't think it should come a a shock to anyone that the level of indirection that FQDNs provides turns out to be a really useful tool. Lets use that indirection tool where appropriate. Related to this, the advice in section 12 seems a bit off to me. I understand the issues - but keep in mind that many modern applications (browsers and SIP phones for example) do the DNS inside the application instead of using the OS resolvers. Part of the reason for this is asynchronous resolution but part of it is also control of which interface is used for DNS and if multiple interfaces are used, being able to keep the applications traffic on the the appropriate interface for the DNS server that returned the address. So while I agree that Existing nodes cannot be assumed to systematically segregate configuration information on the basis of its source; Equally true is you can't assume the converse of that. So I think the statement that As a consequence, DNS resolution done by the DHCP server is more likely to behave predictably than DNS resolution done on a multi-interface or multi- homed client. Is just plain wrong. I think it would be more accurate to say in these cases the results are not always predictable. The issue is the DHCP server may get an DNS answer that contains and server that can not even be reached by the DHCP client. As a general rule of thumb, using FQDN in the configuration of a DHCP server is a really bad idea because IT admins assume that if they change the the DNS information, the clients will get the new information. But they don't. Cullen On Sep 19, 2013, at 3:54 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Guidelines for Creating New DHCPv6 Options' draft-ietf-dhc-option-guidelines-14.txt as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides guidance to prospective DHCPv6 Option developers to help them creating option formats that are easily adoptable by existing DHCPv6 software. This document updates RFC3315. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: WG Review: Secure Telephone Identity Revisited (stir)
This looks reasonable to me and given how much effort it has taken to get agreement on theses words, I am not keen on any of the material changes I have seen proposed. On Aug 21, 2013, at 11:52 AM, The IESG iesg-secret...@ietf.org wrote: A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-08-28. Secure Telephone Identity Revisited (stir) Current Status: Proposed WG Chairs: TBD Assigned Area Director: Richard Barnes r...@ipv.sx Mailing list Address: s...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir Archive: http://www.ietf.org/mail-archive/web/stir/ Charter: The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). In addition, use of an incorrect source telephone number facilitates wire fraud or can lead to a return call at premium rates. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authorization to use telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its priority mechanism work item, the working group will specify a SIP header-based mechanism for verification that the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used. This protection will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key that is associated with the one or more telephone numbers. Credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme. In addition to its priority mechanism work item, the working group will consider a mechanism for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism. Expansion of the authorization mechanism to identities using the user@domain form is out of scope. The work of this group is limited to developing a solution for telephone numbers. The working
Re: [payload] Last Call: draft-ietf-payload-vp8-08.txt (RTP Payload Format for VP8 Video) to Proposed Standard
So do you expect your implementations on devices with hardware acceleration to have any limits on resolution of images they can decode? I can't imagine how I could implement the frame buffers in VP8 in VLSI without having an upper limit on both the width and height of the image. How do you deal with that? I don't know if you ever got the Google VHDL code for VP8 but I have never got it so I don't know what it does but if you do, that would be great. On Jul 24, 2013, at 12:57 PM, Timothy B. Terriberry tterr...@xiph.org wrote: Cullen Jennings (fluffy) wrote: There is one thing that as far as I can tell that all the implementors agree on. None of the implications control the resolution using m=video 62537 RTP/SAVPF 96 a=rtpmap:96 VP8/9 a=fmtp:96 max-fr=30;max-fs=3600 What resolution do you think max-fs=3600 is? I have no idea. It is not possible to implement so it is not surprising no one is doing it. However, this draft-ietf-payload-vp8 draft says the resolution is specified using the max-fs and max-fr. I can't speak for other implementations, but here at Mozilla, our interpretation of RFC 6236 was that the values specified in imageattr can be completely ignored by either side, if they so choose. That leaves max-fs and max-fr as the only mechanism to indicate a resource constraint that cannot be ignored, and we plan to use it as such. See https://bugzilla.mozilla.org/show_bug.cgi?id=881935 for details. ___ payload mailing list payl...@ietf.org https://www.ietf.org/mailman/listinfo/payload
Re: [payload] Last Call: draft-ietf-payload-vp8-08.txt (RTP Payload Format for VP8 Video) to Proposed Standard
Resent on different list … I would like to raise an issue interoperability with this payload specification that we are currently having with WebRTC implementations. In WebRTC, and many other places, you want SDP to be able to control the resolution of the image (or at least the outer limits of the resolution). Yes, I realize there are applications where you know the resolution vis a some out of band mechanisms but O/A SDP is not one of the where this is guaranteed. We do need to specify how this works for use with O/A SDP. Some implementations think that if you want the resolution to by 720 lines by 1280, you control the resolution of codec with a SDP line something like m=video 62537 RTP/SAVPF 96 a=rtpmap:96 VP8/9 a=ssrc:5 imageattr:* [1280, 720] Some other implementers think you control the resolution using RFC 6236 with something like m=video 62537 RTP/SAVPF 96 a=rtpmap:96 VP8/9 a=imageattr:96 [x=1280,y=720] There is one thing that as far as I can tell that all the implementors agree on. None of the implications control the resolution using m=video 62537 RTP/SAVPF 96 a=rtpmap:96 VP8/9 a=fmtp:96 max-fr=30;max-fs=3600 What resolution do you think max-fs=3600 is? I have no idea. It is not possible to implement so it is not surprising no one is doing it. However, this draft-ietf-payload-vp8 draft says the resolution is specified using the max-fs and max-fr. I raised this in the WG and the WG came to consensus that current draft is fine. So I actually believe that current draft does represent IETF consensus and that I was merely in the rough on that consensus. I had decided to just ignore it in LC because I was under the impressing that all the implementations would just ignore the RFC and do a=imageattr:96 [x=1280,y=720]. However, when it came to my attention that many were doing a=imageattr:96 [x=1280,y=720] but some where doing the non interoperable a=ssrc:5 imageattr:* [1280, 720], I decided that this problem actually needed to be fixed. I think this draft is broken and will create interoperability problems for years to come. I encourage the IESG to fix it. I don't care how it is resolved, I care that there is a way to for O/A to sort out the resolution and since the approach used be SDP to do this is codec specific, it needs to be in this draft. Cullen On Jun 4, 2013, at 3:25 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for VP8 Video' draft-ietf-payload-vp8-08.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1622/ ___ payload mailing list payl...@ietf.org https://www.ietf.org/mailman/listinfo/payload
Re: call for ideas: tail-heavy IETF process
Few thoughts. 1) don't get wrapped around the axel of STD, PS, Foo bar label, it has nothing to do with the problem that that IESG believes many drafts need changes to fix significant problems. Lots of people imply that the IESG is setting the bar too high but when you look at the changes that are made to drafts from point they go in, to point they come out of IESG it seems to be a rare example where people don't agree that major changes were an improvement and needed. 2) On the point of what the IESG should be doing, I would like to see the whole IESG say they agree with the Discuss Criteria document and will stay within that (or change it if they disagree). The cross area review teams might want to also provide comments within this context. 3) Require each pub request from a WG to come with names of 3 nom com eligible people that are willing to say I have carefully reviewed this draft and I believe it is ready to be published as an RFC. If a WG can't find 3 people to do this, it should probably be closed. You might consider something similar for AD sponsored drafts but I am more interested in the WG ones. 4) Get the ADs involved earlier. My experience is that many ADs won't say much because they are worried that they would be over influencing the WG. ADs got the job because we think they are the right people to provide influence and obviously it would be better to get that early rather than late. 5) Given how long a WG takes, I have no problem with time IESG / RFCEd takes. I would suggest mitigating this concern by clearly telling the community that if there were a spec that truly needed to be fast tracked for some real reason, you would make it priority. And on the rare occasion that is needed, do it and track the stats for fast track separately. I would guess that less than 1 in 100 needs this and you could do theses with delays in the small numbers of weeks instead of months. How fast you can move when really needed is more important to me than the average and I know that the IESG/IANA/RFCEd team works well in parallel and can move fast when needed. 6) Over the long term, set up the tools to separately track IESG / RFCEd time where the ball is in the authors court. 7) Remember that in the end, the goal is not a standard. The goal is an feature rich interopeable internet that is a fertile ground for inovation. High quality and relevant standards that think about the future are the way to get there. The goal is not to publish lots of specification that aren't used and don't work. Cullen On May 1, 2013, at 9:33 AM, Jari Arkko jari.ar...@piuha.net wrote: I wrote a blog article about how we do a fairly significant amount of reviews and changes in the late stages of the IETF process. Next week the IESG will be having a retreat in Dublin, Ireland. As we brought this topic to our agenda, Pete and I wanted to raise the issue here and call for feedback ideas for improving the situation with all of you. http://www.ietf.org/blog/2013/05/balancing-the-process/ Jari
Re: call for ideas: tail-heavy IETF process
inline On May 14, 2013, at 10:34 AM, Ted Lemon ted.le...@nominum.com wrote: On May 14, 2013, at 9:58 AM, Cullen Jennings (fluffy) flu...@cisco.com wrote: 2) On the point of what the IESG should be doing, I would like to see the whole IESG say they agree with the Discuss Criteria document and will stay within that (or change it if they disagree). The cross area review teams might want to also provide comments within this context. I am not entirely convinced that the DISCUSS criteria are complete. agree but I like and think they help even thought they are not complete There are some rules in the criteria that are intended to curb abuse, and that I think do have that effect, but that also would make some very appropriate DISCUSSes fail to meet the criteria. If you could give some examples of DISCUSSes that you think are reasonable but fail to meet the criteria, it would be really great if you could provide some examples of that as I think it would help refine DISCUSS criteria. I think everyone agrees there could be things in that category but - that was part of the reason DISCUSS criteria did not end up as a BCP. I don't really know how to address that problem. The IESG needs to keep using common sense and keep doing the right thing. I'm happy that the IESG deal with the unexpected. E.g. the rule about not coming up with new DISCUSSes: if a DISCUSS winds opening up a can of worms, it ought to be possible to enlarge the DISCUSS, but I think that the rule about not adding new DISCUSSes after the first DISCUSS tends to forbid that, and the reason given is a good one. Having said that, I don't think the right answer is to ignore that requirement. I don't actually have a good answer. I think the IESG has generally followed a good path of not adding new things, and at the same time if some huge problem was found later, still dealing with it. A long time ago it was hard to know when the IESG might actually finish review, that is not longer a problem but I don't want to go back to it being a problem. It's worth noting that ADs are not omniscient, and hence the DISCUSS criteria apply to what the AD entering the DISCUSS _knows_, not to the full state of all knowledge in the world. Of course and that is part of why the name DISCUSS. The AD wants to DISCUSS it with people and improve their knowledge of state of work and what happened in WG and why it is the way it is and resolve it. I'm perfectly happy with DISCUSSes being resolved with once it got explained to me, I see it is not a problem and cleared. If someone other than the AD has knowledge that they think means that the DISCUSS doesn't meet the criteria, that doesn't mean the DISCUSS doesn't mean the criteria. In this case, the critic needs to communicate it to the AD, who may or may not agree with the critic's point of view. This is not to say that it's never correct to say this doesn't meet the DISCUSS criteria. But the reason given should be that it would be obvious to anyone reading the DISCUSS that it didn't meet the criteria. Sure but as everyone knowledge increases, I'd expect that AD would update the DISCUSS or remove it if it becomes clear it is not longer relevant. My experience has been IESG does do this. The critic's expert knowledge can't be given as a reason. I have also noticed that some authors have the impression that a DISCUSS means the AD doesn't like the document, or doesn't want the document to advance, or is a non-negotiable pronouncement from on high that the authors should not question. This is certainly not my motivation when I enter a DISCUSS. I'm just some guy who got nominated by the nomcom. Hopefully I'm qualified, but I don't claim to be right. I have seen DISCUSSes I've raised improve documents, and I've seen DISCUSSes I've raised turn out not to require any change, but just some discussion to clear up a misunderstanding on my part. I very much hope that in the latter case, the author will argue back, and not just make a change to shut me up! +1 to that. The reason I raise a DISCUSS rather than a comment is that at the time I'm writing the DISCUSS, it appears _to me_ to be the case that there is a problem that ought to be addressed before the document is published. I may think it's generally a great document, but I want the concern I've raised to be addressed before it moves forward. That is _all_ a DISCUSS from me means. If I think the document is an irretrievably bad idea, I will abstain, and say why I think so. Again, +1 to that and my experience is most the IESG feels the same way. Thanks for sending your email. I think it help people understand how ADs think about DISCUSSes.
Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
My read of this draft is that it eliminates the need for rough consensus at both the WG and IETF level. Basically the WG chair can just decide and even if the WG disagrees with the chair. If the WG does not have consensus in WGLC that they they do want to publish the draft, it still gets published. I realize from the email list discussions this may not be what the author of the draft intended but it is how I read this draft. Because of this, I am against approving this and also believe it would need to be BCP not experimental as it changes the fundamental process to approve PS drafts. The rest of this draft, the part about overlapping, is already allowed by the process today as the draft points out. The WGLC is not required at all, the AD processing and IETF LC can overlap. However, I think that the AD should do their processing before they LC the draft because that means they check it is ready before wasting the IESG and everyone else's time revving a document. AD processing can often be done in a few hours or less if the draft is ready. Generally, WGLC avoids late surprises which take more time in the long run but all of this is a general guideline and there are cases where it make sense to overlap all this and put it through. Thus I think it is good that the current process allows this to all be overlapped at the chair and AD discretion. I encourage the AD Chairs to overlap where they think it will 1) is appropriate 2) will speed things up and 3) the speed up actually helps the internet or some groups of users in a meaningful way. I'm certainly not against some chairs, ADs, etc trying to put a draft throughout quickly that they think is ready (running code or not) but I don't see the need for this change to the process. I also have a question for the each IESG member that I think is very relevant - Do all of you agree to only put discussed that meet the Discuss Criteria this draft refers too? I really hope you do. If you don't that raises even more issues for how this draft changes the process. Cullen On Jan 11, 2013, at 8:14 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'A Fast-Track way to RFC with Running Code' draft-farrell-ft-03.txt as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes an optional, fast-track way to progress a working group document to IESG review. It is provided as a process experiment as defined in RFC 3933 for use when working group chairs believe that there is running code that implements a working group Internet-Draft. The motivation is to have the IETF process explicitly consider running code, consistent with the IETF's overall philosophy of running code and rough consensus. In this process all of working group last call, IETF last call, and Area Director review are carried out in the same two week period. Only comments that meet IESG Discuss criteria need to be addressed during this stage, and authors are required to make any changes within two weeks. This experiment will run for one year. The file can be obtained via http://datatracker.ietf.org/doc/draft-farrell-ft/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-farrell-ft/ballot/ No IPR declarations have been submitted directly on this I-D.
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: 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.
