From andrew.hutton@siemens-enterprise.com Mon Jul 1 02:48:37 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F62121F9D0A for ; Mon, 1 Jul 2013 02:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXBzj0G-2vh5 for ; Mon, 1 Jul 2013 02:48:27 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id A2F8221F9CE1 for ; Mon, 1 Jul 2013 02:48:26 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 4A32423F04FB; Mon, 1 Jul 2013 11:48:25 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Mon, 1 Jul 2013 11:48:24 +0200 From: "Hutton, Andrew" To: "Olle E. Johansson" , "Cullen Jennings (fluffy)" Thread-Topic: Chair question around draft-klatsky-dispatch-ipv6-impact-ipv4 Thread-Index: AQHOdE7gkEpHsjUQLkK6+KYIhBdntJlMJEuAgANxDZA= Date: Mon, 1 Jul 2013 09:48:24 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1162AD77@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Chair question around draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 09:48:37 -0000 See below. > -----Original Message----- > From: Olle E. Johansson [mailto:oej@edvina.net] > Sent: 29 June 2013 08:07 > To: Cullen Jennings (fluffy) > Cc: Olle E. Johansson; Rifaat Shekh-Yusef; Gonzalo Salgueiro > (gsalguei); carl_klatsky@cable.comcast.com; Hutton, Andrew; > dispatch@ietf.org list > Subject: Re: Chair question around draft-klatsky-dispatch-ipv6-impact- > ipv4 >=20 >=20 > 29 jun 2013 kl. 00:28 skrev "Cullen Jennings (fluffy)" > : >=20 > > > > The chairs are trying to figure out how to frame the purpose of this > draft as that helps us figure out what to do with it. Three questions > to the authors (but happy to hear from anyone): > > > > 1) Guidance or Standard ? > > > > My current understanding of the draft is that it does not require any > updates or changes to any existing RFC. It does not specify new > normative behavior. (and I see it is informational) It seems to be more > a collection of scenarios that a implementer might want to consider but > does not change any normative behavior. > > > > Is my understanding roughly correct? > Yes. Also agree. > > > > > > 2) Operators or Implementers ? > > > > Another ways of looking at this draft, seem to be advice to operators > to use DNS names instead of IP addresses that might not be supported. > That will allow v4/v6 interop mechanism at layer 3 to come into play. > > > > Does the draft want to be advice to operators about how to use IP > addresses and DNS names in SIP to avoid the problems raised in the > draft? > Good question. I think that is the general religion of SIP - and we've > been working with it at SIPit - "test using DNS, not IP addresses". > I personally don't think we should add it to this specific document at > this point as it may generate a lot of discussions and lead to happy- > eyeballs whcih is in scope for the other documents. >=20 > I need guidance from those of you that are more experienced in the IETF > process here. WHile I would love to add another argument for not using > numeric IP addresses. >=20 I had thought of the draft as being for implementers rather than operators = and that is probably where the focus should stay.=20 > > > > > > 3) Scope > > > > Nearly every section of the draft raises as many questions in my mind > as it answers. Is the intend that this draft is "close to done" with > some review or is it more that this draft is just the starting point of > a much larger effort? ( I can give examples but I want to focus on the > big picture not the questions raised in my mind ) >=20 > I think this draft should stay "problem statement" more than solution. > At this point we just want to alert and wake up everyone saying "oh, I > only do IPv4 so I don't have to bother". And that fact needs to be out > there soon. >=20 > If there are issues in this draft that lacks a solution in the current > set of RFCs we need to handle that, but in my head that would be a > separate document. >=20 > We might make it a bit more clear that this is a problem statement. > Again, I'm the newbie in this process so this is just my 5 =F6re > contribution :-) >=20 Agree with Olle this is intended to be a problem statement and to promote a= wareness and discussion so personally I would like to be open to additional= issues being raised and documented so would not say it is close to done at= this stage. > > > > > > Cullen > > > > PS - As a chair - this type of draft is the hardest. It's hard to > know what is the best thing to do with this draft until I get a clear > picture of what work this is proposing for IETF. >=20 >=20 > /O From mary.ietf.barnes@gmail.com Mon Jul 1 13:58:15 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9183F21F9B8F for ; Mon, 1 Jul 2013 13:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzHBb3NlrpDy for ; Mon, 1 Jul 2013 13:58:14 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7021F9B5B for ; Mon, 1 Jul 2013 13:58:14 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c11so3185054qcv.37 for ; Mon, 01 Jul 2013 13:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=PX19Lf1cmy68rV2cNNtEdTvBiAQDzLtAJP43LE7H3fc=; b=FdptaVCNez+Ceq508oCr/ZSkhG/kUvno67pooVdJg3opBdFlCiWM4+R9nymanqs3nO 3gU1GVgVXvZnaj0Q6AS2qpdgHxebM7Gcx6NpioFcn52y4VcgfsbQMb6cbakR/FRbl+hB 2BUszkB8pS1+niCBWaTaEwd3wSmh+d3y9Iz1++ToF/5iN2EZ3oSOSjez2Hto8ZgQKs6a RuVtWCn1nr0gzDLgf7FCcIX9bXijo5EkxmEd3Ym+l5Ws9eDv7ihHq5l8SPu7dH9FDzYZ RfyBXKG3GVPtsf9Q4WKNTyxXN2QopcmmpkZ5tCw+Iz+zX10bxBSDWZnT++fFG19Iuwhw Gxgg== MIME-Version: 1.0 X-Received: by 10.229.114.209 with SMTP id f17mr7938873qcq.26.1372711802895; Mon, 01 Jul 2013 13:50:02 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Mon, 1 Jul 2013 13:50:02 -0700 (PDT) Date: Mon, 1 Jul 2013 15:50:02 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=00235429d6c464075a04e0795f34 Cc: Cullen Jennings , "rai-ads@tools.ietf.org" Subject: [dispatch] DISPATCH Topics - No Meeting in Berlin X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 20:58:15 -0000 --00235429d6c464075a04e0795f34 Content-Type: text/plain; charset=ISO-8859-1 The chairs and ADs have reviewed the list of topics submitted for the IETF-87 timeframe (i.e., topics since IETF-86). We had the following requests for agenda time or consideration for dispatching prior to IETF-87. Specific responses have been posted on the list and/or sent directly to the authors. The following provides a summary of those responses: 1) draft-allen-dispatch-poc-instanceid-usage-00: Comments: we need more list discussion and it's not quite clear what the problem is or use case that this document is addressing. We know it's a OMA related, but we need more background in order to decide how to handle it. Likely, an expert review and AD sponsorship would be reasonable after any list feedback and the above is addressed 2) draft-holmberg-dispatch-udptl-dtls-00 - DTLS for UDPTL for ITU fax Comments: It's not quite clear why this is needed (by 3GPP). 3) V4/v6 from SIP Forum: draft-klatsky-dispatch-ipv6-impact-ipv4 Comments: It's not quite clear what protocol work is being requested (or if required). Suggest that this needs more discussion and a problem statement. 4) draft-dawes-dispatch-mediasec-parameter-06.txt An informational RFC describing a header field parameter to distinguish security mechanisms that protect media (as opposed to those that protect signalling) between a UA and its first-hop SIP entity, and to create an IANA registry to list names of such media-specific security mechanisms Comments: It's not quite clear why this is in SIP and not SDP - it appears to be a 3GPP requirement. More background as to the problem being solved is needed. One thing in common that is lacking at this time for the above proposals is clear problem statements. The expectation has been that topics being requested to be dispatched have at least a minimal problem statement. For items that are broader in scope, the expectation would be a preliminary charter. Note, that the deadline for those have passed, thus there are no topics that we believe require face to face discussion. As a result, we will NOT be having a f2f meeting in Berlin. If you requested agenda time, you have been contacted with regards to specific handling requested to move your topic forward. Note, that it may be possible to dispatch some of the above topics prior to IETF-88 based on mailing list discussions. If you have comments on any of the above, PLEASE start a separate thread of discussion with an appropriate Subject. On a more general point, one reason we believe that some of the topics are not quite ready for face to face discussion is that we moved out the deadlines to give folks more time to submit documents (i.e., we no longer have separate deadlines from the main IETF deadlines). Thus, we will be considering moving the deadlines earlier as we have done in the past for the IETF-88 meeting. Best Regards, Mary. --00235429d6c464075a04e0795f34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The chairs and ADs have reviewed the list of topics submitted for the
IETF-87 timeframe (i.e., topics since IETF-86).

We had the=A0following requests for agenda time or considerati= on for
dispatching prior to IETF-87. =A0Specific responses have been posted
on the list and/or sent directly to the authors. The following provides
a summary of those responses:

1) =A0draft-allen-dispatch-poc-instanceid-usage-00:
Comments: =A0we need more list discussion and it's not quite clear what=
the problem is or use case that this document is addressing. =A0We know
it's a OMA =A0related, but we need more background in order to decide h= ow
to handle it. =A0Likely, an expert review and AD sponsorship would be reaso= nable
after any list feedback and the above is addressed

2) =A0draft-holmberg-dispatch-udptl-dtls-00 - DTLS for UDPTL for ITU fax Comments: =A0It's not quite clear why this is needed (by 3GPP).

3) =A0V4/v6 from SIP Forum: draft-klatsky-dispatch-ipv6-impact-ipv4
Comments: =A0It's not quite clear what protocol work is being requested=
(or if required). =A0Suggest that this needs more discussion and a problem = statement.

4) =A0draft-dawes-dispatch-mediasec-parameter-06.txt
An informational RFC describing a header field parameter to distinguish sec= urity
mechanisms that protect media (as opposed to those that protect signalling)=
between a UA and its first-hop SIP entity, and to create an IANA registry t= o
list names of such media-specific security mechanisms

Comments: =A0 It's not quite clear why this is in SIP and not SDP - it<= br> appears to be a 3GPP requirement. =A0More background as to the
problem being solved is needed.

One thing in common that is lacking at this time for the above proposals is= clear
problem statements. =A0The expectation has been that topics being requested= to
be dispatched have at least a minimal problem statement. For items that are=
broader in scope, the expectation would be a preliminary charter. Note,
that the deadline for those have passed, thus there are no topics that we b= elieve
require face to face discussion. As a result, =A0we will NOT be having
a f2f meeting in Berlin. =A0 If you requested agenda time, you have been co= ntacted
with regards to specific handling requested to move your topic forward.

Note, that it may be possible to dispatch some of the above topics prior to= IETF-88
based on mailing list discussions.

If you have comments on any of the above, PLEASE start a separate thread of= discussion
with an appropriate Subject.

On a more general point, one reason we believe that some of the topics
are not quite ready for face to face discussion is that we moved out
the deadlines to give folks more time to submit documents (i.e., we no
longer have separate deadlines from the main IETF deadlines). =A0 Thus,
we will be considering moving the deadlines earlier as we have done in
the past for the IETF-88 meeting.

Best Regards,
Mary.


--00235429d6c464075a04e0795f34-- From oej@edvina.net Tue Jul 2 08:05:21 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FDA21F9F55 for ; Tue, 2 Jul 2013 08:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKBhjL3RnF45 for ; Tue, 2 Jul 2013 08:05:20 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 5C61F21F9EE5 for ; Tue, 2 Jul 2013 08:05:19 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 860DC93C2A1; Tue, 2 Jul 2013 15:05:17 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1162AD77@MCHP04MSX.global-ad.net> Date: Tue, 2 Jul 2013 17:04:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A1D225C-3608-4685-AC1D-5E48DB5ABE10@edvina.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1162AD77@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1508) Cc: "Cullen Jennings \(fluffy\)" , "dispatch@ietf.org list" Subject: Re: [dispatch] Chair question around draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 15:05:21 -0000 1 jul 2013 kl. 11:48 skrev "Hutton, Andrew" = : > See below. >=20 >> -----Original Message----- >> From: Olle E. Johansson [mailto:oej@edvina.net] >> Sent: 29 June 2013 08:07 >> To: Cullen Jennings (fluffy) >> Cc: Olle E. Johansson; Rifaat Shekh-Yusef; Gonzalo Salgueiro >> (gsalguei); carl_klatsky@cable.comcast.com; Hutton, Andrew; >> dispatch@ietf.org list >> Subject: Re: Chair question around = draft-klatsky-dispatch-ipv6-impact- >> ipv4 >>=20 >>=20 >> 29 jun 2013 kl. 00:28 skrev "Cullen Jennings (fluffy)" >> : >>=20 >>>=20 >>> The chairs are trying to figure out how to frame the purpose of this >> draft as that helps us figure out what to do with it. Three questions >> to the authors (but happy to hear from anyone): >>>=20 >>> 1) Guidance or Standard ? Just found this statement in the introduction (section 1) "The scenarios outlined in this document are intended as guidance for application developers to help identify solutions to resolve the identified interoperability challenges. " Maybe we should add them more clearly in the abstract. /O=20 >>>=20 >>> My current understanding of the draft is that it does not require = any >> updates or changes to any existing RFC. It does not specify new >> normative behavior. (and I see it is informational) It seems to be = more >> a collection of scenarios that a implementer might want to consider = but >> does not change any normative behavior. >>>=20 >>> Is my understanding roughly correct? >> Yes. >=20 > Also agree. >=20 >>>=20 >>>=20 >>> 2) Operators or Implementers ? >>>=20 >>> Another ways of looking at this draft, seem to be advice to = operators >> to use DNS names instead of IP addresses that might not be supported. >> That will allow v4/v6 interop mechanism at layer 3 to come into play. >>>=20 >>> Does the draft want to be advice to operators about how to use IP >> addresses and DNS names in SIP to avoid the problems raised in the >> draft? >> Good question. I think that is the general religion of SIP - and = we've >> been working with it at SIPit - "test using DNS, not IP addresses". >> I personally don't think we should add it to this specific document = at >> this point as it may generate a lot of discussions and lead to happy- >> eyeballs whcih is in scope for the other documents. >>=20 >> I need guidance from those of you that are more experienced in the = IETF >> process here. WHile I would love to add another argument for not = using >> numeric IP addresses. >>=20 >=20 > I had thought of the draft as being for implementers rather than = operators and that is probably where the focus should stay.=20 >=20 >>>=20 >>>=20 >>> 3) Scope >>>=20 >>> Nearly every section of the draft raises as many questions in my = mind >> as it answers. Is the intend that this draft is "close to done" with >> some review or is it more that this draft is just the starting point = of >> a much larger effort? ( I can give examples but I want to focus on = the >> big picture not the questions raised in my mind ) >>=20 >> I think this draft should stay "problem statement" more than = solution. >> At this point we just want to alert and wake up everyone saying "oh, = I >> only do IPv4 so I don't have to bother". And that fact needs to be = out >> there soon. >>=20 >> If there are issues in this draft that lacks a solution in the = current >> set of RFCs we need to handle that, but in my head that would be a >> separate document. >>=20 >> We might make it a bit more clear that this is a problem statement. >> Again, I'm the newbie in this process so this is just my 5 =F6re >> contribution :-) >>=20 >=20 > Agree with Olle this is intended to be a problem statement and to = promote awareness and discussion so personally I would like to be open = to additional issues being raised and documented so would not say it is = close to done at this stage. >=20 >=20 >>>=20 >>>=20 >>> Cullen >>>=20 >>> PS - As a chair - this type of draft is the hardest. It's hard to >> know what is the best thing to do with this draft until I get a clear >> picture of what work this is proposing for IETF. >>=20 >>=20 >> /O From oej@edvina.net Wed Jul 3 00:51:40 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62BA21F9A3E; Wed, 3 Jul 2013 00:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRjmlrMOY7TU; Wed, 3 Jul 2013 00:51:38 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 53D6121F9A14; Wed, 3 Jul 2013 00:51:36 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 80AD093C1AF; Wed, 3 Jul 2013 07:51:34 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jul 2013 09:51:34 +0200 Message-Id: To: dane WG list Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "Cullen Jennings \(fluffy\)" , "dispatch@ietf.org list" Subject: [dispatch] Random thoughts about SIP and DANE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 07:51:40 -0000 Hi! I've tried to collect my thought about SIP and DANE on a slide set. It's = the way I brainstorm I guess :-) You can view it here: = http://www.slideshare.net/oej/danebased-tls-verification-in-the-sip-protoc= ol Feedback is always welcome!=20 If this is on the right path, I'll try to write a draft. We do have DNSsec support in Kamailio now, so hopefully I can get the = developer team to work with me to get some code for testing. /Olle= From ibc@aliax.net Wed Jul 3 05:17:30 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D65821F9DA5 for ; Wed, 3 Jul 2013 05:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQ-VYJKqpUkz for ; Wed, 3 Jul 2013 05:17:26 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id E74BB21F9DA6 for ; Wed, 3 Jul 2013 05:17:25 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id a1so26991qcx.39 for ; Wed, 03 Jul 2013 05:17:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=TY6ngKE5pES9RqALu5yQ9McCZbdHRBjzy4iJJ5+OPsg=; b=Eu1UpaCRAaWOqkfgu3QYjeE4qzkqdPr3c3hO414KT56AyhuynVX6gqZ9YXjiCez2xx 2YPrgjRZIrNpr9GhNY5YOG9Q2p89xB36dAG/nHrQAF6uaDzW/BqMIGI+YGt4Fn/Ma+PS AnC4nRQoa//6wIIxa90OY1M/UIEZ+QbY2PGIO9D13EegnB9sOr+/WmQWSItwyB3XYS6E z6cEj0iyQNKqIKFaRxwwUtY6NHM/+z/a9Lgzj0rv+y50Jb2bxZiuB9BKnpHzKVl9Tofd /CUVYNCy4XlgdFPqQ8hFfhiQVFVOwhRNIwS1FUSD2EI0UFf6B8QsappPJa2G12VOXc46 4b3Q== X-Received: by 10.224.90.1 with SMTP id g1mr3565466qam.0.1372853841210; Wed, 03 Jul 2013 05:17:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Wed, 3 Jul 2013 05:17:01 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 3 Jul 2013 14:17:01 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnkMu9BXHjS76BC37nzkjryasS5A5XqvRsYX+irJnVbsaAdyC2EyhEi9qOVItxivK2DotSy Cc: "Cullen Jennings \(fluffy\)" , "dispatch@ietf.org list" , dane WG list Subject: Re: [dispatch] Random thoughts about SIP and DANE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 12:17:30 -0000 2013/7/3 Olle E. Johansson : > You can view it here: > http://www.slideshare.net/oej/danebased-tls-verification-in-the-sip-proto= col > > Feedback is always welcome! Just some comments: Slide 13 ------------ According to RFC 5922: - First check subjectAltName for SIP URIs with no username@. If so take them and exit. - Otherwise check subjectAltName for DNS domains. If so take them and exit. - Otherwise check the CN. Slide 14 ----------- SIPS? No please... it's better to write a new draft deprecating SIPS schema= ;) SIMPLE? good luck! :) -- I=C3=B1aki Baz Castillo From fluffy@cisco.com Wed Jul 3 15:39:55 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2856821F9BD5; Wed, 3 Jul 2013 15:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azqy-nupDUsL; Wed, 3 Jul 2013 15:39:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5E21A11E80E0; Wed, 3 Jul 2013 15:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1521; q=dns/txt; s=iport; t=1372891190; x=1374100790; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7cSLhdAkOJdTUDSBVLRaCFNLTNAFXOOQ6m8V5oZ6MwI=; b=hfKLl0xk5/IC32tQmhXLyw+wfyFhS+68hg9nOvkIxYgA13werlTZXc0H AlYXFHEE34JGEXgNVjTqlQ7UF12N77P9BQro9YOSqf6Ez1q7YuRru+Lgo dRZ1Bo/01N2rWnrFonY/lSZaRgNkWfFJ2fHQA7b3nZ+QxYFSYhVIywPfZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAN6n1FGtJXHB/2dsb2JhbABRCYMJMknAOYEJFnSCIwEBAQMBAQEBawsFCwIBCCIkJwslAgQOBQiIAQYMuimOMIEIAjEHgwRpA6kOgxGCKA X-IronPort-AV: E=Sophos;i="4.87,991,1363132800"; d="scan'208";a="230776327" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 03 Jul 2013 22:39:34 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r63MdYZV024354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 22:39:34 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 17:39:33 -0500 From: "Cullen Jennings (fluffy)" To: "Olle E. Johansson" Thread-Topic: [dane] Random thoughts about SIP and DANE Thread-Index: AQHOd8Imgvc/hKNE30u1xa1rKID//JlT4K2A Date: Wed, 3 Jul 2013 22:39:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.38] Content-Type: text/plain; charset="Windows-1252" Content-ID: <66466B2396467D44BE0805440C6C648B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" , dane WG list Subject: Re: [dispatch] [dane] Random thoughts about SIP and DANE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:39:55 -0000 I like it. Hope you write a draft.=20 In slide 9 with pub key, I don't understand how the challenge / response wo= rks but this is probably just me not knowing enough=85 On slide 14,=20 SIPS has turned out to be a mess but I don't think think you have to consid= er it one way or the other. As much as it works (or does not work), a conne= ction secured via the DANE approach can be treated the same as a connection= secured via classic TLS approach=85 I suspect this is about the same answe= r for connection reuse and SIMPLE. It seems like they should both work fine= with this.=20 SIP Identity is a different kettle of fish but I think that as long as the = STIR bof deals with DANE, hopefully that will be resolve with something bet= ter than current SIP Identity RFC.=20 On Jul 3, 2013, at 12:51 AM, Olle E. Johansson wrote: > Hi! >=20 > I've tried to collect my thought about SIP and DANE on a slide set. It's = the way I brainstorm I guess :-) >=20 > You can view it here: > http://www.slideshare.net/oej/danebased-tls-verification-in-the-sip-proto= col >=20 > Feedback is always welcome!=20 >=20 > If this is on the right path, I'll try to write a draft. >=20 > We do have DNSsec support in Kamailio now, so hopefully I can get the dev= eloper team to work with me to get some code for testing. >=20 > /Olle > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From oej@edvina.net Wed Jul 3 22:57:27 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9E921F9EBC; Wed, 3 Jul 2013 22:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upN+AteuVtyA; Wed, 3 Jul 2013 22:57:26 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0B79921F9EE7; Wed, 3 Jul 2013 22:57:23 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 54FA893C1AF; Thu, 4 Jul 2013 05:57:20 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 4 Jul 2013 07:57:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <175DFFE9-3BED-4ECD-B60D-749767B8313C@edvina.net> References: To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1508) Cc: "dispatch@ietf.org list" , dane WG list Subject: Re: [dispatch] [dane] Random thoughts about SIP and DANE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 05:57:27 -0000 4 jul 2013 kl. 00:39 skrev "Cullen Jennings (fluffy)" = : >=20 > I like it. Hope you write a draft.=20 Thanks. >=20 > In slide 9 with pub key, I don't understand how the challenge / = response works but this is probably just me not knowing enough=85 TLS verifies that the server actually has the private key in the cert it = sends using a challenge/response mechanism. If you ignore the cert = (since you actually have the public key and trust it), you still want to = verify that the server has the matching private key. >=20 > On slide 14,=20 >=20 > SIPS has turned out to be a mess but I don't think think you have to = consider it one way or the other. As much as it works (or does not = work), a connection secured via the DANE approach can be treated the = same as a connection secured via classic TLS approach=85 I suspect this = is about the same answer for connection reuse and SIMPLE. It seems like = they should both work fine with this.=20 Yes. There are some questions in regards to certificate matching in = SIMPLE but that applies regardless of DANE. >=20 > SIP Identity is a different kettle of fish but I think that as long as = the STIR bof deals with DANE, hopefully that will be resolve with = something better than current SIP Identity RFC.=20 Well, Jon wrote on the STIR mailing list that the HTTP uri could be = ignored if you had other means of verifying the cert, so if that's = correct the issue is already solved. Thanks for your feedback, Cullen! /O >=20 >=20 >=20 >=20 > On Jul 3, 2013, at 12:51 AM, Olle E. Johansson wrote: >=20 >> Hi! >>=20 >> I've tried to collect my thought about SIP and DANE on a slide set. = It's the way I brainstorm I guess :-) >>=20 >> You can view it here: >> = http://www.slideshare.net/oej/danebased-tls-verification-in-the-sip-protoc= ol >>=20 >> Feedback is always welcome!=20 >>=20 >> If this is on the right path, I'll try to write a draft. >>=20 >> We do have DNSsec support in Kamailio now, so hopefully I can get the = developer team to work with me to get some code for testing. >>=20 >> /Olle >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 From oej@edvina.net Thu Jul 4 05:46:18 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DBE21F9FF2; Thu, 4 Jul 2013 05:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M+SDaaqmHjh; Thu, 4 Jul 2013 05:46:18 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D905F21F9E48; Thu, 4 Jul 2013 05:46:15 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 502C793C1AF; Thu, 4 Jul 2013 12:46:13 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jul 2013 14:46:12 +0200 Message-Id: <18932A7A-8989-4B32-BAE5-1BCFD07BC97F@edvina.net> To: "dane@ietf.org list" , "dispatch@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dispatch] Updated version of SIP DANE brainstorm X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 12:46:18 -0000 Hi! I've updated my brainstorm of SIP & Dane. The new version can be found = here: http://www.slideshare.net/oej/sip-dane Changes: - Clarified TLSA records and validation (Cullen, Victor) - Added thoughts on SIP connection reuse SIP connection reuse is the art form of re-using a TLS connection = between two SIP servers for more than one destination - in the case of = SIP hosting with multiple domains. The current RFC is based on exchanging server and client certificates = with a list of domains in the SubjAltName field.=20 With DANE, there will be only the SRV host name. The server needs to = look up domains and if there's a secure delegation from a new domain to = a hostname where the server has a connection, add the domain to the domain table for that = connection and reuse it. Now the question is raised in my head - what about the client = certificate? We get a connection from an IP address and request a client certificate. = Is it really needed? In the current RFC it's a requirement. Server for example.com gets a connection from serverb.example.net. The = example.com domain relationship to the actual host srv02.example.com was verified using DANE and the cert validated correctly. Now if example.com has a SIP request addressed to example.net - it = checks DNS and gets DNSsec signed responses that points to = serverb.example.net. Is this enough to reuse the existing TLS connection for requests to = example.net? Or do we need a certificate on top of this somewhere? /O References: - RFC 5923 describes SIP connection reuse - RFC 5922 defines SIP domain certificates= From philippe.fouquart@orange.com Mon Jul 8 07:38:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385F321F9C95 for ; Mon, 8 Jul 2013 07:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.301, BAYES_50=0.001, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkLawi6+zoN9 for ; Mon, 8 Jul 2013 07:38:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB8D21F9B5F for ; Mon, 8 Jul 2013 07:38:14 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id B1D393B469A; Mon, 8 Jul 2013 16:38:13 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6591D35C06C; Mon, 8 Jul 2013 16:38:13 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 8 Jul 2013 16:38:12 +0200 From: To: "DRAGE, Keith (Keith)" , Andrew Allen , "dispatch@ietf.org" Thread-Topic: [dispatch] Notes and Summary of April 17 call on draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: Ac5DsEOLJ60tgoO0QGKMbkCcTXG9NAV7fMYQBl+AIaA= Date: Mon, 8 Jul 2013 14:38:12 +0000 Message-ID: <17129_1373294293_51DACED5_17129_4_7_B5939C6860701C49AA39C5DA5189448B0B34D7@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <949EF20990823C4C85C18D59AA11AD8B041DDC@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B041DDC@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_B5939C6860701C49AA39C5DA5189448B0B34D7PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.63327 Subject: Re: [dispatch] Notes and Summary of April 17 call on draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:38:23 -0000 --_000_B5939C6860701C49AA39C5DA5189448B0B34D7PEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andrew, I noted the recent publication of draft-allen-dispatch-imei-urn-as-instance= id-10 and was wondering whether clarification had been given to Keith's - n= ot so recent - question below, possibly off-line, which you could share wit= h the list. (Why ask for more than just a specification?) Thanks, Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of DRAGE, Keith (Keith) Sent: Sunday, May 26, 2013 1:22 AM To: Andrew Allen; dispatch@ietf.org Subject: Re: [dispatch] Notes and Summary of April 17 call on draft-montemu= rro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid I do have a question. This new RFC to be drafted would appear to be doing nothing more than a spe= c (T), which does not require an RFC to be published. So why not just a requirement to document rather than somehow have to put i= t out as a RFC. Surely that is just trying to turn the IETF into the policeman Keith ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Andrew Allen Sent: 29 April 2013 07:29 To: dispatch@ietf.org Subject: [dispatch] Notes and Summary of April 17 call on draft-montemurro-= gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid In order to make progress on draft-montemurro-gsma-imei-urn and draft-allen= -dispatch-imei-urn-as-instanceid a conference call was held on Wednesday April 17 attended by Culllen Jennings, Atle Monrad, John Luc Bakker and mys= elf. Below are the combined notes and summary from Cullen and I of this call on = the IMEI drafts: 1) change draft-allen-dispatch-imei-urn-as-instanceid to say IMEI is only u= sed in either a register request or also in an emergency invite request Cullen will then be OK with it from a privacy point of view as long as it e= xplains the trade offs. It should be highlighted in draft-montemurro-gsma-imei-urn that using the I= MEI as a security credential is a bad thing even though some popular commer= cial applications are actually doing this and some service providers are us= ing knowledge of the IMEI to verify the legitimacy of caller being the auth= orized user/owner of the device. The IMEI is usually extremely easy to obta= in by anyone who has very brief physical access to the device as it is ofte= n printed on the device beneath the battery and can be displayed by using a= well-known key press sequence. Change draft-allen-dispatch-imei-urn-as-instanceid to not be open to any ex= tension to URN but instead require a draft updating this draft if any param= eter other than ver=3D0 was to be included. Also add text in draft-montemu= rro-gsma-imei-urn and, draft-aindicating that extensions to the IMEI parame= ters will require an update of draft-allen-dispatch-imei-urn-as-instanceid. 2) Write a new separate draft that tries to deal with the OMA push to talk = case. This would have the UA include the IMEI in an INVITE request in very partic= ular instances where the UA knew that request was going to the POC server a= nd that the POC server would remove it. I'm not sure what I would think of = this draft - Cullen might hate it - but regardless of if folks thought it w= as good or bad, splitting it into a separate problem can allow the use in t= he first draft to proceed. Cullen would want this draft to be very clear on= how a UA knew it was "safe" to put the IMEI in a INVITE and Cullen does no= t think the IME should ever be in an anonymous INVITE. The current text ar= ound you only include the IMEI if you know it is safe does not seem impleme= ntable so Cullen would prefer something where it was really clear when the = UA did it and when it did not. Cullen thinks this is much easier to do in t= he specific case of push to talk than trying to solve it for all uses of an= INVITE so this should be easier to get people on board with than the curre= nt draft. Response to Cullen on the IME should never be in an anonymous INVITE point.= - in 3GPP networks there is really no such thing as an anonymous INVITE si= nce the P-CSCF always knows the identity of the UE and will always include = a P-Asserted-Identity header field. There are instead requests where privac= y is requested and the P-Asserted-Identity header field is removed at the = edge of the trust domain. Thus in my view there is no need for a UE in the = PoC case where it knows the PoC Server will remove the instance ID to prohi= bit inclusion of the IMEI. Cullen any comments to that? 3) Update draft-montemurro-gsma-imei-urn security section to clarify that t= he IMEI-SV is not updated based on the OS version or when new applications = are added but represents the software version of lower layer software that = has completed certification testing. I am in the process of updating the drafts as described above. Comments on the above are of course welcome Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_B5939C6860701C49AA39C5DA5189448B0B34D7PEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andrew,=

