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