Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On 05 May 2011, at 12:13 , The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels' draft-housley-two-maturity-levels-06.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Yes, please, and as soon as possible. This is very long overdue. Many thanks to Russ H for being patient and persistent on this topic. Yours, Ran Atkinson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Thu May 5 18:31:33 2011, Dave CROCKER wrote: On 5/5/2011 10:22 AM, Dave Cridland wrote: On balance, whilst I appreciate the aims of this document, I think the proposals are not suitable for adoption. 1) This document radically lowers the quality of Proposed Standards. What, specifically, are the parts of the proposal that you believe will lower the quality of a Proposed Standard? The parts unmentioned in the document, in effect. It states: 2.1. The First Maturity Level: Proposed Standard The stated requirements for Proposed Standard are not changed; they remain exactly as specified in RFC 2026 [1]. Various influences have made publishing a Proposed Standard much harder than the stated requirements in RFC 2026. The intention of the two-tier maturity ladder is to restore practice to the requirements for Proposed Standard from RFC 2026, and stop performing more scrutiny than intended in IETF working groups and the IESG. No new requirements are introduced; no existing published requirements are relaxed. RFC 2026 essentially defines a PS document as being a first cut, likely to change, and as such unsuitable for production deployment. In particular: Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. So this clearly states that should we revert to RFC 2026, then we should immediately consider that HTTP, IMAP, and XMPP, for instance, should not be deployed in disruption-sensitive environments. Are you really sure that's what you think our consensus opionion is? It certainly isn't mine. I don't think this reflects the current status quo in the slightest. I think our current PS maturity is essentially considered production quality, although we anticipate that clarifications in the specification may be required, and consultation with other implementors is likely to be beneficial. In particular, for better or worse, the wider internet technical community - ie, the people who are aware of, but not involved in, the IETF - expect our PS documents to have high quality, and would be caught unawares by a sudden shift back to this stance. So to make this clear, I think that as the requirements and scrutiny of PS documents have increased, the quality has as a result, and - undoubtedly more important - the expected quality has also. I am suprised that you don't see this as quite apparent. We have, in general, raised the bar over the years for PS documents, and - whether or not you think this was a good idea - this horse has left the station, and it's too late to put the lid back on - the wider world now expects this. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On Thu May 5 23:47:50 2011, Dave CROCKER wrote: Folks, On 5/5/2011 11:33 AM, Scott O. Bradner wrote: As I have stated before, I do not think that this proposal will achieve anything useful since it will not change anything related to the underlying causes of few Proposed Standards advancing on the standards track. We currently have a standards process that largely ignores two of its stages. That's part of the story. It's not a complete observation, though. We have a standards process that is four stage, not three, and a first step should be to document what we're doing. That's how we work - we document running code. At the least, our community should be embarrassed about this cruft and should want to streamline things and make them more likely to be fully exercised. No. The minimum is that we should be embarrassed about the cruft. It is a trivial observation that we do not follow RFC 2026, and we should ensure that we have a standards process we actually follow. 1. The criteria for the second stage are significantly clarified and rely exclusively on actual adoption and use (again, modulo some important nuances.) Whatever happens with the practice of getting to Proposed, this should make it more predictable and easier to get to (Full) Internet Standard, based solely on actual success of the specification. More predictable is good. Easier? I'm not sure. But the real problem I have is the phrase hidden away in the above - Whatever happens with the practise of getting to Proposed. You're not seriously intending to put forward another document which defines our standards process yet not expecting anyone to follow it, are you? 2. The model is cleaned up, in my opinion significantly. This improves transparency of the process a bit. Also, I think Draft made sense when our whole endeavor was less mature and we needed to help the community understand what is needed for achieving interoperable deployments. Today we need the /practice/ of interop efforts, but we do not need it in the formal process, as demonstrated by how few specs get to Draft in spite of becoming entirely successful community services.[1] I'll go along with this one. 3. The changes are likely to remove bits of community confusion about the IETF standards labels. Not entirely of course, because people are creative. But the proposed changes make a very clean distinction between the initial technical work and the later adoption/deployment/use work. This one is hysterically funny. To quote from draft-bradner-ietf-stds-trk-00 (paraphrasing newtrk). 4/ there seems to be a reinforcing feedback loop involved: vendors implement and deploy PS documents so the IESG tries to make the PS documents better This is the core issue, which far from addressing, the proposal tries to discard the feedback loop, stick its fingers in its ears, and sing la-la-la-I'm-not-listening. The fact remains that vendors treat PS maturity RFCs as standards. By reverting to the letter of RFC 2026, this will undoubtedly increase confusion - indeed, it's apparent that much of the deviation from RFC 2026 has been related to this very confusion. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducingthe Standards Track to Two Maturity Levels) to BCP
I oppose publication of this as an RFC. It is about politics, not about technical matters, and politics is the art of the possible. Even if this proposal succeeds in persuading (most of) the IETF to rethink the meaning of 'Proposed Standard', its impact on the rest of the world will be nil. The rest of the world will see more 'Proposed Standard's and will assume that they have been produced with the same care, consideration and review as in the past decade. Which will be a mistake. If you must have a new lightweight, 'back-to-the-2026' offering, then the name must make it clear that that is what it is and any use of the word 'Standard' for it would be wrong, regardless of the original intention of RFC2026. Rather it should be along the lines of 'Prototype Specification' or Experimental or Preliminary or ... Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Dave Cridland d...@cridland.net wrote: To quote from draft-bradner-ietf-stds-trk-00 (paraphrasing newtrk). 4/ there seems to be a reinforcing feedback loop involved: vendors implement and deploy PS documents so the IESG tries to make the PS documents better This is the core issue, which far from addressing, the proposal tries to discard the feedback loop, stick its fingers in its ears, and sing la-la-la-I'm-not-listening. Please excuse the hyperbole -- Dave's just trying to get our attention. The fact remains that vendors treat PS maturity RFCs as standards. By reverting to the letter of RFC 2026, this will undoubtedly increase confusion - indeed, it's apparent that much of the deviation from RFC 2026 has been related to this very confusion. Nothing we put in a rfc2026-bis will change this. Nothing we put in a rfc2026-bis _CAN_ change this. If we want to change this, we need to start putting warning-labels in the _individual_ RFCs that don't meet a ready for widespread deployment criterion. (I am speaking neither for nor against two-maturity-levels here: warning-labels need to happen if we expect to change implementors' expectations of PS RFCs.) -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Jari, and others, I support this draft with the caveat that we can establish a set of significant metrics that provide us an understanding as to the impact of the change. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On Fri May 6 11:44:48 2011, John Leslie wrote: Dave Cridland d...@cridland.net wrote: To quote from draft-bradner-ietf-stds-trk-00 (paraphrasing newtrk). 4/ there seems to be a reinforcing feedback loop involved: vendors implement and deploy PS documents so the IESG tries to make the PS documents better This is the core issue, which far from addressing, the proposal tries to discard the feedback loop, stick its fingers in its ears, and sing la-la-la-I'm-not-listening. Please excuse the hyperbole -- Dave's just trying to get our attention. I concede that the draft neither has fingers nor sings; the point remains valid however. The fact remains that vendors treat PS maturity RFCs as standards. By reverting to the letter of RFC 2026, this will undoubtedly increase confusion - indeed, it's apparent that much of the deviation from RFC 2026 has been related to this very confusion. Nothing we put in a rfc2026-bis will change this. Nothing we put in a rfc2026-bis _CAN_ change this. I'm in total agreement with this, which is why I'm so against a proposal which exacerbates the issue. If we want to change this, we need to start putting warning-labels in the _individual_ RFCs that don't meet a ready for widespread deployment criterion. I do not believe this will work, actually. In general, I think boilerplate warning messages get ignored - people quickly learn to expect and ignore them as routine - and I don't think we're likely to be able to construct unique and varying warning messages for every RFC we publish. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
As the sponsoring AD for Russ' draft, I'm very interested in hearing what everyone thinks about this. Please keep those comments coming! The last call was started as it was felt that discussion may have converged enough so that we could perhaps move forward with this proposal, or at least agree that its harmless and does not stand in the way of other improvements that some people may wish in addition. We'll see what the consensus will be. I can also see that some specific changes have already been discussed. Thanks for all those suggestions. But I also wanted to provide my own opinion. I would like to see the draft adopted. I personally do not believe that it will make a very significant change by itself; to a large extent the two (or even one) level model is already the running code. However, it does make the process a bit easier and it does allow us to get rid of at least some of the cruft from the IETF process. I think it is very important to simplify the process and align process documents with actual practice, as these will make it easier to describe, use, and evolve the IETF process. There are plenty of IETF process problems to address, even if this draft moves forward. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Dave Cridland d...@cridland.net wrote: On Fri May 6 11:44:48 2011, John Leslie wrote: If we want to change this, we need to start putting warning-labels in the _individual_ RFCs that don't meet a ready for widespread deployment criterion. I do not believe this will work, actually. It is at least a step which _might_ work... In general, I think boilerplate warning messages get ignored - people quickly learn to expect and ignore them as routine - It's not fair to compare this to government-warnings on cigarette packs. However, I agree that if warning-labels look like boilerplate, folks will ignore them. and I don't think we're likely to be able to construct unique and varying warning messages for every RFC we publish. I offer as evidence the quite-limited warning-labels that the IESG may put on RFCs that are not IETF series RFCs. These happen routinely and seem to be accomplishing their intent. And, if I may speculate, we might consider warning-labels that refer readers to status pages maintained by area teams to show progress on issues not (yet) resolved at the time of publication. There _are_ things worthy of trying here. -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On 5/6/2011 1:31 AM, Dave Cridland wrote: On Thu May 5 18:31:33 2011, Dave CROCKER wrote: 1) This document radically lowers the quality of Proposed Standards. What, specifically, are the parts of the proposal that you believe will lower the quality of a Proposed Standard? The parts unmentioned in the document, in effect. It states: ... The stated requirements for Proposed Standard are not changed; they remain exactly as specified in RFC 2026 [1]. ... RFC 2026 essentially defines a PS document as being a first cut, likely to change, and as such unsuitable for production deployment. In particular: You appear to be saying that the new document lowers quality by continuing to use the same basic criteria and qualifiers for Proposed that we've used for many years. Forgive me, but I do not understand how that logic works. How can the new process document lower quality by holding the established criteria for Proposed stable? It appears that your actual concern is not about the new document, but rather the existing process specification (RFC 2026). d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Fri, May 06, 2011 at 08:08:54AM -0700, Dave CROCKER wrote: The parts unmentioned in the document, in effect. ^^^ You appear to be saying that the new document lowers quality by continuing to use the same basic criteria and qualifiers for Proposed that we've used for many years. I think he is saying that there is are _de facto_ criteria that are neither called out in 2026 nor in this draft, and that those criteria are the running code, so the documentation ought to be made to match. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
Dave: the issue is that PS was previously not seen as a finished product, now it has much more exalted status, but the criteria have not changed. On May 6, 2011 11:09 AM, Dave CROCKER d...@dcrocker.net wrote: On 5/6/2011 1:31 AM, Dave Cridland wrote: On Thu May 5 18:31:33 2011, Dave CROCKER wrote: 1) This document radically lowers the quality of Proposed Standards. What, specifically, are the parts of the proposal that you believe will lower the quality of a Proposed Standard? The parts unmentioned in the document, in effect. It states: ... The stated requirements for Proposed Standard are not changed; they remain exactly as specified in RFC 2026 [1]. ... RFC 2026 essentially defines a PS document as being a first cut, likely to change, and as such unsuitable for production deployment. In particular: You appear to be saying that the new document lowers quality by continuing to use the same basic criteria and qualifiers for Proposed that we've used for many years. Forgive me, but I do not understand how that logic works. How can the new process document lower quality by holding the established criteria for Proposed stable? It appears that your actual concern is not about the new document, but rather the existing process specification (RFC 2026). d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
I am strongly opposed to this 2 document maturity level proposal. The real problem tha the IETF is regularly facing are constituencies that will fight hard against specifications getting updated, improved or fixed, once they have been published as RFC. Dave Cridland wrote: Dave CROCKER wrote: Dave Cridland wrote: 1) This document radically lowers the quality of Proposed Standards. What, specifically, are the parts of the proposal that you believe will lower the quality of a Proposed Standard? 2.1. The First Maturity Level: Proposed Standard The intention of the two-tier maturity ladder is to restore practice to the requirements for Proposed Standard from RFC 2026, and stop performing more scrutiny than intended in IETF working groups and the IESG. The proposal literally says stop performing more scurtiny than intended. The lower quality of the documents at Proposed is an explicit goal of this proposal. When this proposal is adopted, good quality for documents at Proposed is only going to happen by accident, but no longer by peer review and scrutiny. I believe that this proposal is based on a premise that is inverse to reality. The real causality is: - very few Working Groups go through the effort on fixing or improving documents once they're published as RFCs, which, for standards track documents usually means, they stay at proposed for years - the widespread adoption of protocols specifications on the internet happens based on specification that are at Proposed, if it happens at all. And the logical consequence of Working Groups not updating and fixing Proposed Document specification within a year after publication as RFC, in order to improve interoperability and the quality of the specification on which the software is based that runs the internet -- is to apply more thorough peer review and scrutiny at that point of the standardization process that can not be evaded by WG constituencies, before the adoption of the specification as Proposed Standard. I recently saw a proposal (by a WG chair) to adopt a new charter item following a list of 3 WG documents at or heading for PS: The WG will attempt to avoid gratuitous changes to these protocols. I do not believe that such a statement is motivated by the three maturity levels for documents, but rather caused by constituencies and emotional engagement by individuals with documents they authored or contributed to, that do not want specification to be updated, fixed or changed after these have been published as RFC. I don't think this reflects the current status quo in the slightest. I think our current PS maturity is essentially considered production quality, although we anticipate that clarifications in the specification may be required, and consultation with other implementors is likely to be beneficial. Some IETF participants do, some don't, which results in controversy. My understanding of the IETF standardization process, in particular with respect to specification at PS is updating a spec to improve interoperability is good, reducing complexity is good, i.e. making stuff optional that is hardly used or creates interop problems. And when there are several different extensibility options in a protocol, some of which with very high interop in the installed base and some of which with poor interop in the installed base, then redefining useful features to use the more interoperable extensibility is useful. However, there sometimes are constituencies in IETF WGs that take the position the PS spec MUST NOT be updated or changed, unless proven beyound all doubt, that the spec does not work at all. In particular, for better or worse, the wider internet technical community - ie, the people who are aware of, but not involved in, the IETF - expect our PS documents to have high quality, and would be caught unawares by a sudden shift back to this stance. +1 I assume that for every IETF spec implementer within the IETF, there are 10 or more implementors that do not participate the IETF. And it is for those others that we should produce, and update/improve our specifications, at least once in a while. So to make this clear, I think that as the requirements and scrutiny of PS documents have increased, the quality has as a result, and - undoubtedly more important - the expected quality has also. I am suprised that you don't see this as quite apparent. We have, in general, raised the bar over the years for PS documents, and - whether or not you think this was a good idea - this horse has left the station, and it's too late to put the lid back on - the wider world now expects this. +1 -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On 5/6/2011 9:15 AM, Martin Rex wrote: The real problem tha the IETF is regularly facing are constituencies that will fight hard against specifications getting updated, improved or fixed, once they have been published as RFC. That seems particularly true about possible changes to RFC 2026. It is, indeed, a problem... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On 5/6/2011 9:01 AM, Andrew Sullivan wrote: I think he is saying that there is are _de facto_ criteria that are neither called out in 2026 nor in this draft, and that those criteria are the running code, so the documentation ought to be made to match. Oh. But then that doesn't mean that the /current/ draft lowers quality but that the existing process has exhibited the lower. In that case, it seems like the concrete way to resolve such concerns is to propose specific text to add to the current draft? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Fri, May 06, 2011 at 09:27:16AM -0700, Dave CROCKER wrote: On 5/6/2011 9:01 AM, Andrew Sullivan wrote: I think he is saying that there is are _de facto_ criteria that are neither called out in 2026 nor in this draft, and that those criteria are the running code, so the documentation ought to be made to match. Oh. But then that doesn't mean that the /current/ draft lowers quality but that the existing process has exhibited the lower. No, it does not. RFC 2026 has a low bar of entry to get something published as PS. As a matter of fact, we don't do what's in 2026. Things published as PS are often quite mature. Since just about nothing moves past PS anyway, people regard it as the effective final level of standardization and therefore require high degrees of review before publication. And once something is published at PS, it is all but impossible to change it in any but the most trivial ways, because of all the contracts that refer to that RFC and require conformance. So in fact a document published as PS has met criteria more stringent than RFC 20206 would have one believe. The present draft explicitly says that the actual criteria as actually published in RFC 2026 are the right ones, and that additional unwritten conventions and so on are to be removed. Therefore, if one thinks those more stringent criteria make for higher quality, then the current draft will lower quality. I think we could state this all more neutrally by saying only that the existing actual criteria do not match the published criteria, and that therefore when the current draft says go back to RFC 2026 published criteria is is in fact changing the criteria. Then we don't have to have an argument about whether the quality is better, since I don't know how that would be measured anyway. But in any case, the document flat out admits that it is changing these criteria: Various influences have made publishing a Proposed Standard much harder than the stated requirements in RFC 2026. The intention of the two-tier maturity ladder is to restore practice to the requirements for Proposed Standard from RFC 2026, and stop performing more scrutiny than intended in IETF working groups and the IESG. So we should not pretend that the draft doesn't change criteria for PS. It just reiterates a position about what should happen. It remains to be seen what will actually happen. And again, I have no horse in this race. I don't believe the document will make any difference at all, but for that very reason I don't care whether it is adopted. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
--On Friday, May 06, 2011 18:15 +0200 Martin Rex m...@sap.com wrote: The real problem tha the IETF is regularly facing are constituencies that will fight hard against specifications getting updated, improved or fixed, once they have been published as RFC. Martin, That is an interesting observation/ claim. Because I don't think I've seen that happen, I'd appreciate some examples. I have seen: * Insistence that any updated version of a document address all known outstanding issues, including insistence that the revised document not move forward until specific changes for which there is no clear consensus be included. In other words, if there is community consensus for changes A and B to document X, but no consensus that change C is needed (or appropriate, or even correct) some people will try to block approval of an X-bis that incorporates only changes A and B until everyone agrees to C. That is a very difficult problem in any standards body. We have sometimes gotten around it by explicitly noting that issue C remains controversial, but rarely without some resistance. But the problem isn't resistance to updates and improvements, only controversy about whether the changes are sufficient. * Insistence by various groups, often (at least apparently) only the IESG, that any document being revised be altered to conform to multiple requirements for content or editorial style that are more recent than the original document and in spite a no evidence that that older style or organization was causing any problems. That clearly makes it more difficult to get an update with actual corrections, etc., issued than it might be. But I've not seen anything that I interpret as evidence of resistance to change or updates once an RFC is published, only procedural and editorial requirements for publication of updated documents that sometimes create barriers that seem unnecessary and inappropriate. * Certainly WGs and others tend to run out of energy once initial RFCs are published. If no one is willing to produce a new or updated draft and persuade others to review it, then revisions are not going to happen. But your comment implies active opposition to such revisions: no energy is not active opposition. Indeed, while I don't think it is justified in today's environment, IIR part of what caused the 2026 advance or die provision was the belief that, if no one cared enough about a given specification to advance it, maybe we didn't need it any more. As someone who has been responsible for several RFCs and who has worked on updates to a large subset of them, I've seen a lot of pushback asking for more, but little or no pushback for the idea of reviewing and revising specs. While I see those issues as significant, none of them have anything to do with this particular proposal: they apply equally regardless of how many steps there are in the Standards Track, apply to documents being recycled in grade, and even apply to non-standards-track materials. So you may be seeing things that I'm not (behaviors do differ between areas and even among protocol families within an area) but, if you are seeing active pushback on making revisions, I'd be interested in hearing specifics about that, what you would propose to do about it, and why this document is either helpful or unhelpful in that regard. regards, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Fri May 6 17:50:07 2011, Andrew Sullivan wrote: On Fri, May 06, 2011 at 09:27:16AM -0700, Dave CROCKER wrote: On 5/6/2011 9:01 AM, Andrew Sullivan wrote: I think he is saying that there is are _de facto_ criteria that are neither called out in 2026 nor in this draft, and that those criteria are the running code, so the documentation ought to be made to match. Oh. But then that doesn't mean that the /current/ draft lowers quality but that the existing process has exhibited the lower. No, it does not. RFC 2026 has a low bar of entry to get something published as PS. As a matter of fact, we don't do what's in 2026. Things published as PS are often quite mature. Since just about nothing moves past PS anyway, people regard it as the effective final level of standardization and therefore require high degrees of review before publication. And once something is published at PS, it is all but impossible to change it in any but the most trivial ways, because of all the contracts that refer to that RFC and require conformance. So in fact a document published as PS has met criteria more stringent than RFC 20206 would have one believe. The present draft explicitly says that the actual criteria as actually published in RFC 2026 are the right ones, and that additional unwritten conventions and so on are to be removed. Therefore, if one thinks those more stringent criteria make for higher quality, then the current draft will lower quality. I think we could state this all more neutrally by saying only that the existing actual criteria do not match the published criteria, and that therefore when the current draft says go back to RFC 2026 published criteria is is in fact changing the criteria. Then we don't have to have an argument about whether the quality is better, since I don't know how that would be measured anyway. But in any case, the document flat out admits that it is changing these criteria: Various influences have made publishing a Proposed Standard much harder than the stated requirements in RFC 2026. The intention of the two-tier maturity ladder is to restore practice to the requirements for Proposed Standard from RFC 2026, and stop performing more scrutiny than intended in IETF working groups and the IESG. So we should not pretend that the draft doesn't change criteria for PS. It just reiterates a position about what should happen. It remains to be seen what will actually happen. Thanks for explaining that; it is indeed what I'm trying to say. And again, I have no horse in this race. I don't believe the document will make any difference at all, but for that very reason I don't care whether it is adopted. I would rather not make the situation worse, especially without documentation which shows we have a real understanding of the de-facto standards process. Ideally, I'd rather we first - before any attempts are made to change the standards process - document what it *is*. Then, we should have a clearer understanding of the problems we're attempting to solve, and it should prove a lot less contentious. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
Martin, I think you may actually be arguing for a 1 step process. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
I think he is saying that there is are _de facto_ criteria that are neither called out in 2026 nor in this draft, and that those criteria are the running code, so the documentation ought to be made to match. This suggests that perhaps we should rename Proposed Standard to Not a Standard But Might Be One Later, promote the PS published under the overstrict rules to DS, and we're done. I'm not sure whether I'm serious or not. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Draft Secretariat SOW for Community Comment: Deadline 20 May
The IETF Administrative Oversight Committee (IAOC) plans to issue a Request for Proposal (RFP) in late May for a vendor to perform the Secretariat functions when the current contract ends on 31 January 2012. To that end the IAOC invites community comments on the draft Statement of Work (SOW) that is located at http://iaoc.ietf.org/rfpsrfis.html. The community comment period will run from 6 to 20 May 2011. The IAOC will consider all comments it receives during that period. The Secretariat provides various meeting, IT, clerical, finance and other services to Supporting Organizations, including Working Groups, Internet Engineering Steering Group (IESG), Internet Architecture Board (IAB), IETF Administrative Oversight Committee (IAOC), and the Internet Research Steering Group (IRSG). Changes in this proposed SOW from the current Secretariat SOW include, but aren't limited to: 1. Provision of IAB Administrative Services (IAB Executive Assistant) 2. Provision of NomCom Administrative Services (NomCom Executive Assistant) 3. Provision of RFC Publisher Services, which will replace the current separate contract, 4. Adding the RFC Series Editor (RSE), Independent Submissions Editor (ISE) and Nominating Committee (NomCom) to the list of Supported Organizations for which services may be provided in the future. 5. Production of minutes of the IETF Meeting Plenaries 6. Requirement to book meeting venues three years in advance, instead of two years, and 7. Requirement to cryptography sign Internet-Drafts Community comment is due no later than 20 May 2011 to secretariat-2...@ietf.org. One may subscribe to that list here: https://www.ietf.org/mailman/listinfo/secretariat-2012. All information submitted in response to this announcement is voluntary and may be used in the development of the SOW and a subsequent RFP. Thanks for your continuing advice and support. Ray Pelletier IETF Administrative Director Internet Society ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications
Hi Joe – Thank you for your thorough review and detailed response. Your feedback will be incorporated into a –04 update with other changes received in last call and from the IESG. (I'm still working through all of the changes though.) In any case, see my detailed responses inline below. I appreciate any suggested changes to the proposed new text of course. Regards Jason On 4/28/11 4:38 PM, Joe Touch to...@isi.edumailto:to...@isi.edu wrote: Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.orgmailto:tsv-...@ietf.org if you reply to or forward this review. The document describes the issues associated with the practice of whitelisting in DNS servers, in an attempt to limit which recursive resolvers receive responses to requests for (IPv6) records. The practice of whitelisting can have significant impact on transport protocols in the reachability of IPv6 endpoints. There are no transport issues of a more specific nature discussed or determined as part of this review. I do have some other concerns which are noted below, and which are offered for consideration. I hope this feedback will be useful to the authors, and will be glad to provide further assistance either on- or off-list as useful. Joe - Overall, this document is quite long and has many gratuitous digressions which could easily be omitted. It is unnecessarily verbose and lengthy for its topic. E.g., the architectural implications that stretch this issue into network heterogeneity are a bit of a stretch, and the discussion (and citation) for Newton's notion of momentum is unnecessary. [JL] Thanks for the general feedback. As for the inclusion of CPE homogeneity being encouraged (Section 7.4) as a result of whitelisting, I am attempting to highlight that on the one hand there is a natural trend towards greater heterogeneity while whitelisting policies may encourage an opposite trend back towards homogeneity. In part this is due to the fact that so may different types of CPE exist and these vary widely with respect to IPv6-related impairments and capabilities. But it seems that whitelisting approvals for domains may occur more readily for those networks with a greater level of control (or complete control) over endpoints, where less variation in those devices exists as a result of that control, since the network can then push out device fixes for IPv6 impairments and so on. This is a tension that I know I as an ISP feel – on the one hand it seems desirable to have greater control over and less variation of CPE in order to win approval to be added to whitelists, while on the other hand there is a great deal of pressure in the opposite direction to enable any IP-capable CPE to connect (often this is encompassed in various countries' open Internet or network neutrality guidelines). Blacklisting is noted in other environments in Sec 6, and noted as an alternative for the DNS issue in a cursory fashion in Sec 7.3.7. It should certainly be introduced and defined earlier, and included in the alternatives discussed in Sec 8. Blacklisting provides a useful alternative because it requires explicit action to inhibit, rather than requiring explicit action to avoid, and the tradeoff between blacklisting and whitelisting should be discussed in more detail. [JL] This is an excellent suggestion. I have acted on it in the following ways: 1 – Added this to Section 2, How DNS Whitelisting Works: At a high level, using a whitelist means no traffic is permitted to the destination host unless the originating host's IP address is contained in the whitelist. In contrast, using a blacklist means that all traffic is permitted to the destination host unless the originating host's IP address is contained in the blacklist. 2 – I have added a new section in the solutions/alternatives, 8.4 Implement DNS Blacklisting, with the following text: Some domains may wish to be more permissive than if they adopted DNS whitelisting [Section 8.2], but not still have some level of control over returning record responses [Section 8.3]. An alternative in this case may be to employ DNS blacklisting, which would enable all DNS recursive resolvers to receive record responses except for the relatively small number that are listed in the blacklist. This could enable an implementer to only prevent such responses where there has been a relatively high level of IPv6-related impairments, until such time as these impairments can be fixed or otherwise meaningfully reduced to an acceptable level.
Re: draft-housley-two-maturity-levels-06
This suggests that perhaps we should rename Proposed Standard to Not a Standard But Might Be One Later, promote the PS published under the overstrict rules to DS, and we're done. I'm not sure whether I'm serious or not. Whether you are or not.., the only way to do this is to stop calling them RFCs. Maybe we should have a PROP series for PS docs, and only give them RFC numbers later, when they progress. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
This suggests that perhaps we should rename Proposed Standard to Not a Standard But Might Be One Later, promote the PS published under the overstrict rules to DS, and we're done. I'm not sure whether I'm serious or not. Whether you are or not.., the only way to do this is to stop calling them RFCs. Maybe we should have a PROP series for PS docs, and only give them RFC numbers later, when they progress. Well, you know, the Not a Standard But Might Be One Later really are requesting comments. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Fri May 6 22:12:35 2011, Barry Leiba wrote: This suggests that perhaps we should rename Proposed Standard to Not a Standard But Might Be One Later, promote the PS published under the overstrict rules to DS, and we're done. I'm not sure whether I'm serious or not. Whether you are or not.., the only way to do this is to stop calling them RFCs. Maybe we should have a PROP series for PS docs, and only give them RFC numbers later, when they progress. This is not far off Scott Bradner's 2004 suggestion of Stable Snapshots of I-Ds. It's also like the (much more versatile) labelling proposal Keith Moore made here. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
John said... Well, you know, the Not a Standard But Might Be One Later really are requesting comments. Yes, well, we all know that RFC has lost any real sense of its expansion long ago. It certainly has done so in the eyes of most of the world, for whom RFC means Internet standard. Dave Cridland sid... It's also like the (much more versatile) labelling proposal Keith Moore made here. Perhaps, but Keith's labelling proposal is still not sufficient if we CALL them RFCs. The *only* way to make people not look at them as already standard is by NOT giving them RFC numbers. Now, I'm not sure that's what we should do. But I *am* sure it's the only way to do it. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On 5/6/2011 2:29 PM, John R. Levine wrote: Whether you are or not.., the only way to do this is to stop calling them RFCs. Maybe we should have a PROP series for PS docs, and only give them RFC numbers later, when they progress. Well, you know, the Not a Standard But Might Be One Later really are requesting comments. seems like that is rather cumbersome phrasing for a label. perhaps we can come up with a term that is shorter but implies a similar status with regard to now and later. hmmm. what about the word 'proposed'? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
On Fri May 6 22:37:20 2011, Barry Leiba wrote: John said... Well, you know, the Not a Standard But Might Be One Later really are requesting comments. Yes, well, we all know that RFC has lost any real sense of its expansion long ago. It certainly has done so in the eyes of most of the world, for whom RFC means Internet standard. Actually, for most of the world, it means Rugby Football Club. But yes, for the majority of folk who know about protocol specs, then RFC means Standard. Dave Cridland sid... It's also like the (much more versatile) labelling proposal Keith Moore made here. Perhaps, but Keith's labelling proposal is still not sufficient if we CALL them RFCs. The *only* way to make people not look at them as already standard is by NOT giving them RFC numbers. Right, which is why both Scott and Keith's proposals involve I-Ds, not RFCs. Now, I'm not sure that's what we should do. But I *am* sure it's the only way to do it. I think it represents the sanest approach proposed so far. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
Barry Leiba wrote: John said... Well, you know, the Not a Standard But Might Be One Later really are requesting comments. Yes, well, we all know that RFC has lost any real sense of its expansion long ago. It certainly has done so in the eyes of most of the world, for whom RFC means Internet standard. Correct. It really does not matter how *WE* call it, it is not going to affect in any way what the world does with it as long as it has the published status. In many areas 90% of the implementors are outside of the IETF. And if they get the task to implement and ship some protocol in a product -- they will check the RFC index for a document describing the protocol. And if there is exactly one version of a protocol (and ultimately just one RFC document describing it), then they going to use exactly that document for their implementation, indepent of what labelboilerplate the IETF has slapped on the front page. It really does not matter whether it reads Informational, Proposed Standard, Draft Standard or Standard. They need to implement it, there is just one document describing it, so really, what does this matter? And frankly, large parts of the internet run with protocols and specification that are Informational and Proposed, and a non-marginal part even runs on I-Ds. The large majority out there just doesn't care how many document maturity levels the IETF uses. And the folks that prefer more numerous and easier I-D - RFC transitions are likely the early adopters which are frequently shipping products based on I-Ds, and often the members of constituencies that would love to completely lock down a specification as soon as they ship a product based on it. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Ship it. We are way past the point of diminishing returns in polishing this. Regards Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-06
07.05.2011 0:29, John R. Levine wrote: This suggests that perhaps we should rename Proposed Standard to Not a Standard But Might Be One Later, promote the PS published under the overstrict rules to DS, and we're done. I'm not sure whether I'm serious or not. Whether you are or not.., the only way to do this is to stop calling them RFCs. Maybe we should have a PROP series for PS docs, and only give them RFC numbers later, when they progress. Well, you know, the Not a Standard But Might Be One Later really are requesting comments. Why invent something new? The Experimental category covers what you want to name Not a Standard But Might Be One Later; Experimental docs. are fine for permanent record of some protocol to encourage its experimental implementations to produce the Standards Track document of really high level (since it's based on received experience with this protocol). Some recent RFCs are good examples; see eg. http://tools.ietf.org/html/rfc6137#section-1.5 The other problem (if it is) is that implementators really don't care whether the Standards Track document is Proposed, Draft or Full; as mentioned before in this thread, everything named RFC is considered to be stable and OK for implementation (maybe, except Historic documents :-). And this can't be changed; this is established; this is implementator's mentality. Considering it, many WGs/folks who once wrote Proposed Standard see no sense to move it forward to Draft and Full. Considering this, even though it was planned by RFC 2026 in the other way, Proposed Standards are actually worth that scrutiny they are currently given (even though I personally can hardly agree with this statement). Mykyta Yevstifeyev Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Hello again, Now as for the document itself. I really appreciate its purpose; encouraging Proposed-Standards-writers to advance their document replacing 3-tier system to 2-tier one is a good idea. However, in fact, this proposal in its current view really can't work effectively because of: Any protocol or service that is currently at the abandoned Draft Standard maturity level will retain that classification, absent explicit actions. In this case, as Brian Carpenter said during discussions of previous versions of this document, unless we have a firm sunset date, the job will never be finished and in fifty years there will still be DS documents. (http://www.ietf.org/mail-archive/web/ietf/current/msg65870.html) Considered this, removal of the sunset period is probably harmful; as nobody cared about progressing their DSs (see my previous message), they will continue to do this. Two possible actions are available: (1) A Draft Standard may be reclassified as an Internet Standard as soon as the criteria inSection 2.2 http://tools.ietf.org/html/draft-housley-two-maturity-levels-06#section-2.2 are satisfied. This [ . . . ] (2) At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard. A reasonable question: whether such action won't be available after 2 years? Anyway, leaving the situation with DSs as is won't result in something useful. As proposed before, 2-year sunset period is OK; if nobody undertakes any steps to advance their DS to FS during these 2 years, such DS is reclassified to PS. Another issue is removing the requirement for implementation reports. This must really result in low quality of FSs. As Bernold Adoba mentioned before, Today it is quite common within WGs to see conflicting claims about protocol implementations and interoperability. IMHO one of the critical purposes served by implementation reports is to require proponents to produce the evidence backing their claims. The above paragraph left me wondering what the burden of proof would be in practice. For example, I would not want to see the IESG put in the position of adjudicating he said, she said arguments made during Last Call. I fully agree with the last sentence; implementation reports serve as some documentary justification of existing of implementations that suit all requirements of the spec. The following requirement for FSs seems unclear: * If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Maybe I'm misunderstanding smth., but this is not a requirement but rather just statement. This introduces new difficulties to advancing PSs to FSs; this hard-to-understand demand will mislead almost everybody, I think. Also, the minimum period for existing on Standards Track of 6 month is not really sufficient to fulfill the following requirement: * There are a significant number of implementations with successful operational experience. Some words on STD numbers as well. Their initial purpose was to provide clear reference point to FSs; RFC 1796 encouraged their use to distinguish Standards from other RFCs. However, the experience showed that they doesn't work (or work partly). The well-known problem is what to do with STD number when FSs is recycled to PS. Some recent proposals, such as written by John Klensin (http://tools.ietf.org/html/draft-klensin-std-numbers-01) proposed assignment of STD numbers to all Standards Track RFCs, including PSs. This, even solving aforementioned problem, decreases the usefulness of STD numbers; but now we are not speaking about that proposal. Russ' document leaves this question open; I think it shouldn't. I really think STD numbers should be abandoned; they just make a mess into the Standards Track. Another proposal should be to put some identifier of maturity level in the STD number, assigning one for all documents moving through the Standards Track system, ie. STD P-xx, STD D-xx and STD xx (for FSs), where xx is assigned to PSs only while all its successors retain it; but I don't think such proposal will ever be adopted. Removal of requirement for annual reviews of PSs is a good deed, since nobody really suited to it after NEWTRK WG effort, except rare cases. There are also some minor defects in this draft, concerning Section 4 mostly; I don't want to mention them now. So, taking everything into account, I wouldn't like to see this document approved as BCP. Having a good idea, its realization isn't as good. Mykyta Yevstifeyev 05.05.2011 19:13, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels'
Document Action: 'A Survey of Lower-than-Best-Effort Transport Protocols' to Informational RFC (draft-ietf-ledbat-survey-07.txt)
The IESG has approved the following document: - 'A Survey of Lower-than-Best-Effort Transport Protocols' (draft-ietf-ledbat-survey-07.txt) as an Informational RFC This document is the product of the Low Extra Delay Background Transport Working Group. The IESG contact person is Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ledbat-survey/ Technical Summary This document provides a survey of transport protocols which are designed to have a smaller bandwidth and/or delay impact on standard TCP than standard TCP itself when they share a bottleneck with it. Such protocols could be used for delay-insensitive background traffic, as they provide what is sometimes called a less than (or lower than) best-effort service. Working Group Summary This document is a product of the LEDBAT WG. It has received reviews from various WG participants. There were no controversies in the Last Call of the document and the WG feels the document is ready for publication. Document Quality The algorithm that triggered this survey, which is still being worked on but nears completion, is implemented by BitTorrent Inc. Special thanks to Mirja Kühlewind, Wesley Eddy and Mayutan Arumaithurai for their thorough reviews of the document. Personnel Rolf Winter (rolf.win...@neclab.eu) is the Document Shepherd. Lars Eggert (lars.egg...@nokia.com) reviewed the document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pwe3-fat-pw-06.txt (Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network) to Proposed Standard
The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network' draft-ietf-pwe3-fat-pw-06.txt as a 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 i...@ietf.org mailing lists by 2011-05-20. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/ No IPR declarations have been submitted directly on this I-D. Abstract Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on MPLS label stacks and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Draft Secretariat SOW for Community Comment: Deadline 20 May
The IETF Administrative Oversight Committee (IAOC) plans to issue a Request for Proposal (RFP) in late May for a vendor to perform the Secretariat functions when the current contract ends on 31 January 2012. To that end the IAOC invites community comments on the draft Statement of Work (SOW) that is located at http://iaoc.ietf.org/rfpsrfis.html. The community comment period will run from 6 to 20 May 2011. The IAOC will consider all comments it receives during that period. The Secretariat provides various meeting, IT, clerical, finance and other services to Supporting Organizations, including Working Groups, Internet Engineering Steering Group (IESG), Internet Architecture Board (IAB), IETF Administrative Oversight Committee (IAOC), and the Internet Research Steering Group (IRSG). Changes in this proposed SOW from the current Secretariat SOW include, but aren't limited to: 1. Provision of IAB Administrative Services (IAB Executive Assistant) 2. Provision of NomCom Administrative Services (NomCom Executive Assistant) 3. Provision of RFC Publisher Services, which will replace the current separate contract, 4. Adding the RFC Series Editor (RSE), Independent Submissions Editor (ISE) and Nominating Committee (NomCom) to the list of Supported Organizations for which services may be provided in the future. 5. Production of minutes of the IETF Meeting Plenaries 6. Requirement to book meeting venues three years in advance, instead of two years, and 7. Requirement to cryptography sign Internet-Drafts Community comment is due no later than 20 May 2011 to secretariat-2...@ietf.org. One may subscribe to that list here: https://www.ietf.org/mailman/listinfo/secretariat-2012. All information submitted in response to this announcement is voluntary and may be used in the development of the SOW and a subsequent RFP. Thanks for your continuing advice and support. Ray Pelletier IETF Administrative Director Internet Society ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6190 on RTP Payload Format for Scalable Video Coding
A new Request for Comments is now available in online RFC libraries. RFC 6190 Title: RTP Payload Format for Scalable Video Coding Author: S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis Status: Standards Track Stream: IETF Date: May 2011 Mailbox:st...@stewe.org, yekui.w...@huawei.com, t...@thomas-schierl.de, a...@vidyo.com Pages: 100 Characters: 250504 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-avt-rtp-svc-27.txt URL:http://www.rfc-editor.org/rfc/rfc6190.txt This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name H264-SVC, but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name (H264) and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Payloads Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6226 on PIM Group-to-Rendezvous-Point Mapping
A new Request for Comments is now available in online RFC libraries. RFC 6226 Title: PIM Group-to-Rendezvous-Point Mapping Author: B. Joshi, A. Kessler, D. McWalter Status: Standards Track Stream: IETF Date: May 2011 Mailbox:bharat_jo...@infosys.com, kess...@cisco.com, da...@mcwalter.eu Pages: 11 Characters: 24092 Updates:RFC4601 I-D Tag:draft-ietf-pim-group-rp-mapping-10.txt URL:http://www.rfc-editor.org/rfc/rfc6226.txt Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in a PIM domain that supports Any Source Multicast (ASM) maintains Group-to-RP mappings that are used to identify a Rendezvous Point (RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned. This document defines a standard algorithm to deterministically choose between several Group-to-RP mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. [STANDARDS-TRACK] This document is a product of the Protocol Independent Multicast Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6227 on Design Goals for Scalable Internet Routing
A new Request for Comments is now available in online RFC libraries. RFC 6227 Title: Design Goals for Scalable Internet Routing Author: T. Li, Ed. Status: Informational Stream: IRTF Date: May 2011 Mailbox:t...@cisco.com Pages: 8 Characters: 18418 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-rrg-design-goals-06.txt URL:http://www.rfc-editor.org/rfc/rfc6227.txt It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi-homing, and inter-domain traffic engineering. The Routing Research Group is investigating an alternate architecture to meet these challenges. This document consists of a prioritized list of design goals for the target architecture. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IRTF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6228 on Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog
A new Request for Comments is now available in online RFC libraries. RFC 6228 Title: Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog Author: C. Holmberg Status: Standards Track Stream: IETF Date: May 2011 Mailbox:christer.holmb...@ericsson.com Pages: 14 Characters: 34311 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sipcore-199-06.txt URL:http://www.rfc-editor.org/rfc/rfc6228.txt This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. [STANDARDS-TRACK] This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6234 on US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)
A new Request for Comments is now available in online RFC libraries. RFC 6234 Title: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) Author: D. Eastlake 3rd, T. Hansen Status: Informational Stream: IETF Date: May 2011 Mailbox:d3e...@gmail.com, tony+...@maillennium.att.com Pages: 127 Characters: 236573 Obsoletes: RFC4634 Updates:RFC3174 I-D Tag:draft-eastlake-sha2b-07.txt URL:http://www.rfc-editor.org/rfc/rfc6234.txt Federal Information Processing Standard, FIPS INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6237 on IMAP4 Multimailbox SEARCH Extension
A new Request for Comments is now available in online RFC libraries. RFC 6237 Title: IMAP4 Multimailbox SEARCH Extension Author: B. Leiba, A. Melnikov Status: Experimental Stream: IETF Date: May 2011 Mailbox:barryle...@computer.org, alexey.melni...@isode.com Pages: 10 Characters: 21234 Updates:RFC4466 I-D Tag:draft-ietf-morg-multimailbox-search-07.txt URL:http://www.rfc-editor.org/rfc/rfc6237.txt The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466. This document defines an Experimental Protocol for the Internet community. This document is a product of the Message Organization Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce