Re: [P2PSIP] DRAFT minutes have been uploaded

["David A. Bryan" <[e-mail]>]

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.
>
>