Hi Hector, On 01/14/2013 05:05 PM, Hector Santos wrote: > 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. RFC 3933 describes that I guess. Basically, if the IESG consider it a success then they could make the RFC into a BCP or more likely find a victim to write an I-D for that. That'd go through the usual process. I don't think this'll have any impact on appeals (hope not anyway), and for me the main metric of success will be whether or not it gets used, and if used, if the people involved in those drafts think its worth making permanent or not. > > - The drafts indicates that fast tracking probably applies better > towards BIS work. Not really. Its says that -bis RFCs might be suitable. > 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 don't get the concern. > 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. Ah, you're worried some WG will shoot out a -bis draft this way and that existing implementers will miss that because of the shorter timescale and no longer be "compliant" with the latest RFC? Is that it? To be honest, I can't really see that this'll have any impact there. If the existing coder who'd be caught out isn't aware that a WG is doing stuff then this will make no difference. If they are aware that the WG is doing a -bis, then they can comment as always before and during IETF LC. I really can't see this experiment causing any real surprise in cases like that. S. > > -- > 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. >> >> >> >