Re: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572 - Pull request

[Christer Holmberg <[e-mail]>]

Pull request: https://github.com/cdh4u/draft-dtls-sdp/pull/30

Regards,

Christer


On 19/04/17 10:54, "Christer Holmberg" <[e-mail]>
wrote:

>Text suggested by Roman, that is… I really need a cup of coffee :)
>
>On 19/04/17 10:51, "Christer Holmberg" <[e-mail]>
>wrote:
>
>>Hi,
>>
>>Sorry, I messed up the RFCs.
>>
>>I do NOT think we need to update 8122. The text says that the new
>>procedures are used ³in conjunction² with the 8122 procedures, and the
>>text suggested by Paul fits into that.
>>
>>Regards,
>>
>>Christer
>>
>>
>>On 19/04/17 10:45, "mmusic on behalf of Christer Holmberg"
>><[e-mail] on behalf of [e-mail]>
>>wrote:
>>
>>>Hi,
>>>
>>>I agree that the draft should be an update to 8122 (not 4572). That was
>>>actually my intention, but I forgot about it.
>>>
>>>The changes suggested by Paul look good.
>>>
>>>Regards,
>>>
>>>Christer
>>>
>>>
>>>
>>>On 19/04/17 02:39, "Martin Thomson" <[e-mail]> wrote:
>>>
>>>>I agree with Roman, we can and should just ensure that this is a new
>>>>feature, not a rewrite.  I don't think that we need to invalidate RFC
>>>>4572 implementations.  This is an enhancement (a very useful one, but
>>>>an enhancement only).
>>>>
>>>>p.s., Any updating should be done to RFC 8122 now, if at all.  That
>>>>probably removes any heat from the discussion as pertains to updating
>>>>of old specs.
>>>>
>>>>On 19 April 2017 at 05:17, Roman Shpount <[e-mail]> wrote:
>>>>> Re-sending to mmusic list and changing the title:
>>>>>
>>>>> On Tue, Apr 18, 2017 at 10:51 AM, Paul Kyzivat
>>>>><[e-mail]>
>>>>> wrote:
>>>>>>
>>>>>> Section 8 has a number of normative requirements around the use of
>>>>>> 'tls-id'. This seems to break interoperability with existing
>>>>>>implementations
>>>>>> that follow RFC4572.
>>>>>>
>>>>>> What is the intent here regarding interoperability with RFC4572?
>>>>>> Perhaps this doc should now also be a formal update to that.
>>>>>
>>>>>
>>>>> Should we reword those requirements that they only apply when tls-id
>>>>>is
>>>>> used?
>>>>>
>>>>> So instead of
>>>>>
>>>>> If an offerer or answerer inserts an SDP 'connection' attribute with
>>>>>a
>>>>>'new'
>>>>> value in the offer/answer, the offerer/answerer MUST also insert an
>>>>>SDP
>>>>> 'tls-id' attribute with a new unique value.
>>>>>
>>>>> We would say:
>>>>>
>>>>> If an offerer or answerer inserts an SDP 'connection' attribute with
>>>>>a
>>>>>'new'
>>>>> value in the offer/answer and also provides SDP 'tls-id' attribute,
>>>>>the
>>>>> value of tls-id' attribute MUST be new and unique.
>>>>>
>>>>> And instead of
>>>>>
>>>>> If an offerer or answerer inserts an SDP 'connection' attribute with
>>>>>a
>>>>> 'existing' value in the offer/answer, and if a previously established
>>>>>TLS
>>>>> connection exists, the offerer/answerer MUST also insert an SDP
>>>>>'tls-id'
>>>>> attribute with the previously assigned value in the offer/answer.
>>>>>
>>>>> We would say
>>>>>
>>>>> If an offerer or answerer inserts an SDP 'connection' attribute with
>>>>>a
>>>>> 'existing' value in the offer/answer, if a previously established TLS
>>>>> connection exists, and if the offerer/answerer provided 'tls-id'
>>>>>value
>>>>>in
>>>>> the previous offer/answer which established this TLS connection, the
>>>>> offerer/answerer MUST also insert an SDP 'tls-id' attribute with the
>>>>> previously assigned value in the offer/answer.
>>>>>
>>>>> If we reword these statements like this, do we still need to specify
>>>>>that
>>>>> this document updates RFC4572?
>>>>>
>>>>> Regards,
>>>>> _____________
>>>>> Roman Shpount
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>
>>>_______________________________________________
>>>mmusic mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/mmusic
>>
>