Subject: Re: FW: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 26 Jan 2013 17:16:16 +0100

I agree with your concerns and may suggest that the tests' results of
the running code SHOULD be reported inside a mandatory section of the
Fast-Tracked I-D to RFC.

AB

On 01/26/2013 Martin Rex wrote:
>Stephen Farrell wrote:
>
>> 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:

Uh-oh!

>
> - 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.

If I hadn't stumbled upon the TLS renegotiation issue while
discussing the proposal for TLS channel bindings, then
the "solution" would have been developed and shipped
under NDA and entirely with involvement of the IETF TLS WG
(just some selected TLS WG members), and likely there would
have been a request for rubber stamping the (half-baked) solution
*AFTER* deploymend of the fixes by major vendors.

  http://www.ietf.org/mail-archive/web/tls/current/msg03928.html
  http://www.ietf.org/mail-archive/web/tls/current/msg03942.html

Myself, I'm worried by the idea of shortcutting review and marginalization
of comments that do not meet the discuss criteria.

>
> - 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.)

Admittedly, I deserve part of the blame for the heated discussion.

But if occasional heated discussions turn out to be a serious problem
for creating or improving technical solutions, then we may need more
procedural safeguards (such as independent leadership), not less.

The true essence of most of the 2009 TLS WG discussion was actually
fairly small and simple:

  http://www.ietf.org/mail-archive/web/tls/current/msg05365.html

-Martin

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jan 2013 11:55:17 +0100

I agree with your approach. However, if it should be tested by
community and reported successful then why we need to go through 5
years, just publish fast ways,

AB

++++++++++++
Sun, 27 Jan 2013 20:27:17 -0800
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