&n= bsp;

I noted= the recent publication of draft-allen-dispatch-imei-urn-as-instanceid-10 a= nd was wondering whether clarification had been given to Keith’s - no= t so recent - question below, possibly off-line, which you could share with the list. (Why ask for more than just a specifi= cation?)

&n= bsp;

Thanks,=

Regards= ,

&n= bsp;

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

&n= bsp;

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ie= tf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Sunday, May 26, 2013 1:22 AM
To: Andrew Allen; dispatch@ietf.org
Subject: Re: [dispatch] Notes and Summary of April 17 call on draft-= montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid

 

I do have a que= stion.

 

This new RFC to= be drafted would appear to be doing nothing more than a spec (T), which do= es not require an RFC to be published.

 

So why not just= a requirement to document rather than somehow have to put it out as a RFC.=

 

Surely that is = just trying to turn the IETF into the policeman

 

Keith

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ie= tf.org] On Behalf Of Andrew Allen
Sent: 29 April 2013 07:29
To: dispatch@ietf.org
Subject: [dispatch] Notes and Summary of April 17 call on draft-mont= emurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid=

 

 

In order to make progress on= draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instan= ceid a conference call was held on Wednesday

April 17 attended by Culllen= Jennings, Atle Monrad, John Luc Bakker and myself.

 

Below are the combined notes= and summary from Cullen and I of this call on the IMEI drafts:<= /span>

 

 

1) change draft-allen-dispat= ch-imei-urn-as-instanceid to say IMEI is only used in either a register req= uest or also in an emergency invite request

 

Cullen will then be OK with = it from a privacy point of view as long as it explains the trade offs.

 

It should be highlighted in = draft-montemurro-gsma-imei-urn that using the IMEI as a security credential= is a bad thing even though some popular commercial applications are actual= ly doing this and some service providers are using knowledge of the IMEI to verify the legitimacy of caller being t= he authorized user/owner of the device. The IMEI is usually extremely easy = to obtain by anyone who has very brief physical access to the device as it = is often printed on the device beneath the battery and can be displayed by using a well-known key press sequence.=

 

Change draft-allen-dispatch-= imei-urn-as-instanceid to not be open to any extension to URN but instead r= equire a draft updating this draft if any parameter other than ver=3D0 was = to be included.  Also add text in draft-montemurro-gsma-imei-urn and, draft-aindicating that extensions to the IMEI parameters will require= an update of draft-allen-dispatch-imei-urn-as-instanceid.

 

 

2) Write a new separate draf= t that tries to deal with the OMA push to talk case.

 

This would have the UA inclu= de the IMEI in an INVITE request in very particular instances where the UA = knew that request was going to the POC server and that the POC server would= remove it. I'm not sure what I would think of this draft - Cullen might hate it - but regardless of if folks th= ought it was good or bad, splitting it into a separate problem can allow th= e use in the first draft to proceed. Cullen would want this draft to be ver= y clear on how a UA knew it was "safe" to put the IMEI in a INVITE and Cullen does not think the= IME should ever be in an anonymous INVITE.  The current text around y= ou only include the IMEI if you know it is safe does not seem implementable= so Cullen would prefer something where it was really clear when the UA did it and when it did not. Cullen thinks this is= much easier to do in the specific case of push to talk than trying to solv= e it for all uses of an INVITE so this should be easier to get people on bo= ard with than the current draft.

 

Response to Cullen on the IM= E should never be in an anonymous INVITE point. - in 3GPP networks there is= really no such thing as an anonymous INVITE since the P-CSCF always knows = the identity of the UE and will always include a P-Asserted-Identity header field. There are instead requests whe= re privacy is requested and the  P-Asserted-Identity header field is r= emoved at the edge of the trust domain. Thus in my view there is no need fo= r a UE in the PoC case where it knows the PoC Server will remove the instance ID to prohibit inclusion of the IM= EI. Cullen any comments to that?

 

3) Update draft-montemurro-g= sma-imei-urn security section to clarify that the IMEI-SV is not updated ba= sed on the OS version or when new applications are added but represents the= software version of lower layer software that has completed certification testing.

 

I am in the process of updat= ing the drafts as described above.

 

Comments on the above are of co= urse welcome

 

Andrew

---------------------= ------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_B5939C6860701C49AA39C5DA5189448B0B34D7PEXCVZYM12corpora_-- From prvs=2901c298c8=aallen@blackberry.com Mon Jul 8 11:11:19 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01C921F9BC8 for ; Mon, 8 Jul 2013 11:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyYPK3Bo3bc5 for ; Mon, 8 Jul 2013 11:11:15 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4CD21F8ECE for ; Mon, 8 Jul 2013 11:11:15 -0700 (PDT) X-AuditID: 0a412830-b7f456d000006310-b2-51db00978f11 Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 25.A6.25360.7900BD15; Mon, 8 Jul 2013 13:10:31 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0328.009; Mon, 8 Jul 2013 13:10:31 -0500 From: Andrew Allen To: "dispatch@ietf.org" Thread-Topic: New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: Ac58BgpJlPAN+XjkR3qQL69BJ6Z0zg== Date: Mon, 8 Jul 2013 18:10:30 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338DC1690XMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsXC5Zyvozud4XagwdaV5hZLJy1gdWD0WLLk J1MAY1QDo01SYklZcGZ6nr6dTWJeXn5JYkmqQkpqcbKtkk9qemKOQkBRZllicqWCS2Zxck5i Zm5qkZJCZoqtkomSQkFOYnJqbmpeia1SYkFBal6Kkh2XAgawASrLzFNIzUvOT8nMS7dV8gz2 17WwMLXUNVSy003o5MlYs2Q6c8HhqoqDd2czNzB+ye5i5OSQEDCR2Dn5NCOELSZx4d56ti5G Lg4hgTYmibvvn4AlhAQ2MUrM/84HYrMJaEnsPzydCcQWEdCWOLqqixnEFhbIklgycTlUPF/i 7qT9bBC2nkTfrTcsXYwcHCwCKhING+1AwrwCHhInr79kB7EZBWQldp+9DtbKLCAucevJfCaI ewQkluw5zwxhi0q8fPyPFcJWlJixZz4rRH2+RN/8PSwQMwUlTs58wjKBUWgWklGzkJTNQlIG EdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzEK5mYUG5gZJucl6xVl5urlpZZsYgRFvqOG wQ7G9+8tDjEKcDAq8fCq/7gVKMSaWFZcmXuIUYKDWUmEd9MxoBBvSmJlVWpRfnxRaU5q8SHG IGCgTGSW4k7OByalvJJ4YwMDIjlK4rzWZ88GCgmkA5NSdmpqQWoRzFAmDk6QpVxSIsXA1JJa lFhakhEPSoDxxcAUKNXAGDbpZsu0wHmNv6ZF77/5uastrXnP32n/7m2f4PQrwP7MZZf+cw7i 07tsHqlbZWX62BnnMUR97zS2PfrgsOKNgNglcqax7ms4BO5nPl976N/Df7J17xwDLy/UdG44 y7mx6YXdRMaD6zNvnnor6Tqp1C/1zpRF2vdSGg32eh3OEt/zrzzioeX72UosxRmJhlrMRcWJ ALqs4pRKAwAA Subject: [dispatch] New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:11:19 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338DC1690XMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei= -urn-as-instanceid were recently submitted http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-15.txt The diff from version 14 is at: http://www.ietf.org/rfcdiff?url2=3Ddraft-montemurro-gsma-imei-urn-15 http://www.ietf.org/internet-drafts/draft-allen-dispatch-imei-urn-as-instanc= eid-10.txt The diff from version 9 is at: http://www.ietf.org/rfcdiff?url2=3Ddraft-allen-dispatch-imei-urn-as-instance= id-10 These versions reflect the PROTO review comments. The following significant changes have been made: draft-montemurro-gsma-imei-urn: 1. Corrections to the ABNF based on output from Bill Fenner's tool: http://tools.ietf.org/tools/bap/abnf.cgi. and also corrected an error that would have resulted in a superfluous "=3D"= in the case of a parameter without a value. Also the IMEI ABNF has been linked together with the URN ABNF for a single c= omplete ABNF. 2. The section regarding binary encoding of the IMEI has been rewritte= n and clarified. 3. The dates of the referenced 3GPP specifications have been updated t= o the latest versions. 4. Various editorial and formatting corrections have been made. draft-allen-dispatch-imei-urn-as-instanceid: 1. The MSC Server for SR-VCC has been included in the text - this is a= nother element in the 3GPP architecture that for the purposes of the draft p= erforms similar functions to the MSC Server for ICS which was already mentio= ned. 2. The UAC and UAS sections have been modified with reference to sendi= ng of responses removed from the UAC section and the requirement for an RFC= for inclusion of an instance-id containing the IMEI in a Non-REGISTER or no= n-Emergency session related response also added to the UAS section. 5. An IANA considerations section has been added (even though there is= nothing for IANA to do) since this is required. 6. The dates of the referenced 3GPP specifications have been updated t= o the latest versions. 7. Various editorial and formatting corrections have been made. I would especially like to thank James Yu for the extensive review of both d= rafts and his comments which uncovered several issues and greatly contribute= d to the readability of the documents. The only outstanding issue I am aware of is Keith Drage's comment of May 25t= h which asks why RFC required and not specification required for inclusion o= f an instance-id containing the IMEI in a Non-REGISTER or non-Emergency sess= ion related response. I have asked Cullen to respond to this as it was his r= equest to require additional RFCs for any future expansion of the usage. Thanks Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338DC1690XMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

 

New versions of draft-montemurro-gsma-imei-urn and dr= aft-allen-dispatch-imei-urn-as-instanceid were recently submitted=

 

http://www.ietf.org/internet-drafts/draft-m= ontemurro-gsma-imei-urn-15.txt

The diff from version 14 is at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-mont= emurro-gsma-imei-urn-15

 

http://www.ietf.org/interne= t-drafts/draft-allen-dispatch-imei-urn-as-instanceid-10.txt

The diff from version 9 is at:

http://www.ietf.org/rfcdiff?url2=3D= draft-allen-dispatch-imei-urn-as-instanceid-10

 

These versions reflect the PROTO review comments.

 

The following significant changes have been made:

 

draft-montemurro-gsma-imei-urn:

 

1.       Corrections to the ABNF based on output from Bill Fe= nner's tool:

http://tools.ietf.org/tools/bap/abnf.cgi.=

and also corrected an err= or that would have resulted in a superfluous “=3D” in the case o= f a parameter without a value.

Also the IMEI ABNF has be= en linked together with the URN ABNF for a single complete ABNF.<= /p>

 

2.      = ; The section regarding binary encoding of the IMEI ha= s been rewritten and clarified.

 

3.      = ; The dates of the referenced 3GPP specifications have= been updated to the latest versions.

 

4.      = ; Various editorial and formatting corrections have be= en made.

 

draft-allen-dispatch-imei-urn-as-instanceid:

 

1.      = ; The MSC Server for SR-VCC has been included in the t= ext – this is another element in the 3GPP architecture that for the pu= rposes of the draft performs similar functions to the MSC Server for ICS whi= ch was already mentioned.

 

2.      = ; The UAC and UAS sections have been modified with ref= erence to sending of responses removed from the UAC section and the requirem= ent for an RFC for inclusion of an instance-id containing the IMEI in a Non-= REGISTER or non-Emergency session related response also added to the UAS section.

 

5.      = ; An IANA considerations section has been added (even= though there is nothing for IANA to do) since this is required.<= /p>

 

6.      = ; The dates of the referenced 3GPP specifications have= been updated to the latest versions.

 

7.      = ; Various editorial and formatting corrections have be= en made.

 

I would especially like to thank James Yu for the ext= ensive review of both drafts and his comments which uncovered several issues= and greatly contributed to the readability of the documents.

 

The only outstanding issue I am aware of is Keith Dra= ge’s comment of May 25th which asks why RFC required and no= t specification required for inclusion of an instance-id containing the IMEI= in a Non-REGISTER or non-Emergency session related response. I have asked Cullen to respond to this as it was his requ= est to require additional RFCs for any future expansion of the usage.

 

Thanks

