Yep. That's what I recall too. It's already in the minutes (see the text you posted below):
"Cullen’s view is that once he updates this document with these changes and there is time to review, this will be ready to go to a WG last call. Consensus of the room was to do so." David (as chair) On Sun, Nov 15, 2009 at 1:48 AM, Cullen Jennings <[email protected]> wrote: > > My recollection may be wrong - I did not go back and listen to the minutes > but I seem to recall that at the end of the reload base spec discussion, the > people in the meeting felt it was ready for WGLC after the updates > discussed in the meeting were made. I think that should be in the minutes. > > Thanks, Cullen in my individual contributor roll. > > On Nov 15, 2009, at 7:03 , David A. Bryan wrote: > >> I've posted DRAFT minutes for the P2PSIP meeting at IETF-76. Please >> take a look, comment, and provide any suggestions/corrections or >> additions: >> >> http://www.ietf.org/proceedings/09nov/minutes/p2psip.htm >> >> There are a few hums from the meeting that we will be taking to list >> shortly for WG list discussion as well. >> >> Thanks, >> >> David (as chair) >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip > > Adding the notes in the link above to email below so they are in the email > archive > > ----------------------- > > > IETF-76 P2PSIP Meeting notes (DRAFT) > > Note takers Jim McEachern and Spencer Dawkins. Edited/compared with audio by > David Bryan. > > REsource LOcation And Discovery (RELOAD) Base Protocol, > Cullen Jennings, > draft-ietf-p2psip-base-05 > > Most points for discussion on slides are cosmetic/minor editorial, with a > few exceptions. > > The draft is completely wrong for calculating the signatures. Proposal to > use Michael Chen’s suggested change. Group indicated that this path was > supported. > > Turn density. The system needs an algorithm for this to work, and this > approach works, even though it is almost trivial. Propose to just leave it > as is since the system is not very sensitive to this (see below). However, > he will update the draft to document some of the limitations of this > approach and to point to better algorithms that might be considered in > future work. David Bryan asked from Jabber room about the slide stating it > should be used since studies and experiments indicated it worked well enough > and was robust if you got it wrong. > > David noted this assertion had been controversial before, and asked where he > could find these studies indicating it worked, and Cullen indicated that the > authors had not shared them publicly and felt it was too much work to > publish the results. Indicated that there was an opportunity for more work > in this area for a general service discovery algorithm. > > Self Tuning: Proposal to include information on successors and predecessors > in Leave messages as it is very helpful for the work in the self tuning > draft. Cullen was interested in what the group thought. Comment in favor > of including this as a should. Cullen will do that for the next draft. > > Other Issues. None > > Robert raised “open issues” in the document. > Reactive recovery. People keep suggesting they will provide input, but they > don’t provide anything. Cullen is therefore proposing to delete this as an > open issue. > Cullen’s view is that once he updates this document with these changes and > there is time to review, this will be ready to go to a WG last call. > Consensus of the room was to do so. > > David Bryan asked substitute chairs to get a list of reviewers who would do > a full review of the document: > > Looking for detailed reviewers > • John Buford > • Robert Sparks > • Jouni Maenpaa > > P2PSIP Security Overview and Risk Analysis > Song Haibin > draft-matuszewski-p2psip-security-overview-01 > > Presentation outlined the two changes that were made to the presentation. > Asked if there were any additional comments. > > Cullen said that he had trouble commenting because he was unclear as to > exactly what the purpose of this document was. Without that, it is hard to > comment. > > From Jabber room David mentioned that in an earlier meeting the consensus > was for this to provide guidance to people new to P2P about the unique > security issues and implications. > > An extension to RELOAD to support Direct Response and Relay Peer routing > Ning Zong > draft-jiang-p2psip-relay-03 > > Comparison of DRR/RPR vs. SRR and the number of messages and hops. > Questions from Cullen about exactly what is being analyzed since the number > of messages seems low to him, especially if they include the entire TLS > handshake. Roni Even says that it does include the TLS handshake. Cullen > is unconvinced. Agreed to take this offline to investigate further. > > The authors feel they have addressed the comments and that it is an optional > method for particular deployment scenarios. > > Load balancing models for DHT-based Peer-to-Peer Networks > Erikki Harjula > draft-harjula-p2psip-loadbalancing-survey-00 > > Load balancing is critical, but DHT does not achieve acceptable load > balancing. Therefore more analysis is needed. > Most techniques use: > - measure load > - distribute load information > - balance the load > > Of the many methods, they focus on four. > • Virtual servers: > • Controlling object location > • controlling node location > • address space balancing > > Summarized a brief analysis of the attributes of each method, including cost > in that analysis. This analysis is very tentative, and they plan to extend > the analysis to provide significantly more detail. > > Only two people have read the draft > > A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And > Discovery (RELOAD), > Jouni Mäenpää, > draft-maenpaa-p2psip-self-tuning-01, > > Previous version did self tuning and load balancing. Current version is self > tuning only. > > With static parameters approach it is not possible to have both low > stabilization overhead and low failure rate. > > Self tuning allows parameters to change. Each peer collects data and uses > this to dynamically adjust parameters. > > Question to the group as to whether or not the group would be interested in > having a milestone related to self tuning. Support was expressed for this > work, but not that many people have read it. Jon encouraged the work to > continue, but with such limited audience, was reluctant to adopt it as a > work group. Jouni countered that we had that situation at the last meeting > and that if it became a WG item, then perhaps more people would actually > read it. Extended discussion, with everyone generally supporting this work. > Jon asked how many people understood the problem that this addressing. > About 20-30 people raised their hands. > > Poll: How many people think that the WG should have a charter item to > address this problem? Result - Audible support and no objections. > > Poll: Should this draft be used as input into that charter item? Result - > Audible support and no objections. > > Jon said they would pass this along to the ADs for consideration. > > > Service Discovery Usage for REsource LOcation And Discovery (RELOAD) > Jouni Mäenpää, > draft-maenpaa-p2psip-service-discovery-00 > > Outlines a proposal for a generic service discovery mechanism > > Poll: Should we be defining a generic service discovery mechanism for > p2psip? Result – lukewarm interest, with no objections. > > Conclusion. Encouraged to continue working on this and bring it to the list > to continue generating interest. > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
