Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)
draft-ietf-mmusic-dtls-sdp-32

[Ballot comment]
Thanks for addressing my discuss by simply removing section 7.1!

Old comments:

A couple mostly editorial comments:
- Probably a nit: In section 3.2 'must' is used while in section 3.3 'MUST' is used. I would assume that both sections should probably use the same.

- in sec 5.1: "Because of
  this, if an unordered transport is used for the DTLS association, a
  new transport (3-tuple) must be allocated by at least one of the
  endpoints so that DTLS packets can be de-multiplexed."
Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the source address, source port, transport 3-tuple? May say this more explicitly.  Also the word of the use transport is confusing to me here because it's used for the transport protocol as well as for the transport 'connection' (if a connection-oriented transport protocol is used). Maybe s/new transport/new flow/? Moreover, there should probably be a 'MUST' here instead of 'must'!

- sec 5.2:"In addition, the offerer MUST insert in the
  offer an SDP 'tls-id' attribute with a unique attribute value."
Is that a MUST or rather a SHOULD? The rest of the text reads like this should be a SHOULD.

- Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3):
"... the answerer MUST initiate a DTLS handshake by sending a
  DTLS ClientHello message towards the offerer."

- I would like to see more discussion about linkability based on the introduction of the "tls-id" in the security considerations section.

[Ballot comment]
Thanks for the quick answer to my DISCUSS.

I agree with the core assertion of EKR's DISCUSS: this document needs to be aligned with JSEP. I think we're going to need a little additional work figuring out which document needs to change where they disagree. In addition to those areas he highlights in his DISCUSS, the following text is also in conflict:

DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association."

JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as in the offer."

[Note: this does appear to be an issue in JSEP rather than this document]

I would think the long-form title of this document should include "TLS," to reflect that it also contains TLS-related procedures.

Section 1: "...but currently there is no way..." will not age well once this is an RFC. Suggest "...previously, there was no way..." or somesuch.

Section 2 uses RFC 2119 boilerplate, and then the very next sentence uses a non-normative "must." I would strongly recommend moving to RFC 8174 boilerplate.

The conventional name for DTLS-SRTP is "DTLS-SRTP" -- please change replace "SRTP-DTLS" with "DTLS-SRTP" everywhere it appears.

The last paragraph in section 5.4 starts with "NOTE" (which implementors frequently read as non-normative) and then contains a normative statement. Suggest removing "NOTE:"



Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

- SDP - Session Description Protocol
- DTLS - Datagram Transport Layer Security
- TLS - Transport Layer Security
- ICE - Interactive Connectivity Establishment
- SCTP - Stream Control Transmission Protocol
- SRTP - Secure Realtime Transport Protocol
- UDPTL - UDP Transport Layer

[Ballot discuss]
Section 5.4 says:

  NOTE: A new DTLS association can be established based on changes in
  either an SDP offer or answer.  When communicating with legacy
  endpoints, an offerer can receive an answer that includes the same
  fingerprint set and setup role.  A new DTLS association MUST still be
  established if such an answer was received as a response to an offer
  which requested the establishment of a new DTLS association.

Unless I've misunderstood something important, this isn't going to work with legacy implementations, unless you also specify that an "offer which requested the establishment of a new DTLS association" must also change something else that the legacy answerer will recognize as requiring a new DTLS association. For example, if I send a re-offer with a changed tls-id but the same fingerprint, setup, and transport, the far end will have no reason to think it needs to establish a new DTLS association. So I'll sit there waiting for a new association to be established, and the remote side will never send one.

This doesn't seem backwards-compatible. At the very least, more text needs to be added explaining how this is intended to work.

[Ballot comment]
I agree with the core assertion of EKR's DISCUSS: this document needs to be aligned with JSEP. I think we're going to need a little additional work figuring out which document needs to change where they disagree. In addition to those areas he highlights in his DISCUSS, the following text is also in conflict:

DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association."

JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as in the offer."

I would think the long-form title of this document should include "TLS," to reflect that it also contains TLS-related procedures.

Section 1: "...but currently there is no way..." will not age well once this is an RFC. Suggest "...previously, there was no way..." or somesuch.

Section 2 uses RFC 2119 boilerplate, and then the very next sentence uses a non-normative "must." I would strongly recommend moving to RFC 8174 boilerplate.

The conventional name for DTLS-SRTP is "DTLS-SRTP" -- please change replace "SRTP-DTLS" with "DTLS-SRTP" everywhere it appears.

The last paragraph in section 5.4 starts with "NOTE" (which implementors frequently read as non-normative) and then contains a normative statement. Suggest removing "NOTE:"



Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

