[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Simple] draft minutes for SIMPLE at IETF72
Please review and provide any corrections and comments as soon as you
can.
Thanks!
RjS
=======================
Minutes - SIMPLE - IETF72
Summary:
The interdomain-federation draft is ready for WGLC, which will likely
occur in
late August or September.
The view-sharing draft is getting close to ready and needs detailed
review. The
chairs will be recruiting reviewers.
There was quite a bit of discussion around supporting a comedia
connection
establishment model for MSRP and how it impacts the use of MSRP
relays. There
is strong interest in taking on supporting comedia connections as a WG
effort.
There is not yet consensus to adopt a particular document as a
starting point.
Additional list discussion (including further discussion of the opaque
path
proposal) is expected.
The MSRP discussions overran the agenda time for group presence.
Please review
Henning's presentation and provide comments to the list.
Raw Notes follow:
----------------------------------------------------
Notes on SIMPLE at IETF 72
reported by Dean Willis
Chaired by Robert Sparks and Hisham Khartabil
Note Well presented
Agenda accepted as presented
Chairs present status and administrivia updates.
Topic: Interdomain Federation
led by Jonathan Rosenberg
slides presented
Changes since last version reviewed.
Result: Plan on WGLC late August or September. PleasFrom simple-bounces at ietf.org Fri Aug 1 01:43:24 2008
Return-Path: <simple-bounces at ietf.org>
X-Original-To: simple-archive at megatron.ietf.org
Delivered-To: ietfarch-simple-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id DE0ED3A6AB4;
Fri, 1 Aug 2008 01:43:24 -0700 (PDT)
X-Original-To: simple at core3.amsl.com
Delivered-To: simple at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 810893A6AB4
for <simple at core3.amsl.com>; Fri, 1 Aug 2008 01:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Level:
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043,
BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id jsdzSzXSIauE for <simple at core3.amsl.com>;
Fri, 1 Aug 2008 01:43:22 -0700 (PDT)
Received: from nostrum.com (unknown [IPv6:2001:470:1f03:267::2])
by core3.amsl.com (Postfix) with ESMTP id 0906C3A6A7C
for <simple at ietf.org>; Fri, 1 Aug 2008 01:43:21 -0700 (PDT)
Received: from [172.16.8.99] ([130.129.65.134]) (authenticated bits=0)
by nostrum.com (8.14.2/8.14.1) with ESMTP id m718hWsR005052
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
for <simple at ietf.org>; Fri, 1 Aug 2008 03:43:34 -0500 (CDT)
(envelope-from rjsparks at nostrum.com)
Message-Id: <214E4A33-F805-4EF6-984A-66B6BF40C1A8 at nostrum.com>
From: Robert Sparks <rjsparks at nostrum.com>
To: simple mailing list <simple at ietf.org>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Fri, 1 Aug 2008 09:43:25 +0100
X-Mailer: Apple Mail (2.926)
Received-SPF: pass (nostrum.com: 130.129.65.134 is authenticated by a trusted
mechanism)
X-Virus-Scanned: ClamAV 0.93.3/7907/Fri Aug 1 01:59:59 2008 on
shaman.nostrum.com
X-Virus-Status: Clean
Subject: [Simple] draft minutes for SIMPLE at IETF72
X-BeenThere: simple at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
<simple.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/simple>,
<mailto:simple-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/simple>
List-Post: <mailto:simple at ietf.org>
List-Help: <mailto:simple-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/simple>,
<mailto:simple-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: simple-bounces at ietf.org
Errors-To: simple-bounces at ietf.org
Please review and provide any corrections and comments as soon as you
can.
Thanks!
RjS
=======================
Minutes - SIMPLE - IETF72
Summary:
The interdomain-federation draft is ready for WGLC, which will likely
occur in
late August or September.
The view-sharing draft is getting close to ready and needs detailed
review. The
chairs will be recruiting reviewers.
There was quite a bit of discussion around supporting a comedia
connection
establishment model for MSRP and how it impacts the use of MSRP
relays. There
is strong interest in taking on supporting comedia connections as a WG
effort.
There is not yet consensus to adopt a particular document as a
starting point.
Additional list discussion (including further discussion of the opaque
path
proposal) is expected.
The MSRP discussions overran the agenda time for group presence.
Please review
Henning's presentation and provide comments to the list.
Raw Notes follow:
----------------------------------------------------
Notes on SIMPLE at IETF 72
reported by Dean Willis
Chaired by Robert Sparks and Hisham Khartabil
Note Well presented
Agenda accepted as presented
Chairs present status and administrivia updates.
Topic: Interdomain Federation
led by Jonathan Rosenberg
slides presented
Changes since last version reviewed.
Result: Plan on WGLC late August or September. Please reviewe review before
then.
Topic: View Sharing
led by Jonathan Rosenberg
slides presented
Pre-WGLC reviewers asked to volunteer.
Topic: Alternative COnnection Model for MSRP
led by Christer Holmberg
slides presented
Noted that correct draft here is draft-blau-simple-msrp-acm-00
Noted that this draft is not an alternate solution, but if adopted it
replaces draft-denis-simple-msrp-comedia.
Issue: C and M line usage
Noted that WG went over this many times and decided they could not use
C and M lines due to relays. So this usage is contradictory with use
of MSRP relay; so if a relay is used (for the many things relays might
be used for) this approach will preclude use of relays.
Question: Is it time to deprecate MSRP relays? Noted that at least one
developer has received RFP requests for relays within the last year.
Question: Is there any real reason to not have two ways to relay MSRP?
Question: B2BUAs have the fundamental flaw of modifying messages
without consent of endpoints. Is it reasonable to make this our only
architecture?
Question: Is it possible to use comedia without using the c and m
lines? If it is, then we could easily use both relay approaches.
Noted by another vendor that all current requests are for B2BUA or
comedia relays, and not MSRP relays.
Noted that in the SIP world, many users are busily removing B2BUAs for
scaling. Should we be putting b2BUAs into MSRP? Response that MSRP
relays have exactly the same scaling issue, and we'd be better off
figuring out how to crosss NATs at the transport layer.
Noted by chairs: We haven't seen much uptake on relays, but this
doesn't seem to be a fault of the protocol. It would not seem
reasonable to deprecate the MSRP relay function at this time.
Noted that the model proposed in this draft requires a relay-model
decision at call setup time. This may result in non-interoperable
clients. This might require negotiation of comedia based on
pre-knowledge of relay behavior.
Question: What has changed since the arguments that led us to develop
MSRP relays? JDR thinks that the initial model of shared TCP
connections between relays/carriers/enterprises has not developed, so
people care less about it. We should not be afraid to learn from
industry experience.
Noted that we really don't have very much deployment experience with
this protocol.
Noted that the need for relays has diminished with the increased TCP
capacity of modern OS.
Noted that MSRP relays may make pushback on congestion more difficult
than TCP.
Suggested that perhaps we should have just used SIP to set up an XMPP
session.
Issue: detailed ICE text. Proposed that document not discuss in detail
Poll: Should WG take on effort of negotiating comedia?
Strong response yes.
Poll: Is this draft a good starting point for the discussion? Response
mixed.
Topic: Opaque Path
led by Hadriel Kaplan
slides presented
Issue: MSRP Relay Scaling
Noted that the MSRP relay has other functions that may be hard with a
comedia relay. Suggested that these might be doable on a
non-transparent signaled relay.
Issue: Proposed Solution
Noted that connection sharing may not be important to nodes using the
proposed solutions.
Privacy was discussed, with the potential impacts on anonymity noted.
Noted that we may not be able to support all the uses of MSRP relays.
Poll: Who read this draft? (few). Who understands? (fewer).
Question: This means we don't need a relay and it won't work with
one. Anonymization requires a B2BUA and a TURN server (and the turn
server alone could have provided anon with current arch). One argument
for this approach is more efficient processing of messages. Is that
enough to justify adding an SBC for anonymization?
Conclusion: We do have group interest in comedia and will further
discuss on the list.
Noteed that last presentation was dropped from the agenda.
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple
before
then.
Topic: View Sharing
led by Jonathan Rosenberg
slides presented
Pre-WGLC reviewers asked to volunteer.
Topic: Alternative COnnection Model for MSRP
led by Christer Holmberg
slides presented
Noted that correct draft here is draft-blau-simple-msrp-acm-00
Noted that this draft is not an alternate solution, but if adopted it
replaces draft-denis-simple-msrp-comedia.
Issue: C and M line usage
Noted that WG went over this many times and decided they could not use
C and M lines due to relays. So this usage is contradictory with use
of MSRP relay; so if a relay is used (for the many things relays might
be used for) this approach will preclude use of relays.
Question: Is it time to deprecate MSRP relays? Noted that at least one
developer has received RFP requests for relays within the last year.
Question: Is there any real reason to not have two ways to relay MSRP?
Question: B2BUAs have the fundamental flaw of modifying messages
without consent of endpoints. Is it reasonable to make this our only
architecture?
Question: Is it possible to use comedia without using the c and m
lines? If it is, then we could easily use both relay approaches.
Noted by another vendor that all current requests are for B2BUA or
comedia relays, and not MSRP relays.
Noted that in the SIP world, many users are busily removing B2BUAs for
scaling. Should we be putting b2BUAs into MSRP? Response that MSRP
relays have exactly the same scaling issue, and we'd be better off
figuring out how to crosss NATs at the transport layer.
Noted by chairs: We haven't seen much uptake on relays, but this
doesn't seem to be a fault of the protocol. It would not seem
reasonable to deprecate the MSRP relay function at this time.
Noted that the model proposed in this draft requires a relay-model
decision at call setup time. This may result in non-interoperable
clients. This might require negotiation of comedia based on
pre-knowledge of relay behavior.
Question: What has changed since the arguments that led us to develop
MSRP relays? JDR thinks that the initial model of shared TCP
connections between relays/carriers/enterprises has not developed, so
people care less about it. We should not be afraid to learn from
industry experience.
Noted that we really don't have very much deployment experience with
this protocol.
Noted that the need for relays has diminished with the increased TCP
capacity of modern OS.
Noted that MSRP relays may make pushback on congestion more difficult
than TCP.
Suggested that perhaps we should have just used SIP to set up an XMPP
session.
Issue: detailed ICE text. Proposed that document not discuss in detail
Poll: Should WG take on effort of negotiating comedia?
Strong response yes.
Poll: Is this draft a good starting point for the discussion? Response
mixed.
Topic: Opaque Path
led by Hadriel Kaplan
slides presented
Issue: MSRP Relay Scaling
Noted that the MSRP relay has other functions that may be hard with a
comedia relay. Suggested that these might be doable on a
non-transparent signaled relay.
Issue: Proposed Solution
Noted that connection sharing may not be important to nodes using the
proposed solutions.
Privacy was discussed, with the potential impacts on anonymity noted.
Noted that we may not be able to support all the uses of MSRP relays.
Poll: Who read this draft? (few). Who understands? (fewer).
Question: This means we don't need a relay and it won't work with
one. Anonymization requires a B2BUA and a TURN server (and the turn
server alone could have provided anon with current arch). One argument
for this approach is more efficient processing of messages. Is that
enough to justify adding an SBC for anonymization?
Conclusion: We do have group interest in comedia and will further
discuss on the list.
Noteed that last presentation was dropped from the agenda.
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple