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

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