- SDP - Session Description Protocol
- DTLS - Datagram Transport Layer Security
- TLS - Transport Layer Security
- ICE - Interactive Connectivity Establishment
- SCTP - Stream Control Transmission Protocol
- SRTP - Secure Realtime Transport Protocol
- UDPTL - UDP Transport Layer

[Ballot comment]
Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

- SDP - Session Description Protocol
- DTLS - Datagram Transport Layer Security
- TLS - Transport Layer Security
- ICE - Interactive Connectivity Establishment
- SCTP - Stream Control Transmission Protocol
- SRTP - Secure Realtime Transport Protocol
- UDPTL - UDP Transport Layer

[Ballot 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.

[Ballot 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?

[Ballot comment]
This falls well into the "This is outside my area of expertise" part of:
This ballot position may be interpreted as "This is outside my area of expertise or have no cycles", in that you exercise the ability to move a document forward on the basis of trust towards the other ADs.
:-)

[Ballot discuss]
This is nothing big and should be easy to fix:

On section 7.1, of course...
"If DTLS is transported on top of a connection-oriented transport
  protocol (e.g., TCP or SCTP), where all IP packets are acknowledged,
  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)."
I don't think this would be necessary for QUIC. The point here is, I believe, not the fact that TCP and SCTP are connection-oriented, but that re-transmissions cannot be easily distinguished from the original packet. So the point is rather the use of a reliable protocol that retransmits in a specific way. However, why would you use DTLS with TCP instead of TLS? And I also don't think you want to use DTLS with QUIC because it has it's own crypto. I guess the recommendation should rather be that reliable transports should use TLS, and if DTLS is needed a new DTLS connection can only be established if there is not retransmission ambiguity which is always the case when all outstanding packets are ack'ed or considered lost (timed out).  Or am I missing the point?

[Ballot comment]
A couple mostly editorial comments:
- Probably a nit: In section 3.2 'must' is used while in section 3.3 'MUST' is used. I would assume that both sections should probably use the same.

- in sec 5.1: "Because of
  this, if an unordered transport is used for the DTLS association, a
  new transport (3-tuple) must be allocated by at least one of the
  endpoints so that DTLS packets can be de-multiplexed."
Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the source address, source port, transport 3-tuple? May say this more explicitly.  Also the word of the use transport is confusing to me here because it's used for the transport protocol as well as for the transport 'connection' (if a connection-oriented transport protocol is used). Maybe s/new transport/new flow/? Moreover, there should probably be a 'MUST' here instead of 'must'!

- sec 5.2:"In addition, the offerer MUST insert in the
  offer an SDP 'tls-id' attribute with a unique attribute value."
Is that a MUST or rather a SHOULD? The rest of the text reads like this should be a SHOULD.

- Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3):
"... the answerer MUST initiate a DTLS handshake by sending a
  DTLS ClientHello message towards the offerer."

- I would like to see more discussion about linkability based on the introduction of the "tls-id" in the security considerations section.

[Ballot discuss]
This is nothing big and should be easy to fix:

On section 7.1, of course...
"If DTLS is transported on top of a connection-oriented transport
  protocol (e.g., TCP or SCTP), where all IP packets are acknowledged,
  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)."
I don't think this would be nessecary for QUIC. The point here is, I believe, not the fact that TCP and SCTP are connection-oriented, but that re-transmissions cannot be easily distinguished from the original packets. So the point is rather the use of a reliable protocol that retransmits in a specific way. However, why would you use DTLS with TCP instead of TLS? And I also don't think you want to use DTLS with QUIC because it has it's own crypto. I guess the recommendation should rather be that reliable transports should use TLS, and if DTLS is needed a new DTLS connection can only be established if there is not retransmission ambiguity which is always the case when all outstanding packets are ack'ed or considered lost (timed out).  Or am I missing the point?

[Ballot comment]
A couple mostly editorial comments:
- Probably a nit: In section 3.2 'must' is used while in section 3.3 'MUST' is used. I would assume that both sections should proabbly use the same.
- in sec 5.1:
" Because of
  this, if an unordered transport is used for the DTLS association, a
  new transport (3-tuple) must be allocated by at least one of the
  endpoints so that DTLS packets can be de-multiplexed."
Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the source address, source port, tranport 3-tuple? May say this more explicitly.  Also the word of the use transport is confusing to mean here because it's used for the transport protocol as well as for the transport 'connection' (if a connection-ordient tranport protocol is used). Maybe s/new transport/new flow/?
- sec 5.2:
"In addition, the offerer MUST insert in the
  offer an SDP 'tls-id' attribute with a unique attribute value."
