Change:
10.2. <ins> Connectedness: Connected Data Unit: Byte-stream API mappings for MPTCP are identical to TCP.  MPTCP adds support for multipath properties, such as "Multi-Paths Transport" and "Policy for using Multi-Path Transports". 10.3. </ins> Connectedness: Unconnected Data Unit: Datagram

Discussion:
Please merge. Completeness really isn't necessary. If this spec is used, the published RFC CAN be updated or added to, at the moment, I'd prefer to ship a spec sooner, rather than add too much, so let's converge:-).
NAME Brought back multicast for now. Good to merge?
I think we can merge this and break out the remaining parts as separate issues as suggested by NAME .
See discussion on
Provide a complete template that covers all functions/properties from the API. Indicate how the template should be used (e.g. leave out the parts that are not relevant for a particular protocol or include all fields and mark fields that are not relevant as such.
I'm wondering if this is really something that's in scope that we should cover. We do have the message properties section that explains how to implement various properties, but I think adding each property to every protocol mapping will be a huge amount of text that will be difficult to get exactly right.
I agree, we have added additional properties since we opened this issue to check the mapping and make sure we have a complete coverage. We should still be consistent in how we treat things though, and perhaps add a sentence that we do not describe all the properties for instance. I have made a pass through to check the mapping from the API to impl. draft for all the protocol mappings as a basis for making things consistent. Here is the summary. We cover the same actions and events for all the protocols with the exceptions that UDP Multicast does not cover the ConnectionError event and SCTP covers the Priority connection property. And MPTCP and UDP-lite are special as they refer back to the base protocols. There is one terminology inconsistency where the impl. draft refers to InitiateError and this has been generalized to EstablishmentError in the API Unless I missed something, there are only two actions that can be made on a connection that are not covered, addRemote and removeRemote. This is probably fine as they do not mean much for most of the protocols (or we could add them to be complete). We should perhaps mention how they relate to MPTCP though if we leave them out. We also do not cover the Preconnection.Rendezvous action. Again this may be fine as it is a bit special (or we can mention it for consistency.)

For the events, we cover a subset with main focus on the connection related events. The Closed Event and some events related to connection setup are missing. As we cover ConnectionError we should perhaps cover the Closed event as well? We do not cover any of the Send or Receive events which seems fine. In relation to Connection and Message properties, we do not cover any of them except for the Connection priority covered for SCTP and we talk about some properties in connection to UDP-lite and MPTCP. SCTP also has support for partial reliability and unordered messages so not sure why the priority part was singled out and added. NAME any particular reasoning behind this part? Possibly we should remove the priority part for SCTP or discuss it in running text in a similar fashion as for UDP-lite and MPTCP We may want to update the UDP-lite description to also say something about what properties it supports over UDP. The current description sounds like it is a subset. Once we agree on how to deal with the bullets above, only smaller modifications should be needed to the text.
ConnectionError should be added; SCTP priority should be removed Fix the inconsistency Add addRemote and removeRemote text related to MPTCP No action Mention Closed Event See item 1, no further action Update UDP-Lite description
Currently, the implementation document does not have mappings for MPTCP, even though MPTCP is part of minset. Should be boring, right? :)
Should be taken care of by , yes
closed byPR
Right now, the per-protocol behavior is specified in Implementation, which is an Informational document; however, this stuff really should be specified normatively. So either they should be split out into (one or more?) separate documents, or Implementation should be made Normative just for the sake of one of its sections (which imo would be weird).
I guess having a separate document for the per-protocol behaviour makes a lot of sense. This document than can also define names for protocol specific properties.
Interim discussion: considering splitting off a non-informational document for mapping definitions
Last discussion ended in agreement on splitting out protocol mappings. Two options were discussed 1) taking out all protocol mappings, 2) leaving TCP and UDP as the two basic protocols and moving the other mappings. Good if we can conclude on which path to take.

I suggest that keeping UDP and TCP in here could be a simple expedient, especially if we make it clear that other RFCs can specify additional mappings. These two are very long-established transport protocols, and I think we can rapidly conclude this spec using them. Whilst I would be very happy to also see bindings for other important transports, that seems like something that could delay the group.
Leave minset protocols (UDP, TCP, SCTP, MPTCP), and define the template for new mappings. Split out drafts: (TLS + DTLS), QUIC (and fallback to TLS, maybe join with TLS), HTTP
Just a small correction: minset also includes UDP-Lite, and the LEDBAT congestion control (the latter should probably be skipped since its encapsulation still isn't spec'd).
We should apply this as soon as possible as it makes the implementation consistent with minset, but deleting UDP multicast really hurts .Can we re-add the UDP multicast part, especially as this does not seem to be enough for an individual mapping document. Let's merge and fix the rest separately.