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

[Paul Kyzivat <[e-mail]>]

On 3/3/16 7:35 PM, Justin Uberti wrote:
>
>
> On Thu, Mar 3, 2016 at 4:12 PM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> 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