Andrew

 

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338DC1690XMB104ADSrimnet_-- From carl_klatsky@cable.comcast.com Tue Jul 9 11:30:18 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F5021F99DD for ; Tue, 9 Jul 2013 11:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzJxv471554i for ; Tue, 9 Jul 2013 11:30:13 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9CD21F99C6 for ; Tue, 9 Jul 2013 11:30:13 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.57967385; Tue, 09 Jul 2013 14:28:16 -0400 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 9 Jul 2013 14:30:05 -0400 Received: from PACDCEXMB15.cable.comcast.com ([169.254.2.127]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Tue, 9 Jul 2013 14:30:05 -0400 From: "Klatsky, Carl" To: "'dispatch@ietf.org'" Thread-Topic: New Version Notification for draft-klatsky-dispatch-ipv6-impact-ipv4-01.txt Thread-Index: AQHOfM59i/TATMDjoE6MbV1fAXeZrJlcqlww Date: Tue, 9 Jul 2013 18:30:04 +0000 Message-ID: <6C15A6B88541034E912E94C2D8BC3E87C96D5160@PACDCEXMB15.cable.comcast.com> References: <20130709180228.24023.45732.idtracker@ietfa.amsl.com> In-Reply-To: <20130709180228.24023.45732.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.178] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [dispatch] FW: New Version Notification for draft-klatsky-dispatch-ipv6-impact-ipv4-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:30:18 -0000 SGksDQoNCk9uIGJlaGFsZiBvZiB0aGUgYXV0aG9ycyBvZiB0aGlzIGRyYWZ0LCBhIG5ldyB2ZXJz aW9uIGhhcyBiZWVuIHVwbG9hZGVkIHRvIGFkZHJlc3MgY29tbWVudHMgcmFpc2VkIGhlcmUgb24g dGhlIGRpc3BhdGNoIGxpc3QuICBBZGRpdGlvbmFsIGZlZWRiYWNrIG9uIHRoaXMgdmVyc2lvbiBp ZiB0aGUgZHJhZnQgaXMgcmVxdWVzdGVkLg0KDQpUaGFua3MgJiBSZWdhcmRzLA0KwqANCkNhcmwg S2xhdHNreQ0KQ29tY2FzdA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN ClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDksIDIwMTMgMjowMiBQTQ0KVG86IE9sbGUgRS5Kb2hhbnNz b247IEdvbnphbG8gU2FsZ3VlaXJvOyBSaWZhYXQgU2hla2gtWXVzZWY7IEtsYXRza3ksIENhcmw7 IEFuZHJldyBIdXR0b24NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQta2xhdHNreS1kaXNwYXRjaC1pcHY2LWltcGFjdC1pcHY0LTAxLnR4dA0KDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1rbGF0c2t5LWRpc3BhdGNoLWlwdjYtaW1wYWN0LWlwdjQtMDEu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IENhcmwgS2xhdHNreSBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQta2xhdHNr eS1kaXNwYXRjaC1pcHY2LWltcGFjdC1pcHY0DQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBJbnRl cm9wZXJhYmlsaXR5IEltcGFjdHMgb2YgSVB2NiBJbnRlcndvcmtpbmcgd2l0aCBFeGlzdGluZyBJ UHY0IFNJUCBJbXBsZW1lbnRhdGlvbnMNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTA5DQpHcm91 cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTANClVSTDogICAg ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta2xhdHNr eS1kaXNwYXRjaC1pcHY2LWltcGFjdC1pcHY0LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtsYXRza3ktZGlzcGF0Y2gtaXB2Ni1p bXBhY3QtaXB2NA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1rbGF0c2t5LWRpc3BhdGNoLWlwdjYtaW1wYWN0LWlwdjQtMDENCkRpZmY6ICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQta2xhdHNreS1kaXNwYXRj aC1pcHY2LWltcGFjdC1pcHY0LTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBjYXB0 dXJlcyBwb3RlbnRpYWwgaW1wYWN0cyB0byBJUHY0IFNJUCBpbXBsZW1lbnRhdGlvbnMNCiAgIHdo ZW4gaW50ZXJ3b3JraW5nIHdpdGggSVB2NiBTSVAgaW1wbGVtZW50YXRpb25zLiAgQWx0aG91Z2gg c29tZQ0KICAgYW1vdW50IG9mIGludGVyd29ya2luZyB0cmFuc2xhdGlvbiB3aWxsIG9jY3VyIGF0 IHRoZSBuZXR3b3JrIGFuZA0KICAgYXBwbGljYXRpb24gbGF5ZXJzLCBhbiBJUHY0IFNJUCBhcHBs aWNhdGlvbiBtYXkgc3RpbGwgZW5jb3VudGVyIGEgU0lQDQogICBtZXNzYWdlIHdpdGggc29tZSBJ UHY2IHZhbHVlcyBpbiBpdCwgcmVzdWx0aW5nIGluIHVuZm9yZXNlZW4gZXJyb3INCiAgIGNvbmRp dGlvbnMuICBTdWNoIHBvdGVudGlhbCBzY2VuYXJpb3Mgd2lsbCBiZSBpZGVudGlmaWVkIGluIHRo aXMNCiAgIGRvY3VtZW50IHNvIHRoYXQgU0lQIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgY2FuIGRl ZmluZSBzb2x1dGlvbnMgdG8NCiAgIGhhbmRsZSB0aGVzZSBjYXNlcy4gIE5vdGUsIHRoaXMgZG9j dW1lbnQgaXMgbm90IGludGVuZGVkIHRvIGJlIGFuDQogICBleGhhdXN0aXZlIGxpc3QsIHJhdGhl ciB0byBwcm92aWRlIGFuIG92ZXJ2aWV3IG9mIHNvbWUgb2YgdGhlIG1vcmUNCiAgIGNvbW1vbmx5 IGVuY291bnRlcmVkIHBvdGVudGlhbCBzY2VuYXJpb3MuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From richard.ejzak@alcatel-lucent.com Tue Jul 9 12:32:46 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2926721F9D01; Tue, 9 Jul 2013 12:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-CQnYM62pcu; Tue, 9 Jul 2013 12:32:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1F221F9D02; Tue, 9 Jul 2013 12:32:35 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r69JWVRv009433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Jul 2013 14:32:32 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r69JWVTA027735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 15:32:31 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.181]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 9 Jul 2013 15:32:28 -0400 From: "Ejzak, Richard P (Richard)" To: "dispatch@ietf.org" , "mmusic@ietf.org WG" Thread-Topic: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt Thread-Index: AQHOfDMs+G1XaZJM/UuxFbqIPUpRyplcuxag Date: Tue, 9 Jul 2013 19:32:28 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D80279E@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 19:32:46 -0000 UGxlYXNlIG5vdGUgb3VyIHByb3Bvc2VkIGFsdGVybmF0aXZlIHRvIGRyYWZ0LXBkLW1zcnAtd2Vi cnRjLTAwIGZvciBob3cgdG8gdXNlIERhdGFDaGFubmVsIHRyYW5zcG9ydCBmb3IgTVNSUC4gIE91 ciBkcmFmdCBkb2VzIG5vdCBwbGFjZSByZXN0cmljdGlvbnMgb24gdGhlIG51bWJlciBvZiBNU1JQ IHNlc3Npb25zIHRoYXQgY2FuIGJlIGVzdGFibGlzaGVkIHdpdGhpbiBhbiBTQ1RQIGFzc29jaWF0 aW9uIGFuZCBkZXNjcmliZXMgYWx0ZXJuYXRpdmVzIGZvciB1c2luZyBhIGdhdGV3YXkgdG8gaW50 ZXJjb25uZWN0IHRvIGV4aXN0aW5nIE1TUlAgZW5kcG9pbnRzLiAgVGhlIFNEUCBleHRlbnNpb25z IGRlc2NyaWJlZCBhcmUgYXBwbGljYWJsZSB0byBvdGhlciBwb3RlbnRpYWwgRGF0YUNoYW5uZWwg c3ViLXByb3RvY29scyBzdWNoIGFzIFQuMTQwLCBCRkNQLCBULjM4LCBldGMuDQoNClJpY2hhcmQN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1 bHkgMDgsIDIwMTMgNjozMSBQTQ0KVG86IEVqemFrLCBSaWNoYXJkIFAgKFJpY2hhcmQpOyBNQVJD T04sIEpFUk9NRSAoSkVST01FKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1tYXJjb24tbXNycC1vdmVyLXdlYnJ0Yy1kYXRhLWNoYW5uZWxzLTAwLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYXJjb24tbXNycC1vdmVyLXdlYnJ0Yy1kYXRh LWNoYW5uZWxzLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKZXJv bWUgTWFyY29uIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 CSBkcmFmdC1tYXJjb24tbXNycC1vdmVyLXdlYnJ0Yy1kYXRhLWNoYW5uZWxzDQpSZXZpc2lvbjoJ IDAwDQpUaXRsZToJCSBNU1JQIG92ZXIgV2ViUlRDIGRhdGEgY2hhbm5lbHMNCkNyZWF0aW9uIGRh dGU6CSAyMDEzLTA3LTA5DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBv ZiBwYWdlczogMTINClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtbWFyY29uLW1zcnAtb3Zlci13ZWJydGMtZGF0YS1jaGFubmVscy0wMC50 eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1tYXJjb24tbXNycC1vdmVyLXdlYnJ0Yy1kYXRhLWNoYW5uZWxzDQpIdG1saXplZDogICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcmNvbi1tc3JwLW92ZXItd2VicnRj LWRhdGEtY2hhbm5lbHMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoZSBSZWFsLVRpbWUgQ29tbXVu aWNhdGlvbiBpbiBXRUItYnJvd3NlcnMgKFJUQ1dlYikgd29ya2luZyBncm91cCBpcw0KICAgY2hh cmdlZCB0byBwcm92aWRlIHByb3RvY29scyB0byBzdXBwb3J0IGRpcmVjdCBpbnRlcmFjdGl2ZSBy aWNoDQogICBjb21tdW5pY2F0aW9uIHVzaW5nIGF1ZGlvLCB2aWRlbywgYW5kIGRhdGEgYmV0d2Vl biB0d28gcGVlcnMnIHdlYi0NCiAgIGJyb3dzZXJzLiAgRm9yIHRoZSBzdXBwb3J0IG9mIGRhdGEg Y29tbXVuaWNhdGlvbiwgdGhlIFJUQ1dlYiB3b3JraW5nDQogICBncm91cCBoYXMgaW4gcGFydGlj dWxhciBkZWZpbmVkIHRoZSBjb25jZXB0IG9mIGJpLWRpcmVjdGlvbmFsIGRhdGENCiAgIGNoYW5u ZWxzIG92ZXIgU0NUUCwgd2hlcmUgZWFjaCBkYXRhIGNoYW5uZWwgbWlnaHQgYmUgdXNlZCB0bw0K ICAgdHJhbnNwb3J0IG90aGVyIHByb3RvY29scywgY2FsbGVkIHN1Yi1wcm90b2NvbHMuICBUaGlz IGRvY3VtZW50DQogICBzcGVjaWZpZXMgaG93IHRoZSBNZXNzYWdlIFNlc3Npb24gUmVsYXkgUHJv dG9jb2wgKE1TUlApIGNhbiBiZQ0KICAgaW5zdGFudGlhdGVkIGFzIGEgV2ViUlRDIGRhdGEgY2hh bm5lbCBzdWItcHJvdG9jb2wsIHVzaW5nIHRoZSBTRFANCiAgIG9mZmVyL2V4Y2hhbmdlIHRvIG5l Z290aWF0ZSBvdXQtb2YtYmFuZCB0aGUgc3ViLXByb3RvY29sIHNwZWNpZmljDQogICBwYXJhbWV0 ZXJzLiAgVHdvIG5ldHdvcmsgY29uZmlndXJhdGlvbnMgYXJlIGRvY3VtZW50ZWQ6IGEgV2ViUlRD IGVuZC0NCiAgIHRvLWVuZCBjb25maWd1cmF0aW9uIChjb25uZWN0aW5nIHR3byBNU1JQIG92ZXIg ZGF0YSBjaGFubmVsDQogICBlbmRwb2ludHMpLCBhbmQgYSBnYXRld2F5IGNvbmZpZ3VyYXRpb24g KGNvbm5lY3RpbmcgYW4gTVNSUCBvdmVyIGRhdGENCiAgIGNoYW5uZWwgZW5kcG9pbnQgd2l0aCBh biBNU1JQIG92ZXIgVENQIGVuZHBvaW50KS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From richard.ejzak@alcatel-lucent.com Wed Jul 10 07:22:49 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F8421F99F4; Wed, 10 Jul 2013 07:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW+udQi9kY3M; Wed, 10 Jul 2013 07:22:43 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1B41011E8167; Wed, 10 Jul 2013 07:22:41 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6AEMc0q025991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Jul 2013 09:22:38 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r6AEMbKv026861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 10:22:38 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.181]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 10 Jul 2013 10:22:37 -0400 From: "Ejzak, Richard P (Richard)" To: Gavin Llewellyn Thread-Topic: [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt Thread-Index: AQHOfWPFLqfwD9/ad0qtPZT+Eb2kHZld542g Date: Wed, 10 Jul 2013 14:22:36 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D802975@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F3D80279E@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D802975US70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "dispatch@ietf.org" , "mmusic@ietf.org WG" Subject: Re: [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:22:49 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F3D802975US70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gavin, Thanks for your support of our approach and for your comments. It's great = that you are planning an implementation along these lines. I am including mmusic on this distribution to not exclude anyone who may be= interested, but please limit the distribution to dispatch only for subsequ= ent emails in this thread. Regarding why we chose to create a new draft: Our approach was sufficiently= different from yours that we felt a separate draft was a better idea in th= e short term. We can merge when it's appropriate to do so. Even though we= have no significant difference of opinion regarding the SDP extensions nee= ded, we clearly have different views regarding the value of a DataChannel g= ateway. It would be good to hear other opinions on this matter, as you are= clearly heavily committed to your preference. Our preference for support of a DataChannel gateway model is based on the n= umerous advantages of DataChannels. Just a partial list: We have one trans= port mechanism for all cases; we don't have to offer two options or perform= fallback/retry procedures on failure of one transport option; we can easil= y multiplex all media and sub-protocols together; we can leverage the integ= rated browser handling of multiple flows of different priority; we have to = be able to interoperate with legacy tcp/tls endpoints anyway. We look forward to continuing the debate. BR, Richard From: Gavin Llewellyn [mailto:gavin.llewellyn@crocodilertc.net] Sent: Wednesday, July 10, 2013 6:51 AM To: Ejzak, Richard P (Richard) Cc: dispatch@ietf.org; mmusic@ietf.org WG Subject: Re: [dispatch] FW: New Version Notification for draft-marcon-msrp-= over-webrtc-data-channels-00.txt As a co-author of draft-pd-msrp-webrtc-00, I support this new draft for est= ablishment of MSRP sessions between WebRTC endpoints. The SDP enhancements= allowing re-use of the SCTP association is very much along the lines of wh= at we had in mind for the next version of our draft, but we have not had ti= me to complete it. We will likely be implementing this as a feature in our= WebRTC library in the near future, as the DataChannel implementations in b= rowsers mature (support SCTP, reliable delivery, binary data, etc). Having said that, it would have been appreciated if the authors had contact= ed Peter and/or myself to discuss the existing draft and its limitations - = we would have been happy to receive feedback and work together to find the = best solution going forward. I cannot see the value in introducing DataChannel gateways as a means to co= mmunicate with traditional TCP-based MSRP endpoints. I believe this is bet= ter catered for by the WebSocket-based solution, as described in draft-pd-d= ispatch-msrp-websocket, which already has client and server implementations= , and is currently in-use in a production environment. Given the (intentio= nal) similarities between the WebSocket and DataChannel APIs, it is not dif= ficult for the client application to support both transports. I would like= to see a clear justification for this aspect of the draft. One minor correction: the opening paragraph of section 5.2.3 appears to ref= erence the wrong SDP syntax for sub-protocol-specific attributes; I believe= it should reference the syntax for the new "wdcsa" attribute. Regards, Gavin Llewellyn -- Gavin Llewellyn Principal Design Engineer Crocodile RCS Ltd GPG key: 0xF8F6FFF2 On 9 July 2013 20:32, Ejzak, Richard P (Richard) > wrote: Please note our proposed alternative to draft-pd-msrp-webrtc-00 for how to = use DataChannel transport for MSRP. Our draft does not place restrictions = on the number of MSRP sessions that can be established within an SCTP assoc= iation and describes alternatives for using a gateway to interconnect to ex= isting MSRP endpoints. The SDP extensions described are applicable to othe= r potential DataChannel sub-protocols such as T.140, BFCP, T.38, etc. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Monday, July 08, 2013 6:31 PM To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME) Subject: New Version Notification for draft-marcon-msrp-over-webrtc-data-ch= annels-00.txt A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt has been successfully submitted by Jerome Marcon and posted to the IETF rep= ository. Filename: draft-marcon-msrp-over-webrtc-data-channels Revision: 00 Title: MSRP over WebRTC data channels Creation date: 2013-07-09 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-marcon-msrp-over= -webrtc-data-channels-00.txt Status: http://datatracker.ietf.org/doc/draft-marcon-msrp-over-web= rtc-data-channels Htmlized: http://tools.ietf.org/html/draft-marcon-msrp-over-webrtc-d= ata-channels-00 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communication using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP, where each data channel might be used to transport other protocols, called sub-protocols. This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a WebRTC data channel sub-protocol, using the SDP offer/exchange to negotiate out-of-band the sub-protocol specific parameters. Two network configurations are documented: a WebRTC end- to-end configuration (connecting two MSRP over data channel endpoints), and a gateway configuration (connecting an MSRP over data channel endpoint with an MSRP over TCP endpoint). The IETF Secretariat _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_03FBA798AC24E3498B74F47FD082A92F3D802975US70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Gavin,

Thanks for your support o= f our approach and for your comments.  It’s great that you are p= lanning an implementation along these lines.

 <= /p>

I am including mmusic on = this distribution to not exclude anyone who may be interested, but please l= imit the distribution to dispatch only for subsequent emails in this thread.

 <= /p>

Regarding why we chose to= create a new draft: Our approach was sufficiently different from yours tha= t we felt a separate draft was a better idea in the short term.  We can merge when it’s appropriate to do so.  Even = though we have no significant difference of opinion regarding the SDP exten= sions needed, we clearly have different views regarding the value of a Data= Channel gateway.  It would be good to hear other opinions on this matter, as you are clearly heavily committed to your pref= erence.

 <= /p>

Our preference for suppor= t of a DataChannel gateway model is based on the numerous advantages of Dat= aChannels.  Just a partial list: We have one transport mechanism for all cases; we don’t have to offer two options or perform fallbac= k/retry procedures on failure of one transport option; we can easily multip= lex all media and sub-protocols together; we can leverage the integrated br= owser handling of multiple flows of different priority; we have to be able to interoperate with legacy tcp/tls endpoints= anyway.

 <= /p>

We look forward to contin= uing the debate.

 <= /p>

BR, Richard

 <= /p>

From: Gavin Ll= ewellyn [mailto:gavin.llewellyn@crocodilertc.net]
Sent: Wednesday, July 10, 2013 6:51 AM
To: Ejzak, Richard P (Richard)
Cc: dispatch@ietf.org; mmusic@ietf.org WG
Subject: Re: [dispatch] FW: New Version Notification for draft-marco= n-msrp-over-webrtc-data-channels-00.txt

 

As a co-author of draft-pd-msrp-webr= tc-00, I support this new draft for establishment of MSRP sessions between = WebRTC endpoints.  The SDP enhancements allowing re-use of the SCTP association is very much along the lines of what we had in mind for t= he next version of our draft, but we have not had time to complete it. &nbs= p;We will likely be implementing this as a feature in our WebRTC library in= the near future, as the DataChannel implementations in browsers mature (support SCTP, reliable delivery, binar= y data, etc).

 

Having said that, it would have been appr= eciated if the authors had contacted Peter and/or myself to discuss the exi= sting draft and its limitations - we would have been happy to receive feedback and work together to find the best solution going forw= ard.

 

I cannot see the value in introducing Dat= aChannel gateways as a means to communicate with traditional TCP-based MSRP= endpoints.  I believe this is better catered for by the WebSocket-based solution, as described in draft-pd-dispatch-msrp-web= socket, which already has client and server implementations, and is current= ly in-use in a production environment.  Given the (intentional) similarities between the WebSocket and DataChannel APIs, it is not difficu= lt for the client application to support both transports.  I would lik= e to see a clear justification for this aspect of the draft.

 

One minor correction: the opening paragraph of section 5.2= .3 appears to reference the wrong SDP syntax for sub-protocol-specific attr= ibutes; I believe it should reference the syntax for the new "wdcsa" attribute.

 

Regards,

Gavin Llewellyn

 

--

Gavin Llewellyn

Principal Design Engineer

Crocodile RCS Ltd

GPG key: 0xF8F6FFF2

 

On 9 July 2013 20:32, Ejzak, Richard P (Richard) <= ;rich= ard.ejzak@alcatel-lucent.com> wrote:

Please note our proposed alternative to draft-pd-msr= p-webrtc-00 for how to use DataChannel transport for MSRP.  Our draft = does not place restrictions on the number of MSRP sessions that can be esta= blished within an SCTP association and describes alternatives for using a gateway to interconnect to existing MSR= P endpoints.  The SDP extensions described are applicable to other pot= ential DataChannel sub-protocols such as T.140, BFCP, T.38, etc.

Richard

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 08, 2013 6:31 PM
To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME)
Subject: New Version Notification for draft-marcon-msrp-over-webrtc-data-ch= annels-00.txt


A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt has been successfully submitted by Jerome Marcon and posted to the IETF rep= ository.

Filename:        draft-marcon-msrp-over-webrtc-data-cha= nnels
Revision:        00
Title:           MSRP over WebRTC data channels Creation date:   2013-07-09
Group:           Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-chan= nels-00.txt
Status:          ht= tp://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels
Htmlized:        http://to= ols.ietf.org/html/draft-marcon-msrp-over-webrtc-data-channels-00


Abstract:
   The Real-Time Communication in WEB-browsers (RTCWeb) working g= roup is
   charged to provide protocols to support direct interactive ric= h
   communication using audio, video, and data between two peers' = web-
   browsers.  For the support of data communication, the RTC= Web working
   group has in particular defined the concept of bi-directional = data
   channels over SCTP, where each data channel might be used to    transport other protocols, called sub-protocols.  This do= cument
   specifies how the Message Session Relay Protocol (MSRP) can be=
   instantiated as a WebRTC data channel sub-protocol, using the = SDP
   offer/exchange to negotiate out-of-band the sub-protocol speci= fic
   parameters.  Two network configurations are documented: a= WebRTC end-
   to-end configuration (connecting two MSRP over data channel    endpoints), and a gateway configuration (connecting an MSRP ov= er data
   channel endpoint with an MSRP over TCP endpoint).




The IETF Secretariat

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

--_000_03FBA798AC24E3498B74F47FD082A92F3D802975US70UWXCHMBA04z_-- From peter.dunkley@crocodilertc.net Wed Jul 10 07:57:49 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE7321F9AFB for ; Wed, 10 Jul 2013 07:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.815 X-Spam-Level: X-Spam-Status: No, score=0.815 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bP8nhl59cMIM for ; Wed, 10 Jul 2013 07:57:44 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2892321F853A for ; Wed, 10 Jul 2013 07:57:00 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so15574586ied.14 for ; Wed, 10 Jul 2013 07:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZLCeOweDxT4PiWc3mQeCxKrRW0Z8TcEQsbRTrYJxElA=; b=U6mkebSkBwPPlmhJ57Ah3U56BHB5M1eWigndUzZww75HBow+BcrpC+5O5FLcjG1aLJ sLhtDAVR+c2fM+3aGqyJOZpOEuoMqLH0NU+b4FTlF9HFyNCXxa4uH+5kE0iv+FdZD54t SMa2XL+NHoViKl0Y5raaWQdTdH2VijHYOHSDo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZLCeOweDxT4PiWc3mQeCxKrRW0Z8TcEQsbRTrYJxElA=; b=DeCNHBs4S91g8+KMMLi0HD8AsVs85Ofdxy3J068de0TXDExyw/z5K/tZ0zyYszj5Mm xdngsxfVHAMikzoJj2pGCO5t+0AdcfQ6GmEFvaE7pvR8zgSbTF4W+4CCC3u1hM7vum+r k+QjbaWC74gyyY0SnMUoyuJa/pPsaZHgUH2R7nqi/G/C4UlZHnOY4swqsFziXIT0UgMu yaPCDZqN+1FQxBwoUW3JtVOQ2KBau4pHl2g9GLJBV2APnTGFsq1NNobQ8HYgx+fqEMKm p6zokqSZrthKLZ8z1X8s/vORnGyybUhzQNUJE1fwnH0mKb4jkuH+XdwaWck30PQSYgob PpCw== MIME-Version: 1.0 X-Received: by 10.50.18.5 with SMTP id s5mr12030291igd.6.1373468219635; Wed, 10 Jul 2013 07:56:59 -0700 (PDT) Received: by 10.64.137.163 with HTTP; Wed, 10 Jul 2013 07:56:59 -0700 (PDT) X-Originating-IP: [90.152.0.102] In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D802975@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F3D80279E@US70UWXCHMBA04.zam.alcatel-lucent.com> <03FBA798AC24E3498B74F47FD082A92F3D802975@US70UWXCHMBA04.zam.alcatel-lucent.com> Date: Wed, 10 Jul 2013 15:56:59 +0100 Message-ID: From: Peter Dunkley To: "dispatch@ietf.org" , "mmusic@ietf.org WG" Content-Type: multipart/alternative; boundary=089e013cc1c4578b7304e1297d42 X-Gm-Message-State: ALoCoQm/sX8xo248FX5CfrJBqGbjxbyxTVGHotdPG366hsHuIDKyG9fvk75biKLJuUqQPVhTzyfV Subject: Re: [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:57:49 -0000 --089e013cc1c4578b7304e1297d42 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, My preference for the WebSocket solution for client/server interaction stems simply from: 1) There are many MSRP use cases that are strictly client to/from server. WebSockets are a far simpler mechanism for these use cases, is far simpler to implement at both ends, and is arguably more efficient due to this simplicity. 2) There are many MSRP use cases that do not involve real-time media, and use of WebSockets enables these use cases to be satisfied with browsers (or other environments) that do not support WebRTC at this time (and some of these browsers/environments may never support WebRTC). I am not happy about requiring WebRTC support in a browser just for me to be able to use MSRP there. The requirements for peer-to-peer MSRP and client/server MSRP are quite different. Even when TCP/TLS is the transport these requirements are covered by two separate RFCs (which were developed and published in parallel). RFC 4976 adds additional MSRP requests and procedures that are simply not needed for peer-to-peer MSRP. I have no objection in principle to existence of a "gateway" device as you have described (although, for the reasons described above, I will continue to use WebSockets in my production system when client/server interaction is required), but to me it would make more sense to separate this function into another document that updates RFC 4976. When I started writing draft-pd-msrp-webrtc I envisaged this as simply an update to RFC 4975 to enable a new transport between MSRP peers - and I believe there is value in this simplicity. Regards, Peter On 10 July 2013 15:22, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> wrote: > Hi Gavin,**** > > Thanks for your support of our approach and for your comments. It=92s gr= eat > that you are planning an implementation along these lines.**** > > ** ** > > I am including mmusic on this distribution to not exclude anyone who may > be interested, but please limit the distribution to dispatch only for > subsequent emails in this thread.**** > > ** ** > > Regarding why we chose to create a new draft: Our approach was > sufficiently different from yours that we felt a separate draft was a > better idea in the short term. We can merge when it=92s appropriate to d= o > so. Even though we have no significant difference of opinion regarding t= he > SDP extensions needed, we clearly have different views regarding the valu= e > of a DataChannel gateway. It would be good to hear other opinions on thi= s > matter, as you are clearly heavily committed to your preference.**** > > ** ** > > Our preference for support of a DataChannel gateway model is based on the > numerous advantages of DataChannels. Just a partial list: We have one > transport mechanism for all cases; we don=92t have to offer two options o= r > perform fallback/retry procedures on failure of one transport option; we > can easily multiplex all media and sub-protocols together; we can leverag= e > the integrated browser handling of multiple flows of different priority; = we > have to be able to interoperate with legacy tcp/tls endpoints anyway. ***= * > > ** ** > > We look forward to continuing the debate.**** > > ** ** > > BR, Richard**** > > ** ** > > *From:* Gavin Llewellyn [mailto:gavin.llewellyn@crocodilertc.net] > *Sent:* Wednesday, July 10, 2013 6:51 AM > > *To:* Ejzak, Richard P (Richard) > *Cc:* dispatch@ietf.org; mmusic@ietf.org WG > *Subject:* Re: [dispatch] FW: New Version Notification for > draft-marcon-msrp-over-webrtc-data-channels-00.txt**** > > ** ** > > As a co-author of draft-pd-msrp-webrtc-00, I support this new draft for > establishment of MSRP sessions between WebRTC endpoints. The SDP > enhancements allowing re-use of the SCTP association is very much along t= he > lines of what we had in mind for the next version of our draft, but we ha= ve > not had time to complete it. We will likely be implementing this as a > feature in our WebRTC library in the near future, as the DataChannel > implementations in browsers mature (support SCTP, reliable delivery, bina= ry > data, etc).**** > > ** ** > > Having said that, it would have been appreciated if the authors had > contacted Peter and/or myself to discuss the existing draft and its > limitations - we would have been happy to receive feedback and work > together to find the best solution going forward.**** > > ** ** > > I cannot see the value in introducing DataChannel gateways as a means to > communicate with traditional TCP-based MSRP endpoints. I believe this is > better catered for by the WebSocket-based solution, as described in draft= -pd-dispatch-msrp-websocket, > which already has client and server implementations, and is currently > in-use in a production environment. Given the (intentional) similarities > between the WebSocket and DataChannel APIs, it is not difficult for the > client application to support both transports. I would like to see a cle= ar > justification for this aspect of the draft.**** > > ** ** > > One minor correction: the opening paragraph of section 5.2.3 appears to > reference the wrong SDP syntax for sub-protocol-specific attributes; I > believe it should reference the syntax for the new "wdcsa" attribute.**** > > ** ** > > Regards,**** > > Gavin Llewellyn**** > > ** ** > > --**** > > Gavin Llewellyn**** > > Principal Design Engineer**** > > Crocodile RCS Ltd**** > > GPG key: 0xF8F6FFF2**** > > ** ** > > On 9 July 2013 20:32, Ejzak, Richard P (Richard) < > richard.ejzak@alcatel-lucent.com> wrote:**** > > Please note our proposed alternative to draft-pd-msrp-webrtc-00 for how t= o > use DataChannel transport for MSRP. Our draft does not place restriction= s > on the number of MSRP sessions that can be established within an SCTP > association and describes alternatives for using a gateway to interconnec= t > to existing MSRP endpoints. The SDP extensions described are applicable = to > other potential DataChannel sub-protocols such as T.140, BFCP, T.38, etc. > > Richard > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 08, 2013 6:31 PM > To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME) > Subject: New Version Notification for > draft-marcon-msrp-over-webrtc-data-channels-00.txt > > > A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt > has been successfully submitted by Jerome Marcon and posted to the IETF > repository. > > Filename: draft-marcon-msrp-over-webrtc-data-channels > Revision: 00 > Title: MSRP over WebRTC data channels > Creation date: 2013-07-09 > Group: Individual Submission > Number of pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-ch= annels-00.txt > Status: > http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channe= ls > Htmlized: > http://tools.ietf.org/html/draft-marcon-msrp-over-webrtc-data-channels-00 > > > Abstract: > The Real-Time Communication in WEB-browsers (RTCWeb) working group is > charged to provide protocols to support direct interactive rich > communication using audio, video, and data between two peers' web- > browsers. For the support of data communication, the RTCWeb working > group has in particular defined the concept of bi-directional data > channels over SCTP, where each data channel might be used to > transport other protocols, called sub-protocols. This document > specifies how the Message Session Relay Protocol (MSRP) can be > instantiated as a WebRTC data channel sub-protocol, using the SDP > offer/exchange to negotiate out-of-band the sub-protocol specific > parameters. Two network configurations are documented: a WebRTC end- > to-end configuration (connecting two MSRP over data channel > endpoints), and a gateway configuration (connecting an MSRP over data > channel endpoint with an MSRP over TCP endpoint). > > > > > The IETF Secretariat > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch**** > > ** ** > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --=20 Peter Dunkley Technical Director Crocodile RCS Ltd --089e013cc1c4578b7304e1297d42 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello,

My preference for the WebSocket solution f= or client/server interaction stems simply from:
1) There are many MSRP = use cases that are strictly client to/from server. WebSockets are a far sim= pler mechanism for these use cases, is far simpler to implement at both end= s, and is arguably more efficient due to this simplicity.
2) There are many MSRP use cases that do not involve real-time media, = and use of WebSockets enables these use cases to be satisfied with browsers= (or other environments) that do not support WebRTC at this time (and some = of these browsers/environments may never support WebRTC). =A0I am not happy= about requiring WebRTC support in a browser just for me to be able to use = MSRP there.

The requirements for peer-to-peer MSRP and client/serve= r MSRP are quite different. =A0Even when TCP/TLS is the transport these req= uirements are covered by two separate RFCs (which were developed and publis= hed in parallel). =A0RFC 4976 adds additional MSRP requests and procedures = that are simply not needed for peer-to-peer MSRP.

I have no objection in principle to existence of a &quo= t;gateway" device as you have described (although, for the reasons des= cribed above, I will continue to use WebSockets in my production system whe= n client/server interaction is required), but to me it would make more sens= e to separate this function into another document that updates RFC 4976.

When I started writing draft-pd-msrp-webrtc I envisaged= this as simply an update to RFC 4975 to enable a new transport between MSR= P peers - and I believe there is value in this simplicity.

Regard= s,

Peter


On 10 July 20= 13 15:22, Ejzak, Richard P (Richard) <richard.ejzak@alcatel= -lucent.com> wrote:

Hi Gavin,

Thanks for your support o= f our approach and for your comments.=A0 It=92s great that you are planning= an implementation along these lines.

=A0<= /p>

I am including mmusic on = this distribution to not exclude anyone who may be interested, but please l= imit the distribution to dispatch only for subsequent emails in this thread.

=A0<= /p>

Regarding why we chose to= create a new draft: Our approach was sufficiently different from yours tha= t we felt a separate draft was a better idea in the short term.=A0 We can merge when it=92s appropriate to do so.=A0 Even though we = have no significant difference of opinion regarding the SDP extensions need= ed, we clearly have different views regarding the value of a DataChannel ga= teway.=A0 It would be good to hear other opinions on this matter, as you are clearly heavily committed to your pref= erence.

=A0<= /p>

Our preference for suppor= t of a DataChannel gateway model is based on the numerous advantages of Dat= aChannels.=A0 Just a partial list: We have one transport mechanism for all cases; we don=92t have to offer two options or perform fallback/re= try procedures on failure of one transport option; we can easily multiplex = all media and sub-protocols together; we can leverage the integrated browse= r handling of multiple flows of different priority; we have to be able to interoperate with legacy tcp/tls endpoints= anyway.

=A0<= /p>

We look forward to contin= uing the debate.

=A0<= /p>

BR, Richard=

=A0<= /p>

From: Gavin Ll= ewellyn [mailto:gavin.llewellyn@crocodilertc.net]
Sent: Wednesday, July 10, 2013 6:51 AM

