Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-mmusic-dtls-sdp-28: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1. Assuming I understand this document correctly, it conflicts with
the guidance in JSEP. Specifically, S 4 says:

   No default value is defined for the SDP 'tls-id' attribute.
   Implementations that wish to use the attribute MUST explicitly
   include it in SDP offers and answers.  If an offer or answer does not
   contain a 'tls-id' attribute (this could happen if the offerer or
   answerer represents an existing implementation that has not been
   updated to support the 'tls-id' attribute), unless there is another
   mechanism to explicitly indicate that a new DTLS association is to be
   established, a modification of one or more of the following
   characteristics MUST be treated as an indication that an endpoint
   wants to establish a new DTLS association:

   o  DTLS setup role; or

   o  fingerprint set; or

   o  local transport parameters; or

   o  ICE ufrag value

This seems to say that if there is no tls-id attribute, then an ICE restart
(which necessitates a ufrag change) requires a DTLS restart. JSEP isn't
incredibly clear on this point, but 5.7.3 seems to say that tls-id
neeed not be present:

      *  tls-id value, which MUST be set according to
         [I-D.ietf-mmusic-dtls-sdp], Section 5.  If this is a re-offer
         and the tls-id value is different from that presently in use,
         the DTLS connection is not being continued and the remote
         description MUST be part of an ICE restart, together with new
         ufrag and password values.  If this is an answer, the tls-id
         value, if present, MUST be the same as in the offer.

I believe that the first sentence is in error, as we clearly
can't have JSEP implementations requiring that tls-id be present.

   ...

   o  If the remote DTLS fingerprint has been changed or the tls-id has
      changed, tear down the DTLS connection.  This includes the case
      when the PeerConnection state is "have-remote-pranswer".  If a
      DTLS connection needs to be torn down but the answer does not
      indicate an ICE restart or, in the case of "have-remote-pranswer",
      new ICE credentials, an error MUST be generated.  If an ICE
      restart is performed without a change in tls-id or fingerprint,
      then the same DTLS connection is continued over the new ICE
      channel.

I think the best interpretation of this is that if tls-id is not present
(and hence unchanged) then ICE restart does not cause DTLS restart.
This is also my memory of the consensus in RTCWEB. In any case, these
two documents clearly must match.


2. S 4 says:

   The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls-
   id' attribute is 'IDENTICAL', which means that the attribute value
   must be identical across all media descriptions being multiplexed
   [I-D.ietf-mmusic-sdp-bundle-negotiation].

This is not actually what JSEP requires:

   different categories.  To avoid unnecessary duplication when
   bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be
   repeated in bundled m= sections, repeating the guidance from
   [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1.  This includes

I suspect this is old text.


3. S 7.1 says:
   If DTLS is transported on top of a connection-oriented transport
   protocol (e.g., TCP or SCTP), where all IP packets are acknowledged,

This is incorrect, because none of these protocols ack all IP packets.


   all DTLS packets associated with a previous DTLS association MUST be
   acknowledged (or timed out) before a new DTLS association can be
   established on the same instance of that transport (5-tuple).

More generally, I'm not sure that this is useful, because the
required semantic isn't *acknowledged* but rather that the receiver
can appropriately demux. So, say you just stop sending DTLS on
connection A and start sending on B, what's the delimiter, given
that you don't require close_notify here? IIRC, we just decided to
punt on this whole thing. Does anyone try to have successive
connections over the same transport, even when it's connection oriented?


4. The demux instructions seem to have gotten lost from 6.7.1. At minimum
these need a reference to RFC 7983.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 5.1.
   media session immediately (see [RFC8122]).  Note that it is
   permissible to wait until the other side's fingerprint(s) has been
   received before establishing the connection; however, this may have
   undesirable latency effects.

I agree that it's permissible, but why would you do this? This does
not seem like helpful guidance.



S 10.
Please do something about the "NEW" constructions. I literally had to
pull these into ediff to know what had changed. That's not useful to
people. I'm not a fan of this construction in general, but at minimum
you need to explain what has changed.


S 9.
   Regardless of the
   previous existence of a DTLS association, the SDP 'setup' attribute
   MUST be included according to the rules defined in [RFC4145] and if
   ICE is used, ICE restart MUST be initiated.

What is the rationale for this rule?