Is that a MUST or rather a SHOULD?
- Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3):
"... the answerer MUST initiate a DTLS handshake by sending a
  DTLS ClientHello message towards the offerer."

[Ballot discuss]
This is a fine document, but I have one [hopefully easy to answer] question and a couple of other minor ones:

In Section 5.1.  General

  Endpoints MUST support the cipher suites as defined in [RFC8122].

I don't see any ciphers specified in that RFC. Can you clarify what you mean?

[Ballot comment]

8.  TLS Considerations

  NOTE: Even though the SDP 'connection' attribute can be used to
  indicate whether a new TLS connection is to be established, the
  unique combination of SDP 'tls-id' attribute values can be used to
  identity a TLS connection.  The unique value can be used e.g., within
  TLS protocol extensions to differentiate between multiple TLS
  connections and correlate those connections with specific offer/
  answer exchanges.

Are any such extensions defined or in the process of being standardized?

  If an offerer or answerer receives an offer/answer with conflicting
  attribute values, the offerer/answerer MUST process the offer/answer
  as misformed.

I think a pointer to document and section where such handling is specified would be useful here.

[Ballot comment]
Mostly a nit...

RFC4572 has been Obsoleted by RFC8122.  I think that this change in status implicitly means that all references to RFC4572 should now really refer to RFC8122.  I then don't think there's a need to explicitly Update the references from RFC4572 to RFC8122.

In the text Updating RFC5763 (10.2.1), the document says: "The reference to [RFC4572] is replaced with a reference to [RFC8122]."  I don't think that is necessary.

Also, the Update to RFC7345 (10.3.3) adds a Normative bibliographical entry to RFC8122, but no text is updated to point at that RFC.  I don't think this is necessary either.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-mmusic-dtls-sdp-26. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the att-field (media level only) registry on the Session Description Protocol (SDP) Parameters registry page located at:

https://www.iana.org/assignments/sdp-parameters/

a new attribute is to be added as follows:

Type: att-field (media level only)
SDP Name: tls-id
Mux Category: IDENTICAL
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: draft-ietf-mmusic-dtls-sdp@ietf.org, ben@nostrum.com, fandreas@cisco.com, mmusic@ietf.org, mmusic-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using the SDP Offer/Answer Mechanism for DTLS) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document: - 'Using the SDP
Offer/Answer Mechanism for DTLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-07-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Version 22 of this document was previously last called. The last call is
being repeated due to material changes made by the working group
since that previous last call.  Please see section 14 for details.

Abstract

  This document defines the SDP offer/answer procedures for negotiating
  and establishing a DTLS association.  The document also defines the
  criteria for when a new DTLS association must be established.  The
  document updates RFC 5763 and RFC 7345, by replacing common SDP
  offer/answer procedures with a reference to this specification.

  This document defines a new SDP media-level attribute, 'tls-id'.

  This document also defines how the 'tls-id' attribute can be used for
  negotiating and establishing a TLS connection, in conjunction with
  the procedures in RFC 4145 and RFC 8122.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ballot/

No IPR declarations have been submitted directly on this I-D.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-mmusic-dtls-sdp-22.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the att-field (media level only) subregistry of the Session Description Protocol (SDP) Parameters registry located at:

https://www.iana.org/assignments/sdp-parameters/

a single, new attribute will be added as follows:

Type: att-field (media level only)
SDP Name: dtls-id
Mux Category: IDENTICAL
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: draft-ietf-mmusic-dtls-sdp@ietf.org, ben@nostrum.com, fandreas@cisco.com, mmusic@ietf.org, mmusic-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using the SDP Offer/Answer Mechanism for DTLS) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'Using the SDP Offer/Answer Mechanism for DTLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-04-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines the SDP offer/answer procedures for negotiating
  and establishing a DTLS association.  The document also defines the
  criteria for when a new DTLS association must be established.  The
  document updates RFC 5763 and RFC 7345, by replacing common SDP
  offer/answer procedures with a reference to this specification.

  This document defines a new SDP media-level attribute, 'dtls-id'.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ballot/


No IPR declarations have been submitted directly on this I-D.

This is my AD Evaluation of draft-ietf-mmusic-dtls-sdp-20. I'd like to resolve my substantive comments and questions prior to IETF last call.

Substantive Comments:

- section 4: "If an offer or answer does not
  contain a ’dtls-id’ attribute (this could happen if the offerer or
  answerer represents an existing implementation that has not been
  updated to support the ’dtls-id’ attribute), the offer or answer MUST
  be treated as if no ’dtls-id’ attribute is included. "

That seems to say that if dtls-id is not included, the offer or answer must be treated as if it's not included. Since that's tautologically true, I suspect you meant to say something more?

