Subject: Re: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added]
From: Christer Holmberg <[email-masked]>
To: "mmusic (E-mail)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Ben Campbell <[email-masked]>
Date: Mon, 10 Apr 2017 19:10:55 +0000
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>

And XXX stands for section 5.1 :)

From: Christer Holmberg
Sent: 10 April 2017 22:10
To: Christer Holmberg <[email-masked]>; mmusic (E-mail) <[email-masked]>
Cc: [email-masked]; Ben Campbell <[email-masked]>
Subject: SDP connection attribute optional [was: DTLS-SDP: TLS support added]

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 present); OR

2)      We mandate that the connection attribute is present, with an 'existing' value, whenever an existing connection is to be maintained.

Option 2) seems most safe, i.e., we continue using the 'connection' attribute and its semantics even if both endpoints support the 'tls-id' attribute.

Comments?

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 09 April 2017 10:15
To: mmusic (E-mail) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Ben Campbell <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] DTLS-SDP: TLS support added

Hi,

Based on the decision in Chicago to allow usage of the SDP 'dtls-id' attribute 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 throughout the document, I've basically added a section describing the TLS-specific considerations - mainly regarding the interaction with the SDP 'connection' attribute.

Now, I think we do need some text on WHY we also cover TLS connections since, as far as creating new connections is concerned, the 'connection' attribute 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 reference, though.

Regards,

Christer