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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Martin Rex wrote:

> John Leslie wrote:
> >
> >    I'm pretty darn uncomfortable _ever_ picking a fight with any
> > sitting AD, But I feel obligated to say this seems like a terrible
> > idea to me.
> >
> >    As a background, I'm a long-time believer in "rough consensus" for
> > Proposed Standard and "running code" for advancement along the
> > standards track. I do not believe the two mix well.

> I don't have the resource to participate the discussion, but
> these statements capture my opinion pretty well.

I'm reluctantly going to have to join John and Martin, with one very important
difference: I think there is huge value in implementing specifications during
the process leading up to proposed standard. (As many people know, I do this
myself quite often for drafts I'm interested in.) I would rather phrase it as
having demonstrable interoperability for advancement, and ideally having
implementations done much earlier.

More specifically, where I part ways with this draft is in believing that very
early implementation helps find interoperability issues. I have not found that
to be the case. What it helps find are issues affecting implementability. In
the applications area at least, it's surprisingly easy to specify things that
look good on paper but turn out to suck when you try to code them. (My own sins
in this area are well known - RFC 2231 - and one of the reasons for that it is
one of the few RFCs I've written without implementing it first.)

Now, it's quite true that implementability problems can lead to
interoperability problems, like when different people take different shortcuts
in coding an unnecessarily problematic specification. But other outcomes are
possible, including fragility, unnecessary restrictions, and most especially
scalability problems.

Another problem with focusing on interoperability specifically as opposed to
overall implementability is that it makes it hard to argue that one or two
implementations provide that much benefit. In my experience having just one
implementation, even one done by a draft author, is surprisingly helpful in
cleaning up drafts.

I guess what I would like to see is for the draft to talk a little more about
finding implementation issues in general and a lot less about finding
interoperability issues specifically. I also think the draft goes a bit far in
the "carrots" it provides, but that may have more to do with my own experiences
in the applications area, where important comments have a way of only showing
up at the last second and where therefore the abbreviated process might be a
little dangerous to use.

Finally, I'm going to apologize for the tardiness of this comment, which really
should have been made sooner. I'm also going to apologize in advance for
probably not being able to fully participate in this discussion due to severe
time constraints.

				Ned


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]