<= br> To: Ejzak, Richard P (Richard)
Cc: dis= patch@ietf.org; mm= usic@ietf.org WG
Subject: Re: [dispatch] FW: New Version Notification for draft-marco= n-msrp-over-webrtc-data-channels-00.txt

=A0

As a co-author of=A0draft-pd-msrp-webrtc-= 00, I support this new draft for establishment of MSRP sessions between Web= RTC endpoints. =A0The SDP enhancements allowing re-use of the SCTP association is very much along the lines of what we had in mind for t= he next version of our draft, but we have not had time to complete it. =A0W= e will likely be implementing this as a feature in our WebRTC library in th= e near future, as the DataChannel implementations in browsers mature (support SCTP, reliable delivery, binar= y data, etc).

=A0

Having said that, it would have been appr= eciated if the authors had contacted Peter and/or myself to discuss the exi= sting draft and its limitations - we would have been happy to receive feedback and work together to find the best solution going forw= ard.

=A0

I cannot see the value in introducing Dat= aChannel gateways as a means to communicate with traditional TCP-based MSRP= endpoints. =A0I believe this is better catered for by the WebSocket-based solution, as described in=A0draft-pd-dispatch-msrp-websoc= ket, which already has client and server implementations, and is currently = in-use in a production environment. =A0Given the (intentional) similarities between the WebSocket and DataChannel APIs, it is not difficu= lt for the client application to support both transports. =A0I would like t= o see a clear justification for this aspect of the draft.<= /u>

=A0

One minor correction: the opening paragraph of section 5.2= .3 appears to reference the wrong SDP syntax for sub-protocol-specific attr= ibutes; I believe it should reference the syntax for the new "wdcsa" attribute.

=A0

Regards,

Gavin Llewellyn

=A0

--

Gavin Llewellyn

Principal Design Engineer

Crocodile RCS Ltd

GPG key: 0xF8F6FFF2

=A0

On 9 July 2013 20:32, Ejzak, Richard P (Richard) <= ;rich= ard.ejzak@alcatel-lucent.com> wrote:

Please note our proposed alternative to draft-pd-msr= p-webrtc-00 for how to use DataChannel transport for MSRP. =A0Our draft doe= s not place restrictions on the number of MSRP sessions that can be establi= shed within an SCTP association and describes alternatives for using a gateway to interconnect to existing MSR= P endpoints. =A0The SDP extensions described are applicable to other potent= ial DataChannel sub-protocols such as T.140, BFCP, T.38, etc.

Richard

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 08, 2013 6:31 PM
To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME)
Subject: New Version Notification for draft-marcon-msrp-over-webrtc-data-ch= annels-00.txt


A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt has been successfully submitted by Jerome Marcon and posted to the IETF rep= ository.

Filename: =A0 =A0 =A0 =A0draft-marcon-msrp-over-webrtc-data-channels
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 MSRP over WebRTC data channels
Creation date: =A0 2013-07-09
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-chan= nels-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracke= r.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-marcon-msrp-over-webrtc-data-channels-00


Abstract:
=A0 =A0The Real-Time Communication in WEB-browsers (RTCWeb) working group i= s
=A0 =A0charged to provide protocols to support direct interactive rich
=A0 =A0communication using audio, video, and data between two peers' we= b-
=A0 =A0browsers. =A0For the support of data communication, the RTCWeb worki= ng
=A0 =A0group has in particular defined the concept of bi-directional data =A0 =A0channels over SCTP, where each data channel might be used to
=A0 =A0transport other protocols, called sub-protocols. =A0This document =A0 =A0specifies how the Message Session Relay Protocol (MSRP) can be
=A0 =A0instantiated as a WebRTC data channel sub-protocol, using the SDP =A0 =A0offer/exchange to negotiate out-of-band the sub-protocol specific =A0 =A0parameters. =A0Two network configurations are documented: a WebRTC e= nd-
=A0 =A0to-end configuration (connecting two MSRP over data channel
=A0 =A0endpoints), and a gateway configuration (connecting an MSRP over dat= a
=A0 =A0channel endpoint with an MSRP over TCP endpoint).




The IETF Secretariat

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

=A0


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
--089e013cc1c4578b7304e1297d42-- From richard.ejzak@alcatel-lucent.com Wed Jul 10 08:52:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3741421F8AD5 for ; Wed, 10 Jul 2013 08:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.668 X-Spam-Level: X-Spam-Status: No, score=-9.668 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiEqe8X7cynH for ; Wed, 10 Jul 2013 08:52:21 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C869621F9F8D for ; Wed, 10 Jul 2013 08:52:18 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6AFqFOJ011676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Jul 2013 10:52:16 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r6AFqEi4021730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 11:52:15 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.181]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 10 Jul 2013 11:52:14 -0400 From: "Ejzak, Richard P (Richard)" To: Peter Dunkley , "dispatch@ietf.org" Thread-Topic: [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt Thread-Index: AQHOfX3qvX7mKjCrKku8qg7UnaNVUpleD4kQ Date: Wed, 10 Jul 2013 15:52:14 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D8029F2@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F3D80279E@US70UWXCHMBA04.zam.alcatel-lucent.com> <03FBA798AC24E3498B74F47FD082A92F3D802975@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D8029F2US70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 15:52:28 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F3D8029F2US70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Limiting the distribution to dispatch only... Hi Peter, I certainly understand and appreciate your points, even if I don't agree fu= lly with them. Let's try not to confuse document scope with technical solu= tions. I actually think that we should break out the generic sub-protocol = procedures from the document as well since wdcsa can be applied for use wit= h any sub-protocol. But this is a documentation issue that we can leave to= the chairs once the work has progressed a little further and a WG agrees t= o sponsor a draft (or three). We're just not there yet! Just to be clear, I certainly don't object to having a websocket transport = defined for MSRP either, and do see use cases for it. BR, Richard From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Peter Dunkley Sent: Wednesday, July 10, 2013 9:57 AM To: dispatch@ietf.org; mmusic@ietf.org WG Subject: Re: [dispatch] FW: New Version Notification for draft-marcon-msrp-= over-webrtc-data-channels-00.txt Hello, My preference for the WebSocket solution for client/server interaction stem= s simply from: 1) There are many MSRP use cases that are strictly client to/from server. W= ebSockets are a far simpler mechanism for these use cases, is far simpler t= o implement at both ends, and is arguably more efficient due to this simpli= city. 2) There are many MSRP use cases that do not involve real-time media, and u= se of WebSockets enables these use cases to be satisfied with browsers (or = other environments) that do not support WebRTC at this time (and some of th= ese browsers/environments may never support WebRTC). I am not happy about = requiring WebRTC support in a browser just for me to be able to use MSRP th= ere. The requirements for peer-to-peer MSRP and client/server MSRP are quite dif= ferent. Even when TCP/TLS is the transport these requirements are covered = by two separate RFCs (which were developed and published in parallel). RFC= 4976 adds additional MSRP requests and procedures that are simply not need= ed for peer-to-peer MSRP. I have no objection in principle to existence of a "gateway" device as you = have described (although, for the reasons described above, I will continue = to use WebSockets in my production system when client/server interaction is= required), but to me it would make more sense to separate this function in= to another document that updates RFC 4976. When I started writing draft-pd-msrp-webrtc I envisaged this as simply an u= pdate to RFC 4975 to enable a new transport between MSRP peers - and I beli= eve there is value in this simplicity. Regards, Peter On 10 July 2013 15:22, Ejzak, Richard P (Richard) > wrote: Hi Gavin, Thanks for your support of our approach and for your comments. It's great = that you are planning an implementation along these lines. I am including mmusic on this distribution to not exclude anyone who may be= interested, but please limit the distribution to dispatch only for subsequ= ent emails in this thread. Regarding why we chose to create a new draft: Our approach was sufficiently= different from yours that we felt a separate draft was a better idea in th= e short term. We can merge when it's appropriate to do so. Even though we= have no significant difference of opinion regarding the SDP extensions nee= ded, we clearly have different views regarding the value of a DataChannel g= ateway. It would be good to hear other opinions on this matter, as you are= clearly heavily committed to your preference. Our preference for support of a DataChannel gateway model is based on the n= umerous advantages of DataChannels. Just a partial list: We have one trans= port mechanism for all cases; we don't have to offer two options or perform= fallback/retry procedures on failure of one transport option; we can easil= y multiplex all media and sub-protocols together; we can leverage the integ= rated browser handling of multiple flows of different priority; we have to = be able to interoperate with legacy tcp/tls endpoints anyway. We look forward to continuing the debate. BR, Richard From: Gavin Llewellyn [mailto:gavin.llewellyn@crocodilertc.net] Sent: Wednesday, July 10, 2013 6:51 AM To: Ejzak, Richard P (Richard) Cc: dispatch@ietf.org; mmusic@ietf.org WG Subject: Re: [dispatch] FW: New Version Notification for draft-marcon-msrp-= over-webrtc-data-channels-00.txt As a co-author of draft-pd-msrp-webrtc-00, I support this new draft for est= ablishment of MSRP sessions between WebRTC endpoints. The SDP enhancements= allowing re-use of the SCTP association is very much along the lines of wh= at we had in mind for the next version of our draft, but we have not had ti= me to complete it. We will likely be implementing this as a feature in our= WebRTC library in the near future, as the DataChannel implementations in b= rowsers mature (support SCTP, reliable delivery, binary data, etc). Having said that, it would have been appreciated if the authors had contact= ed Peter and/or myself to discuss the existing draft and its limitations - = we would have been happy to receive feedback and work together to find the = best solution going forward. I cannot see the value in introducing DataChannel gateways as a means to co= mmunicate with traditional TCP-based MSRP endpoints. I believe this is bet= ter catered for by the WebSocket-based solution, as described in draft-pd-d= ispatch-msrp-websocket, which already has client and server implementations= , and is currently in-use in a production environment. Given the (intentio= nal) similarities between the WebSocket and DataChannel APIs, it is not dif= ficult for the client application to support both transports. I would like= to see a clear justification for this aspect of the draft. One minor correction: the opening paragraph of section 5.2.3 appears to ref= erence the wrong SDP syntax for sub-protocol-specific attributes; I believe= it should reference the syntax for the new "wdcsa" attribute. Regards, Gavin Llewellyn -- Gavin Llewellyn Principal Design Engineer Crocodile RCS Ltd GPG key: 0xF8F6FFF2 On 9 July 2013 20:32, Ejzak, Richard P (Richard) > wrote: Please note our proposed alternative to draft-pd-msrp-webrtc-00 for how to = use DataChannel transport for MSRP. Our draft does not place restrictions = on the number of MSRP sessions that can be established within an SCTP assoc= iation and describes alternatives for using a gateway to interconnect to ex= isting MSRP endpoints. The SDP extensions described are applicable to othe= r potential DataChannel sub-protocols such as T.140, BFCP, T.38, etc. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Monday, July 08, 2013 6:31 PM To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME) Subject: New Version Notification for draft-marcon-msrp-over-webrtc-data-ch= annels-00.txt A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt has been successfully submitted by Jerome Marcon and posted to the IETF rep= ository. Filename: draft-marcon-msrp-over-webrtc-data-channels Revision: 00 Title: MSRP over WebRTC data channels Creation date: 2013-07-09 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-marcon-msrp-over= -webrtc-data-channels-00.txt Status: http://datatracker.ietf.org/doc/draft-marcon-msrp-over-web= rtc-data-channels Htmlized: http://tools.ietf.org/html/draft-marcon-msrp-over-webrtc-d= ata-channels-00 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communication using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP, where each data channel might be used to transport other protocols, called sub-protocols. This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a WebRTC data channel sub-protocol, using the SDP offer/exchange to negotiate out-of-band the sub-protocol specific parameters. Two network configurations are documented: a WebRTC end- to-end configuration (connecting two MSRP over data channel endpoints), and a gateway configuration (connecting an MSRP over data channel endpoint with an MSRP over TCP endpoint). The IETF Secretariat _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch -- Peter Dunkley Technical Director Crocodile RCS Ltd --_000_03FBA798AC24E3498B74F47FD082A92F3D8029F2US70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Limiting the distribution= to dispatch only…

 <= /p>

Hi Peter,

I certainly understand an= d appreciate your points, even if I don’t agree fully with them. = ; Let’s try not to confuse document scope with technical solutions.&n= bsp; I actually think that we should break out the generic sub-protocol procedu= res from the document as well since wdcsa can be applied for use with any s= ub-protocol.  But this is a documentation issue that we can leave to t= he chairs once the work has progressed a little further and a WG agrees to sponsor a draft (or three).  We&#= 8217;re just not there yet!

 <= /p>

Just to be clear, I certa= inly don’t object to having a websocket transport defined for MSRP ei= ther, and do see use cases for it.

 <= /p>

BR, Richard

 <= /p>

 <= /p>

From: dispatch= -bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Dunkley
Sent: Wednesday, July 10, 2013 9:57 AM
To: dispatch@ietf.org; mmusic@ietf.org WG
Subject: Re: [dispatch] FW: New Version Notification for draft-marco= n-msrp-over-webrtc-data-channels-00.txt

 

Hello,

 

My preference for the WebSocket solution = for client/server interaction stems simply from:

1) There are many MSRP use cases that are= strictly client to/from server. WebSockets are a far simpler mechanism for= these use cases, is far simpler to implement at both ends, and is arguably more efficient due to this simplicity.

2) There are many MSRP use cases that do = not involve real-time media, and use of WebSockets enables these use cases = to be satisfied with browsers (or other environments) that do not support WebRTC at this time (and some of these browsers/environment= s may never support WebRTC).  I am not happy about requiring WebRTC su= pport in a browser just for me to be able to use MSRP there.

 

The requirements for peer-to-peer MSRP an= d client/server MSRP are quite different.  Even when TCP/TLS is the tr= ansport these requirements are covered by two separate RFCs (which were developed and published in parallel).  RFC 4976 adds additional = MSRP requests and procedures that are simply not needed for peer-to-peer MS= RP.

 

I have no objection in principle to exist= ence of a "gateway" device as you have described (although, for t= he reasons described above, I will continue to use WebSockets in my production system when client/server interaction is required), but to me i= t would make more sense to separate this function into another document tha= t updates RFC 4976.

 

When I started writing draft-pd-msrp-webr= tc I envisaged this as simply an update to RFC 4975 to enable a new transpo= rt between MSRP peers - and I believe there is value in this simplicity.

 

Regards,

 

Peter

 

On 10 July 2013 15:22, Ejzak, Richard P (Richard) &l= t;ric= hard.ejzak@alcatel-lucent.com> wrote:

Hi Gavin,

Thanks for your support of our approach= and for your comments.  It’s great that you are planning an implementation along these lines.

 

I am including mmusic on this distribut= ion to not exclude anyone who may be interested, but please limit the distribution to dispatch only for subsequent emails in this thre= ad.

 

Regarding why we chose to create a new = draft: Our approach was sufficiently different from yours that we felt a separate draft was a better idea in the short term.  W= e can merge when it’s appropriate to do so.  Even though we have= no significant difference of opinion regarding the SDP extensions needed, = we clearly have different views regarding the value of a DataChannel gateway.  It would be good to hear other opinions on= this matter, as you are clearly heavily committed to your preference.

 

Our preference for support of a DataCha= nnel gateway model is based on the numerous advantages of DataChannels.  Just a partial list: We have one transport mechanism f= or all cases; we don’t have to offer two options or perform fallback/= retry procedures on failure of one transport option; we can easily multiple= x all media and sub-protocols together; we can leverage the integrated browser handling of multiple flows of differen= t priority; we have to be able to interoperate with legacy tcp/tls endpoint= s anyway.

 

We look forward to continuing the debat= e.

 

BR, Richard

 

From: Gavin Llewellyn [mailt= o:gav= in.llewellyn@crocodilertc.net]
Sent: Wednesday, July 10, 2013 6:51 AM


To: Ejzak, Richard P (Richard)

Cc: dispatch@ietf.org; mmusic@ietf.org WG
Subject: Re: [dispatch] FW: New Version Notification for draft-marco= n-msrp-over-webrtc-data-channels-00.txt

 

As a co-author of draft-pd-msrp-webrtc-00, I suppo= rt this new draft for establishment of MSRP sessions between WebRTC endpoints.  The SDP enhancements allowing re-use of the SCTP associat= ion is very much along the lines of what we had in mind for the next versio= n of our draft, but we have not had time to complete it.  We will like= ly be implementing this as a feature in our WebRTC library in the near future, as the DataChannel implementations in b= rowsers mature (support SCTP, reliable delivery, binary data, etc).<= o:p>

 

Having said that, it would have been appreciated if the= authors had contacted Peter and/or myself to discuss the existing draft and its limitations - we would have been happy to receive f= eedback and work together to find the best solution going forward.

 

I cannot see the value in introducing DataChannel gatew= ays as a means to communicate with traditional TCP-based MSRP endpoints.  I believe this is better catered for by the WebSocket-bas= ed solution, as described in draft-pd-dispatch-msrp-websocket, which = already has client and server implementations, and is currently in-use in a production environment.  Given the (intentional) similari= ties between the WebSocket and DataChannel APIs, it is not difficult for th= e client application to support both transports.  I would like to see = a clear justification for this aspect of the draft.

 

One minor correction: the opening paragraph of section 5.2.3 appears to = reference the wrong SDP syntax for sub-protocol-specific attributes; I believe it should reference the syntax for the new "wdcsa&qu= ot; attribute.

 

Regards,

Gavin Llewellyn

 

--

Gavin Llewellyn

Principal Design Engineer

Crocodile RCS Ltd

GPG key: 0xF8F6FFF2

 

On 9 July 2013 20:32, Ejzak, Richard P (Richard) <richard.ejzak@alca= tel-lucent.com> wrote:

Please note our proposed alternative to draft-pd-msrp-webrtc-00 fo= r how to use DataChannel transport for MSRP.  Our draft does not place= restrictions on the number of MSRP sessions that can be established within an SCTP association and describes alternati= ves for using a gateway to interconnect to existing MSRP endpoints.  T= he SDP extensions described are applicable to other potential DataChannel s= ub-protocols such as T.140, BFCP, T.38, etc.

Richard

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 08, 2013 6:31 PM
To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME)
Subject: New Version Notification for draft-marcon-msrp-over-webrtc-data-ch= annels-00.txt


A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt has been successfully submitted by Jerome Marcon and posted to the IETF rep= ository.

Filename:        draft-marcon-msrp-over-webrtc-data-cha= nnels
Revision:        00
Title:           MSRP over WebRTC data channels Creation date:   2013-07-09
Group:           Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-chan= nels-00.txt
Status:          ht= tp://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels
Htmlized:        http://to= ols.ietf.org/html/draft-marcon-msrp-over-webrtc-data-channels-00


Abstract:
   The Real-Time Communication in WEB-browsers (RTCWeb) working g= roup is
   charged to provide protocols to support direct interactive ric= h
   communication using audio, video, and data between two peers' = web-
   browsers.  For the support of data communication, the RTC= Web working
   group has in particular defined the concept of bi-directional = data
   channels over SCTP, where each data channel might be used to    transport other protocols, called sub-protocols.  This do= cument
   specifies how the Message Session Relay Protocol (MSRP) can be=
   instantiated as a WebRTC data channel sub-protocol, using the = SDP
   offer/exchange to negotiate out-of-band the sub-protocol speci= fic
   parameters.  Two network configurations are documented: a= WebRTC end-
   to-end configuration (connecting two MSRP over data channel    endpoints), and a gateway configuration (connecting an MSRP ov= er data
   channel endpoint with an MSRP over TCP endpoint).




The IETF Secretariat

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



 

--

Peter Dunkley

Technical Director

Crocodile RCS Ltd

