Re: Should draft-dtls-sdp-23 be a normative update to RFC4572

Text suggested by Roman, that is… I really need a cup of coffee :)

On 19/04/17 10:51, "Christer Holmberg" <[email protected]>
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"
><[email protected] on behalf of [email protected]>
>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" <[email protected]> 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 <[email protected]> wrote:
>>>> Re-sending to mmusic list and changing the title:
>>>>
>>>> On Tue, Apr 18, 2017 at 10:51 AM, Paul Kyzivat <[email protected]>
>>>> 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
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>
>>_______________________________________________
>>mmusic mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic