Full agreement with Stephan. Lars On Jan 11, 2013, at 22:02, Stephan Wenger <stewe@xxxxxxxxx> wrote: > Hi, > > Sorry for replying to this "advise to secretariat" thread and not to the > ietf-announce thread--I'm not subscribed to ietf-announce. > I have three comments, and regret that I have not followed all of the > discussions regarding this draft before, so please advise if those > comments have already been raised and/or resolved. > > > First, I'm glad that the direct preferences of open source implementations > over implementations compliant with other business models are mostly gone. > Still, there is one reference that worries me, and that is the reference > to GPLv3 code as an "extreme" in section 2.1. Yes, the GPL (and similar > copyleft licenses) is an extreme, at least in terms of open source > licensing models. However, it is not an extreme of openness or > accessibility of the source code for review by WG chair, AD, and > community. I would hope that we are all aware that many (most?) > commercial software developers, by company policy or common sense, avoid > looking at GPL-ed code, out of fear of contamination of their own closed > source code. GPL-ed code is, therefore, inaccessible for verification by > a large part of the IETF community, and does not serve as a good example > for "openness", which is how I interpret the spectrum laid out in section > 2.1. A better example would be source code that is almost universally > accessible. The extreme here would be source code in the public domain. > Somewhat less convincing but perhaps a bit more realistically, source code > under a BSD-style license like the one the IETF Trust is using. > > Second, the draft suggest that the existence of an implementation of the > specification should serve as a shortcut towards RFC, presumably because > such an implementation speak favorably to the implementability of the > specification. That, however, is not universally true. Specifically, if > implementer and spec writer are the same person (or part of the same > team), it is quite likely that the spec takes certain assumptions made by > the implementers for granted, and does not document it. That would be a > bad spec, accessible implementation or not. The solution to this issue is > IMO not, as the draft appears to be to suggest, to put burden on WG chairs > and ADs to ensure that the spec and the implementation match. Both WG > chairs and ADs have enough to do, and the incentive for rubber-stamping is > quite high. A more sensible solution may be to require that the > implementer is unaffiliated with the spec author; in other words, the > implementation is derived from the spec + IETF discussion context. > > A third comment would be that, if you interpret the draft strictly, it is > highly unlikely that the experiment would ever be exercised, as the > implementation needs to "match" the draft to be advanced, and that would > mean that the implementation has to follow in lockstep with the draft > development up until the final version. With respect to the core subject > matter of a draft, that may be fine. However, many of the final edits in > a draft come as input from IETF wide community review; things like > security, congestion control, and the like. Those are often trivial to > write down, but can have a major implementation impact. To cure this, it > would IMO be acceptable if the implementation would be required to match > the latest or a reasonably young, i.e. a few months old version of the > draft. > > Please consider this. > Thanks, > Stephan > > > On 1.11.2013 08:21 , "Adrian Farrel" <adrian@xxxxxxxxxxxx> 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. >> >> > >