--_000_03FBA798AC24E3498B74F47FD082A92F3D8029F2US70UWXCHMBA04z_-- From oej@edvina.net Wed Jul 10 11:20:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD9721F9A35; Wed, 10 Jul 2013 11:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVSIS4aG1z8f; Wed, 10 Jul 2013 11:20:49 -0700 (PDT) Received: from aero.webway.se (aero.webway.se [212.3.14.206]) by ietfa.amsl.com (Postfix) with ESMTP id DC81321F9A7E; Wed, 10 Jul 2013 11:20:40 -0700 (PDT) Received: from aero.webway.se (localhost [127.0.0.1]) by aero.webway.se (Postfix) with ESMTP id 6E115AA1700; Wed, 10 Jul 2013 20:20:38 +0200 (CEST) Received: from 88.2.166.170 (SquirrelMail authenticated user p02) by aero.webway.se with HTTP; Wed, 10 Jul 2013 20:20:38 +0200 Message-ID: <9732162f6a7183a96ce9d46630a35c78.squirrel@aero.webway.se> Date: Wed, 10 Jul 2013 20:20:38 +0200 From: "Olle E. Johansson" To: dispatch@ietf.org, dane@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [dispatch] [Fwd: New Version Notification for draft-johansson-dane-sip-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 18:20:53 -0000 Hi! I've submitted a first version of the draft describing a possible way to use DANE in SIP. I don't really know which working group - dispatch or DANE - that will handle this, so I cross-post at this time to get as much feedback as possible. I will add more examples, but wanted to get the first draft of the draft out now. Greetings from a sunny Malaga in Spain! /Olle -------------------------------------------------------------------------- A new version of I-D, draft-johansson-dane-sip-00.txt has been successfully submitted by Olle E. Johansson and posted to the IETF repository. Filename: draft-johansson-dane-sip Revision: 00 Title: TLS sessions in SIP using DNS-based Authentication of Named Entities (DANE) TLSA records Creation date: 2013-07-10 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-johansson-dane-sip-00.txt Status: http://datatracker.ietf.org/doc/draft-johansson-dane-sip Htmlized: http://tools.ietf.org/html/draft-johansson-dane-sip-00 Abstract: Use of TLS in the SIP protocol is defined in multiple documents, starting with RFC 3261. The actual verification that happens when setting up a SIP TLS connection to a SIP server based on a SIP URI is described in detail in RFC 5922 - SIP Domain Certificates. In this document, an alternative method is defined, using DNS-Based Authentication of Named Entities (DANE). By looking up TLSA DNS records and using DNSsec protection of the required queries, including lookups for NAPTR and SRV records, a SIP Client can verify the identity of the TLS SIP server in a different way, matching on the SRV host name in the X.509 PKIX certificate instead of the SIP domain. This provides more scalability in hosting solutions and make it easier to use standard CA certificates (if needed at all). This document updates RFC 5922. The IETF Secretariat From mary.ietf.barnes@gmail.com Wed Jul 10 11:37:22 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA4821F9DDD for ; Wed, 10 Jul 2013 11:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfRZYSO9NZZz for ; Wed, 10 Jul 2013 11:37:22 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2488321F9DC6 for ; Wed, 10 Jul 2013 11:37:22 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id q19so3907102qeb.2 for ; Wed, 10 Jul 2013 11:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=j/TKe2+q9lkWv3ppaQ69dC+YRLipO9aCkq9l36xJHlw=; b=K1URPAT5IJhL1qD+npf+HSbtvunrrNQ/GMpoICf+yBzyX3dlXYgq4KN5iqx7Tp8/uW rfQsE3GOaaZpHWHu3Uoto39jeP9XWaj8VUw9dOcWDGK3EHZ7JrkPj52ACtzB/hVydASQ WCOycXeYUmWkcxi2xoEXCjB6yB02pi6IxWjHBeyMBN2Fwg/jWnUKbepFUPTE/ub9Z0ez xwBsJZDdQBUwGptmdDSXENM+i6nGe0cSX6gIU6+VqC6rmnxZ7tToJ2509XXLp+z0wbhd aN97sBLQjGBSGLLeUvVv2dydw9LqSsOsZ7ZfgPlykGPwgS2xLJUw4uRNBqZ88bimIhWz u4jw== MIME-Version: 1.0 X-Received: by 10.49.95.97 with SMTP id dj1mr26626421qeb.46.1373481441641; Wed, 10 Jul 2013 11:37:21 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 10 Jul 2013 11:37:21 -0700 (PDT) Date: Wed, 10 Jul 2013 13:37:21 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , "rai-ads@tools.ietf.org" Subject: [dispatch] Submitting documents for new RAI work to DISPATCH WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 18:37:22 -0000 Hi all, It would be really helpful for folks to use the typical rules of including a WG name in the filename for documents that are submitted for discussion in the DISPATCH WG, in particular when it isn't clear what WG would ultimately handle the document. That would allow folks to see all the relevant documents in the datatracker and on the tools page. Thanks, Mary. From rjsparks@nostrum.com Wed Jul 10 13:27:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB3121F9CB5; Wed, 10 Jul 2013 13:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRHKxtoRS-+K; Wed, 10 Jul 2013 13:27:53 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2559F21F9AA1; Wed, 10 Jul 2013 13:27:52 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6AKRpda019939 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Wed, 10 Jul 2013 15:27:52 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51DDC3C7.6070800@nostrum.com> Date: Wed, 10 Jul 2013 15:27:51 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: rai@ietf.org, dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [dispatch] Please consider mentoring new attendees in Berlin X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:27:53 -0000 Folks - As you may have already heard, we are trying a new program to help people who are new to the IETF engage more quickly and effectively. There is some information about the program here: We've started matching participants to mentors already, and expect more people to ask to participate. It would be _very_ helpful to have a large pool of mentors that are familiar with RAI. If you haven't already volunteered, please consider doing so. Check out the FAQ at to see what's involved. RjS From john@junctionnetworks.com Thu Jul 11 09:13:04 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867B121F9FF8 for ; Thu, 11 Jul 2013 09:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXLYmGON0kzh for ; Thu, 11 Jul 2013 09:12:42 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA0021F9E78 for ; Thu, 11 Jul 2013 09:12:02 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id q19so4504986qeb.2 for ; Thu, 11 Jul 2013 09:10:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=4ioX9IX5kNPJ0v3Qc3d/R4DuyViKHu6wlLNWGEg1/bM=; b=fNSwLIBwSPkThrbaC0zd5PUkg9dB/3ia1HWmXFpc+rinZFLlDKhQraTEMzhODZPnpC BGKH41HOPAByDeoqQfHI8KqwMJSqDZcN5EWe8w3OfaVBF7aZ1qCKKeMYmJA1aBO+QMXS TYtB5fDf7P9Gh1ez/r7c6ghaqbZjOV3LQElDpWu6y4GRIHIQVBj+wbZZV3NIMVLxX8AU XUbVOFx5NgA/1+hqz/yh+HZ9UljhUcnM0sT4czJFlz71UH3HRAZRqbbq/F/QlQxOi0Y8 1Y9JE3jvtZOEs9ralqh3nZoQtG9d+Fyiq82AiTsxD8DsDljiu9IpPS7sTxyBRf1eudMp e7gA== X-Received: by 10.229.242.132 with SMTP id li4mr7522328qcb.3.1373559052797; Thu, 11 Jul 2013 09:10:52 -0700 (PDT) Received: from ?IPv6:2001:550:2200:205:649d:55ce:f057:e218? ([2001:550:2200:205:649d:55ce:f057:e218]) by mx.google.com with ESMTPSA id l4sm30381326qay.0.2013.07.11.09.10.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 09:10:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: John Riordan X-Priority: 3 (Normal) In-Reply-To: <9732162f6a7183a96ce9d46630a35c78.squirrel@aero.webway.se> Date: Thu, 11 Jul 2013 12:10:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9732162f6a7183a96ce9d46630a35c78.squirrel@aero.webway.se> To: Olle E. Johansson X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQl/wRBezX5ryhPOb2CnDa4X53jjmGfr9qJry93dhcVXZapecsT6V6TtUaoB5g+EzsW9eMMF Cc: fluffy@cisco.com, dispatch@ietf.org, Richard Barnes , Jennings@ietfa.amsl.com, Cullen@ietfa.amsl.com Subject: Re: [dispatch] Progressing draft-worley-service-example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:13:04 -0000 Hi, I support the progress of draft-worley-service-example. We've been using = this approach in production for well over a year and know others have = incorporated it as well. Cheers, John Riordan CTO - OnSIP (ps: sorry if I mixed email threads on this) On Jul 8, 2013, at 2:38 PM, Dale R. Worley wrote: >> From: John Riordan >>=20 >> Good to hear. And I would be happy to be used as a reference. >>=20 >> John >=20 > (Sorry about getting this to you late.) >=20 > You can help push draft-worley-service-example along by giving a > positive response to the DISPATCH working group last call: >=20 > http://www.ietf.org/mail-archive/web/dispatch/current/msg04953.html >=20 > From: Mary Barnes > To: DISPATCH > Cc: Cullen Jennings , Richard Barnes = > Date: Tue, 25 Jun 2013 13:50:04 -0500 >=20 > Hi all, >=20 > This document got orphaned when the BLISS WG closed and discussions = in > the past with ADs indicated that it could be AD sponsored. We would > like to request folks to review this document and provide any = comments > and raise any concerns about it being progressed as AD sponsored no > later than July 10th, 2013 (2 weeks time). > http://datatracker.ietf.org/doc/draft-worley-service-example/ >=20 > Thanks, > Mary. From nneelakantan@sonusnet.com Thu Jul 11 22:07:54 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FDD21F99A9 for ; Thu, 11 Jul 2013 22:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OJRQ4IgrXZf for ; Thu, 11 Jul 2013 22:07:49 -0700 (PDT) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48721F8468 for ; Thu, 11 Jul 2013 22:07:49 -0700 (PDT) Received: from unknown [69.147.176.212] (EHLO usma-ex-hub1.sonusnet.com) by p01c12o144.mxlogic.net(mxl_mta-7.1.0-3) with ESMTP id 52f8fd15.2b3085e02940.8958.00-579.23610.p01c12o144.mxlogic.net (envelope-from ); Thu, 11 Jul 2013 23:07:49 -0600 (MDT) X-MXL-Hash: 51df8f256e2127ca-7a4c48169fa9a0f26a10fc27d484317cffd5eeb1 Received: from unknown [69.147.176.212] (EHLO usma-ex-hub1.sonusnet.com) by p01c12o144.mxlogic.net(mxl_mta-7.1.0-3) over TLS secured channel with ESMTP id 12f8fd15.0.8948.00-391.23589.p01c12o144.mxlogic.net (envelope-from ); Thu, 11 Jul 2013 23:07:48 -0600 (MDT) X-MXL-Hash: 51df8f24037a84a3-a285c21744ef8fb30973e49b0996c978e668a0dc Received: from USMA-EX-MB2.sonusnet.com ([fe80::c51d:eb9c:bce7:e4b0]) by usma-ex-hub1.sonusnet.com ([2002:42cb:5a10::42cb:5a10]) with mapi id 14.02.0342.003; Fri, 12 Jul 2013 01:07:43 -0400 From: "Neelakantan, Neel" To: "Klatsky, Carl" , "'dispatch@ietf.org'" Thread-Topic: [dispatch] FW: New Version Notification for draft-klatsky-dispatch-ipv6-impact-ipv4-01.txt Thread-Index: AQHOfM59i/TATMDjoE6MbV1fAXeZrJlcqlwwgAPFTLA= Date: Fri, 12 Jul 2013 05:07:43 +0000 Message-ID: <56EB3FF5A53614438D93B3325407DBE577B86A@USMA-EX-MB2.sonusnet.com> References: <20130709180228.24023.45732.idtracker@ietfa.amsl.com> <6C15A6B88541034E912E94C2D8BC3E87C96D5160@PACDCEXMB15.cable.comcast.com> In-Reply-To: <6C15A6B88541034E912E94C2D8BC3E87C96D5160@PACDCEXMB15.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=d/pCP2fE c=1 sm=1 a=ed0SwufR/ZNkx8DvM7kK7A==:17 a] X-AnalysisOut: [=kxZvkmloRasA:10 a=95aDduG4Ub4A:10 a=URNJFqk9g_oA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=kUVcWBO] X-AnalysisOut: [SAAAA:8 a=OHvEDBntBCUA:10 a=48vgC7mUAAAA:8 a=-PhP3wk3W4VoC] X-AnalysisOut: [nWiDYIA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=HQHDKSSLG0] X-AnalysisOut: [PV2VGx:21 a=e9GaaWEUL4U8xTfC:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [69.147.176.212] Subject: Re: [dispatch] FW: New Version Notification for draft-klatsky-dispatch-ipv6-impact-ipv4-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:07:54 -0000 VGhlIHVwZGF0ZXMgbG9vayBnb29kLiAgVGhlIGdvYWwgaXMgdG8gZW5oYW5jZSB0aGUgaW50ZXJv cGVyYWJpbGl0eSBiZXR3ZWVuIGNvbWJpbmF0aW9uIG9mIElQdjQgYW5kIElQdjYgZW50aXRpZXMu DQoNCkZvciBJUHY0IGd1aWRlbGluZXMsDQoNCkl0IHdpbGwgYmUgZ29vZCBpZGVhIHRvIHRhbGsg YWJvdXQgdGhlIGltcGFjdCBvZiBjYWxsIGZvcmtpbmcgaW52b2x2aW5nIGNvbWJpbmF0aW9uIG9m ICBJUHY0L0lQVjYuICBPbmUgY2FzZSBjb21lIHRvIG1pbmQgaXMNCg0KU2F5IFVBQyBpcyBJUHY0 ICBvbmx5LCBjYWxsIGdldHMgZm9ya2VkIGJ5IFNJUCBQcm94eSB0byBmZXcgSVB2NCBhbmQgSVB2 NiBvbmx5IGVuZHBvaW50cy4gIFdoZW4gdGhlIHByb3Zpc2lvbmFsIHJlc3BvbnNlcyBhcmUgcmVj ZWl2ZWQgZnJvbSBJUHY2IG9ubHksIHRoZSBVQUMgc2hvdWxkIHBvdGVudGlhbGx5IGRpc2Nvbm5l Y3QgKEJZRSkgdGhlIGVhcmx5IGRpYWxvZ3MgdG8gcHJldmVudCBhbnkgaW5jb21wYXRpYmlsaXR5 IGR1ZSB0byBpcHY0L2lwdjYuICAgTm90IGRvaW5nIHNvLCBtYXkgbGVhZCB0byBmYWlsdXJlLCBp ZiBJUHY2IGVuZHBvaW50IHNlbmRzIDIwMCBPSy4gIFRoZSBTSVAgcHJveHkgaW4gdGhlIG1pZGRs ZSB3b3VsZCBzdGFydCBDQU5DRUwgb3RoZXIgZm9ya3MuDQoNCkZvciBJUHY2IGd1aWRlbGluZXMs DQoNClRoZSBvZmZlci9hbnN3ZXIgZG9lcyBub3QgaW5jbHVkZSBJUCBBZGRyZXNzIGluIG5lZ290 aWF0aW9uIGFzcGVjdHMgYW5kIGRvZXNu4oCZdCBkaXN0aW5ndWlzaCBJUHY0L0lQdjYuICBJZiB0 aGUgZHVhbCBzdGFjayBJUHY0L0lQdjYgVUFTIHJlY2VpdmVzIGFuIElOVklURSBmcm9tIElQdjQg ZW5kcG9pbnQsIGJhc2VkIG9uIENvbnRhY3QgaW5mb3JtYXRpb24sIGl0IHNob3VsZCByZXNwb25k IHVzaW5nIHRoZSBvZmZlciAoSVB2NC9JUHY2KSBpbiBtZWRpYS9jPSBmb3IgYmV0dGVyIGludGVy b3BlcmFiaWxpdHkuDQoNClRoZSBJUHY0IGVuZHBvaW50IHNob3VsZCBiZSBhYmxlIHRvIHBhcnNl IGEgSVB2NiBTSVAgZmllbGRzLiAgSXQgaXMgd29ydGh3aGlsZSBhZGQgcmVmZXJlbmNlIGZvciBJ UFY2IFRvcnR1cmUgdGVzdCBjYXNlcyBmb3IgSVBWNi9JUHY0IGludGVyb3BlcmFiaWxpdHkuIChS RkMgNTExOCkuDQoNClRoYW5rcywNCk5lZWwuDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaXNwYXRj aC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgS2xhdHNreSwgQ2FybA0KPiBTZW50 OiBUdWVzZGF5LCBKdWx5IDA5LCAyMDEzIDE6MzAgUE0NCj4gVG86ICdkaXNwYXRjaEBpZXRmLm9y ZycNCj4gU3ViamVjdDogW2Rpc3BhdGNoXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1rbGF0c2t5LWRpc3BhdGNoLQ0KPiBpcHY2LWltcGFjdC1pcHY0LTAxLnR4dA0KPiAN Cj4gSGksDQo+IA0KPiBPbiBiZWhhbGYgb2YgdGhlIGF1dGhvcnMgb2YgdGhpcyBkcmFmdCwgYSBu ZXcgdmVyc2lvbiBoYXMgYmVlbiB1cGxvYWRlZCB0bw0KPiBhZGRyZXNzIGNvbW1lbnRzIHJhaXNl ZCBoZXJlIG9uIHRoZSBkaXNwYXRjaCBsaXN0LiAgQWRkaXRpb25hbCBmZWVkYmFjayBvbg0KPiB0 aGlzIHZlcnNpb24gaWYgdGhlIGRyYWZ0IGlzIHJlcXVlc3RlZC4NCj4gDQo+IFRoYW5rcyAmIFJl Z2FyZHMsDQo+IA0KPiBDYXJsIEtsYXRza3kNCj4gQ29tY2FzdA0KPiANCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDA5LCAyMDEz IDI6MDIgUE0NCj4gVG86IE9sbGUgRS5Kb2hhbnNzb247IEdvbnphbG8gU2FsZ3VlaXJvOyBSaWZh YXQgU2hla2gtWXVzZWY7IEtsYXRza3ksIENhcmw7DQo+IEFuZHJldyBIdXR0b24NCj4gU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rbGF0c2t5LWRpc3BhdGNoLWlw djYtaW1wYWN0LQ0KPiBpcHY0LTAxLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1rbGF0c2t5LWRpc3BhdGNoLWlwdjYtaW1wYWN0LWlwdjQtMDEudHh0DQo+IGhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ2FybCBLbGF0c2t5IGFuZCBwb3N0ZWQgdG8g dGhlIElFVEYNCj4gcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQta2xhdHNreS1k aXNwYXRjaC1pcHY2LWltcGFjdC1pcHY0DQo+IFJldmlzaW9uOgkgMDENCj4gVGl0bGU6CQkgSW50 ZXJvcGVyYWJpbGl0eSBJbXBhY3RzIG9mIElQdjYgSW50ZXJ3b3JraW5nIHdpdGggRXhpc3RpbmcN Cj4gSVB2NCBTSVAgSW1wbGVtZW50YXRpb25zDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTA5 DQo+IEdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDEw DQo+IFVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQta2xhdHNreS1kaXNwYXRjaC1pcHY2LQ0KPiBpbXBhY3QtaXB2NC0wMS50eHQNCj4gU3Rh dHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtsYXRz a3ktZGlzcGF0Y2gtaXB2Ni0NCj4gaW1wYWN0LWlwdjQNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rbGF0c2t5LWRpc3BhdGNoLWlwdjYtaW1wYWN0 LQ0KPiBpcHY0LTAxDQo+IERpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQta2xhdHNreS1kaXNwYXRjaC1pcHY2LQ0KPiBpbXBhY3QtaXB2NC0wMQ0K PiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgY2FwdHVyZXMgcG90ZW50aWFsIGlt cGFjdHMgdG8gSVB2NCBTSVAgaW1wbGVtZW50YXRpb25zDQo+ICAgIHdoZW4gaW50ZXJ3b3JraW5n IHdpdGggSVB2NiBTSVAgaW1wbGVtZW50YXRpb25zLiAgQWx0aG91Z2ggc29tZQ0KPiAgICBhbW91 bnQgb2YgaW50ZXJ3b3JraW5nIHRyYW5zbGF0aW9uIHdpbGwgb2NjdXIgYXQgdGhlIG5ldHdvcmsg YW5kDQo+ICAgIGFwcGxpY2F0aW9uIGxheWVycywgYW4gSVB2NCBTSVAgYXBwbGljYXRpb24gbWF5 IHN0aWxsIGVuY291bnRlciBhIFNJUA0KPiAgICBtZXNzYWdlIHdpdGggc29tZSBJUHY2IHZhbHVl cyBpbiBpdCwgcmVzdWx0aW5nIGluIHVuZm9yZXNlZW4gZXJyb3INCj4gICAgY29uZGl0aW9ucy4g IFN1Y2ggcG90ZW50aWFsIHNjZW5hcmlvcyB3aWxsIGJlIGlkZW50aWZpZWQgaW4gdGhpcw0KPiAg ICBkb2N1bWVudCBzbyB0aGF0IFNJUCBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIGNhbiBkZWZpbmUg c29sdXRpb25zIHRvDQo+ICAgIGhhbmRsZSB0aGVzZSBjYXNlcy4gIE5vdGUsIHRoaXMgZG9jdW1l bnQgaXMgbm90IGludGVuZGVkIHRvIGJlIGFuDQo+ICAgIGV4aGF1c3RpdmUgbGlzdCwgcmF0aGVy IHRvIHByb3ZpZGUgYW4gb3ZlcnZpZXcgb2Ygc29tZSBvZiB0aGUgbW9yZQ0KPiAgICBjb21tb25s eSBlbmNvdW50ZXJlZCBwb3RlbnRpYWwgc2NlbmFyaW9zLg0KPiANCj4gDQo+IA0KPiANCj4gVGhl IElFVEYgU2VjcmV0YXJpYXQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo= From nneelakantan@sonusnet.com Fri Jul 12 07:16:20 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA57621F99F4 for ; Fri, 12 Jul 2013 07:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1cooWZv0bhv for ; Fri, 12 Jul 2013 07:16:15 -0700 (PDT) Received: from p01c12o143.mxlogic.net (p01c12o143.mxlogic.net [208.65.145.66]) by ietfa.amsl.com (Postfix) with ESMTP id 43A4621F9A1B for ; Fri, 12 Jul 2013 07:16:09 -0700 (PDT) Received: from unknown [69.147.176.212] (EHLO usma-ex-hub1.sonusnet.com) by p01c12o143.mxlogic.net(mxl_mta-7.1.0-3) with ESMTP id 9af00e15.2b90fb204940.13752.00-524.37830.p01c12o143.mxlogic.net (envelope-from ); Fri, 12 Jul 2013 08:16:09 -0600 (MDT) X-MXL-Hash: 51e00fa96021dcf0-620050a610d30195c473934b7c0bd3efee220c45 Received: from unknown [69.147.176.212] (EHLO usma-ex-hub1.sonusnet.com) by p01c12o143.mxlogic.net(mxl_mta-7.1.0-3) over TLS secured channel with ESMTP id b4f00e15.0.13121.00-330.36064.p01c12o143.mxlogic.net (envelope-from ); Fri, 12 Jul 2013 08:14:37 -0600 (MDT) X-MXL-Hash: 51e00f4d3705798e-34a05a231de836b130b7525d6cd7eda230f593c4 Received: from USMA-EX-MB2.sonusnet.com ([fe80::c51d:eb9c:bce7:e4b0]) by usma-ex-hub1.sonusnet.com ([2002:42cb:5a10::42cb:5a10]) with mapi id 14.02.0342.003; Fri, 12 Jul 2013 10:14:31 -0400 From: "Neelakantan, Neel" To: "Klatsky, Carl" , "'dispatch@ietf.org'" Thread-Topic: [dispatch] FW: New Version Notification for draft-klatsky-dispatch-ipv6-impact-ipv4-01.txt Thread-Index: AQHOfM59i/TATMDjoE6MbV1fAXeZrJlcqlwwgAPFTLCAAKjmIQ== Date: Fri, 12 Jul 2013 14:14:30 +0000 Message-ID: <56EB3FF5A53614438D93B3325407DBE577BC3C@USMA-EX-MB2.sonusnet.com> References: <20130709180228.24023.45732.idtracker@ietfa.amsl.com> <6C15A6B88541034E912E94C2D8BC3E87C96D5160@PACDCEXMB15.cable.comcast.com>, <56EB3FF5A53614438D93B3325407DBE577B86A@USMA-EX-MB2.sonusnet.com> In-Reply-To: <56EB3FF5A53614438D93B3325407DBE577B86A@USMA-EX-MB2.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.209.50.95] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=dZk3Kwre c=1 sm=1 a=ed0SwufR/ZNkx8DvM7kK7A==:17 a] X-AnalysisOut: [=MdxjFd7PPvQA:10 a=95aDduG4Ub4A:10 a=URNJFqk9g_oA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=kUVcWBO] X-AnalysisOut: [SAAAA:8 a=OHvEDBntBCUA:10 a=48vgC7mUAAAA:8 a=HRo0PTTAoT0yZ] X-AnalysisOut: [1K20qwA:9 a=pILNOxqGKmIA:10 a=lZB815dzVvQA:10 a=CD1q411P2o] X-AnalysisOut: [nJ7POg:21 a=QgjAMq2YqQ0dzxzc:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [69.147.176.212] Subject: Re: [dispatch] FW: New Version Notification for draft-klatsky-dispatch-ipv6-impact-ipv4-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 14:16:21 -0000 I see ipv6/ipv4 no different than say PRACK or any other option tags that i= s used for both endpoints (UAC/UAS) to support the feature. Probably somet= hing along the lines of Supported: ipv6/ipv4 would help better interoperabi= lity. For example, a IPv4 endpoint which implemented Require/Supported han= dling might better respond to IPv6 SDP. Thanks, Neel ________________________________________ From: Neelakantan, Neel Sent: Friday, July 12, 2013 12:07 AM To: Klatsky, Carl; 'dispatch@ietf.org' Subject: RE: [dispatch] FW: New Version Notification for draft-klats= ky-dispatch-ipv6-impact-ipv4-01.txt The updates look good. The goal is to enhance the interoperability between= combination of IPv4 and IPv6 entities. For IPv4 guidelines, It will be good idea to talk about the impact of call forking involving com= bination of IPv4/IPV6. One case come to mind is Say UAC is IPv4 only, call gets forked by SIP Proxy to few IPv4 and IPv6 o= nly endpoints. When the provisional responses are received from IPv6 only,= the UAC should potentially disconnect (BYE) the early dialogs to prevent a= ny incompatibility due to ipv4/ipv6. Not doing so, may lead to failure, i= f IPv6 endpoint sends 200 OK. The SIP proxy in the middle would start CANC= EL other forks. For IPv6 guidelines, The offer/answer does not include IP Address in negotiation aspects and doe= sn=92t distinguish IPv4/IPv6. If the dual stack IPv4/IPv6 UAS receives an = INVITE from IPv4 endpoint, based on Contact information, it should respond = using the offer (IPv4/IPv6) in media/c=3D for better interoperability. The IPv4 endpoint should be able to parse a IPv6 SIP fields. It is worthwh= ile add reference for IPV6 Torture test cases for IPV6/IPv4 interoperabilit= y. (RFC 5118). Thanks, Neel. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Klatsky, Carl > Sent: Tuesday, July 09, 2013 1:30 PM > To: 'dispatch@ietf.org' > Subject: [dispatch] FW: New Version Notification for draft-klatsky-dispat= ch- > ipv6-impact-ipv4-01.txt > > Hi, > > On behalf of the authors of this draft, a new version has been uploaded t= o > address comments raised here on the dispatch list. Additional feedback o= n > this version if the draft is requested. > > Thanks & Regards, > > Carl Klatsky > Comcast > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, July 09, 2013 2:02 PM > To: Olle E.Johansson; Gonzalo Salgueiro; Rifaat Shekh-Yusef; Klatsky, Car= l; > Andrew Hutton > Subject: New Version Notification for draft-klatsky-dispatch-ipv6-impact- > ipv4-01.txt > > > A new version of I-D, draft-klatsky-dispatch-ipv6-impact-ipv4-01.txt > has been successfully submitted by Carl Klatsky and posted to the IETF > repository. > > Filename: draft-klatsky-dispatch-ipv6-impact-ipv4 > Revision: 01 > Title: Interoperability Impacts of IPv6 Interworking with= Existing > IPv4 SIP Implementations > Creation date: 2013-07-09 > Group: Individual Submission > Number of pages: 10 > URL: http://www.ietf.org/internet-drafts/draft-klatsky-dispat= ch-ipv6- > impact-ipv4-01.txt > Status: http://datatracker.ietf.org/doc/draft-klatsky-dispatch-i= pv6- > impact-ipv4 > Htmlized: http://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-i= mpact- > ipv4-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-klatsky-dispatc= h-ipv6- > impact-ipv4-01 > > Abstract: > This document captures potential impacts to IPv4 SIP implementations > when interworking with IPv6 SIP implementations. Although some > amount of interworking translation will occur at the network and > application layers, an IPv4 SIP application may still encounter a SIP > message with some IPv6 values in it, resulting in unforeseen error > conditions. Such potential scenarios will be identified in this > document so that SIP application developers can define solutions to > handle these cases. Note, this document is not intended to be an > exhaustive list, rather to provide an overview of some of the more > commonly encountered potential scenarios. > > > > > The IETF Secretariat > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch= From mayumi.ohsugi@ntt-at.co.jp Mon Jul 15 19:50:32 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5B411E81B5 for ; Mon, 15 Jul 2013 19:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oqVtZcwLwiV for ; Mon, 15 Jul 2013 19:50:28 -0700 (PDT) Received: from mgw2.ntt-at.co.jp (mgw2.ntt-at.co.jp [202.253.162.42]) by ietfa.amsl.com (Postfix) with ESMTP id 661CF11E817B for ; Mon, 15 Jul 2013 19:50:27 -0700 (PDT) Received: from gwall1.bb.ntt-at.co.jp ([192.168.225.241]) by mgw2i.dc.ntt-at.co.jp with ESMTP; 16 Jul 2013 11:50:26 +0900 Received: (from root@localhost) by gwall1.bb.ntt-at.co.jp (8.13.1/8.13.1) id r6G2oQVI012898; Tue, 16 Jul 2013 11:50:26 +0900 Received: from vcsrv1d.dc.ntt-at.co.jp [192.168.225.46] by gwall1.bb.ntt-at.co.jp with ESMTP id MAA12897; Tue, 16 Jul 2013 11:50:26 +0900 Received: from vcsrv1d.dc.ntt-at.co.jp (vcsrv1d.dc.ntt-at.co.jp [127.0.0.1]) by vcsrv1d.dc.ntt-at.co.jp (vcsrv1d) with ESMTP id r6G2oQp9027923; Tue, 16 Jul 2013 11:50:26 +0900 Received: from atmail26.am.ntt-at.co.jp (atmail26.am.ntt-at.co.jp [192.168.225.146]) by vcsrv1d.dc.ntt-at.co.jp (vcsrv1d) with ESMTP id r6G2oQVh027920; Tue, 16 Jul 2013 11:50:26 +0900 Received: from [IPv6:::1] (ip21-098.tec.ntt-at.co.jp [192.168.21.98]) by atmail26.am.ntt-at.co.jp (Postfix) with ESMTP id D1D71C50062; Tue, 16 Jul 2013 11:50:25 +0900 (JST) Message-ID: <51E4B4ED.4060305@ntt-at.co.jp> Date: Tue, 16 Jul 2013 11:50:21 +0900 From: Mayumi Ohsugi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-TM-AS-MML: No Subject: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 02:50:33 -0000 Hi, I have submitted the following draft: http://www.ietf.org/id/draft-vanelburg-dispatch-private-network-ind-02.txt The draft was discussed in DISPATCH list three years ago. While it has been expired for more than two years, the draft has been referred in 3GPP IMS specifications and the P-Private-Network-Indication header field is now implemented by some vendors for enterprise customers. We have updated the draft to solve the remaining issues from Expert Review (by John Elwell) of three years ago. Any comments are welcome. Thanks, Mayumi ----- Mayumi Ohsugi, NTT From keith.drage@alcatel-lucent.com Tue Jul 16 07:58:33 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D55521F9B8C; Tue, 16 Jul 2013 07:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsNPlcex7ima; Tue, 16 Jul 2013 07:58:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id D14CA21F84D1; Tue, 16 Jul 2013 07:58:27 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6GEwPhL020697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jul 2013 09:58:27 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6GEwP2U023868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 16:58:25 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 16:58:25 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" , "dispatch@ietf.org" , "avt@ietf.org" Thread-Topic: Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gAACsrA Date: Tue, 16 Jul 2013 14:58:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06AD7A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [dispatch] FW: Taxonomy X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:58:33 -0000 Extensive cross-post do not reply to this email. For information. We do expect participation input from all the listed worki= ng groups (and possibly more). Keith -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= DRAGE, Keith (Keith) Sent: 16 July 2013 15:53 To: avtext@ietf.org Subject: [avtext] Taxonomy (As AVTEXT WG cochair) The latest version of the RTP taxonomy draft has been submitted. https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy= /=20 This document was allocated to AVTEXT by DISPATCH, and we have created a mi= lestone for it in AVTEXT. This draft is not yet a working group document. We do expect to spend some significant meeting time discussing the contents= in the AVTEXT meeting in Berlin, so please start raising your issues on th= e AVTEXT list. Additionally, if there are counter proposals existing that the AVTEXT chair= s would not otherwise be aware of, then please identify them to the AVTEXT = chairs / list. Regards Keith _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From keith.drage@alcatel-lucent.com Wed Jul 17 04:07:01 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C366921F9948; Wed, 17 Jul 2013 04:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7BkwHXD8h6U; Wed, 17 Jul 2013 04:06:56 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 41BF521F9D4A; Wed, 17 Jul 2013 04:06:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6HB6nwZ009557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2013 06:06:50 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6HB6lVR032483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 13:06:49 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 17 Jul 2013 13:06:48 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" , "dispatch@ietf.org" , "avt@ietf.org" Thread-Topic: Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gAACsrAACo7ARA= Date: Wed, 17 Jul 2013 11:06:48 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [dispatch] Taxonomy X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:07:02 -0000 Breaking my own rule about cross posting... Just wanted to add is that this document would not be retrospective, i.e. w= e would not start rewriting the existing published RFCs to take into accoun= t the new terminology. The expectation however is that documents going forward from other working = groups would use the new terminology rather than other terms.=20 Obviously how this is handled is up to the individual working groups, but u= sing the new terminology will be the only good way of making your results u= nderstandable outside your specific field. So that is why your review and input is important. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 16 July 2013 15:58 > To: mmusic@ietf.org; rtcweb@ietf.org; clue@ietf.org; dispatch@ietf.org; > avt@ietf.org > Subject: FW: Taxonomy >=20 > Extensive cross-post do not reply to this email. >=20 > For information. We do expect participation input from all the listed > working groups (and possibly more). >=20 > Keith >=20 > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of DRAGE, Keith (Keith) > Sent: 16 July 2013 15:53 > To: avtext@ietf.org > Subject: [avtext] Taxonomy >=20 > (As AVTEXT WG cochair) >=20 > The latest version of the RTP taxonomy draft has been submitted. >=20 > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping- > taxonomy/ >=20 > This document was allocated to AVTEXT by DISPATCH, and we have created a > milestone for it in AVTEXT. >=20 > This draft is not yet a working group document. >=20 > We do expect to spend some significant meeting time discussing the > contents in the AVTEXT meeting in Berlin, so please start raising your > issues on the AVTEXT list. >=20 > Additionally, if there are counter proposals existing that the AVTEXT > chairs would not otherwise be aware of, then please identify them to the > AVTEXT chairs / list. >=20 > Regards >=20 > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From ibc@aliax.net Wed Jul 17 04:27:13 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026D621F9DAF for ; Wed, 17 Jul 2013 04:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WhylkefKFy6 for ; Wed, 17 Jul 2013 04:27:12 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9CECF21F9DFA for ; Wed, 17 Jul 2013 04:27:08 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id a11so1025891qen.24 for ; Wed, 17 Jul 2013 04:27:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=EKaU4MI2ZQsAWPvMCk3JxHj6BeoOuRCIjkCYNQ+jx9I=; b=ORZoFUSp8arQNfON3EN+N4l1wQG636RA/Y+9WgdaIi7qdR3Bn/lTSYGAZ3VAV8I4Vm ZYyrROe5knN85rmDw7nDrzCOBW/cLVp6jtW4n7hEJSYAkr+xCaktqOIyp8qTA04lj03n c7H0a3+hmVl6UMwZUHt+26OnAUzoRcD6ykft8ub0ljhjhF6vjro+R4OTIjbJsTrsRWvM scNrXVFEvdqIokoOiZioJhFxpWFv7RvLfFX137FMDWEq6LnRN6V9kvQo+ZVp+tmQosA/ Q4Z0Agb5MwTFmWBXk5ZMBpKfgWuRvBmW+wf6GPXRjUg82SijTYWmlOGXpibTkvzYJhue jkyA== X-Received: by 10.224.90.1 with SMTP id g1mr8708293qam.0.1374060427977; Wed, 17 Jul 2013 04:27:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Wed, 17 Jul 2013 04:26:47 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 17 Jul 2013 13:26:47 +0200 Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmfianPCRhbMnKQuC0shRgFejG+yQD11VyulF6MSWGPXG7UcIxsnvlhOK6dUSdQ0M7nRUau Cc: "clue@ietf.org" , "dispatch@ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" , "avt@ietf.org" Subject: Re: [dispatch] Taxonomy X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:27:13 -0000 2013/7/17 DRAGE, Keith (Keith) : > The expectation however is that documents going forward from other workin= g groups would use the new terminology rather than other terms. > > Obviously how this is handled is up to the individual working groups, but= using the new terminology will be the only good way of making your results= understandable outside your specific field. > > So that is why your review and input is important. Hi Drage, First of I'm sorry but I'm not subscribed to MMUSIC nor CLUE, so let me please reply here (it is just a single topic): I'm really annoying after reading the draft section 2.4 "Media Stream": http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01#= section-2.4 ------------------------ Each Media Stream is identified by a unique Synchronization source (SSRC) [RFC3550] that is carried in every RTP and Real-time Transport Control Protocol (RTCP) packet header. ------------------------ In W3C we have "MediaStream" and "MediaStreamTrack", and "MediaStreamTrack" is exactly what the draft above defines as "Media Stream". So let me say that this is the most confusing terminology it can be. -- I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Mon Jul 22 14:24:01 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A10711E8161 for ; Mon, 22 Jul 2013 14:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.326 X-Spam-Level: X-Spam-Status: No, score=0.326 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6Z-htuZrRa2 for ; Mon, 22 Jul 2013 14:23:55 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 3884111E8150 for ; Mon, 22 Jul 2013 14:23:54 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta13.westchester.pa.mail.comcast.net with comcast id 3Xn21m0090Fqzac5DZPtbR; Mon, 22 Jul 2013 21:23:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 3ZPt1m01C3ZTu2S3UZPtvx; Mon, 22 Jul 2013 21:23:53 +0000 Message-ID: <51EDA2E8.1050603@alum.mit.edu> Date: Mon, 22 Jul 2013 17:23:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374528233; bh=T+yOUG97OBXeXElL3lc+JWQQr5cc0Ot7IOq/nK9KNmQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=neQ/+qrv1dUKiqBf/BkDwYY8YPEN19EATUhF9YuwTQGDSd1btzRrrNTJYdd+Sr3W8 vAe67+U69lnFUrAQ+PgMwoYGiWhStny/TcfWJgqvJk8ahQ8kA0sQEI4K2d3FVU53Hn ZD7OsONGrza588MLup/Uzh9QvtzPht4KNa2/YnSCXFiE86SVds/AaVXEEB9S/Ojdj0 o2NEAR7nrLhy/I5W/o60sI272O3oXVxBbZpA468iKSShAePQkY+KuNVpSSTsAyI4RZ ec7mmlC1G2vpx3CxMYHa7wPN0w/hGDIe2y23udfh3Zh61nSmxecTU6aqqwEpFeRy6o 9Yb5ougcyIRfQ== Subject: [dispatch] draft-dawes-dispatch-logme-reqs-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 21:24:01 -0000 Some questions about this draft: The requirements and other discussion imply certain behavior by servers that support this. I'd like to hear more explicit discussion of what that expected behavior is, within the potential solutions. E.g., when some servers are expected to be dialog stateful. Also if logging is to stop after some period of time. Section 7.1: This says the header is first inserted by the UAC. There might be reason to have it inserted by the UAS in some cases, or even a proxy or B2BUA based on policy for debugging a UA that can't be controlled. Is free text good enough for identifying test cases? Isn't there possibility of collision? Since there is likely to be resistance to meaningful names that might tunnel information, perhaps these should be random numbers. I want to hear more about sending the address of the server collecting logs. For this to be useful there must be an explicit or implicit protocol used to transmit the logs. Is there one such protocol or many? If many, how do you know which will be supported? What about trust by the server doing the logging of the log server, and authorization by the log server of those sending logs? Will all servers doing logging want to use a server chosen by the one inserting the logme request? Section 7.2: Where does the test case id go with this solution? In Figure 3 the call-info in the figure is syntactically incorrect. The parameter is a domain name, but it is required to be a URL. Thanks, Paul From keith.drage@alcatel-lucent.com Mon Jul 22 18:49:21 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A48311E81D0 for ; Mon, 22 Jul 2013 18:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU7Ye8tLm84C for ; Mon, 22 Jul 2013 18:49:15 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A3E4611E8183 for ; Mon, 22 Jul 2013 18:49:15 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6N1nCNb023934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Jul 2013 20:49:13 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6N1nBWN032617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jul 2013 03:49:11 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 23 Jul 2013 03:49:11 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-dawes-dispatch-logme-reqs-02 Thread-Index: AQHOhyHT2fQ5+R9+ZUKrwNePXTabJZlxfzRg Date: Tue, 23 Jul 2013 01:49:10 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07036A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <51EDA2E8.1050603@alum.mit.edu> In-Reply-To: <51EDA2E8.1050603@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 01:49:21 -0000 The next discussion of this draft will take place in the INSIPID group so y= ou might like to post your comments there. Regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 22 July 2013 22:24 > To: dispatch@ietf.org > Subject: [dispatch] draft-dawes-dispatch-logme-reqs-02 >=20 > Some questions about this draft: >=20 > The requirements and other discussion imply certain behavior by servers > that support this. I'd like to hear more explicit discussion of what > that expected behavior is, within the potential solutions. >=20 > E.g., when some servers are expected to be dialog stateful. Also if > logging is to stop after some period of time. >=20 > Section 7.1: >=20 > This says the header is first inserted by the UAC. There might be reason > to have it inserted by the UAS in some cases, or even a proxy or B2BUA > based on policy for debugging a UA that can't be controlled. >=20 > Is free text good enough for identifying test cases? Isn't there > possibility of collision? Since there is likely to be resistance to > meaningful names that might tunnel information, perhaps these should be > random numbers. >=20 > I want to hear more about sending the address of the server collecting > logs. For this to be useful there must be an explicit or implicit > protocol used to transmit the logs. Is there one such protocol or many? > If many, how do you know which will be supported? What about trust by > the server doing the logging of the log server, and authorization by the > log server of those sending logs? Will all servers doing logging want to > use a server chosen by the one inserting the logme request? >=20 > Section 7.2: >=20 > Where does the test case id go with this solution? >=20 > In Figure 3 the call-info in the figure is syntactically incorrect. The > parameter is a domain name, but it is required to be a URL. >=20 > Thanks, > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Mon Jul 22 19:49:35 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0625911E81D4 for ; Mon, 22 Jul 2013 19:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.03 X-Spam-Level: X-Spam-Status: No, score=0.03 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqJkaqfb1fuE for ; Mon, 22 Jul 2013 19:49:28 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id D0B9511E8183 for ; Mon, 22 Jul 2013 19:49:27 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta04.westchester.pa.mail.comcast.net with comcast id 3ekS1m0041GhbT854epThk; Tue, 23 Jul 2013 02:49:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id 3epS1m00u3ZTu2S3TepTlY; Tue, 23 Jul 2013 02:49:27 +0000 Message-ID: <51EDEF36.9020702@alum.mit.edu> Date: Mon, 22 Jul 2013 22:49:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <51EDA2E8.1050603@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B07036A@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B07036A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374547767; bh=iNT/yvnh++rhEb8eaM/4ubyyBSQCkcxQbHjBKPSN7kA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fghHIm6Gr+0W7D/51llB/LDnIH9dasHVsBwsrIkHIaPy3CJ+Akej9WsMqzikN2GOf C5KIQxNnzKCPsXH98x21amawvhqkNdvCO2COMWXTKRR78bSGqyMyuzF6qfxnfRmFB+ DMVXT8RB5l/YzZ/Om7SafFoOsJ6oEQOM+MXUqZRyXvpdofLxljVlvJngQ/GKfgKSgA KJeC/mLaiZY/wRY1qlPoUS+ls9F4RyPQ9WerSXcnnJe1knrUBddQbzjAyYqzllE6j7 GUffiNELVEnJh6p2xvNUsuCXXctpL7/QQI3aD+ZMLClzS4Fs9MaHAC0CYEIhGfqyPt NJ3Gwz+u54rkg== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 02:49:35 -0000 On 7/22/13 9:49 PM, DRAGE, Keith (Keith) wrote: > The next discussion of this draft will take place in the INSIPID group so you might like to post your comments there. OK. I wasn't thinking - just went by the name of the draft. Thanks, Paul > Regards > > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 22 July 2013 22:24 >> To: dispatch@ietf.org >> Subject: [dispatch] draft-dawes-dispatch-logme-reqs-02 >> >> Some questions about this draft: >> >> The requirements and other discussion imply certain behavior by servers >> that support this. I'd like to hear more explicit discussion of what >> that expected behavior is, within the potential solutions. >> >> E.g., when some servers are expected to be dialog stateful. Also if >> logging is to stop after some period of time. >> >> Section 7.1: >> >> This says the header is first inserted by the UAC. There might be reason >> to have it inserted by the UAS in some cases, or even a proxy or B2BUA >> based on policy for debugging a UA that can't be controlled. >> >> Is free text good enough for identifying test cases? Isn't there >> possibility of collision? Since there is likely to be resistance to >> meaningful names that might tunnel information, perhaps these should be >> random numbers. >> >> I want to hear more about sending the address of the server collecting >> logs. For this to be useful there must be an explicit or implicit >> protocol used to transmit the logs. Is there one such protocol or many? >> If many, how do you know which will be supported? What about trust by >> the server doing the logging of the log server, and authorization by the >> log server of those sending logs? Will all servers doing logging want to >> use a server chosen by the one inserting the logme request? >> >> Section 7.2: >> >> Where does the test case id go with this solution? >> >> In Figure 3 the call-info in the figure is syntactically incorrect. The >> parameter is a domain name, but it is required to be a URL. >> >> Thanks, >> Paul >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From fas_vm@surguttel.ru Tue Jul 23 08:33:40 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC7F11E810E for ; Tue, 23 Jul 2013 08:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.484 X-Spam-Level: *** X-Spam-Status: No, score=3.484 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FAKE_REPLY_C=2.012, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-MATnKJXk1H for ; Tue, 23 Jul 2013 08:33:34 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2E40F11E80F2 for ; Tue, 23 Jul 2013 08:33:33 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id 1D713514744; Tue, 23 Jul 2013 21:33:22 +0600 (YEKT) Received: from Gateway (unknown [151.252.65.92]) by mail.s86.ru (Postfix) with ESMTPA id E61235144AA for ; Tue, 23 Jul 2013 21:33:18 +0600 (YEKT) Message-ID: <6DC3744292C44522ADC8D3C7D7CB876B@Gateway> From: "Anton Tveretin" To: Date: Tue, 23 Jul 2013 21:31:12 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130723-0, 23.07.2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [dispatch] Taxonomy X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:33:40 -0000 As for me, there is no single real-time application. Telephony and television are two different applications; I do not think that a combined device makes any use. From fas_vm@surguttel.ru Tue Jul 23 09:33:35 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3311C11E82BF for ; Tue, 23 Jul 2013 09:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.478 X-Spam-Level: ** X-Spam-Status: No, score=2.478 tagged_above=-999 required=5 tests=[AWL=1.006, BAYES_50=0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bw3T3jHWCv42 for ; Tue, 23 Jul 2013 09:33:29 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 16DE711E82C3 for ; Tue, 23 Jul 2013 09:33:27 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id 17FB9514411; Tue, 23 Jul 2013 22:33:25 +0600 (YEKT) Received: from Gateway (unknown [151.252.65.92]) by mail.s86.ru (Postfix) with ESMTPA id CEF4C5143AF for ; Tue, 23 Jul 2013 22:33:21 +0600 (YEKT) Message-ID: From: "Anton Tveretin" To: Date: Tue, 23 Jul 2013 22:17:41 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130723-0, 23.07.2013), Outbound message X-Antivirus-Status: Clean Subject: [dispatch] I-D draft-tveretin-dispatch-l2tp-sdp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:33:35 -0000 OK, now I'm back. Before I continue with version -01 of this draft, consider: Intended status is STD. It is reflection of much stuff of SIP/SIPPING times having STD status. Personally, I think that it shouldn't (including this draft). So I propose either: 1. (preferred) change the intended status of this I-D to Informational, and demote all SIP/SIPPING RFCs to Informational; 2. or, leave this I-D as intended STD. Besides, I will separate references into normative and informative (not done yet), and I think I should have more references. Sincerely yours. Anton Tveretin From keith.drage@alcatel-lucent.com Tue Jul 23 18:47:22 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B640811E81B9 for ; Tue, 23 Jul 2013 18:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.576 X-Spam-Level: X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfVWEJgDgwNF for ; Tue, 23 Jul 2013 18:47:17 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4060111E81AC for ; Tue, 23 Jul 2013 18:47:17 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r6O1lEpi025712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Jul 2013 20:47:15 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6O1lCcg032509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 03:47:14 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 24 Jul 2013 03:47:12 +0200 From: "DRAGE, Keith (Keith)" To: Anton Tveretin , "dispatch@ietf.org" Thread-Topic: [dispatch] I-D draft-tveretin-dispatch-l2tp-sdp-00.txt Thread-Index: AQHOh8Jkm1MEcKVE7ka3IJjH9hwGQZlzD5CQ Date: Wed, 24 Jul 2013 01:47:11 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0714E2@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [dispatch] I-D draft-tveretin-dispatch-l2tp-sdp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 01:47:22 -0000 Is this a jibe at the SIP and SIPPING RFCs being on standards track and nev= er progressing beyond proposed standard, or is there something deeper here = that I have failed to understand. Regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Anton Tveretin > Sent: 23 July 2013 17:18 > To: dispatch@ietf.org > Subject: [dispatch] I-D draft-tveretin-dispatch-l2tp-sdp-00.txt >=20 > OK, now I'm back. Before I continue with version -01 of this draft, > consider: > Intended status is STD. It is reflection of much stuff of SIP/SIPPING > times > having STD status. Personally, I think that it shouldn't (including this > draft). So I propose either: > 1. (preferred) change the intended status of this I-D to Informational, > and > demote all SIP/SIPPING RFCs to Informational; > 2. or, leave this I-D as intended STD. > Besides, I will separate references into normative and informative (not > done > yet), and I think I should have more references. > Sincerely yours. > Anton Tveretin >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Fri Jul 26 09:16:15 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378B811E80F6 for ; Fri, 26 Jul 2013 09:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kso3aFT8YnxX for ; Fri, 26 Jul 2013 09:16:10 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C47C911E8112 for ; Fri, 26 Jul 2013 09:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3947; q=dns/txt; s=iport; t=1374855366; x=1376064966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lHOfAz/bdvI+jPVVIqGShCwYpTblM/+PLSM8diAIxhg=; b=eUdiFLRQODxPc+WGdUTGUqcPUSaIak9gDkYYvxuV5JK9Wxm0M8drLhI1 ftPBaLJt3Stu8pWzEgwqo+pbQUjy0VXUCa26ZVT0GfXdD36reOZ5HB65R qCd97S8JSYG2rz231A027s/ewMsByC92i6ufyRJFgMBpUf011mHMkkK4d Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFANyf8lGtJV2d/2dsb2JhbABbgwY1Sga9TIEYFnSCJAEBAQMBAQEBawsQAgEIDgQQGQsnCxcOAgQOBQgBiAEGBwW4PI9KAjEHgxZvA4xAjEiFbIo3gVuBOYIq X-IronPort-AV: E=Sophos;i="4.89,752,1367971200"; d="scan'208";a="239738877" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2013 16:16:06 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6QGG67R017391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 16:16:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 11:16:05 -0500 From: "Cullen Jennings (fluffy)" To: Andrew Allen Thread-Topic: [dispatch] New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHOihtuEFwrQb1FQEyrDQGhyJ2mCQ== Date: Fri, 26 Jul 2013 16:16:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 16:16:15 -0000 FWIW =85 I reviewed theses changes and they all looked good to me. On Jul 8, 2013, at 12:10 PM, Andrew Allen wrote: > =20 > New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-i= mei-urn-as-instanceid were recently submitted > =20 > http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-15.txt > The diff from version 14 is at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-montemurro-gsma-imei-urn-15 > =20 > http://www.ietf.org/internet-drafts/draft-allen-dispatch-imei-urn-as-inst= anceid-10.txt > The diff from version 9 is at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-allen-dispatch-imei-urn-as-insta= nceid-10 > =20 > These versions reflect the PROTO review comments. > =20 > The following significant changes have been made: > =20 > draft-montemurro-gsma-imei-urn: > =20 > 1. Corrections to the ABNF based on output from Bill Fenner's tool: > http://tools.ietf.org/tools/bap/abnf.cgi. > and also corrected an error that would have resulted in a superfluous =93= =3D=94 in the case of a parameter without a value. > Also the IMEI ABNF has been linked together with the URN ABNF for a singl= e complete ABNF. > =20 > 2. The section regarding binary encoding of the IMEI has been rewri= tten and clarified. > =20 > 3. The dates of the referenced 3GPP specifications have been update= d to the latest versions. > =20 > 4. Various editorial and formatting corrections have been made. > =20 > draft-allen-dispatch-imei-urn-as-instanceid: > =20 > 1. The MSC Server for SR-VCC has been included in the text =96 this= is another element in the 3GPP architecture that for the purposes of the d= raft performs similar functions to the MSC Server for ICS which was already= mentioned. > =20 > 2. The UAC and UAS sections have been modified with reference to se= nding of responses removed from the UAC section and the requirement for an = RFC for inclusion of an instance-id containing the IMEI in a Non-REGISTER o= r non-Emergency session related response also added to the UAS section. > =20 > 5. An IANA considerations section has been added (even though there= is nothing for IANA to do) since this is required. > =20 > 6. The dates of the referenced 3GPP specifications have been update= d to the latest versions. > =20 > 7. Various editorial and formatting corrections have been made. > =20 > I would especially like to thank James Yu for the extensive review of bot= h drafts and his comments which uncovered several issues and greatly contri= buted to the readability of the documents. > =20 > The only outstanding issue I am aware of is Keith Drage=92s comment of Ma= y 25th which asks why RFC required and not specification required for inclu= sion of an instance-id containing the IMEI in a Non-REGISTER or non-Emergen= cy session related response. I have asked Cullen to respond to this as it w= as his request to require additional RFCs for any future expansion of the u= sage. > =20 > Thanks > Andrew > =20 > =20 > ---------------------------------------------------------------------=20 > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. _____________= __________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Sun Jul 28 04:59:02 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4488F21F9DA1 for ; Sun, 28 Jul 2013 04:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.303 X-Spam-Level: X-Spam-Status: No, score=-102.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQif0AXAea4Z for ; Sun, 28 Jul 2013 04:59:01 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 060DF21F9D7A for ; Sun, 28 Jul 2013 04:59:00 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id s1so43752qcw.9 for ; Sun, 28 Jul 2013 04:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=3meNmFBwvfFimBc0Z0CqXo0QpTvewvlUy/EHSGhtx0Y=; b=NJnJNCn9fJ6hARfe6BWyC9LKnG2UkfXK9yAeMRJzU0jPMX1hn6pFldLEnrDP5198Lm bm5klNepzHvKW67TavRv3no0Fo7qnt7b32NrBT9eqVFPM33Cji/aQTjwzCJFofLkcI5k F/Ixb2y7c8x4z4p7NynaY0jWE5mn2/l4Ehz222dkCTOLNV39/xXMQz9L28O+cjdplMoH a35V//85hL71NSzHHBngRq6py1vQNcOG7IjG7hgHUdI1NsD/yn8Mz306nIMk2PCwpdS+ etD7TH7nB6yfWSIWuh8I7fECbpDbRIAJGGDSBVJphLFjlaUfaETHJjrHB/P0rquk6ROC o3hw== MIME-Version: 1.0 X-Received: by 10.49.26.202 with SMTP id n10mr64826692qeg.60.1375012739663; Sun, 28 Jul 2013 04:58:59 -0700 (PDT) Received: by 10.49.48.42 with HTTP; Sun, 28 Jul 2013 04:58:59 -0700 (PDT) In-Reply-To: <68D007A2-9596-4D64-8426-7B99410BEF25@netapp.com> References: <76B78224-2A21-48F2-94ED-FE5CFD32A2BC@netapp.com> <68D007A2-9596-4D64-8426-7B99410BEF25@netapp.com> Date: Sun, 28 Jul 2013 06:58:59 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=047d7b6d970ce8cb6c04e291197c Subject: [dispatch] Fwd: ANRP winner talk on rate control for media streaming in IRTFOPEN X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 11:59:02 -0000 --047d7b6d970ce8cb6c04e291197c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI...this might be of interest to RAI folks. ---------- Forwarded message ---------- From: Eggert, Lars Date: Sun, Jul 28, 2013 at 6:15 AM Subject: ANRP winner talk on rate control for media streaming in IRTFOPEN To: "" , "rai@ietf.org" , "iccrg@irtf.org" Hi, the following talk by ANRP 2013 prize winner Laurent Vanbever is probably of interest to some RAI and TSV folks. The talk will start at approx. 9:15AM on Tuesday: > *** TE-YUAN HUANG *** for insights into the difficulties of rate > adaptation for streaming video: > > Te-Yuan Huang, Nikhil Handigol, Brandon Heller, Nick McKeown > and Ramesh Johari. Confused, Timid, and Unstable: Picking a > Video Streaming Rate is Hard. Proc. ACM Internet Measurement > Conference (IMC),November 2012, Boston, MA, USA. > > Today=E2=80=99s commercial video streaming services use dynamic r= ate > selection to provide a high-quality user experience. We > measure three popular video streaming services and =EF=AC=81nd th= at > accurate client-side bandwidth estimation above the HTTP > layer is hard. As a result, rate selection based on > inaccurate estimates can trigger a feedback loop, leading to > undesirably variable and low-quality video. In this talk, we > will present insights into its root causes and validate > initial solutions to prevent it. Lars --047d7b6d970ce8cb6c04e291197c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI...this might be of interest to RAI folks.

---------- Forwarded message ----------
From: Eggert, Lars <lars@netapp.com>
Date: Sun, Jul 28, 2013 at 6:15 AM
Subject: ANRP winner talk on rate con= trol for media streaming in IRTFOPEN
To: "<tsv-area@ietf.org>" <tsv-area@ietf.org>, "rai@ietf.org" <rai@ietf.org= >, "iccrg@irtf.org" = <iccrg@irtf.org>


Hi,

the following talk by ANRP 2013 prize winner Laurent Vanbever is probably o= f interest to some RAI and TSV folks. The talk will start at approx. 9:15AM= on Tuesday:

> =C2=A0 =C2=A0 *** TE-YUAN HUANG *** for insights into the difficulties= of rate
> =C2=A0 =C2=A0 adaptation for streaming video:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Te-Yuan Huang, Nikhil Handigol, Brandon He= ller, Nick McKeown
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 and Ramesh Johari. Confused, Timid, and Un= stable: Picking a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Video Streaming Rate is Hard. Proc. ACM In= ternet Measurement
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Conference (IMC),November 2012, Boston, MA= , USA.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Today=E2=80=99s commercial video streaming= services use dynamic rate
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 selection to provide a high-quality user e= xperience. We
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 measure three popular video streaming serv= ices and =EF=AC=81nd that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 accurate client-side bandwidth estimation = above the HTTP
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 layer is hard. As a result, rate selection= based on
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 inaccurate estimates can trigger a feedbac= k loop, leading to
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 undesirably variable and low-quality video= . In this talk, we
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 will present insights into its root causes= and validate
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 initial solutions to prevent it.

Lars

--047d7b6d970ce8cb6c04e291197c-- From hadriel.kaplan@oracle.com Mon Jul 29 00:40:43 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF83121F996F for ; Mon, 29 Jul 2013 00:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I3eoql2ldA8 for ; Mon, 29 Jul 2013 00:40:38 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7710B21F8CDD for ; Mon, 29 Jul 2013 00:40:38 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6T7ebjO009857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 29 Jul 2013 07:40:38 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6T7eaSe024697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Jul 2013 07:40:37 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6T7eaw3006756 for ; Mon, 29 Jul 2013 07:40:36 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Jul 2013 00:40:36 -0700 From: Hadriel Kaplan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jul 2013 03:40:40 -0400 References: <20130729073108.1851.41406.idtracker@ietfa.amsl.com> To: "dispatch@ietf.org list" Message-Id: <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 07:40:44 -0000 Howdy, During discussion on the STRAW WG mailing list about the sip-traceroute = draft found here: http://tools.ietf.org/html/draft-ietf-straw-sip-traceroute-00 ...we realized we needed a way for a B2BUA to answer a = media-loopback-based INVITE and establish a dialog with the UAC, and = somehow tell the UAC it was the B2BUA answering and not the final target = UAS. That way the UAC would know it hasn't reached the end of its = traceroute testing and to instead continue increasing max-forwards. So = we were thinking of doing this as a 205 response, along with a Reason = header. The below draft is for that new response code. I'm sending this to DISPATCH because I think that's what I'm supposed to = do, but I believe it should be dispatched to SIPCORE and let them decide = whether it makes sense or not, etc. -hadriel Begin forwarded message: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Session Initiation Protocol (SIP) Success = Response Code for Indication of Alternate Target Answerer > Author(s) : Hadriel Kaplan > Filename : draft-kaplan-dispatch-sip-205-response-00.txt > Pages : 7 > Date : 2013-07-29 >=20 > Abstract: > This document defines a new Session Initiation Protocol (SIP) > response, 205 Alternate Answerer, that a SIP User Agent Server (UAS) > can use to indicate to the User Agent Client (UAC) that the UAS is > answering the request for which it was not the intended target. > This is useful for cases where the UAC might wish to perform > different actions based on such knowledge, such as terminate the > dialog or re-attempt the request in a different way. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-kaplan-dispatch-sip-205-response >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-kaplan-dispatch-sip-205-response-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From atle.monrad@ericsson.com Mon Jul 29 01:11:27 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0868821F9D07 for ; Mon, 29 Jul 2013 01:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zllULsLARMUH for ; Mon, 29 Jul 2013 01:11:21 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DD36121F9808 for ; Mon, 29 Jul 2013 01:11:18 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-83-51f623a5461f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 01.28.11907.5A326F15; Mon, 29 Jul 2013 10:11:18 +0200 (CEST) Received: from ESESSMB203.ericsson.se ([169.254.3.48]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Mon, 29 Jul 2013 10:11:17 +0200 From: Atle Monrad To: "dispatch@ietf.org" Thread-Topic: New Version Notification for draft-avasarala-dispatch-comm-div-notification-12.txt Thread-Index: Ac6MMii+QIDtxA3jRfyuzWCUcnk4Ig== Date: Mon, 29 Jul 2013 08:11:17 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C14A8CE@ESESSMB203.ericsson.se> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvre4y5W+BBt+vsVksnbSA1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGc+3bWQsOCdesaX7NEsDY4N4FyMnh4SAicS0aZvYIGwxiQv3 1gPZXBxCAkcZJZ6v28kO4SxmlNh0cBsLSBWbgI7EuZ93WEFsEQFtiaOrupi7GDk4hAUSJRYd LgIxRQSSJPqfqEKYehL37+SCFLMIqEpsmX4MbBWvgLfE05/zWUFKGAVkJeY28YKEmQXEJW49 mc8EcY2AxJI955khbFGJl4//sULYShKNS56AtTILaEqs36UP0aooMaX7ITvEdEGJkzOfsExg FJ6FZOoshI5ZSDpmIelYwMiyipGjOLU4KTfdyGATIzB8D275bbGD8fJfm0OM0hwsSuK8W/TO BAoJpCeWpGanphakFsUXleakFh9iZOLglGpgzLaZbnO7Oihg5kWlQ8/Wm2b/f1TJF90648Td jsN/9/CeZDCJT1WcktaR+6z/y73Jpsse6nG/6O3ea9Hq/ak790bF/4caJz7lp6qL23392+iW JRQX9vJF0rP3hxpzZT6eMDQrXm/Ja9Mp9ZztTvbE8IQXNkxztlourFFLtRX7y+uqvWTV1f0r lFiKMxINtZiLihMBBsxbFi0CAAA= Subject: Re: [dispatch] New Version Notification for draft-avasarala-dispatch-comm-div-notification-12.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:11:27 -0000 QWxsDQoNClRoaXMgZHJhZnQgaXMgYSAzR1BQIGRlcGVuZGVuY3kgdGhhdCBoYXMgYmVlbiBhcm91 bmQgZm9yIGxvbmcgdGltZS4NCg0KSSBob3BlIHRoaXMgdmVyc2lvbiBpcyBhY2NlcHRhYmxlIGFu ZCBjYW4gZ28gZm9yd2FyZC4NCg0KdGhhbmtzDQovYXRsZQ0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIA0KDQoNCkF0bGUgTW9ucmFkDQozR1BQIENUIENoYWlybWFuDQoNCkdy b3VwIEZ1bmN0aW9uIFRlY2hub2xvZ3kg4oCTIFN0YW5kYXJkaXphdGlvbiBhbmQgVGVjaG5pY2Fs IFJlZ3VsYXRpb24gDQpFcmljc3Nvbg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10gDQpTZW50OiAxMy4ganVsaSAyMDEzIDAxOjQwDQpUbzogSm9obi1MdWMgQmFra2Vy OyBSYW5qaXQgQXZhc2FyYWxhOyBKb2huLUx1YyBCYWtrZXINClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYXZhc2FyYWxhLWRpc3BhdGNoLWNvbW0tZGl2LW5vdGlm aWNhdGlvbi0xMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYXZhc2FyYWxh LWRpc3BhdGNoLWNvbW0tZGl2LW5vdGlmaWNhdGlvbi0xMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSm9obiBMdWMgQmFra2VyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICBkcmFmdC1hdmFzYXJhbGEtZGlzcGF0Y2gt Y29tbS1kaXYtbm90aWZpY2F0aW9uDQpSZXZpc2lvbjogICAgICAgIDEyDQpUaXRsZTogICAgICAg ICAgIEEgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIEV2ZW50IFBhY2thZ2UgZm9y IENvbW11bmljYXRpb24gRGl2ZXJzaW9uIEluZm9ybWF0aW9uIGluIHN1cHBvcnQgb2YgdGhlIENv bW11bmljYXRpb24gRGl2ZXJzaW9uIChDRElWKSBOb3RpZmljYXRpb24gKENESVZOKSBDRElWIHNl cnZpY2UNCkNyZWF0aW9uIGRhdGU6ICAgMjAxMy0wNy0xMw0KR3JvdXA6ICAgICAgICAgICBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTYNClVSTDogICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYXZhc2FyYWxhLWRpc3Bh dGNoLWNvbW0tZGl2LW5vdGlmaWNhdGlvbi0xMi50eHQNClN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hdmFzYXJhbGEtZGlzcGF0Y2gtY29tbS1k aXYtbm90aWZpY2F0aW9uDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWF2YXNhcmFsYS1kaXNwYXRjaC1jb21tLWRpdi1ub3RpZmljYXRpb24tMTINCkRp ZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYXZh c2FyYWxhLWRpc3BhdGNoLWNvbW0tZGl2LW5vdGlmaWNhdGlvbi0xMg0KDQpBYnN0cmFjdDoNCiAg IDNHUFAgYW5kIFRJU1BBTiBhcmUgZGVmaW5pbmcgdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24g Zm9yIHRoZQ0KICAgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gKENESVYpIHNlcnZpY2UgdXNpbmcg SVAgTXVsdGltZWRpYSAoSU0pIENvcmUNCiAgIE5ldHdvcmsgKENOKSBzdWJzeXN0ZW0gKElNUykg c3VwcGxlbWVudGFyeSBzZXJ2aWNlLiAgQXMgcGFydCBvZiBDRElWLA0KICAgYSBTSVAgYmFzZWQg ZXZlbnQgcGFja2FnZSBpcyB1c2VkIGZvciBub3RpZnlpbmcgdXNlcnMgYWJvdXQNCiAgIGRpdmVy c2lvbnMgKHJlLWRpcmVjdGlvbnMgb3IgZm9yd2FyZGluZykgb2YgcmVxdWVzdHMgZm9yDQogICBj b21tdW5pY2F0aW9uIHNlc3Npb25zIHRhcmdldHRpbmcgdGhlIHVzZXIuICBUaGlzIGRvY3VtZW50 IGRlZmluZXMNCiAgIHRoZSBTSVAgZXZlbnQgcGFja2FnZSB0byBzdXBwb3J0IHN1YnNjcmlwdGlv biBhbmQgbm90aWZpY2F0aW9uIG9mDQogICBkaXZlcnNpb25zLiAgVGhlIHByb3Bvc2VkIGV2ZW50 IHBhY2thZ2UgaXMgYXBwbGljYWJsZSB0byB0aGUgQ0RJVg0KICAgc3VwcGxlbWVudGFyeSBzZXJ2 aWNlIGluIElNUyBhbmQgbWF5IG5vdCBiZSBhcHBsaWNhYmxlIHRvIHRoZSBnZW5lcmFsDQogICBp bnRlcm5ldC4NCg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From atle.monrad@ericsson.com Mon Jul 29 01:39:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458C921F9EDF for ; Mon, 29 Jul 2013 01:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afu2WIKXFUx6 for ; Mon, 29 Jul 2013 01:39:37 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 99D5421F9E15 for ; Mon, 29 Jul 2013 01:39:34 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-6a-51f62a452419 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F6.0C.11907.54A26F15; Mon, 29 Jul 2013 10:39:33 +0200 (CEST) Received: from ESESSMB203.ericsson.se ([169.254.3.48]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Mon, 29 Jul 2013 10:39:33 +0200 From: Atle Monrad To: Mayumi Ohsugi , "dispatch@ietf.org" Thread-Topic: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind Thread-Index: AQHOgc8/nVrLkpIm20qv5/AQF7UZC5l7XWNw Date: Mon, 29 Jul 2013 08:39:31 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C14AA59@ESESSMB203.ericsson.se> References: <51E4B4ED.4060305@ntt-at.co.jp> In-Reply-To: <51E4B4ED.4060305@ntt-at.co.jp> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvra6r1rdAg2dT9CyWTlrAajGro4nd gcljyZKfTB6/Nm1kDWCK4rJJSc3JLEst0rdL4Mp4seMLS8Ei7opvx1uYGxhXcHYxcnJICJhI XF25ihnCFpO4cG89WxcjF4eQwFFGiRd9r1khnMWMEot3N7GDVLEJ6Eic+3mHFcQWEYiUmLJ4 KpgtLBAqsbblEwtEPEyi9dA7dgjbSGLCz0Y2EJtFQFWi5e9mRhCbV8BbYsa5RrB6IQFtiTvH N4HVcALN33FsPtBMDg5GAVmJuU28IGFmAXGJW0/mM0EcKiCxZM95qKNFJV4+/scKYStJNC55 wgpRryOxYPcnNghbW2LZwtfMEGsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMHMWpxUm5 6UYGmxiB0XBwy2+LHYyX/9ocYpTmYFES592idyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A6P7ow36vLcb5D+/59GYNv3Ri+/r2zc/f7znu77v77c2szfvEmbg1hJzWrjcW3/uhiR/N2Yv 9twTk2YnLjhzUcQuz0Qm9699aJSi3tkd7bubeJQ5ulZ/mSWW6viDtUt5zaqV//0v3lduu5x0 8ZeZ1s/q7XlN1/23JfB8VpSNeO3cXqp+4vLU9F9KLMUZiYZazEXFiQBatrKcVAIAAA== Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:39:42 -0000 All Thanks to Mayumi to pick up the remaining topics on this draft. I have reviewed the new version. I have no comments and can confirm that 3GPP would like to get the draft co= mpleted to finish one of our long time outstanding dependencies. cheers /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation=20 Ericsson -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Mayumi Ohsugi Sent: 16. juli 2013 04:50 To: dispatch@ietf.org Subject: [dispatch] New version of draft-vanelburg-dispatch-private-network= -ind Hi, I have submitted the following draft: http://www.ietf.org/id/draft-vanelburg-dispatch-private-network-ind-02.txt The draft was discussed in DISPATCH list three years ago.=20 While it has been expired for more than two years, the draft has been refer= red in 3GPP IMS specifications and the P-Private-Network-Indication header = field is now implemented by some vendors for enterprise customers. We have updated the draft to solve the remaining issues from Expert Review = (by John Elwell) of three years ago. Any comments are welcome. Thanks, Mayumi ----- Mayumi Ohsugi, NTT _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Mon Jul 29 01:54:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4AF21E8087 for ; Mon, 29 Jul 2013 01:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDl94G+2nptC for ; Mon, 29 Jul 2013 01:54:24 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 54E0121F9E6C for ; Mon, 29 Jul 2013 01:54:12 -0700 (PDT) Received: from dhcp-5033.meeting.ietf.org (dhcp-5033.meeting.ietf.org [130.129.80.51]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6T8s8Cc034100 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 29 Jul 2013 03:54:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51F62DAF.2080009@nostrum.com> Date: Mon, 29 Jul 2013 10:54:07 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John-Luc Bakker References: <20130324173154.5139.13198.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA35D343DA@XMB103ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35D343DA@XMB103ADS.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 130.129.80.51 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-div-notification-11.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:54:26 -0000 On 3/24/13 20:06, John-Luc Bakker wrote: > The FSM is per subscriber's URI. So a subscriber with multiple URIs can have multiple FSMs. I can't believe the number of times we've had to go over this, but that's quite simply not how RFC 3265/RFC 6665 works. There's an underlying state, associated with the resource to which you are subscribing. Your subscription finds out about that state, as modified by any relevant filters. I can't fathom what's difficult about understanding this model. I'll repeat the guidance that I provided as private feedback in February of 2010: "Another way to examine this problem might be to consider the state as being composed of the list of diverted callers. You can age entries out, and reset the list when diversion is shut off.... Note that this is conceptually similar to what the winfo event package template does with its 'waiting' state." I'm frankly astonished at how thoroughly impervious to feedback this document has been. Beyond ignoring expert advice that clearly indicates that this is not consistent with the framework that it attempts to use (complete with specific suggestions about how to achieve the intended goals within that framework), it hasn't even adopted the common-sense suggestion that Gao Yang proposed back in late 2010 that we need to allow subscription forking. It was neither accepted as a comment nor explicitly rebutted. The authors are accepting neither architectural changes to make the overall approach viable, nor minor (and obvious) changes necessary to address real-world use cases. The reason event packages need to go through the IETF is to ensure that they receive review, with the implicit assumption that they will be shaped by that feedback. I don't see that happening here. I can't imagine why we would even consider publishing this document. /a From hadriel.kaplan@oracle.com Mon Jul 29 04:18:14 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D7021F9D09 for ; Mon, 29 Jul 2013 04:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YePovyi+2mtR for ; Mon, 29 Jul 2013 04:18:09 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id ED14721F9D1F for ; Mon, 29 Jul 2013 04:18:08 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6TBI732030061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 29 Jul 2013 11:18:08 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6TBI7i8021300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Jul 2013 11:18:07 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6TBI7cO000561 for ; Mon, 29 Jul 2013 11:18:07 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Jul 2013 04:18:07 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> Date: Mon, 29 Jul 2013 07:18:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <70E9A298-6B10-4A4C-A590-76B6C376C190@oracle.com> References: <20130729073108.1851.41406.idtracker@ietfa.amsl.com> <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> To: "dispatch@ietf.org list" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:18:14 -0000 BTW, just to be clear - this is not an official request (or draft) from = the STRAW Working Group. It's an individual draft from an individual = (me), and I'm requesting it be dispatched, and I suggest/recommend it be = dispatched to SIPCORE. -hadriel On Jul 29, 2013, at 3:40 AM, Hadriel Kaplan = wrote: >=20 > Howdy, > During discussion on the STRAW WG mailing list about the = sip-traceroute draft found here: >=20 > http://tools.ietf.org/html/draft-ietf-straw-sip-traceroute-00 >=20 > ...we realized we needed a way for a B2BUA to answer a = media-loopback-based INVITE and establish a dialog with the UAC, and = somehow tell the UAC it was the B2BUA answering and not the final target = UAS. That way the UAC would know it hasn't reached the end of its = traceroute testing and to instead continue increasing max-forwards. So = we were thinking of doing this as a 205 response, along with a Reason = header. The below draft is for that new response code. >=20 > I'm sending this to DISPATCH because I think that's what I'm supposed = to do, but I believe it should be dispatched to SIPCORE and let them = decide whether it makes sense or not, etc. >=20 > -hadriel >=20 >=20 > Begin forwarded message: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : Session Initiation Protocol (SIP) Success = Response Code for Indication of Alternate Target Answerer >> Author(s) : Hadriel Kaplan >> Filename : draft-kaplan-dispatch-sip-205-response-00.txt >> Pages : 7 >> Date : 2013-07-29 >>=20 >> Abstract: >> This document defines a new Session Initiation Protocol (SIP) >> response, 205 Alternate Answerer, that a SIP User Agent Server (UAS) >> can use to indicate to the User Agent Client (UAC) that the UAS is >> answering the request for which it was not the intended target. >> This is useful for cases where the UAC might wish to perform >> different actions based on such knowledge, such as terminate the >> dialog or re-attempt the request in a different way. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-kaplan-dispatch-sip-205-response >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-kaplan-dispatch-sip-205-response-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Mon Jul 29 08:09:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986A621F9AE3 for ; Mon, 29 Jul 2013 08:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGEriwH+71GU for ; Mon, 29 Jul 2013 08:09:17 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4A31511E8103 for ; Mon, 29 Jul 2013 08:08:13 -0700 (PDT) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 6DcW1m00516AWCUABF8BZp; Mon, 29 Jul 2013 15:08:11 +0000 Received: from dhcp-43d2.meeting.ietf.org ([130.129.67.210]) by omta06.emeryville.ca.mail.comcast.net with comcast id 6F611m00R4YBfqS8SF64ZJ; Mon, 29 Jul 2013 15:06:09 +0000 Message-ID: <51F684D9.6040204@alum.mit.edu> Date: Mon, 29 Jul 2013 17:06:01 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130729073108.1851.41406.idtracker@ietfa.amsl.com> <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> In-Reply-To: <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375110491; bh=FV8tiaaoEZmVDX8N5jQF+IW2gcDXhrK9zqUMaS2gkzc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jKdAERIDWDZThRRZuNOqXSqV80HnM/dps5T0ag9sFH+K5zHfsV0BzXECEJZke3ube ua7+ItBk+YjcMwc0YSGl4ISskz9ToCLvo6GZeRO9iQXYd3WC/fdUEKAq3+hCHXp/Ih t6WFsTkAV1Uak2C+WwKF3SbERCYcicJng3OGvfzfEL2P/1ToHivcg4KI1+PZzLehuG hRGDoiYzYIrMo98MdMaxnl3eCOYG1jGlnpR9+ID+kYkVG59U9ET4qDWicvosECRskK mYxd0lsQW7C3Qwl8mibesIW+C8HlmSNpl3gfPQPtSKNHKMxPlr1GMqp8OshuJh6W2m /kYf208B6cVXw== Subject: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:09:24 -0000 Hadriel, As sipcore co-chair, I also think sipcore will ultimately be the right place for this. But it may be valuable to leave it on dispatch for awhile. My main concern is that we talk through whether the decision to use 205 is well defined, and if introducing this will solve any problems. (And I say this in spite of this having been (IIRC) my suggestion in the first place.) It is far from clear to me whether there can be clear rules for when to use 205. - Should it be used whenever a call has been forwarded? - Should a VM server use it? (In some sense the VM server is an agent of the callee, and is entitled to use 200.) It is also not clear to me that it will solve the traceroute problem. - what if the call is forwarded. Then it might get a 205, but not for the right reason. Will that be sufficient to stop the traceroute? I don't know that these are show stoppers. I just think we need to work out the details a bit more. Assuming we think the occasions for use can be well defined, and that it solves the problem you want it to solve, then IMO we should take it to sipcore and polish it off. THanks, Paul On 7/29/13 9:40 AM, Hadriel Kaplan wrote: > > Howdy, > During discussion on the STRAW WG mailing list about the sip-traceroute draft found here: > > http://tools.ietf.org/html/draft-ietf-straw-sip-traceroute-00 > > ...we realized we needed a way for a B2BUA to answer a media-loopback-based INVITE and establish a dialog with the UAC, and somehow tell the UAC it was the B2BUA answering and not the final target UAS. That way the UAC would know it hasn't reached the end of its traceroute testing and to instead continue increasing max-forwards. So we were thinking of doing this as a 205 response, along with a Reason header. The below draft is for that new response code. > > I'm sending this to DISPATCH because I think that's what I'm supposed to do, but I believe it should be dispatched to SIPCORE and let them decide whether it makes sense or not, etc. > > -hadriel > > > Begin forwarded message: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : Session Initiation Protocol (SIP) Success Response Code for Indication of Alternate Target Answerer >> Author(s) : Hadriel Kaplan >> Filename : draft-kaplan-dispatch-sip-205-response-00.txt >> Pages : 7 >> Date : 2013-07-29 >> >> Abstract: >> This document defines a new Session Initiation Protocol (SIP) >> response, 205 Alternate Answerer, that a SIP User Agent Server (UAS) >> can use to indicate to the User Agent Client (UAC) that the UAS is >> answering the request for which it was not the intended target. >> This is useful for cases where the UAC might wish to perform >> different actions based on such knowledge, such as terminate the >> dialog or re-attempt the request in a different way. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-kaplan-dispatch-sip-205-response >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-kaplan-dispatch-sip-205-response-00 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@alum.mit.edu Mon Jul 29 13:44:43 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0841121F943C for ; Mon, 29 Jul 2013 13:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRfaEz0ZbM9C for ; Mon, 29 Jul 2013 13:44:36 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id B645521F8FA1 for ; Mon, 29 Jul 2013 13:44:36 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 6Ej31m0061smiN4ABLkcmC; Mon, 29 Jul 2013 20:44:36 +0000 Received: from dhcp-43d2.meeting.ietf.org ([130.129.67.210]) by omta20.emeryville.ca.mail.comcast.net with comcast id 6LiR1m00Q4YBfqS8gLiUHQ; Mon, 29 Jul 2013 20:42:33 +0000 Message-ID: <51F6D3B1.9020005@alum.mit.edu> Date: Mon, 29 Jul 2013 22:42:25 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130324173154.5139.13198.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA35D343DA@XMB103ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35D343DA@XMB103ADS.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375130676; bh=FMWt/6Bhgb62SSmZaxz8iZ3C9lQDYnG6upVsKAFxcKE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jW5FRn+MKF+PYTqnSgCW6aNj8cRynZS0FGl+47+73oQj0J0uZvD12V123KWhGJbMg pSzLSxfBmJ+GQ8cN7Ix7Kj+yBYgDs/xraWGDgndRkGVqKwlm75WDNuynIp7TgeHGSA mhQxuBx7Vs6ov3Ls106+mUAFp2tvdc03udiZ5473nW8JFDgG7ZWbZlOGNjIoiB9zeF vQZtO4yPRaMILvPGJ0qZlBSCOKQJG/krtjJ72rB5wSMKjOPJV5sgClWAUBCFC+kiMD ZAc64wwFjVswFg+mew4bSL46/p7o1C46C/q1r7+iGAPJJPGdxsLt39SrBWjq40oLc6 coXh6lLZOulOQ== Subject: Re: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-div-notification-11.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 20:44:44 -0000 On 3/24/13 8:06 PM, John-Luc Bakker wrote: > - Paul asked a FSM question: "Is it really the intent that the state machine is affected by the subscriber filter? That seems wrong. That means that a subscription refresh that changes the filter criteria could lose an event. > Also, is the FSM associated with the subscriber, or with the subscription? (IOW, if the same subscriber has two concurrent subscriptions, does it have two FSMs or one?)" > [response] The intended use of the event package is to notify a subscriber when a diversion occurs that matches a set of filters provided when subscribing. The FSM is per subscriber's URI. So a subscriber with multiple URIs can have multiple FSMs. Whenever a different (or first) set of rules is received, the FSM (re)starts in IDLE. Each transition in the FSM is caused by the detection of a diversion for the URI. The rules that cause a diversion to happen are different from the rules that cause a notification to happen. No notifications are missed, as long as the notified diversion matches a filter. ISTM you didn't answer my concern. If the FSM is per subscriber's URI, then two subscriptions to the same URI can still result in confusion. Perhaps you expect a deployment model where this isn't possible. But even if so, is it wise to count on that? Will you enforce that? ISTM that the FSM should be per-subscription. As a result, two different subscribers might be notified of the same diversion, and possibly not at the same time. Thanks, Paul > > Kind regards, > > JL > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, March 24, 2013 12:32 PM > To: John-Luc Bakker > Cc: ranjit.avasarala@polycom.com > Subject: New Version Notification for draft-avasarala-dispatch-comm-div-notification-11.txt > > > A new version of I-D, draft-avasarala-dispatch-comm-div-notification-11.txt > has been successfully submitted by John Luc Bakker and posted to the IETF repository. > > Filename: draft-avasarala-dispatch-comm-div-notification > Revision: 11 > Title: A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service > Creation date: 2013-03-24 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-notification-11.txt > Status: http://datatracker.ietf.org/doc/draft-avasarala-dispatch-comm-div-notification > Htmlized: http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-notification-11 > Diff: http://www.ietf.org/rfcdiff?url2=draft-avasarala-dispatch-comm-div-notification-11 > > Abstract: > 3GPP and TISPAN are defining the protocol specification for the > Communication Diversion (CDIV) service using IP Multimedia (IM) Core > Network (CN) subsystem (IMS) supplementary service. As part of CDIV, > a SIP based event package is used for notifying users about > diversions (re-directions or forwarding) of requests for > communication sessions targetting the user. This document defines > the SIP event package to support subscription and notification of > diversions. The proposed event package is applicable to the CDIV > supplementary service in IMS and may not be applicable to the general > internet. > > > > > The IETF Secretariat > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@alum.mit.edu Mon Jul 29 13:56:46 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0311121F9702 for ; Mon, 29 Jul 2013 13:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjtKt7TsMLsq for ; Mon, 29 Jul 2013 13:56:41 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id 191EE21F9948 for ; Mon, 29 Jul 2013 13:56:41 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 6FqQ1m0040b6N64ABLwhjy; Mon, 29 Jul 2013 20:56:41 +0000 Received: from dhcp-43d2.meeting.ietf.org ([130.129.67.210]) by omta03.emeryville.ca.mail.comcast.net with comcast id 6Ltw1m00h4YBfqS8PLu1NR; Mon, 29 Jul 2013 20:54:39 +0000 Message-ID: <51F6D663.5040909@alum.mit.edu> Date: Mon, 29 Jul 2013 22:53:55 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130324173154.5139.13198.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA35D343DA@XMB103ADS.rim.net> <51F62DAF.2080009@nostrum.com> In-Reply-To: <51F62DAF.2080009@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375131401; bh=1y/F5GXlimpVvOo5RNT2P6ky6dnPNYhjpMLP1k2zjH8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Bm4ccxYHmzBahWguzczUoBl4xutPciLlkncAxAjpEXb2Z6zn4A380FDxWrnl+dzod dKCu5P6ejkKvVPVDnrIONxyJeqjBR7fDNXiCIOAasI8qeKLPqbaMaRnv+Z0ih7w28C XQX5HuH+q4yWCNE9TsDrkqAO07989P3pufdoQhEcbySOSwbPu53AXtVWz5Qgv8jjuM j71mu3q2CsRtwnGbajUFCZJ8gU8iyNB/TAWZCZWtlCmoKHDB6V5g04JTN9IaGieSP8 9vAGFlYgdKqOL06biieTcL5/71rOa3V4Q/EUL12t7m+EsPJ+Y8CNNCXkmEIS1kkwo2 JTTtUfvpxDhTg== Subject: Re: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-div-notification-11.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 20:56:46 -0000 My prior reply was in the context of what the draft is trying to do - that even with its assumptions it has problems. I agree with Adam that 3265/6665 intended that the FSM be associated with the resource being subscribed to. As Adam describes below, the FSM for that would be quite different. Thanks, Paul On 7/29/13 10:54 AM, Adam Roach wrote: > On 3/24/13 20:06, John-Luc Bakker wrote: >> The FSM is per subscriber's URI. So a subscriber with multiple URIs >> can have multiple FSMs. > > I can't believe the number of times we've had to go over this, but > that's quite simply not how RFC 3265/RFC 6665 works. > > There's an underlying state, associated with the resource to which you > are subscribing. Your subscription finds out about that state, as > modified by any relevant filters. I can't fathom what's difficult about > understanding this model. > > I'll repeat the guidance that I provided as private feedback in February > of 2010: "Another way to examine this problem might be to consider the > state as being composed of the list of diverted callers. You can age > entries out, and reset the list when diversion is shut off.... Note that > this is conceptually similar to what the winfo event package template > does with its 'waiting' state." > > I'm frankly astonished at how thoroughly impervious to feedback this > document has been. Beyond ignoring expert advice that clearly indicates > that this is not consistent with the framework that it attempts to use > (complete with specific suggestions about how to achieve the intended > goals within that framework), it hasn't even adopted the common-sense > suggestion that Gao Yang proposed back in late 2010 that we need to > allow subscription forking. It was neither accepted as a comment nor > explicitly rebutted. > > The authors are accepting neither architectural changes to make the > overall approach viable, nor minor (and obvious) changes necessary to > address real-world use cases. > > The reason event packages need to go through the IETF is to ensure that > they receive review, with the implicit assumption that they will be > shaped by that feedback. I don't see that happening here. I can't > imagine why we would even consider publishing this document. > > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From hadriel.kaplan@oracle.com Tue Jul 30 00:13:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD7021F9371 for ; Tue, 30 Jul 2013 00:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvW5G+WuPXb3 for ; Tue, 30 Jul 2013 00:13:36 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DEF1E21F93E4 for ; Tue, 30 Jul 2013 00:13:35 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6U7DXRE023005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Jul 2013 07:13:34 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6U7DXIx010773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 07:13:33 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6U7DXBM010758; Tue, 30 Jul 2013 07:13:33 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 30 Jul 2013 00:13:33 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51F684D9.6040204@alum.mit.edu> Date: Tue, 30 Jul 2013 03:13:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130729073108.1851.41406.idtracker@ietfa.amsl.com> <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> <51F684D9.6040204@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: dispatch@ietf.org Subject: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 07:13:42 -0000 On Jul 29, 2013, at 11:06 AM, Paul Kyzivat = wrote: > Hadriel, >=20 > As sipcore co-chair, I also think sipcore will ultimately be the right = place for this. But it may be valuable to leave it on dispatch for = awhile. My main concern is that we talk through whether the decision to = use 205 is well defined, and if introducing this will solve any = problems. (And I say this in spite of this having been (IIRC) my = suggestion in the first place.) >=20 > It is far from clear to me whether there can be clear rules for when = to use 205. > - Should it be used whenever a call has been forwarded? By "call forwarded", you mean the call/dialog is answered/established at = a SIP layer, but then the UAS makes a separate second call to another UA = and ultimately bridges the media together? > - Should a VM server use it? (In some sense the VM server is an agent > of the callee, and is entitled to use 200.) You used the phrase "entitled to use 200", but the way I tried writing = the 205 draft was not to mandate VMs to use 205 - it was to *allow* them = to use 205. In other words, a VM (or its operator) can decide whether = to send a 205 or not, based on what it wants the UAC to do. The = rationale for sending a 205 would be to save resources on the VM, = because in theory the UAC can know it's been redirected to voicemail and = can hang up immediately. (I'm not saying the draft is good enough yet to = make the distinction that it's reached a VM, but that can be worked = on...) > It is also not clear to me that it will solve the traceroute problem. > - what if the call is forwarded. Then it might get a 205, but not for > the right reason. Will that be sufficient to stop the traceroute? Yes - the Reason header will have a cause code of 483 when it's answered = by the B2BUA for the traceroute purpose. Once the testing UAC increases = Max-Forwards, the next 205 would have a different Reason code. -hadriel From oej@edvina.net Tue Jul 30 04:24:17 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA2711E81EB for ; Tue, 30 Jul 2013 04:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COGIEuBktUHj for ; Tue, 30 Jul 2013 04:24:15 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 40A5611E81E9 for ; Tue, 30 Jul 2013 04:24:13 -0700 (PDT) Received: from [IPv6:2001:df8::16:b432:467c:9b65:7956] (unknown [IPv6:2001:df8:0:16:b432:467c:9b65:7956]) by smtp7.webway.se (Postfix) with ESMTPA id 1F74D93C2A1 for ; Tue, 30 Jul 2013 11:24:02 +0000 (UTC) From: "Olle E. Johansson" Content-Type: multipart/alternative; boundary="Apple-Mail=_85050269-1718-4F72-8526-A7A1C74C74E1" Date: Tue, 30 Jul 2013 13:24:03 +0200 References: <20130730112120.28655.39869.idtracker@ietfa.amsl.com> To: "dispatch@ietf.org list" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dispatch] Fwd: New Version Notification for draft-johansson-sip-dual-stack-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:24:17 -0000 --Apple-Mail=_85050269-1718-4F72-8526-A7A1C74C74E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi! Gonzalo and I have updated our draft that updates RFC 3263 so that DNS = lookups are done for both IPv4 and IPv6 at the same time. Changes in this version are: - Slightly re-organized the document content layout - Expanded and added some clarity to the text dealing with the "DNS = Procedures in a Dual-Stack Network" - Added some language to the Security Considerations section - Made editorial, grammatical and idnits fixes throughout We do think this belongs in SIPcore and have discussed this with the = chairs of that wg, whcih both seems to agree. /Olle Vidarebefordrat brev: > Fr=E5n: internet-drafts@ietf.org > =C4mne: New Version Notification for = draft-johansson-sip-dual-stack-01.txt > Datum: 30 juli 2013 13:21:20 CEST > Till: Olle E. Johansson , Gonzalo Salgueiro = >=20 >=20 > A new version of I-D, draft-johansson-sip-dual-stack-01.txt > has been successfully submitted by Olle E. Johansson and posted to the > IETF repository. >=20 > Filename: draft-johansson-sip-dual-stack > Revision: 01 > Title: Locating Session Initiation Protocol (SIP) = Servers in a Dual-Stack IP Network > Creation date: 2013-07-30 > Group: Individual Submission > Number of pages: 6 > URL: = http://www.ietf.org/internet-drafts/draft-johansson-sip-dual-stack-01.txt > Status: = http://datatracker.ietf.org/doc/draft-johansson-sip-dual-stack > Htmlized: = http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-johansson-sip-dual-stack-01 >=20 > Abstract: > RFC 3263 defines how a Session Initiation Protocol (SIP) > implementation, given a SIP Uniform Resource Identifier (URI), = should > locate the next hop SIP server using Domain Name System (DNS) > procedures. The specification repeatedly states that the > implementation should look up IPv4 or IPv6 addresses. This is not a > suitable solution and one that can cause severely degraded user > experience dual-stack clients, as detailed in the Happy Eyeballs > specification. This document specifies amended procedures for dual- > stack SIP implementations so that they look up both IPv4 and IPv6 > addresses. This way, the SIP implementation can find the preferred > network path and protocol with an improved chance of successfully > reaching the desired service. This document also clarifies DNS SRV > usage for single-stack clients. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_85050269-1718-4F72-8526-A7A1C74C74E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 - = Slightly re-organized the document content layout
- Expanded and added some clarity to the text dealing with = the "DNS Procedures in a Dual-Stack Network"
- Added some language to the Security Considerations = section
- Made editorial, grammatical and = idnits fixes throughout

We do think this belongs in = SIPcore and have discussed this with the chairs of that wg, whcih both = seems to = agree.

/Olle

Vidarebefordrat = brev:

Fr=E5n: internet-drafts@ietf.org
<= /span>
=C4mne: New Version Notification for = draft-johansson-sip-dual-stack-01.txt
Datum: 30 juli 2013 = 13:21:20 CEST
Till: Olle E. Johansson <oej@edvina.net>, Gonzalo Salgueiro = <gsalguei@cisco.com>


A new version of I-D, = draft-johansson-sip-dual-stack-01.txt
has been successfully submitted = by Olle E. Johansson and posted to the
IETF = repository.

Filename: = draft-johansson-sip-dual-stack
Revision: 01
Title: Locating = Session Initiation Protocol (SIP) Servers in a Dual-Stack IP = Network
Creation date: 2013-07-30
Group: = Individual Submission
Number of pages: 6
URL: =             http://www.ietf.org/internet-drafts/draft-johansson-sip-dual-stac= k-01.txt
Status: =          ht= tp://datatracker.ietf.org/doc/draft-johansson-sip-dual-stack
Htmliz= ed:        http= ://tools.ietf.org/html/draft-johansson-sip-dual-stack-01
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-johansson-sip-dual-stack-01

Abstract:
  RFC 3263 defines how a Session = Initiation Protocol (SIP)
  implementation, given a SIP = Uniform Resource Identifier (URI), should
  locate the = next hop SIP server using Domain Name System (DNS)
=   procedures.  The specification repeatedly states that = the
  implementation should look up IPv4 or IPv6 = addresses.  This is not a
  suitable solution and one = that can cause severely degraded user
  experience = dual-stack clients, as detailed in the Happy Eyeballs
=   specification.  This document specifies amended = procedures for dual-
  stack SIP implementations so that = they look up both IPv4 and IPv6
  addresses.  This = way, the SIP implementation can find the preferred
=   network path and protocol with an improved chance of = successfully
  reaching the desired service.  This = document also clarifies DNS SRV
  usage for single-stack = clients.




Please note that it may take a couple of = minutes from the time of submission
until the htmlized version and = diff are available at tools.ietf.org.

The IETF = Secretariat


---
* Olle E = Johansson - oej@edvina.net
* Cell phone = +46 70 593 68 51, Office +46 8 96 40 20, Sweden



= --Apple-Mail=_85050269-1718-4F72-8526-A7A1C74C74E1-- From richard.ejzak@alcatel-lucent.com Tue Jul 30 04:45:45 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478E621F99D0; Tue, 30 Jul 2013 04:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm0fvBbDE3Z8; Tue, 30 Jul 2013 04:45:39 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 89E8B21F9E4F; Tue, 30 Jul 2013 04:45:39 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6UBjall017779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jul 2013 06:45:36 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r6UBjaVr018744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 07:45:36 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.98]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 30 Jul 2013 07:45:36 -0400 From: "Ejzak, Richard P (Richard)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "dispatch@ietf.org" Thread-Topic: [MMUSIC] [rtcweb] [dispatch] bar BOF on msrp over DataChannels Thread-Index: AQHOjRpNvvdmZT6rGEqXeTPhf185Ug== Date: Tue, 30 Jul 2013 11:45:35 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D844196@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412CD3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412D3F@ESESSMB209.ericsson.se> <51F78002.80102@alvestrand.no> In-Reply-To: <51F78002.80102@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [dispatch] [MMUSIC] [rtcweb] bar BOF on msrp over DataChannels X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:45:45 -0000 QXMganVzdCBtZW50aW9uZWQgaW4gbW11c2ljLCB3ZSBhcmUgb3JnYW5pemluZyBhIGJhciBCT0Yg Zm9yIFRodXJzZGF5IGF0IDY6MzAgUE0gaW4gdGhlIE1hcmxlbmUgQmFyIHRvIGRpc2N1c3MgU0RQ IGFzcGVjdHMgaW4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFy Y29uLW1zcnAtb3Zlci13ZWJydGMtZGF0YS1jaGFubmVscy0wMC50eHQuICBJbiBwYXJ0aWN1bGFy LCB0aGUgZHJhZnQgaW5jbHVkZXMgU0RQIHByb2NlZHVyZXMgdG8gbmVnb3RpYXRlIHRoZSB1c2Ug b2YgYW55IHN1Yi1wcm90b2NvbCAoZS5nLiwgbXNycCwgYmZjcCwgdDE0MCkgb3ZlciBEYXRhQ2hh bm5lbHMgKGZvciBzdWItcHJvdG9jb2xzIHRoYXQgbm9ybWFsbHkgdXNlIFNEUCBuZWdvdGlhdGlv biBmb3Igb3RoZXIgdHJhbnNwb3J0IG9wdGlvbnMpLiAgU29tZSBtaW5pbWFsIGFkZGl0aW9uYWwg c3ViLXByb3RvY29sIHNwZWNpZmljIHByb2NlZHVyZXMgbWlnaHQgYWxzbyBuZWVkIHRvIGJlIHNw ZWNpZmllZC4gIFRoZSBkcmFmdCBhbHNvIGluY2x1ZGVzIG1zcnAtc3BlY2lmaWMgcHJvY2VkdXJl cyBuZWVkZWQgZm9yIHRoZSB0cmFuc3BvcnQgb2YgbXNycCBvdmVyIERhdGFDaGFubmVscy4NCg0K VGhpcyBwcm9wb3NhbCBpcyBpbnRlbmRlZCB0byBjb21wbGVtZW50IHRoZSBjdXJyZW50IERhdGFD aGFubmVsIHByb2NlZHVyZXMgd2l0aG91dCByZXF1aXJpbmcgYW55IGJyb3dzZXIgc3VwcG9ydCwg d2hpY2ggaXMgd2h5IHRoaXMgd29yayBoYXMgbm90IGJlZW4gcmFpc2VkIGRpcmVjdGx5IGluIHJ0 Y3dlYi4NCg0KUGxlYXNlIGpvaW4gdXMgYXQgdGhlIE1hcmxlbmUgYmFyIG9yIGxldCBtZSBrbm93 IGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBidXQgdW5hYmxlIHRvIHBhcnRpY2lwYXRlLg0KDQpUaGFu a3MsDQpSaWNoYXJkDQo= From oej@edvina.net Tue Jul 30 07:27:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3239C21E80FD for ; Tue, 30 Jul 2013 07:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJY1YiQ6PZaO for ; Tue, 30 Jul 2013 07:27:09 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 21B6521E80FC for ; Tue, 30 Jul 2013 07:27:09 -0700 (PDT) Received: from [IPv6:2001:df8::16:a19c:455a:375f:115d] (unknown [IPv6:2001:df8:0:16:a19c:455a:375f:115d]) by smtp7.webway.se (Postfix) with ESMTPA id C26E793C2A2 for ; Tue, 30 Jul 2013 14:27:07 +0000 (UTC) From: "Olle E. Johansson" Content-Type: multipart/alternative; boundary="Apple-Mail=_0A55D6BF-280B-4E63-A79E-034C1B1FC49B" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Tue, 30 Jul 2013 16:27:09 +0200 References: <20130730112120.28655.39869.idtracker@ietfa.amsl.com> To: "dispatch@ietf.org list" In-Reply-To: X-Mailer: Apple Mail (2.1508) Subject: Re: [dispatch] Fwd: New Version Notification for draft-johansson-sip-dual-stack-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:27:10 -0000 --Apple-Mail=_0A55D6BF-280B-4E63-A79E-034C1B1FC49B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 30 jul 2013 kl. 13:24 skrev "Olle E. Johansson" : > Hi! >=20 > Gonzalo and I have updated our draft that updates RFC 3263 so that DNS = lookups are done for both > IPv4 and IPv6 at the same time. Changes in this version are: >=20 > - Slightly re-organized the document content layout > - Expanded and added some clarity to the text dealing with the "DNS = Procedures in a Dual-Stack Network" > - Added some language to the Security Considerations section > - Made editorial, grammatical and idnits fixes throughout >=20 > We do think this belongs in SIPcore and have discussed this with the = chairs of that wg, whcih both seems to agree. Sorry for forgetting to rename the document to reflect the wg... Still = learning the process, but obviously very slowly... /O --Apple-Mail=_0A55D6BF-280B-4E63-A79E-034C1B1FC49B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 oej@edvina.net>:

