RE: Running Code

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

 



>We also certainly don't want to put yet more hurdles into the 
>path of getting drafts published. Does the RFC editor have to 
>verify the URLs and that they still exist? Do we worry about 
>advertising pages and implementations that turn out to be 
>malicious? I'd really rather not have to deal with an RFC 
>where a domain of a fledgling open-source project was taken 
>over by a malware distributor.
>
>Henning

I would like to provide one recent example. In the EMU working group we
worked on a protocol, called EAP-GPSK http://www.ietf.org/rfc/rfc5433.txt. 
The work was done in a design team, it took a very long time (the first
design team draft dates back to May 2006). 

Jouni Malinen implemented the protocol in 8 hours! Jouni also provided a
number of suggestions and we put him into the acknowledgments section.
Before the draft got published as an RFC the reference to his implementation
was removed by the RFC Editor. The RFC Editor also verified the URL and it
was not correct anymore (but that's another topic). 

As mentioned in
http://www.ietf.org/internet-drafts/draft-tschofenig-rai-reducing-delays-00.
txt the problem with feeding experience with running code back into the
specification work is elsewhere.

There are three main problems: 

* Almost random changes to the specification make early implementation work
almost useless (if your goal is to produce code that aims having code for a
specific RFC after all). Since it takes so long to finish the
standardization work it is often not possible to wait till the RFC comes
out. 

* Nobody cares if you have running code. Requests to substantially change
the specification often come at a late stage. Even IESG members have already
re-written specifications during IETF Last Call. As a joke, I suggested to
just submit the table of contents to the IESG and then start the work there.

* Finally, because it takes so long to finish specifications the 3-level
Standards Track process is rarely utilized anymore. That process considers
interoperable code but what does it help? 

Ciao
Hannes







_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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