Subject: Re: [P2PSIP] Notes have been uploaded

From: Cullen Jennings <[email-masked]>
Date: Tue, 3 Aug 2010 15:28:46 -0700

This one note seemed a bit off (and I certainly understand how it was confusing in the meeting). You can find this discussion in the audio file from 2:47:25 to 2:47:06

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

Per the discussion in the audio file, I plan to use the term TLS throughout the document but make it clear in the terminology and security section that "TLS" refers to TLS or whatever other thing is providing the security.

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 4 Aug 2010 13:07:02 -0400

Thanks for noticing that. That was my recollection as well, I'll update the
notes accordingly unless there are any objections.

David (as chair)

On Aug 3, 2010 6:28 PM, "Cullen Jennings" <[email-masked]> wrote:

This one note seemed a bit off (and I certainly understand how it was
confusing in the meeting). You can find this discussion in the audio file
from 2:47:25 to 2:47:06

> meaning "the configured sec...
Per the discussion in the audio file, I plan to use the term TLS throughout
the document but make it clear in the terminology and security section that
"TLS" refers to TLS or whatever other thing is providing the security.

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 23 Aug 2010 14:47:22 -0400

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 <[email-masked]> 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.
>
> 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.
>