Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2877129AB6; Mon, 10 Apr 2017 12:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANMVubtpVZae; Mon, 10 Apr 2017 12:10:31 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B121129AD2; Mon, 10 Apr 2017 12:10:25 -0700 (PDT) X-AuditID: c1b4fb2d-d97ff700000033e1-0d-58ebd89e88cd Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id F2.DF.13281.E98DBE85; Mon, 10 Apr 2017 21:10:23 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0339.000; Mon, 10 Apr 2017 21:10:22 +0200 From: Christer Holmberg To: "mmusic (E-mail)" CC: "mmusic-chairs@ietf.org" , Ben Campbell Thread-Topic: SDP connection attribute optional [was: DTLS-SDP: TLS support added] Thread-Index: AdKyNUrA9tbRCyqiRcKnD0Le75fq9gAATjfw Date: Mon, 10 Apr 2017 19:10:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB5E219@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB5E219ESESSMB102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7n+78G68jDDY2aVrM7zzNbnF+53om i6nLH7M4MHssWfKTyWPWzicsAUxRXDYpqTmZZalF+nYJXBlLX1xiKrhSXtF4rIO1gXFTZhcj J4eEgInEz+YlrF2MXBxCAusZJd7M3csIkhASWMIo8fWbaxcjBwebgIVE9z9tkLCIgLpE6+Y+ VhCbWSBcYs6bM2C2sECwxMPOqawQNSESR9dPZYewjSQ+/v4IFmcRUJW4/+opWJxXwFdi/q6f UKt8JW5PO80GYnMK+EmcfTERLM4oICbx/dQaJohd4hK3nsxngrhZQGLJnvPMELaoxMvH/1gh bCWJFdsvMULU50t8etTPCLFLUOLkzCcsExhFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaG sc8ceMyELL6AkX0Vo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmB8HdzyW3cH4+rXjocYBTgY lXh4H/S/jhBiTSwrrsw9xCjBwawkwnu1AyjEm5JYWZValB9fVJqTWnyIUZqDRUmc12HfhQgh gfTEktTs1NSC1CKYLBMHp1QDY32l35rm/kPn9a32X32fzDhhauWqd0npt3Z9+W5rPbmGWTVg /wuGR59V/zRk2bXregkYHjINPhNw+rz7kYC9fM5+qfZ3KxYnr5/8v7Hnp/2ZFeGly1tr8yNP fj04S/uMYsqLu76ZdvlHum6d7rOryBaKXPZrw3kJxe3+6fvW/99/eq3PxuObcpRYijMSDbWY i4oTAeX98M+rAgAA Archived-At: Subject: Re: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:10:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB5E219ESESSMB102erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And XXX stands for section 5.1 :) From: Christer Holmberg Sent: 10 April 2017 22:10 To: Christer Holmberg ; mmusic (E-mail) Cc: mmusic-chairs@ietf.org; Ben Campbell Subject: SDP connection attribute optional [was: DTLS-SDP: TLS support adde= d] Hi, Section XXX of RFC 4145 says: "When an offerer generates an 'm' line that uses TCP, it SHOULD provide = a connection attribute for the 'm' line unless the application using the 'm' line has other means to deal with connection reestablishment." Now, if both endpoints support the 'tls-id' attribute, that would be "other= means". However, section of RFC 4145 says: "The default value of the connection attribute in both offers and answers is 'new'." So, I think we need to say something. Either: 1) If both endpoints support tls-id, they don't need to care about the= connection attribute (or the default value in case the attribute is not pr= esent); OR 2) We mandate that the connection attribute is present, with an 'exist= ing' value, whenever an existing connection is to be maintained. Option 2) seems most safe, i.e., we continue using the 'connection' attribu= te and its semantics even if both endpoints support the 'tls-id' attribute. Comments? Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 09 April 2017 10:15 To: mmusic (E-mail) > Cc: mmusic-chairs@ietf.org; Ben Campbell > Subject: [MMUSIC] DTLS-SDP: TLS support added Hi, Based on the decision in Chicago to allow usage of the SDP 'dtls-id' attrib= ute also for TLS connections, I have created a pull request: https://github.com/cdh4u/draft-dtls-sdp/pull/26 Note that the name of the attribute has now been changed to 'tls-id'. The approach I've taken is: rather than talking about both DTLS and TLS thr= oughout the document, I've basically added a section describing the TLS-spe= cific considerations - mainly regarding the interaction with the SDP 'conne= ction' attribute. Now, I think we do need some text on WHY we also cover TLS connections sinc= e, as far as creating new connections is concerned, the 'connection' attrib= ute can be used. We know that it would be needed for draft-thomson-avtcore-= sdp-uks (https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/). = But, AFAIK that work has not been adopted yet, so I don't think we can use = it as justification at this point? Note that this pull request does NOT include any of the changes to be done = based on the gen-art/sec-dir reviews. I have updated the 4572-update refere= nce, though. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB5E219ESESSMB102erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And XXX stands for sec= tion 5.1 :)

 

