I have two concerns and comments:
- How will success or failure be measured? Number of appeal increases
or lesser amount? I have a concern that once this door is open, there
will be increase appeals and also apathy of outcomes. There should be
a statement of what sort of problems or issues are possible and
envisioned and the plans to deal with them or not.
- The drafts indicates that fast tracking probably applies better
towards BIS work. I cited concerns that this ideas should only be used
for new work, not BIS work where there is already established
implementators and working code. I prefer to work in "No Surprises"
environment where it doesn't require me to pay attention to all
protocol change work to make sure nothing fell thru the crack or some
group of vendors with their questionable "code" implementation
different from the norm being mandated in new BIS work.
I only see this RFC being used to negate voiced concerns in the name
of fast tracking, not win people over if they already have a problem
with the work, especially if its BIS WORK. But then again, maybe that
is the intent.
I believe the experiment should only be applied first to new protocol
work, not BIS work and if so, iff there are absolutely no question of
possible conflict of interest, rush to judgment and no new code change
impacts. Existing protocol implementers should not be put into a
position, and worst within a shorter time period, to argue or just
review what BIS changes made entail and force them into appeal actions.
Perhaps the experiment can be done in two phases. I believe there is
good in fast tracking new ideas and methods, especially if simple and
one that most people seem to agree with with little concerns. Many
vendors have much to contribute in this area. So the first phase can
explore only with fast tracking new concepts. If this works out well
using some measuring tool, then BIS work can be better explored for
fast tracking by gaining some insights from the first phase.
--
HLS
Adrian Farrel wrote:
Hi Alexa,
Please be aware of this document that has just entered a four-week IETF last
call. The document describes a proposed IETF process experiment under the rules
of RFC 3933.
The proposed experiment calls on the IETF Secretariat to take specific actions
under certain circumstances in corner cases of the experiment. Could you please
have someone in the Secretariat look at the draft and comment on the
practicalities of the actions. Note that, at this stage, no changes to the tools
are proposed so any actions would require manual intervention (if the experiment
were successful and resulted in permanent changes to IETF process we might make
changes to the tools at some future time).
Thanks,
Adrian
-----Original Message-----
From: ietf-announce-bounces@xxxxxxxx [mailto:ietf-announce-
bounces@xxxxxxxx] On Behalf Of The IESG
Sent: 11 January 2013 15:15
To: IETF-Announce
Subject: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with
Running
Code) to Experimental RFC
The IESG has received a request from an individual submitter to consider
the following document:
- 'A Fast-Track way to RFC with Running Code'
<draft-farrell-ft-03.txt> as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2013-02-08. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This memo describes an optional, fast-track way to progress a working
group document to IESG review. It is provided as a process
experiment as defined in RFC 3933 for use when working group chairs
believe that there is running code that implements a working group
Internet-Draft. The motivation is to have the IETF process
explicitly consider running code, consistent with the IETF's overall
philosophy of running code and rough consensus.
In this process all of working group last call, IETF last call, and
Area Director review are carried out in the same two week period.
Only comments that meet IESG Discuss criteria need to be addressed
during this stage, and authors are required to make any changes
within two weeks.
This experiment will run for one year.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-farrell-ft/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-farrell-ft/ballot/
No IPR declarations have been submitted directly on this I-D.
--
HLS