Re: The notion of "fast tracking" drafts
Hiya, On 12/16/2012 10:27 PM, Keith Moore wrote: > On 12/16/2012 04:49 PM, Stephen Farrell wrote: >> ISTM that you are of the opinion that anything the IETF >> does to go faster is bad in and of itself because its >> scary. > It's not that simple, at least in my opinion. > > I'm generally fine with fast tracking a document that describes a simple > protocol that is easily understood, easily implemented, > noncontroversial, and has a limited impact. In all other cases, I think > that more deliberation is appropriate. That's not to say that IETF > currently makes good use of deliberation time. But I'd rather see it > make better use of that time, than to try to reduce that time without > first improving protocol and document quality. For example, I'd like to > see earlier and more explicit cross-area review. All reasonable stuff and the draft says that this won't be suitable for all cases. If you've better wording to suggest that'd be welcome. Cheers, S. > > Keith > > >
Re: The notion of "fast tracking" drafts
On 12/16/2012 04:49 PM, Stephen Farrell wrote: ISTM that you are of the opinion that anything the IETF does to go faster is bad in and of itself because its scary. It's not that simple, at least in my opinion. I'm generally fine with fast tracking a document that describes a simple protocol that is easily understood, easily implemented, noncontroversial, and has a limited impact. In all other cases, I think that more deliberation is appropriate. That's not to say that IETF currently makes good use of deliberation time. But I'd rather see it make better use of that time, than to try to reduce that time without first improving protocol and document quality. For example, I'd like to see earlier and more explicit cross-area review. Keith
Re: The notion of "fast tracking" drafts
John, Keith, I really have to say that you both seem to be talking about things that have nothing whatsoever to do with my proposal. ISTM that you are of the opinion that anything the IETF does to go faster is bad in and of itself because its scary. This also seems to me to be an example of the kind of process discussion wandering onto everyone's favourite hobby horse that I mentioned before. So I don't see any change to the draft is required, but if you do have a direct comment on the draft, that'd be welcome and I'd be very happy to get such comments. Or perhaps I'm missing something that is relevant to my draft, but if so, I don't see it, so you need to bring your concerns down to issues with the draft if you are making a specific comment rather than being generally worried. Cheers, S. On 12/16/2012 08:49 PM, John C Klensin wrote: > > > --On Sunday, December 16, 2012 15:08 -0500 Keith Moore > wrote: > >> to this I'd add >> >> (5) Widespread, examined belief that the specification has >> minimal impact on the Internet architecture. >> >> I keep seeing IETF standardize protocols that seem likely to >> have seriously damaging architectural impact without much, if >> any, examination of that impact (the PCP and MIF work come >> most immediately to mind, but I could cite several others >> given a few minutes to think about it). I'd hate to see a >> fast-tracking procedure used as a way to further circumvent >> such examination. > > I think I would have said "impact on the Internet architecture > is well-understood and judged to be acceptable" instead, but we > agree about the general principle. > >john > > >
Re: The notion of "fast tracking" drafts
--On Sunday, December 16, 2012 15:08 -0500 Keith Moore wrote: > to this I'd add > > (5) Widespread, examined belief that the specification has > minimal impact on the Internet architecture. > > I keep seeing IETF standardize protocols that seem likely to > have seriously damaging architectural impact without much, if > any, examination of that impact (the PCP and MIF work come > most immediately to mind, but I could cite several others > given a few minutes to think about it). I'd hate to see a > fast-tracking procedure used as a way to further circumvent > such examination. I think I would have said "impact on the Internet architecture is well-understood and judged to be acceptable" instead, but we agree about the general principle. john
Re: The notion of "fast tracking" drafts
On 12/14/2012 06:09 PM, John C Klensin wrote: I've been trying to say out of this because I think most of the suggestions are better carried out by AD-encouraged experiments and reports to the rest of us on effectiveness rather than by long discussions in the community about details and the costs of an unnecessary consensus process. However, since I gather we are pushing (or being pushed) down this path, let me suggest that approval of an IETF spec, especially a standards-track one, has (or should have) elements of all of the following: (1) A conviction that the idea is implementable and that the ideas expressed are consistent with implementation (and, ideally, operational realities. (2) Specification of sufficient quality to make independently-developed interoperable implementations by people who were not part of the WG or development process possible and specifically that there are no ambiguities that could adversely affect interoperable implementations. This includes, but is not limited to, editorial quality in terms of good technical English, but does not include "good idea" criteria (see (4)). (3) "No known technical defects" in the spec (the RFC 2026 requirement). Note that, while an implementation might turn up technical defects that might otherwise be unknown, it might easily not turn up ones that could be identified in other ways. It should imply a fairly comprehensive review that would have a high likelihood of turning up any technical defects that are present, but we all know that sometimes doesn't happen. (4) Some level of IETF consensus that publishing the specification has value for the community. This might or might not include a community belief that the document specifies a good idea that should be implemented and deployed (the latter is why we have Applicability Statements). to this I'd add (5) Widespread, examined belief that the specification has minimal impact on the Internet architecture. I keep seeing IETF standardize protocols that seem likely to have seriously damaging architectural impact without much, if any, examination of that impact (the PCP and MIF work come most immediately to mind, but I could cite several others given a few minutes to think about it). I'd hate to see a fast-tracking procedure used as a way to further circumvent such examination. Keith
Re: The notion of "fast tracking" drafts
Hiya, On 12/14/2012 11:09 PM, John C Klensin wrote: > Hi. > > I've been trying to say out of this because I think most of the > suggestions are better carried out by AD-encouraged experiments > and reports to the rest of us on effectiveness rather than by > long discussions in the community about details and the costs of > an unnecessary consensus process. That's a defensible opinion that I don't share. I'd say s/most/many/ above would be better, but also think that we ought try break this logjam where everything that touches on process has to involve a gigantic debate with all the usual suspects. (I don't foresee success in breaking that logjam, but do think we ought not let it prevent us trying things.) I also think that since my proposal has a corner case where a WG chair gets to put a draft on the IESG telechat agenda that that ought only be done after some form of IETF LC. > However, since I gather we are pushing (or being pushed) down > this path, let me suggest that approval of an IETF spec, > especially a standards-track one, has (or should have) elements > of all of the following: Luckily my draft says that: "All other criteria for Proposed Standard or Experimental need to be met as usual." So I've no idea how the text below is relevant. Cheers, S. > > (1) A conviction that the idea is implementable and that the > ideas expressed are consistent with implementation (and, > ideally, operational realities. > > (2) Specification of sufficient quality to make > independently-developed interoperable implementations by people > who were not part of the WG or development process possible and > specifically that there are no ambiguities that could adversely > affect interoperable implementations. This includes, but is not > limited to, editorial quality in terms of good technical > English, but does not include "good idea" criteria (see (4)). > > (3) "No known technical defects" in the spec (the RFC 2026 > requirement). Note that, while an implementation might turn up > technical defects that might otherwise be unknown, it might > easily not turn up ones that could be identified in other ways. > It should imply a fairly comprehensive review that would have a > high likelihood of turning up any technical defects that are > present, but we all know that sometimes doesn't happen. > > (4) Some level of IETF consensus that publishing the > specification has value for the community. This might or might > not include a community belief that the document specifies a > good idea that should be implemented and deployed (the latter is > why we have Applicability Statements). > > While I hope the above is obvious, the four categories are > nearly orthogonal. One can have a good specification and a > worthwhile idea without an implementation, an implementation of > a bad idea and a lousy specification, and so on. I believe... > > (i) It is a bad idea, and could be a real disservice to the > community, to say that meeting a high standard on any one of > those dimensions should allow some of the others to be dealt > with in a perfunctory fashion. That is exactly what a "fast > track" idea seems to be about and much of the debate seem to be > about how high a standard is relevant. > > (ii) If it were really acceptable to decide that an > implementation (i.e., a limited demonstration of the first > criterion) justifies a "fast track", then demonstrations of the > others should to. For example, if a WG could demonstrate that > the specification had been carefully and professionally > technically edited, perhaps that should justify "fast track" > treatment. If there is already wide and successful deployment > of what is supposedly the specification, leaving aside the > question of whether those deployments and the specification > actually match, perhaps that should justify "fast track" > treatment. If the review of the specification in a WG had been > particularly intense, including careful looks by many diverse > parties, perhaps that should justify "fast track" treatment. > > I'm not certain what makes having an implementation more special > than any of these other categories and, to the extent to which > "fast track" means "less review" or a "higher bar to comments", > the idea makes me really, really, nervous, especially if the > requirement is not for a production-quality implementation that > has been tested both for interoperability and through deployment > to users. > >john > >
The notion of "fast tracking" drafts (was: Re: Running code, take 2)
Hi. I've been trying to say out of this because I think most of the suggestions are better carried out by AD-encouraged experiments and reports to the rest of us on effectiveness rather than by long discussions in the community about details and the costs of an unnecessary consensus process. However, since I gather we are pushing (or being pushed) down this path, let me suggest that approval of an IETF spec, especially a standards-track one, has (or should have) elements of all of the following: (1) A conviction that the idea is implementable and that the ideas expressed are consistent with implementation (and, ideally, operational realities. (2) Specification of sufficient quality to make independently-developed interoperable implementations by people who were not part of the WG or development process possible and specifically that there are no ambiguities that could adversely affect interoperable implementations. This includes, but is not limited to, editorial quality in terms of good technical English, but does not include "good idea" criteria (see (4)). (3) "No known technical defects" in the spec (the RFC 2026 requirement). Note that, while an implementation might turn up technical defects that might otherwise be unknown, it might easily not turn up ones that could be identified in other ways. It should imply a fairly comprehensive review that would have a high likelihood of turning up any technical defects that are present, but we all know that sometimes doesn't happen. (4) Some level of IETF consensus that publishing the specification has value for the community. This might or might not include a community belief that the document specifies a good idea that should be implemented and deployed (the latter is why we have Applicability Statements). While I hope the above is obvious, the four categories are nearly orthogonal. One can have a good specification and a worthwhile idea without an implementation, an implementation of a bad idea and a lousy specification, and so on. I believe... (i) It is a bad idea, and could be a real disservice to the community, to say that meeting a high standard on any one of those dimensions should allow some of the others to be dealt with in a perfunctory fashion. That is exactly what a "fast track" idea seems to be about and much of the debate seem to be about how high a standard is relevant. (ii) If it were really acceptable to decide that an implementation (i.e., a limited demonstration of the first criterion) justifies a "fast track", then demonstrations of the others should to. For example, if a WG could demonstrate that the specification had been carefully and professionally technically edited, perhaps that should justify "fast track" treatment. If there is already wide and successful deployment of what is supposedly the specification, leaving aside the question of whether those deployments and the specification actually match, perhaps that should justify "fast track" treatment. If the review of the specification in a WG had been particularly intense, including careful looks by many diverse parties, perhaps that should justify "fast track" treatment. I'm not certain what makes having an implementation more special than any of these other categories and, to the extent to which "fast track" means "less review" or a "higher bar to comments", the idea makes me really, really, nervous, especially if the requirement is not for a production-quality implementation that has been tested both for interoperability and through deployment to users. john