-8, 2nd paragraph: Why are the 2 SHOULDs not MUSTs? Can you invision a scenario where it would make sense to not follow them?

-9.2, new text for section 5, 5th paragraph:
Since we are touching this section, shouldn't we update the 4474 reference to 4474bis, and update the language about what gets signed in 4474bis? And can we take this opportunity for a MUST level requirement for some kind of integrity protection of fingerprints, even if not 4474/4474bis? (At least when not considering opportunistic crypto cases.)

-- 4th paragraph from end of new text:
should "the certificate fingerprint" say "a certificate fingerprint"? (Since you can have multiple fingerprints now...)

-10:

If you accept my suggestion to move from 4474 to 4474bis in the updated text for 5763, that will create changes that should probably be mentioned here. For example, 4474bis signatures cover fewer things than do 4474 signatures. The hope that 4474bis may be more deployable than 4474, and therefore really used, may also be worth a mention here.



Editorial Comments:

- Throughout the document, I found it confusing whether a "new" association means an initial association or a replacement association. In some places it doesn't matter (and I was happy to see that it really doesn't matter for much of the normative guidance), but for example 5.4 talks about replacing an old association even though IIUC the section talks about the answer to an initial offer.

If the intent is for new to mean "initial or replacement" in all cases, then a sentence to that effect early in the document would be helpful.

- 3.1, "A new DOTLS association MUST be estlablished ...": Established by what? (Please consider active voice.) Also, that MUST seems redundant to the 2119 language in the much more detailed procedure sections that follow; maybe this should be lower case?

"The intent to establish a new DTLS association is explicitly signaled ...": Likewise, signaled by what?

- 3.2: Are the 2119 keywords here redundant with those in the more detailed procedure sections that follow?

- 3.2, paragraph 2: I don't think the word "explicitly" constrains anything. Also, s/"... to span ..." / "... from spanning ..."

- 4: "a modification of one or more of the following characteristics MUST be treated as an indication": Treated as an indication by what? (Please consider active voice when using 2119 keywords.)

- 5.1, paragraph 4: "a new
  transport (3-tuple) MUST be allocated by at least one of the end
  points so that DTLS packets can be de-multiplexed.":

That seems redundant with the more detailed procedures that follow. Please consider it descriptively here, and saving the 2119 words for the more detailed procedures.

-6, 2nd paragraph: Can you offer a citation for the deprecation of aggressive nomination?
-- 3rd paragraph: "at least one of the endpoints MUST allocate": I suspect that's redundant to 2119 language in the detailed procedures. But if it's not, please restate with specific procedure for the offerer and answer. It's vague to assign a 2119 MUST to "at least one".

-8, first paragraph: "If forking occurs, separate DTLS associations MUST be established between the caller and each callee.": This seems like a statement of fact. That is, how could they _not_ establish a separate association, since I assume you would end up with a unique 5-tuple for each branch.

-9.2, paragraph 5: "The SIP message containing the offer SHOULD be sent to
  the offerer’s SIP proxy over an integrity protected channel":

This seems redundant with a previous statement 2 sentences back. (Yes, this was in the original text...)

-- Last paragraph in new text for section 5: Do you intend for "RFCXXXX" to refer to _this_ document? If so, a note to the RFC editor to that effect would be helpful. (There are multiple occurrences.)

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard, which is appropriate since the document updates RFC 5763 and RFC 7345. Standards Track is indicated on the title page.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

The document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association.  The document also defines the criteria for when a new DTLS association must be established.  The document updates RFC 5763 and RFC 7345, by replacing common SDP  offer/answer procedures with a reference to this specification. The document defines a new SDP media-level attribute, 'dtls-id'.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?


No controversy or anything else to note.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are existing implementations of the protocol, and a number of vendors have indicated that they intend to implement it.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Flemming Andreasen is the Document Shepherd.
Ben Campbell is the Area Director


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed several versions of the document and most recently -15 and -18 through -20 in detail. The document is in good shape at this point and ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No such concern. There has been good WG participation during the development of the document and several reviews of both earlier and recent versions.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Each author has confirmed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is solid WG consensus with good overall participation.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

ID nits check has been run and found no issues. The same applies for the manual review I have performed.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

The document has a normative reference to draft-ietf-mmusic-4572-update-13, which has been submitted for Publication and is currently with the RFC Editor.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The document updates RFC 5763 and RFC 7345, both of which are marked in the title header, and called out in the Abstract and Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA Considerations are consistent with the document body and the requirements for SDP attribute registration.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ABNF has been verified with Bill Fenner's ABNF parser