- = Slightly re-organized the document content layout
- Expanded and added some clarity to the text dealing with = the "DNS Procedures in a Dual-Stack Network"
- Added some language to the Security Considerations = section
- Made editorial, grammatical and = idnits fixes throughout

We do think this belongs in = SIPcore and have discussed this with the chairs of that wg, whcih both = seems to agree.

Sorry for = forgetting to rename the document to reflect the wg... Still learning = the process, but obviously very = slowly...

/O

= --Apple-Mail=_0A55D6BF-280B-4E63-A79E-034C1B1FC49B-- From worley@shell01.TheWorld.com Tue Jul 30 07:28:38 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2FE21E8101 for ; Tue, 30 Jul 2013 07:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 141568o0Vu6R for ; Tue, 30 Jul 2013 07:28:30 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 588E021E80F5 for ; Tue, 30 Jul 2013 07:28:03 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r6UEQwuL016351; Tue, 30 Jul 2013 10:27:00 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r6UEQuaV225644; Tue, 30 Jul 2013 10:26:57 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r6UEQns1226031; Tue, 30 Jul 2013 10:26:49 -0400 (EDT) Date: Tue, 30 Jul 2013 10:26:49 -0400 (EDT) Message-Id: <201307301426.r6UEQns1226031@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Atle Monrad In-reply-to: <7D2F7D7ADBA812449F25F4A69922881C14A8CE@ESESSMB203.ericsson.se> (atle.monrad@ericsson.com) References: <7D2F7D7ADBA812449F25F4A69922881C14A8CE@ESESSMB203.ericsson.se> Cc: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-avasarala-dispatch-comm-div-notification-12.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:28:38 -0000 I admit that I've not read this document thoroughly, but it does seem that Adam's criticisms are relevant. The document is also rough in a number of places, but that can be addressed after the structural problems are fixed. In regard to what SIP events *are*, the key is to remember that they are mis-named. NOTIFYs do not tell the subscriber of *events* but of changes in a *state value*. Thus SIP events can only be used to observe data which can be modeled as a state value (which pertains to the "resource" to which the SUBSCRIBE was addressed). Every definition of a SIP event package has to make explicit what the state value is. What I've just said is vague and philosophical, but it can be made concrete by asking this question: What is the body of the NOTIFY that is returned when a SUBSCRIBE is processed by the notifier? That body is the *current* state value at the moment that the SUBSCRIBE is processed. (Additionally, the notifier produces further NOTIFYs whenever the state value changes.) I note that this draft does not (as far as I could tell) answer the question, What is the body of the NOTIFY that is returned when a SUBSCRIBE is processed by the notifier? Section 6.7 says, "A notifier sends a NOTIFY request when a communication diversion is enacted on behalf of the user." But of course, receiving a SUBSCRIBE to create a subscription, or a re-SUBSCRIBE to refresh a subscription, is not "when a communication diversion is enacted". Nonetheless, a NOTIFY must be sent at those times (RFC 6665). In regard to this draft, there are many ways this problem can be fixed. A simple one would be to have the state value be the description of the *last* diversion done on behalf of subscribed-to user. You can see that that change would provide a definite state value, and the state value would change every time a diversion was done. Constructing the state value in a way that suits your purposes might require some work, but with some care, state values and filters can be constructed that handle situations that do not at the outset seem to fall within the SIP event framework. (E.g., RFC 6910.) I do not understand the purpose of section 6.11. It describes a state machine whose purpose is unclear. Is this useful information for the subscriber? And it is mis-placed, as this FSM has nothing to do with "state agents" in the sense of RFC 6665. In regard to forking of SUBSCRIBE requests, more thought needs to be applied. It is very tempting to say "It would take extra work to handle forked SUBSCRIBE requests and we don't need it." But history has shown that often forking of SUBSCRIBE requests must be supported to make things work. The draft should describe how to handle the commonest cases: - A SUBSCRIBE request is forked and two forks arrive at one notifier. Usually this is handled by rejecting all but one fork with 482 Loop Detected errors. - A SUBSCRIBE request is forked and two forks arrive at different notifiers. The subscriber receives two NOTIFYs from different notifiers, establishing two subscriptions. In most cases, the subscriber needs to maintain both subscriptions and integrate the information received from them. In some cases, it is certain that one subscription will provide all information that the subscriber needs, so it can terminate all but one subscription. But if so, there should be a clear explanation of why this is acceptable. - A subscriber establishes a subscription to the resource, and later sends a new SUBSCRIBE (different dialog) to the same resource. This may happen because the subscriber has lost record of the first subscription (and it has not yet timed out at the notifier) or because the subscriber is executing a second operation that needs the same information. Generally, two such subscriptions should be maintained independently, but in some cases that is undesirable. In the latter case, the reasons it is undesirable need to be explained and the procedures for resolving the situation need to be described. (RFC 6910 has an example of this.) Dale From worley@shell01.TheWorld.com Tue Jul 30 11:44:08 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618A611E8110 for ; Tue, 30 Jul 2013 11:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2MBpx81IjUR for ; Tue, 30 Jul 2013 11:44:02 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 799AF11E81DF for ; Tue, 30 Jul 2013 11:44:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r6UIhGB3030194 for ; Tue, 30 Jul 2013 14:43:18 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r6UIhGpl237916 for ; Tue, 30 Jul 2013 14:43:16 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r6UIhES6237996; Tue, 30 Jul 2013 14:43:14 -0400 (EDT) Date: Tue, 30 Jul 2013 14:43:14 -0400 (EDT) Message-Id: <201307301843.r6UIhES6237996@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: <51F6D3B1.9020005@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <20130324173154.5139.13198.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA35D343DA@XMB103ADS.rim.net> <51F6D3B1.9020005@alum.mit.edu> Subject: Re: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-div-notification-11.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 18:44:08 -0000 > On 3/24/13 8:06 PM, John-Luc Bakker wrote: > The intended use of the event package is to notify a > subscriber when a diversion occurs that matches a set of filters > provided when subscribing. The FSM is per subscriber's URI. So a > subscriber with multiple URIs can have multiple FSMs. Whenever a > different (or first) set of rules is received, the FSM (re)starts in > IDLE. Each transition in the FSM is caused by the detection of a > diversion for the URI. The rules that cause a diversion to happen > are different from the rules that cause a notification to happen. No > notifications are missed, as long as the notified diversion matches > a filter. First, you have to remember that the SIP event notification model does not directly support "send a NOTIFY whenever X happens". But I've written about that before. You say, "The FSM is per subscriber's URI." This is treacherous ground because of how it interacts with the case when a single entity makes two subscriptions, with each subscription using the same From address, that is, using the same subscriber's URI. How do you want that to work? (And exactly what definition of equality for "subscriber's URI" are you using? For that matter, is the notifier ensured of seeing the *actual* subscriber's URI in the From header, or might it get rewritten by some B2BUA somewhere?) It is considerably safer and closer to the SIP model to say, "The FSM is per subscription." Even so, there are probably complications you haven't considered. For example, when a diversion is done that does not match the filter, the FSM may transition from DIVERSION NOTIFIED to DIVERSION NOT NOTIFIED. But the state of the FSM is *part of the state that is visible to the subscriber*, and since that changes, the notifier is obligated (RFC 6665) to sent a NOTIFY to inform the subscriber of that. Dale