A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-nat-22

[Ballot comment]

- I slightly disagree with Kathleen's discuss. NAT logs within
enterprises are useful for n/w management reasons, but I'm not
sure that extends to public Internet cases at all, where such
logs will be huge and potentially quite privacy invasive.
(Yes, they maybe required by local legislation but that's
different and not really our concern.) I'd hope that text
resolving the discuss properly takes both aspects into
account. Privacy and log flushing does get a mention but I'd
emphasise it more and maybe consider that difference between
enterprise and public Internet use-cases.

- I don't recall RTSP 2.0 security well enough, but was a bit
surprised to not see any mention of (D)TLS for media content
here. Can you say why that's not needed?

(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?

Standards Track. The RFC type is indicated on the front 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.

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?

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?

Personnel:

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

The document defines a solution for Network Address Translation (NAT)
traversal for datagram based media streams set up and controlled with
Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive
Connectivity Establishment (ICE) adapted to use RTSP as a signalling
channel, defining the necessary RTSP extensions and procedures.

Working Group Summary

The RTSP specification (RFC 2326 and RFC2326bis) has long suffered
from lack of a standardized NAT traversal mechanism and hence there
was a desire to rectify that. The WG has separately investigated
different approaches to RTSP NAT and concluded that a solution
leveraging ICE was preferred. The ICE-based solution appeared
initially in the -05 WG version of this document in 2007. Since the
document is a companion to RTSP 2.0, progress on the document was to
some extent gated on RTSP 2.0 progress as well as progress on the
accompanying RTSP NAT Evaluation document, but a WGLC was issued on
the -14 version in the latter part of 2012. Following review comments
and updates, another WGLC was issued on -15 in the middle of 2013 with
no major comments received. A few minor updates have been done since
then as a result of active reviews from 2 people while waiting for
RTSP 2.0 and the accompanying RTSP NAT Evalution documents to
progress.

Document Quality The document has been reviewed in detail several
times after WGLC (incl. by one of the ICE-bis authors) and in
preparation for the publication request and the authors have made
various minor updates as a result of those. The document is considered
to be of good quality at this point.

There are no known implementations of the current specification,
however a prototype implementation of an earlier version of the spec
was done a while back.

There are no new media types, MIBs, etc. and hence no such reviews
apply.

Personnel

Flemming Andreasen is the document shepherd.

Gonazalo Camarillo is the responsible AD.

(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 the latest versions (-17, -18, -19, and -20) of the
document in detail and my MMUSIC co-chair reviewed the prior versions
(-14, -15, and -16) in detail.

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

The document has seen limited review and active contributions from the
WG for a while, however, besides the authors, 2 people have reviewed
recent version(s) in detail and other people have reviewed earlier
versions. One of the reviewers is Ari Keranen who is a known ICE
expert, and as such there is no concern with the depth of the reviews.
While the breadth of the reviews could be better, there are no
specific concerns.


(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.

No such review is required.

(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.

The document shepheard does not have any specific concerns or issues
with the document.

(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?

All authors have confirmed they are not aware of any IPR to be
declared.

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

There is no such 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?

The document has seen limited active participation by the WG,
especially for the more recent versions, however we believe there is
good consensus behind the document for two reasons: - We have not seen
(or heard) anybody express any concerns with the document - The NAT
traversal solution leverages ICE, which is the standards-based IETF
mechanism for doing so, and furthermore a product of the MMUSIC group.

(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.)

There are no known concerns

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

There are no nits at this point. A check with ID nits will generate 2
warnings and 2 comments, however these are all false positives (as
verified by the document shepherd as well as the authors). In
particular, the reference to the obsolete RFC 3489 is fully
intentional.

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

The document does not specify any extensions that would require any
such formal reviews.

(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?

There are no such normative references.

(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.

There are no downward normative references.

(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 does not change the status of any existing RFCs.

(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).

The document specifies several extensions which are all covered by the
IANA considerations with existing registries. There are no new IANA
registries required.

(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.

Not applicable.

(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.

There is ABNF in the document which has been checked by use of Bill
Fenner's ABNF Parser.

(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?

Standards Track. The RFC type is indicated on the front 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.

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?

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?

Personnel:

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

The document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams set up and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary RTSP extensions and procedures.

Working Group Summary

The RTSP specification (RFC 2326 and RFC2326bis) has long suffered from lack of a standardized NAT traversal mechanism and hence there was a desire to rectify that. The WG has separately investigated different approaches to RTSP NAT and concluded that a solution leveraging ICE was preferred. The ICE-based solution appeared initially in the -05 WG version of this document in 2007. Since the document is a companion to RTSP 2.0, progress on the document was to some extent gated on RTSP 2.0 progress as well as progress on the accompanying RTSP NAT Evaluation document, but a WGLC was issued on the -14 version in the latter part of 2012. Following review comments and updates, another WGLC was issued on -15 in the middle of 2013 with no major comments received. A few minor updates have been done since then as a result of active reviews from 2 people while waiting for RTSP 2.0 and the accompanying RTSP NAT Evalution documents to progress.

Document Quality
The document has been reviewed in detail several times after WGLC (incl. by one of the ICE-bis authors) and in preparation for the publication request and the authors have made various minor updates as a result of those. The document is considered to be of good quality at this point.

There are no known implementations of the current specification, however a prototype implementation of an earlier version of the spec was done a while back.

There are no new media types, MIBs, etc. and hence no such reviews apply.

Personnel

Flemming Andreasen is the document shepherd.

Gonazalo Camarillo is the responsible AD.

(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 the latest versions (-17, -18, -19, and -20) of the document in detail and my MMUSIC co-chair reviewed the prior versions (-14, -15, and -16) in detail.

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

The document has seen limited review and active contributions from the WG for a while, however, besides the authors, 2 people have reviewed recent version(s) in detail and other people have reviewed earlier versions. One of the reviewers is Ari Keranen who is a known ICE expert, and as such there is no concern with the depth of the reviews. While the breadth of the reviews could be better, there are no specific concerns.


(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.

No such review is required.

(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.

The document shepheard does not have any specific concerns or issues with the document.

(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?

All authors have confirmed they are not aware of any IPR to be declared.

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

There is no such 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?

The document has seen limited active participation by the WG, especially for the more recent versions, however we believe there is good consensus behind the document for two reasons:
- We have not seen (or heard) anybody express any concerns with the document
- The NAT traversal solution leverages ICE, which is the standards-based IETF mechanism for doing so, and furthermore a product of the MMUSIC group.

(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.)

There are no known concerns

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

There are no nits at this point. A check with ID nits will generate 2 warnings and 2 comments, however these are all false positives (as verified by the document shepherd as well as the authors). In particular, the reference to the obsolete RFC 3489 is fully intentional.

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

The document does not specify any extensions that would require any such formal reviews.

(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?

There are no such normative references.

(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.

There are no downward normative references.

(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 does not change the status of any existing RFCs.

(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).

The document specifies several extensions which are all covered by the IANA considerations with existing registries. There are no new IANA registries required.

(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.

Not applicable.

(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.

There is ABNF in the document which has been checked by use of Bill Fenner's ABNF Parser.

[Ballot discuss]
The draft looks good, I just have a question to discuss to see if some additional text is needed for the security considerations section.

I don't see any mention of logging and maybe I missed something, if so, please let me know.  Since NAT is supported, logging of the NAT translation would be helpful for analysts.  Analysts will need to be able to map sessions when investigating possible issues where the NAT happens.  Protection of those logs would be helpful as well and should consider log integrity, privacy protection, and purging logs occasionally (retention policies, etc.).

Also, logging of connection errors and other messages established by this draft may also be important.

Thanks.

[Ballot comment]
Two issues in the IANA section, otherwise a fine document:

  150:  The 150 response code indicates that ICE connectivity checks
      are still in progress and haven't concluded.  This response SHALL
      be sent within 200 milliseconds of receiving a PLAY request that
      currently can't be fulfilled because ICE connectivity checks are
      still running.  Subsequently, every 3 seconds after the previous
      sent one, a 150 reply SHALL be sent until the ICE connectivity

I am not sure why the IANA section contains normative language that is important for the implementer, e.g., the above 200 milliseconds.  Further the status codes of RTSP 2.0 have usually a short text description called "Directionalty" (which is odd by the way in the registry).


  480:  The 480 response code is used in cases when the request can't
      be fulfilled due to a failure in the ICE processing, such as all
      the connectivity checks have timed out.  This error message can
      appear either in response to a SETUP request to indicate that no
      candidate pair can be constructed or to a PLAY request that the
      server's connectivity checks resulted in failure.

Can't this be shortened to a truly meaningful error description? And also saying somewhere in the text when this error code should be used, instead of having this in the IANA considerations?

[Ballot comment]
Nice, clear document, and what looks to be good technology.  Thanks for this.
I have a number of  non-blocking comments that I'd like you to consider.  I'm happy to chat about any of them, if you like (particularly the ones that are not marked as "Editorial").  There's no need to respond to any you agree with, and thanks in advance for considering them.

-- Section 4.2 --

I like the way you show the source for the ABNF items that are defined elsewhere.  I think I'll remember that, and use it myself.

Editorial:
      Note, the syntax
      allows multicast addresses, but they SHALL NOT be used in this
      context.

Entirely your option here, but I think it would be better to word this positively, as "This context MUST have a unicast address for this parameter, even though a muticast address would be syntactically valid."

      An IP address
      SHOULD be used, but an FQDN MAY be used in place of an IP address.

(I think I'm going to give this comment a number, so I can say "Comment #27".)  MAY can't be used this way, as an alternative to SHOULD: MAY says that something is completely optional, and that's not what you mean here.

What I'd like to see is something that explains why you might not use an IP address, despite the SHOULD... and then says that the alternative for those cases is an FQDN, but without the 2119 key word.  Something like this:

      An IP address
      SHOULD be used, but [in situations such as X or Y], it could be
      necessary to use an FQDN instead.

-- Section 4.3 --

Editorial:
  The ICE password and username for each agent needs to be transported
  using RTSP.

The subject is plural, so the verb should be too: "need".

-- Section 4.5.1 --
I see that ICE doesn't itself specify any sort of keep-alive responses for the connectivity checks.  Here, without advice to the client, I worry about clients that are too strict about checking the timing of the responses.  A server sending a response 200 ms after receiving a request does not translate into a client receiving the response within 200 ms of having sent the request.  If network delays mean that the response gets to the client after 250 ms, or 300, or whetever, and the client has set a 200 ms timer based on this section, there'll be a problem, no?  Similarly for the 150 ms time for the subsequent keep-alives.  Should this say something about that?

-- Section 6.10 --

Editorial:
  Both server and client MAY free its non selected candidates

Another case of a plural subject: make it "their non-selected candidates" (with hyphen).

In the second paragraph, "respectively" needs commas around it (one before, one after). "Client's" should have the apostrophe removed.  "Thus" needs a comma after it.

-- Section 6.11 --

Editorial:
  This is important as normally RTSP play mode sessions
  only contain traffic from the server to the client so the bindings in
  the NAT need to be refreshed by the client to server traffic provided
  by the STUN keep-alive.

Please add a comma after "important", and hyphens in "client-to-server".

-- Section 6.12 --

  ICE restarts may be triggered due to changes of client or server
  attachment to the network, i.e., changes to the media streams
  destination or source address or port.

Is "changes to the media streams destination or source address or port" an exhaustive list?  If not, you should change "i.e.," to "such as".

  Most RTSP parameter changes
  would not require an ICE restart; instead existing mechanisms in RTSP
  for indicating from where in the RTP stream they apply is used.

I can't parse this; it looks like there's a word missing, or maybe it's just that the structure is awkward.  Maybe this?:

NEW
  Most RTSP parameter changes
  would not require an ICE restart, but would use existing mechanisms
  in RTSP to indicate from what point in the RTP stream they apply.
END

OLD
  Even if otherwise not supporting SETUP during PLAY state for other
  purposes, the server SHALL support SETUP requests in PLAY state, as
  long as the SETUP changes only the ICE parameters, which are: ICE-
  Password, ICE-ufrag and the content of ICE candidates.
NEW
  Even if the server does not normally support SETUP during PLAY state,
  it SHALL support SETUP requests in PLAY state for the purpose of
  changing only the ICE parameters, which are ICE-Password, ICE-ufrag,
  and the content of ICE candidates.
END

-- Section 7.1 --
A "media-handling proxy" needs a hyphen.

-- Section 7.2 --
Editorial:
"Signalling-only proxy" should have that hyphen in there.  Please add it in the three places that "signalling only" appears.  Also, the first paragraph has the two words not capitalized, and the second paragraph has them both capitalized.  Please pick one way or the other.  (The section title should leave both words capitalized, regardless, because that's what we do in section titles.)

-- Section 7.3 --
Editorial:
A "media-handling proxy" needs a hyphen; "non-media-handling proxy" needs two hyphens.  There are several instances of both in this section.

-- Section 11.1 --

  To protect against the attacks in ICE-based on signalling information
  RTSP signalling SHOULD be protected using TLS to prevent
  eavesdropping and modification of information.

This doesn't parse.  I think you mean this (but tweak it differently if I didn't get it quite right):

NEW
  To protect against attacks on ICE based on signalling information,
  RTSP signalling SHOULD be protected using TLS to prevent
  eavesdropping and modification of information.
END

[Ballot comment]
Yet more variation on ice that said it appears to be suitable to task.

If someone wanted to write a draft that stated that the IETF is sufficiently bad at nat traversal that it should not be pursued here I would totally sponsor that.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mmusic-rtsp-nat-21.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has a question about one of the actions requested in the IANA Considerations section of the current document.

IANA understands that, upon approval of this document, there are six actions which IANA must complete.

First, in the Feature-tags subregistry of the Real Time Streaming Protocol (RTSP) 2.0 Parameters located at:

http://www.iana.org/assignments/rtspv2-parameters/

one new RTSP 2.0 feature tag will be registered as follows:

Name: setup.ice-d-m
Description: A feature tag representing the support of the ICE-based establishment of datagram media transport that is capable of transport establishment through NAT and Firewalls. This feature tag applies to clients, servers and proxies and indicates support of all the mandatory functions of this specification.
Reference: [ RFC-to-be ]

Second, in the RTSP 2.0 Transport Protocol Identifiers subregistry also in the Real Time Streaming Protocol (RTSP) 2.0 Parameters located at:

http://www.iana.org/assignments/rtspv2-parameters/

the following four protocol identifiers will be registered:

ID String: RTP/AVP/D-ICE
Reference: [ RFC-to-be ]

ID String: RTP/AVPF/D-ICE
Reference: [ RFC-to-be ]

ID String: RTP/SAVP/D-ICE
Reference: [ RFC-to-be ]

ID String: RTP/SAVPF/D-ICE
Reference: [ RFC-to-be ]

Third, in the RTSP 2.0's Transport Parameters subregistry also in the Real Time Streaming Protocol (RTSP) 2.0 Parameters located at:

http://www.iana.org/assignments/rtspv2-parameters/

three new transport parameters will be registered as follows:

Name: candidates
Reference: [ RfC-to-be ]

Name: ICE-Password
Reference: [ RfC-to-be ]

Name: ICE-ufrag
Reference: [ RfC-to-be ]

Fourth, in the RTSP 2.0 Status Codes subregistry also in the Real Time Streaming Protocol (RTSP) 2.0 Parameters located at:

http://www.iana.org/assignments/rtspv2-parameters/

two new status codes will be registered as follows:

IANA Question -> IANA understands that the codes 150 and 480 are to be registered, however, it is not clear from the document what the entry for Directionality should be in the Status Codes subregistry. What should the entries for Directionality be for the status codes 150 and 480?  Are
they being depicted in Table 1 in section 4.5? 

QUESTION: Table 1 uses "Reason" as the name of the second
column.  But, the registry RTSP 2.0 Status Codes has a different
name called "Directionality".  What is the correct name of that
2nd column?

QUESTION: Table 1 has entries for "Method".  But the registry does
not has that column.  Is that correct?

Fifth, in the Notify-Reason header value subregistry also in the Real Time Streaming Protocol (RTSP) 2.0 Parameters located at:

http://www.iana.org/assignments/rtspv2-parameters/

a single, new Notify-Reason header value will be registered as follows:

Name: ice-restart
Description: Server notifying the client about the need for an ICE restart.
Reference: [ RFC-to-be ]

Sixth, in the att-field (session level) subregistry of the Session Description Protocol (SDP) Parameters registry located at:

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

a new SDP attribute will be registered as follows:

Type: rtsp-ice-d-m
SDP Name: ICE for RTSP datagram media NAT traversal
Reference: [ RFC-to-be ]

IANA understands that these six actions are the only ones 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP)) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'A Network Address Translator (NAT) Traversal Mechanism for Media
  Controlled by Real-Time Streaming Protocol (RTSP)'
  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 2014-06-20. 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 a solution for Network Address Translation
  (NAT) traversal for datagram based media streams set up and
  controlled with Real-time Streaming Protocol version 2 (RTSP 2.0).
  It uses Interactive Connectivity Establishment (ICE) adapted to use
  RTSP as a signalling channel, defining the necessary RTSP extensions
  and procedures.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/ballot/


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