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]

 



Hi Ned,

at the end...

On 01/15/2013 10:31 PM, ned+ietf@xxxxxxxxxxxxxxxxx wrote:
> 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.

Actually I think you make a couple of great points that ought be
mentioned in the draft about implementability. (No chance you'd
have time to craft a paragraph? If not, I'll try pinch text from
above:-) Now that you point it out like that, I'm irritated at
myself for not having included it already! (It rings bells for me.)

Cheers,
S.

> 
> 				Ned
> 
> 


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