Hi, On 2010-8-20, at 8:26, Gerrit Renker wrote: > thank you for your reply and for pointing out the responsibility of the IETF. > This has clarified the situation much. > > Actually the question of "who is going do deal with this" is very important, > since I don't think that this single draft will be the only thing, as there > are > other problems, such as using TFRC over wireless (but that is a separate > issue).
like everything else, whether we should close the DCCP WG or not is a judgment call. Yes, like any other protocol, DCCP can be continuously improved. No question about it. The first question is whether the IETF should spend cycles on maintaining DCCP. At the moment, I believe the answer is yes, although I will note that actual deployments will at some point in the future become important in order to argue that the IETF should continue to spent the cycles. But, as I said, at the moment I think the answer is yes. The next question is whether this DCCP maintenance requires a stand-alone WG. At the moment, at least my feeling is that it may not (and that any pressing maintenance work can be done e.g. in TSVWG or as AD-sponsored documents.) The reason I have this opinion is that the energy levels in the WG are extremely low, as witnessed by long update cycles for the past few WG items and very little in terms of discussion. The community that is interested in DCCP is also not exactly huge, and very few proposals for new work saw much interest during the last few years. Also note that when I say "maintenance", I mean we should be doing bug fixes and minor improvements that make the currently specified DCCP protocol more appealing to potential users. *If* more substantial extension proposals are motivated by the needs of actual deployments, I'm more than happy to see the work happen, but I'm not terribly excited about doing substantial extensions to DCCP in the IETF that are mostly academically motivated. (I note that those can always be published as direct submissions to the RFC Editor.) > I believe it is better to try and fix the problems rather than to abandon ship > and try to start something similar from scratch. We're not abandoning ship. We are shifting gears, however. With the publication of the major specs, DCCP is entering maintenance mode, until DCCP deployments necessitate more substantial extensions. > So please let me know what I can do to best support your work. The absolute best thing anyone interested in DCCP can do is push it out onto the Internet, so it becomes an actively used protocol. This should become much easier once the UDP encapsulation spec is done, and implementations are available. I know that you and others are actively maintaining the Linux implementation, which is really great! Without actual code that folks can run, DCCP won't really get more traction. Lars
smime.p7s
Description: S/MIME cryptographic signature
