Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way toRFC with Running Code) to Experimental RFC
- Original Message - From: Stephen Farrell stephen.farr...@cs.tcd.ie To: m...@sap.com Cc: John C Klensin john-i...@jck.com; Thomas Narten nar...@us.ibm.com; ietf@ietf.org; adr...@olddog.co.uk Sent: Friday, January 25, 2013 10:47 PM Hi Martin, On 01/25/2013 09:36 PM, Martin Rex wrote: I don't know about the last time it happened, but I know about one time in Nov-2009 in the TLS WG (now rfc5746). I recall that and agree with the sequence of events you describe, but I'm not sure that that situation is relevant when considering this draft, for two reasons: Sounds a bit like 'don't confuse me with the facts, my mind is made up:-)' The point that Thomas made and John endorsed is that when we want to speed things up, our current procedures allow us to do just that. We do not need a formal process (more complications, more work). And as John pointed out, having two independent Last Call discussions, on two different lists, on communities that may have little overlap, is not the way, IMO, to establish a clear consensus. Tom Petch - First, that was the IETF in security-incident-handling mode, and that's just different from normal process for us, whether fast-tracked or not. Its in the nature of things that the vast majority of security incidents don't directly affect IETF protocols so as to require a backwards incompatible change. So I think that was a highly unusual case. (And let's hope things stay that way.) - Second, there was significant controversy within the WG before the last calls, (with many hundreds of mails;-) so a set of WG chairs that chose to try a fast-track experiment in such circumstances would be crazy basically. (Remember, we're only talking about an experiment here.) As for Eliot's question, I don't recall any case when a WG skipped WGLC. Even if its not part of 2026, right now it's a de-facto but mandatory part of the process as far as I can see. I'd be interested if there are cases where WGLC was skipped, esp. if its been regularly done. S.
Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way toRFC with Running Code) to Experimental RFC
On 01/27/2013 11:19 AM, t.p. wrote: - Original Message - From: Stephen Farrell stephen.farr...@cs.tcd.ie To: m...@sap.com Cc: John C Klensin john-i...@jck.com; Thomas Narten nar...@us.ibm.com; ietf@ietf.org; adr...@olddog.co.uk Sent: Friday, January 25, 2013 10:47 PM Hi Martin, On 01/25/2013 09:36 PM, Martin Rex wrote: I don't know about the last time it happened, but I know about one time in Nov-2009 in the TLS WG (now rfc5746). I recall that and agree with the sequence of events you describe, but I'm not sure that that situation is relevant when considering this draft, for two reasons: Sounds a bit like 'don't confuse me with the facts, my mind is made up:-)' Absolutely not. Handling the TLS renegotiation bug was just not the kind of thing that's relevant for this experiment. It'd have been entirely dumb, stupid and crazy to try use any kind of process experiment to handle that situation. *After* this experiment is run, and if it turns up something that we might want to make part of the normal formal process then perhaps we might want to think about whether security incident handling could be done that way or not. (I'd think maybe not.) That'd happen in a year or so at the end of the experiment if the experiment seems to have gone well. But, that's not relevant now. This IETF LC is about whether or not to run a process experiment for a limited time that's optional to use at the discretion of WG chairs. This IETF LC is not about whether this or any proposal ought be part of our formal, long-term process. The point that Thomas made and John endorsed is that when we want to speed things up, our current procedures allow us to do just that. We do not need a formal process (more complications, more work). And as John pointed out, having two independent Last Call discussions, on two different lists, on communities that may have little overlap, is not the way, IMO, to establish a clear consensus. John's point about the two discussions in parallel was well made and already acknowledged as such. S. Tom Petch - First, that was the IETF in security-incident-handling mode, and that's just different from normal process for us, whether fast-tracked or not. Its in the nature of things that the vast majority of security incidents don't directly affect IETF protocols so as to require a backwards incompatible change. So I think that was a highly unusual case. (And let's hope things stay that way.) - Second, there was significant controversy within the WG before the last calls, (with many hundreds of mails;-) so a set of WG chairs that chose to try a fast-track experiment in such circumstances would be crazy basically. (Remember, we're only talking about an experiment here.) As for Eliot's question, I don't recall any case when a WG skipped WGLC. Even if its not part of 2026, right now it's a de-facto but mandatory part of the process as far as I can see. I'd be interested if there are cases where WGLC was skipped, esp. if its been regularly done. S.
IPv6 update for BCP5?
So... we probably need a IPv6 update for BCP5 (RFC1918), doesnt that make sense? Todd -- Regards TSG Ex-Cruce-Leo //Confidential Mailing - Please destroy this if you are not the intended recipient.
Re: IPv6 update for BCP5?
On 1/27/13 10:07 AM, tglassey wrote: So... we probably need a IPv6 update for BCP5 (RFC1918), doesnt that make sense? My understanding is people have been using ULAs (RFC 4193) for this type of functionality. Todd
Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way toRFC with Running Code) to Experimental RFC
On 1/27/13 12:19 PM, t.p. wrote: The point that Thomas made and John endorsed is that when we want to speed things up, our current procedures allow us to do just that. We do not need a formal process (more complications, more work). And as John pointed out, having two independent Last Call discussions, on two different lists, on communities that may have little overlap, is not the way, IMO, to establish a clear consensus. If we don't need a formal process, then I'd like it clarified in WG training that this procedure already exists. Furthermore, I don't buy the notion about confusion. In the cases where this is likely to be done, either an emergency exists (which was the case with TLS, IMHO), or the draft is likely not to elicit much in the way of objection. This DOES happen. But that having been said, if both a WG chair and an AD make a bad call, there are numerous opportunities to correct it in this process, the NOMCOM process, appeal, etc. Eliot
Re: IPv6 update for BCP5?
On 1/27/13 10:07 AM, tglassey wrote: So... we probably need a IPv6 update for BCP5 (RFC1918), doesnt that make sense? My understanding is people have been using ULAs (RFC 4193) for this type of functionality. That's certainly one option. The other is just to apply for some IPv6 address space from your local RIR. There's plenty of it, they don't care if you don't plan to make it routable outside your own network. It is definitely NOT a goal of IPv6 to create hacks to permit two different interfaces to have the same IP address, anywhere.
Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFCwith Running Code) to Experimental RFC
About the idea of an experiment: On 1/25/2013 5:07 AM, Stephen Farrell wrote: Responses to some points below but I'd really like to ask people to consider a few things here: - what's proposed is an experiment, it'd likely get tried out a few times and won't consume any huge resource anywhere If this is an experiment, then you presumably answers to the following questions: 1- what is your an hypothesis? 2- what you intend to measure? 3- what is your 'control' against which to compare the results? 4- what is your objective metric for success/failure? I've heard only one hypothesis - that this reduces time to publication. I disagree that this is a useful hypothesis to test for the following reasons: - time to publication isn't a goal of the IETF IMO, any doc that isn't useful in 5 years ought to not be published here; we don't need to document every sneeze - thorough review ought to be a requirement and this 'experiment' potentially compromises that by reducing the overall time of review - community resources ought to be considered and this 'experiment' burns group resources due to having a broad group concurrently review a doc that could have been reviewed by smaller groups first Given the limited cycles this community has to review docs, I cannot see a benefit to this experiment that is worth the cost. Having this entire community burn cycles on this document speaks for itself. It should have been vetted in a smaller, more invested community first. Calling something an 'experiment' doesn't make it worthwhile to test. Joe
