Re: [MMUSIC] actpass redux

On Mon, Jun 12, 2017 at 8:33 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> First, one of the reasons we update specs is because there are usages etc,
> that people weren’t aware of when the original spec was published, that we
> think we need to cover. So, rather than just saying that we don’t care
> about non-comformant endpoints, we should ask WHY they are non-comformant.
> Is there a specific use-case behind? If so, do we need to cover that
> use-case?
>

Yes, and one of the things we have to keep in mind is not breaking
conformant endpoints.

Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-sdp
> is GENERIC - one of the main reasons we do the spec in the first place is
> to have the DTLS-related O/A procedures in one place. And, RFC 7345
> (UDPTL-DTLS) DOES allow non-actpass values in the offer:
>
> 	"The offerer SHOULD assign the SDP "setup" attribute with a value of
>    	"actpass", unless the offerer insists on being either the sender or
>    	receiver of the DTLS ClientHello message,"
>
> draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, and
> by mandating actpass we would remove a valid option for UDPTL-DTLS. Sure,
> we can do that, but it cannot be based on a claim that existing endpoints
> are non-comformant.
>
> And, I do NOT think we want to allow non-actpass for some usages (e.g.,
> UDPTL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because that
> would go against the purpose of having generic DTLS O/A procedures.
>

Well, given that we apparently have incompatible existing RFCs, I'm not
sure I see any
alternative.

-Ekr

> Regards,
>
> Christer
>
>
> From: mmusic <mmusic-bounces@ietf.org> on behalf of Eric Rescorla <
> ekr@rtfm.com>
> Date: Saturday 10 June 2017 at 12:34
> To: Roman Shpount <roman@telurix.com>
> Cc: Paul Kyzivat <paul.kyzivat@comcast.net>, "mmusic@ietf.org" <
> mmusic@ietf.org>
> Subject: Re: [MMUSIC] actpass redux
>
>
>
> On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount <roman@telurix.com> wrote:
>
>> On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <paul.kyzivat@comcast.net>
>> wrote:
>>
>>> On 6/9/17 9:17 AM, Cullen Jennings wrote:
>>>
>>>>
>>>> On Jun 8, 2017, at 6:49 PM, Roman Shpount <roman@telurix.com> wrote:
>>>>>
>>>>>   Because of this, I think for the best interop, offerer MUST specify
>>>>> actpass for both initial and subsequent offers but answerer MUST be able to
>>>>> handle active and passive setup roles as well.
>>>>>
>>>>
>>>> that works for me
>>>>
>>>
>>> I don't understand what this accomplishes. If you must be able to accept
>>> anything in a received offer, then what is gained by restricting what can
>>> be used in an offer?
>>>
>>
>> This is all because of legacy interop. There are legacy end points that
>> send non-actpass, so end point MUST be able to accept active and passive to
>> interop with such legacy devices.
>>
>
> Those legacy endpoints are clearly noncomformant, so I'm not sure I care
> about breaking them,
>
>
>
>> There are also legacy end points that only expect actass so end point
>> MUST only send actpass to interop with such devices.
>>
>
> These legacy endpoints are conformant, which is why it's important to
> accommodate them
>
> -Ekr
>
>
>> _____________
>> Roman Shpount
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>