Hiya, On 01/14/2013 07:50 AM, Stephan Wenger wrote: >> <rant> ... > I understand that this is a rant. And, I'm not ranting back, even if > tempted. ... Yes, its tempting, but I'm going to resist since its irrelevant IMO. ... >> </rant> >> 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. > > Yes, I'm arguing in favor of replacing "GPL" with "BSD", or, even better, > with "public domain". To rephrase the reason for it: ideally, in order to > verify "matching" between software and specification, the software would > need to be accessible to as many people (in practice: IETF participants) > as possible. One extreme is correctly identified: closed source code is, > in almost all cases, accessible only to a very small group of people. The > other extreme is "public domain" source code, where no reasonable lawyer > or business guy has a reason to tell their developers to not touch it. > BSD licensed code comes close, and is more common. > > The GPLed code is not at one of the extremes, but middle ground. I would > wager a guess that perhaps less than half of the IETF participants are > allowed to check GPLed code for something as business-uncritical as > fast-tracking a draft. Therefore, GPLed code should not be an example for > universally accessible and verifiable code. > > Clearer? Please reconsider your position. Yes, that's clearer. We're talking about two different continuums (or continua:-), so either would work, and neither is important to this draft. I'll make the change if there's enough support for it, but as I guess you can see, this is an area where we won't get folks to entirely agree. In this case, we don't need to, since the text in question is just explanatory and has no significant impact on the experiment at all. (BTW, I'll just note in passing that this kind of contentious irrelevancy is exactly the kind of thing that an author/editor running the experiment could freely ignore as not meeting the discuss criteria. That'd be nice, but doesn't apply this time unfortunately;-) >>> 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, > > "Affiliation" was not meant as "same employer". Clearly, same team in the > same company is a problem. Co-developer in the same (small) open source > project is a problem. US-based Office of CTO full-time standardizer (of > which the IETF has a fair share, we may like it or not) and code-grunts in > China are IMO not a problem, even if they work for the same mega-company. > There may be a better word than "affiliated" to describe this > relationship. That word escapes me, though. (Standard excuse: not an > English native speaker.) > > >> and b) there's >> nothing in principle wrong with the editor writing code. > > For the purpose of short-cutting an approval mechanism (and only in this s/short-cutting/speeding up/ > context), I disagree, for the reasons already mentioned. Outside of that > context, I'm fully with you, and I wish there would be more of those > multi-purpose types. > >> 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. > > Ack. > >> >> I'd have no problem adding text that encouraged some form of >> independence though, if you'd like to provide some. > > How about: > > "If the source code has been developed independently of the authoring of > the draft (and ideally by non WG participants), it is likely that the > implementation and the draft match, and that pitfalls unaware developers > may find have been found and dealt with. If, on the other hand, draft > author(s) and implementation developer(s) overlap, then it is sensible to > scrutinize the draft more closely, both with respect to its match with the > implementation and for assumptions that author/developer may have taken > for granted which warrant documentation in the draft." That'd be no harm to add. I don't know that it improves the document enough to bother though. I'll think about it, but let's see if anyone else cares. >>> 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. > > Trying: > > "Match means that all, or substantially all, protocol mechanisms of the > draft are implemented, that no other code points are implemented that > would reasonably fall into the scope of the draft in question, that all > documented state machines are implemented and no other state machines, and > so forth. The over-the-wire behavior of the implementation and of the > draft should substantially match, including more subtle points such as > timing relationship of messages, . Minor divergences in details stemming > from unaligned development cycles of draft and implementation are > acceptable." I like most of that, thanks. For now, I've added this to 2.1, let me know if it works: We do not give a precise definition for "match" here but the intent is that all, or substantially all, protocol mechanisms of the draft are implemented, that the over-the-wire behavior of the implementation and of the draft should substantially match, including more subtle points such as timing relationship of messages, etc. Minor divergences in details stemming from unaligned development cycles of draft and implementation are acceptable. Cheers, S. PS: There's a working draft at [1] in case that helps. [1] http://down.dsg.cs.tcd.ie/misc/draft-farrell-ft-04.txt > >> >> 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. >>>> >>>> >>> >>> >>> >> > > > >