Hiya, On 01/11/2013 09:02 PM, Stephan Wenger 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. FWIW, I'm not at all glad about that personally but the text we have probably does represent a consensus. Note, there are others like me who'd prefer to favour open-source here, as well as some, presumably including you, that would prefer something like the opposite. > 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. <rant> I am aware that lawyers and others do encourage ignorance in such ways. Its an incredibly stupid way to behave IMO even if understandable in a horrendously short-sighted kind of way. Thankfully I don't work in a place that has to deal with such anti-scientific idiocy. (Being a university we have our own idiocies:-) And there are even many commercial companies that have yet to adopt such silliness. So there's hope for us all yet. </rant> > 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. I'm not at all sure what concrete suggestion you're making, other than disparaging GPL. If your suggestion is s/GPLv3/BSD license/ then that could be done but would make no difference at all to this draft, so I plan to leave this as-is. > 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. Very few things in the IETF are 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. That's a fair point but, a) we don't consider affiliations like that in the IETF, at least not in a written-rules kind of way, and b) there's nothing in principle wrong with the editor writing code. While it is better if the code is written independent of the editor and even better if someone who hasn't been involved in the WG has done the coding, that'd be too high a burden to require IMO, especially given that this is an experiment. I'd have no problem adding text that encouraged some form of independence though, if you'd like to provide some. > 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. Another fair point but again one where its not really possible to describe a rule that'd be better and more precise than "match." I don't think a rule mentioning earlier or older drafts would be useful for this. I'll see if I can come up with something better than "match" but if you have text to suggest, that might help. Cheers, S. > > 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. >> >> > > >