Re: [P2PSIP] DRAFT minutes have been uploaded

[Cullen Jennings <[e-mail]>]

Clearly I need more sleep at IETF :-) Thanks.

On Nov 15, 2009, at 11:56 AM, David A. Bryan wrote:

> 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 <[e-mail]>  
> 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
> >> [e-mail]
> >> 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.
> >
> >
>