ietf
[Top] [All Lists]

Re: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC

2013-01-11 15:03:02
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(_at_)olddog(_dot_)co(_dot_)uk> 
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(_at_)ietf(_dot_)org [mailto:ietf-announce-
bounces(_at_)ietf(_dot_)org] 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(_at_)ietf(_dot_)org mailing lists by 2013-02-08. Exceptionally, 
comments may
be
sent to iesg(_at_)ietf(_dot_)org 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.





<Prev in Thread] Current Thread [Next in Thread>