From: Christer Holmberg
Sent: 10 April 2017 22:10
To: Christer Holmberg <christer.holmberg@ericsson.com>; mmusic= (E-mail) <mmusic@ietf.org>
Cc: mmusic-chairs@ietf.org; Ben Campbell <ben@nostrum.com>
Subject: SDP connection attribute optional [was: DTLS-SDP: TLS suppo= rt added]

 

Hi,<= /p>

 

Section XXX of RFC 414= 5 says:

 

   “When an off= erer generates an 'm' line that uses TCP, it SHOULD provide a

   connection attribu= te for the 'm' line unless the application using

   the 'm' line has o= ther means to deal with connection reestablishment.”

 

Now, if both endpoints= support the ‘tls-id’ attribute, that would be “other mea= ns”.

 

However, section of RF= C 4145 says:

 

   “The default value of the connection attribute in b=
oth offers and
   answers is 'new'.”

 

So, I think we need to= say something. Either:

 

1)&= nbsp;     If both endpoi= nts support tls-id, they don’t need to care about the connection attr= ibute (or the default value in case the attribute is not present); OR<= /o:p>

2)&= nbsp;     We mandate tha= t the connection attribute is present, with an ‘existing’ value= , whenever an existing connection is to be maintained.

 

Option 2) seems most s= afe, i.e., we continue using the ‘connection’ attribute and its= semantics even if both endpoints support the ‘tls-id’ attribut= e.

 

Comments?

 

Regards,

 

Christer

 

 

From: mmusic [mailto:mmusic-b= ounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 09 April 2017 10:15
To: mmusic (E-mail) <mmusic@ie= tf.org>
Cc: mmusic-chairs@ietf.org= ; Ben Campbell <ben@nostrum.com>
Subject: [MMUSIC] DTLS-SDP: TLS support added

 

Hi,

 

Based on the decision in Chicago to allow usage of t= he SDP ‘dtls-id’ attribute also for TLS connections, I have cre= ated a pull request:

 

https://github.com/cdh4u/draft-dtls-sdp/pull/26

 

Note that the name of the attribute has now been cha= nged to ‘tls-id’.

 

The approach I’ve taken is: rather than talkin= g about both DTLS and TLS throughout the document, I’ve basically add= ed a section describing the TLS-specific considerations – mainly rega= rding the interaction with the SDP ‘connection’ attribute.=

 

Now, I think we do need some text on WHY we also cov= er TLS connections since, as far as creating new connections is concerned, = the ‘connection’ attribute can be used. We know that it would b= e needed for draft-thomson-avtcore-sdp-uks (https://datatracker.ietf.org/d= oc/draft-thomson-avtcore-sdp-uks/). But, AFAIK that work has not been adopted yet, so I don’t think we c= an use it as justification at this point?

 

Note that this pull request does NOT include any of = the changes to be done based on the gen-art/sec-dir reviews. I have updated= the 4572-update reference, though.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4CB5E219ESESSMB102erics_--