Change:
Implementations do not need to wait to receive "close_notify" before delivering the "Closed" event. <del> 10.4. </del> <ins> 10.5. </ins> DTLS follows the same behavior as TLS (tls), with the notable exception of not inheriting behavior directly from TCP.  Differences

Discussion:
URL After some discussion with Max and Theresa, we believe the interface draft does not need any changes. This adds a UDP Multicast Receive protocol-specific section to outline the specific considerations for a UDP multicast receive connection.
Of course it's fantastic if we can keep things as simple as that! URL I must be missing something. E.g., from this PR: So this means that I can create a connection but never use a Send on it. Actually, I can't even use Initiate. Fine... but where in the process do I learn (or, rather, specify and then expect) that this is the case?
You need to specify a selection property requesting a unidirectional/receive connection, therefore you are aware of it when the connection is ready.
Sure, that's how I'd also do it - but that selection property doesn't exist AFAICT. So, that's the required change to the API then.
The way we are doing it is that we check if the address of the local endpoint is a mc group address. So thats where the distinction between unicast and multicast is made. If that is the case we also require the transport properties to include that the direction is unidirection receive.
Ah, sure. That makes the most sense. Still, that's also not written in the API document. I'm just saying this should be there.
Well, there is a Connection Property called "Direction of communication" (Section 5.2.13 in the API draft). Maybe this should be a Selection Property instead? Because those you have to specify before the Connection gets established. Also, do you think it's worth adding to that section that it's not supported to call Send() on a unidirectional receive Connection or Receive() on a unidirectional send Connection? Initiate() being unsupported is probably not something that applies to all unidirectional receive Connections, even though I haven't thought about use cases other than multicast yet.
Yes and yes. "Direction of communication" should be a selection property, as it's unlikely to make sense as something to change later. Also, just because that exists, there's no relationship to multicast in the text - the word "multicast" doesn't exist in the API draft right now. I'm thinking that somewhere, almost literally the statement from NAME above should be added.

Something like this: If the address of the local endpoint is a multicast group address: The "Direction of communication" selection property must be set to unidirectional receive. Initiate, Send, ... (list them all here) are not supported. (whatever else should be said.)
Oh, I just realized that "Direction of communication" already is a Selection Property, so we don't need to change anything there. But yes, it probably makes sense to add a paragraph on multicast to the "Specifying Endpoints" section 5.1 in the API draft.
We did not make it a selection property, because it is not of Preference type it should be queryable and probably may change to bidi after establishment if the underlaying protocol is bi-directional it my be settable from bidi to recv to half-close connections. Yes, this is one of the properties where our categories do not work so great.
NAME - that's ok, then we leave the property type as it is.
I think this is the mapping that works best for multicast. Just to give a bit of context: First, we tried to fit multicast into Initiate() because the multicast receiver actively joins a group. However, this doesn't work for Any-source Multicast, as Initiate() requires a remote endpoint. Re-reading our definitions in the architecture draft for Listener, Connection, and so on, I think we don't need to change them, as they are already generic enough for multicast to fit in there. In the Implementation draft, at the beginning of Section 2 it says that a listener is "a passive waiting object". Here, "passive waiting" sounds a bit off to me if a listener can actively join a multicast group. So maybe we want to change that to just say that a listener is "an object that can receive incoming connections".I think this is fine besides a little nit.