Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

On 3/7/16 3:09 AM, Christer Holmberg wrote:
> So, would anyone object to the principle of going forward with an ID approach?

I am ok with this, as long as it is done well.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: 7. maaliskuuta 2016 0:46
> To: Justin Uberti
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics
>
> On 3/3/16 7:35 PM, Justin Uberti wrote:
>>
>>
>> On Thu, Mar 3, 2016 at 4:12 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>
>>      On 3/3/16 6:23 PM, Roman Shpount wrote:
>>
>>               Assuming you are comfortable with the above, I think the
>>          indicator
>>               we want is some sort of “connection-id” parameter, either as a
>>               standalone value or as a value which is unique in
>>          association with
>>               the fingerprint. This seems cleaner than having a “new” versus
>>               “reuse” token. The semantics would be that if you see a new
>>               identifier that means you need to form a new association
>>          but that
>>               multiple replays of the same identifier mean that you reuse
>>          the same
>>               association (i.e., do not DTLS reconnect).
>>
>>
>>               This resolves the idempotency concern that present with the
>>          existing
>>               proposal, and also makes backwards compatibility simpler; a
>>          change
>>               in either a=fingerprint or a=dtls-connection-id will
>>          trigger a new
>>               DTLS connection.
>>
>>
>>          I have actually proposed this very thing (dtls-association-id
>>          instead of
>>          dtls-connection), but people on the list found this to be too
>>          complex.
>>          This has an additional benefit of handling some of the 3pcc use
>>          cases
>>          when in response to empty INVITE it is unknown if generated
>>          offer will
>>          be used in the same session or in the new one. dtls-association-id
>>          resolves this nicely, but we settled for a simpler requirement
>>          to always
>>          respond with a=dtls-connection=new in response to empty INVITE.
>>
>>          The question is does group feels strongly about changes to
>>          (dtls-association-id from dtls-connection at this late stage,
>>          since this
>>          will require a major rewrite.
>>
>>
>>      I had discomfort with connection=new/existing back when it first
>>      came up with TCP, exactly because it isn't idempotent. I don't
>>      recall why I lost that battle.
>>
>>      But now that is water over the dam. So I think it takes a stronger
>>      argument for why to adopt a different pattern now for something so
>>      similar. If the SDP implementation already has to deal with this for
>>      a=connection, then why is it a problem to also do so for
>>      dtls-connection?
>>
>>
>> I don't agree that the ship has sailed on this.
>
> I agree. (Their is a lot of *water* over the dam, but the ship hasn't gone over the dam yet.:-) I just said the bar was higher than normal.
>
>> If we unearth a
>> compelling reason (idempotency), we shouldn't be bound by decisions to
>> a different attribute made 10+ years ago.
>>
>> Besides idempotency, the connection/instance id approach has the
>> additional benefit of simpler logic for old remote endpoints - if
>> either the fingerprint or id changes, make a new DTLS connection.
>
> The tradeoff is that it becomes a *new* mechanism. More opportunities for people to misunderstand and get it wrong. More opportunities for us to write the description unclearly to help with that.
>
> 	Thanks,
> 	Paul
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>