Re: [MMUSIC] actpass redux

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.

"Be conservative in what you send, be liberal in what you accept”

As far as I understand, we would still mandate endpoints to support receiving non-actpass values.

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.

I object to that – we basically would have to update the spec every time there is a new data type, or define the type-specific O/A procedures in a separate spec – which is what has been previously been done.

I think our aim should be to have generic procedures, even if that means we have to change procedures some existing RFCs.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>> on behalf of Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>
Date: Saturday 10 June 2017 at 12:34
To: Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>>
Cc: Paul Kyzivat <paul.kyzivat@comcast.net<mailto:paul.kyzivat@comcast.net>>, "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>
Subject: Re: [MMUSIC] actpass redux

On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> wrote:
On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <paul.kyzivat@comcast.net<mailto: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<mailto: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<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic