Re: [P2PSIP] Notes have been uploaded

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

Hello all,

I have made the (few and minor) changes folks pointed out, and the
meeting minutes can be found here:

http://www.ietf.org/proceedings/78/minutes/p2psip.txt

If you had any concerns, please make sure they got fixed, and if there
is anything else anyone sees, let me know.

Thanks,

David (as chair)


On Wed, Jul 28, 2010 at 4:43 AM, David A. Bryan <[e-mail]> wrote:
> The notes have now been uploaded from the meeting, and all materials
> should be available. Notes are also in this email.
>
> Please let me know if you see any errors/omissions. Thanks.
>
> David
>
> ---
>
> P2PSIP notes, IETF 78
> 17:40 Monday, July 26, 2010. Brussels Conference Room
> Notes by Dale Worley
>
> ----------------------------------------------------------------------
>
> Cullen Jennings presents draft-ietf-p2psip-base-09:
> REsource LOcation And Discovery (RELOAD) Base Protocol
>
> slide:  Overlay Link Protocols
>
> Question put:  Is it OK to have the use/non-use of ICE as a fixed
> attribute of each overlay?  This proposal is because there is no known
> way to make mixed ICE/non-ICE use within one overlay to work.
>
> No objection.
>
> slide:  Direct Return Responses
>
> David Bryan asks:  Do we have problems with compression of via lists,
> retransmission, and direct return?
>
> Cullen:  I think it's been handled effectively.
>
> Roni Evan:  Intermediaries need to time out transaction state even if
> they don't see responses.
>
> ---> Note for Cullen:  Make sure it is clear to implementers how to
>     time out state in intermediate systems handling requests.
>
> Question put:  Any objections to closing the issue?
>
> No objection.
>
> slide:  Overlay Algorithm
>
> Question put:  Shall we add a flag as to whether sender wants the
> finger table in the response?
>
> No objection.
>
> slide:  Transport Security
>
> Proposal:  Propose to have pluggable security mechanism, with TLS
> being the initially defined mechanism.  An overlay's configuration
> will specify the security mechanism it uses.
>
> Roni Evan: Asks why, if IPSEC is the chosen security mechanism, it
> would be necessary to specify it, since IPSEC operates at a lower
> layer than the application.
>
> Cullen:  Confirming the identity of the far end requires interaction
> between the application and IPSEC.
>
> ---> Note for Cullen:  Need to revise text to use a placeholder
>     meaning "the configured security mechanism" instead of the term
>     "TLS" which is used frequently in the document.
>
> Chair:  That draft is close to being complete regarding security
> configurability and people who have complaints should speak up.
>
> No objections.
>
> slide:  Peer-ID Length
>
> Proposal:  Length of the peer ID is fixed per-overlay, with a maximum
> of 160 bits.
>
> No objections.
>
> David Bryan:  Requests document be updated to clarify that "opaque"
> objects self-describe their lengths.
>
> ---> Note for Cullen:  Promises to clarify in the draft that "opaque"
>     objects self-describe their lengths.
>
> slide:  Revision Plans
>
> Chairs ask for volunteers to do reviews of document before WGLC.
>
> ----------------------------------------------------------------------
>
> Haibin Song presents draft-ietf-p2psip-diagnostics-04:
> P2PSIP Overlay Diagnostics
>
> slide:  Changes since last version - 1
>
> slide:  Changes since last version - 2
>
> slide:  Changes since last version - 3
>
> slide:  Changes since last version - 4
>
> Chair:  Intention is to WGLC this document immediately after WGLC for
> the Reload draft (draft-ietf-p2psip-base).
>
> ----------------------------------------------------------------------
>
> Alexander Knauf presents draft-knauf-p2psip-disco-00:
> A RELOAD Usage for Distributed Conference Control
>
> slide: Outline
>
> slide: Problem Statement for Conferences in P2PSIP Scenarios
>
> slide: Objectives of Distributed Conference Control
>
> slide: Distributing a focus with SIP
>
> slide: Operations in a distributed conference
>
> Brian Rosen: If each participant is attached to one (distributed)
> focus peer, what happens if a focus peer fails?
>
> Knauf:  Each participant attached to that focus peer hunts for another
> focus peer through the usual discovery mechanism.
>
> slide:  Definition of a Distributed Conferencing (DisCo) Kind
>
> slide:  Creating a conference
>
> Cullen Jennings:  A lot of original design was premised on permitting
> continuing functioning when the credential server fails.  But this
> design requires the credential server for ongoing operation.  I
> encourage adjusting the design to not require the credential server
> for operations.
>
> slide:  Joining a Conference and publishing Focus-ability
>
> Brian Rosen:  This mechanism has more uses than conference focuses.
> Can the document be structured so as to separate the definition of the
> general mechanism and the specific use for conference focuses.
>
> Eric Rescorla: What if the key is stolen?
>
> Gabriel Hege:  We haven't considered it.
>
> Jin Peng:  If a focus peer fails, can another participant take over
> doing signaling and media mixing?
>
> Alexander Knauf:  Haven't worked out how to recover media mixing.
>
> Roni Evan:  Who establishes the media parameters of the conference?
>
> Gabriel Hege:  The first peer to join establishes the media
> types/codecs.
>