Leaving the process issue aside for a moment, it is useful to look at the root causes of the problem. One of them is the authors clearly did not have time for this document, let alone do research and run code, except for Columbia University.
Most authors of the (overly large number as has been pointed out) document are truly world class and no doubt the best in the IETF. Reload-03 has not had the benefit of their expertise and capability by any stretch of the imagination. So the core issue #1 is IMO: Do the listed authors really want to make the tough choice of dedicating their time and priorities to P2P and give up all countless other engagements to provide such time and focus? _P2P work cannot be delegated_. What about #2 generating and sharing code as the Columbia University folks have done? Or are we expected to trust invisible work and assurances that code and measurements we cannot see are more than a claim? My understanding from the meeting is the P2PP authors will take a turn to edit the next version of the document and also the name may be changed. Yes?/No ? So let's keep our fingers crossed... Henry -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Spencer Dawkins Sent: Friday, March 14, 2008 11:34 AM To: P2PSIP Mailing List Cc: Lars Eggert; Jon Peterson Subject: Re: [P2PSIP] Just to be clear... I agree with Dean on several points. One difference - I am not concerned that the ADs might be pushing (we have both RAI ADs in this room plus more ADs than most WG meetings, so anything suspicious that I'm missing is happening in front of witnesses). Like Dean, I don't have concerns that this draft is being strong-armed, but like Dean, I also have a sense from listening to people that (for example) it wasn't even worth getting up at the mike and saying "I think this other proposal should be considered". I especially agree that a clearer, revised draft will make it easier to agree that we are doing the right thing if we do what it looks like we are going to do. I believe that the short interval between IETF 70 and IETF 71 forced the slamming merge that we saw, and I believe the slamming merge output explains the rest of the problematic situation. No harm, no foul, but we need to LOOK as "clear" (procedurally) as we are. In summary... this was only a small elephant, but it is an elephant. It could even be a nice pet elephant, but we need to make sure that we don't trip over it while walking through the room. Thanks, Spencer From: "Dean Willis" <[EMAIL PROTECTED]> > On Mar 14, 2008, at 10:17 AM, Spencer Dawkins wrote: > >> I really AM thinking that RELOAD-04 will be adopted as a working group >> item >> after it is submitted (under whatever name is finally chosen). >> >> Is anyone expecting something else to happen? >> > > Since it is my apparent self-appointed role to point out the elephants in > the room . . . > > There are people who feel that RELOAD is being "strong-armed" (coerced by > people with procedural authority) into place. I've personally heard this > perception expressed by several working group participants, even though I > don't have the same perception. This sort of problem happens anytime a > candidate draft has contributor support from a chair, area director, or > area technical advisor (and RELOAD has all three!). The WG's only counter > is to be meticulous about the application of process and propriety with > respect to such a draft. > > The relative unreadability of the hastily merged RELOAD draft makes > comparing and discussing the merits/demerits of the proposal against > alternatives difficult. > > Strong pressure from the chairs, ADs, and area technical adviser to adopt > the draft in the light of this "difficult to compare and discuss" > condition aggravate the perception of being "strong-armed" > > I believe that a more mature draft will eliminate the argument that > debate on the technical issues is too difficult. > > So once we have a better draft, people will either have good technical > arguments against the proposal or will be willing to accept the proposal > as a consensus position. > > In the end, I expect that the RELOAD draft will be accepted as the WG > baseline document. But we need to more-than-fairly exercise the process > to get there if we want the working group to continue to move smoothly. > > -- > Dean > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
