On Mar 29, 2012, at 12:04 PM, Rob Austein wrote: > At Wed, 28 Mar 2012 20:33:24 -0400, Danny McPherson wrote: >> >> i don't think the rsync scale issues surprise anyone that was paying >> attention. If we're already considering new architectures, >> substrates, et al., here perhaps we shouldn't be so quick on the >> trigger for Standards Track work and move this and related >> "investigation" to the IRTF, or at least ensure they're only >> Experimental until broader experience is gained. >
<snip> > > For the record, this presentation was originally targeted at the IEPG, > as a direct follow-up to multiple suggestions received at a previous > IEPG meeting that it might be interesting to see how BitTorrent works > in this environment. I presented this at the SIDR WG meeting because > the chairs thought it might be of interest to the WG. > So, I just want to wade in here very quickly: in the sidr wg we are constantly facing packed agendas, multiple sessions, and now interim meeting extravaganzas... I feel like there is no shortage of feedback that people try to give to many of the drafts (during sessions and obviously on the list), but the session agendas often seem to require the chairs to cut the mic lines (imho) way too early. This has made feedback harder to give. I (for one) was a little surprised to see the bittorrent work presented at both the iepg and again during the wg considering the amount of feedback that often comes from pretty much _any_ given draft on the agenda. I am not claiming it is bad work, inappropriate, or anything like that. Simply, an interesting scheduling choice... With all due respect (honestly, I know this can't be easy), I really feel this is symptomatic of a disconnect between the session agendas and the level of comfort that the overall wg members have with some of the drafts. I really think fewer/more focused sets of presentations are critical to moving forward and I think I've heard _several_ people on the list push very hard for us to return our focus to solid requirements analysis (which I think very much should include drafts like the req's draft, Steve's threats draft, etc) so that we can evaluate the nature of the work we are all trying to do separately from how implementations and designs are being fleshed out. Getting the wg members on the same page wrt what we are trying to do would likely make a number of points of friction smoother. I really think this does _not_ necessarily invalidate work that has already been done (though we may still need to examine some of it carefully). For example, Danny's questions to Rob et al about the scaling requirements that the protocol was aimed at is very apropos of us proceeding in an orderly fashion towards a feasible security system. Lessons learned from experiments can be used to inform evolving requirements. That is, this isn't necessarily the waterfall software lifecycle ( http://en.wikipedia.org/wiki/Waterfall_model ), which only goes forward without feedback loops. Personally, I would find it helpful to see less packed, more focused, and a return to reqs in future sessions if possible... And, yes, we should strive for world peace too... Thanks, Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
