RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-10

[Ballot comment]
I have a meta-question about why this "updates" 5104.  It appears to be an extension to 5104, using normal extension mechanisms -- someone implementing 5104 and not intending to implement this would have no reason to look at this document, as far as I can tell.  I don't see anything that describes a *change* to 5104 (though perhaps I've missed it).  What's the reasoning behind specifying "updates"?

[Ballot comment]

- 58 pages! There is quite a bit of repetition here but too
late to change now.

- I see there are 2 IPR declarations, both with possible
royalty/fee and neither that I can see actually specifying
what patent (or other property) is involved despite both
declarations being some years old.  (And there was me thinking
remote controls were almost older than me, but I guess what do
I know and the USPTO must always be right;-) Anyway, can
someone point me at where the working group said they were ok
with this situation?  (The shepherd write up says that
happened so I hope it's not hard to get that pointer.)

- Section 7: in a multiparty call, say participant#1 hits
pause with PauseID = 0x0001, and stuff is resumed some time
later, is participant#2 supposed to use a PauseID of 0x0002
subsequently? In other words does the SHALL there apply to
everyone on the call or just to the participant who sent out
the last PAUSE message?  If the former, does that create a
race condition? Or maybe that's a harmless race? I guess you
could reduce the probability of a race by recommending that
PauseID be randomly selected between last-PauseID-seen and
last-PauseID-seen+(2^14) or something like that?  (And
apologies if all this is obvious to someone expert in RTP, I
am not that person:-)

[Ballot comment]
This draft was really easy for me to read (with some background in RTP/RTCP, but I'm no expert on the topic). Thank you for the work on it - the results show.

I have some questions, but nothing is a show-stopper.

In this text:

3.3.  RTP Mixer to Media Sender in Point-to-Multipoint

  In this use case there are several receivers of a stream and special
  care must be taken as not to pause a stream that is still wanted by
  some receivers.
 
I'm assuming that the Mixer is taking special care, but this is passive enough that I'm filling in blanks. If you like passive voice, perhaps something like

  In this use case there are several receivers of a stream and special
  care must be taken by the Mixer so as not to pause a stream that is
                      ^^^^^^^^^^^^^^^
  still wanted by some receivers.
 
would be easier to parse.

If you can do active voice, perhaps

  In this use case there are several receivers of a stream and the
  Mixer must take special care so as not to pause a stream that is still
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  wanted by some receivers.
 
In this text:

8.  Message Details

  Any references to PAUSE, PAUSED, RESUME and REFUSED in this section
  SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
  are used (Section 5.6) for this functionality.  TMMBR/TMMBN MAY be
                                                              ^^^
  used instead of the messages defined in this specification when the
  effective topology is point-to-point.  If either sender or receiver
  learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT
  be used for pause/resume functionality.  If the messages defined in
  this specification are supported in addition to TMMBR/TMMBN by all
  involved parties, pause/resume signaling MUST use messages from this
  specification.  If the topology is not point-to-point and the
  messages defined in this specification are not supported, pause/
  resume functionality with TMMBR/TMMBN MUST NOT be used.
 
All of this makes sense to me, except that I'm not understanding why TMMBR/TMMBN is a MAY. There's a lot of text that says you really need to use the messages from this specification in this case, and in that case, and ... but here, you MAY do something else.

I understand that TMMBR/TMMBN works in a point-to-point topology, but is there a reason to prefer TMMBR/TMMBN in that topology? If so, it would probably be good to explain why.

And as I read futher, I see this, in section 9:

      Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
      resume functionality (with the restrictions described in this
      specification), signaling rtcp-fb attribute with ccm tmmbr
      parameter is sufficient and no further signaling is necessary.
      There is however no guarantee that TMMBR/TMMBN implementations
                      ^^^^^^^^^^^^
      pre-dating this specification work exactly as described here when
      used with a bitrate value of 0.
     
and that really makes me wonder why this specification is also describing TMMBR/TMMBN. I'm sure there's a good reason, but can you understand my confusion?

Finally, I see this, in section 9.1,

  If both "pause" and "tmmbr" are present in the offer, both MAY be
  included also in the answer, in which case TMMBR/TMMBN MUST NOT be
  used for pause/resume purposes (with a bitrate value of 0), to avoid
  signaling ambiguity.
 
and in section 9.2,

  If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST
  NOT be used for pause/resume purposes (with a bitrate value of 0), to
  avoid signaling ambiguity.
 
I'm now wondering if the description of TMMBR/TMMBN in this specification just for interworking with older implementations that don't support PAUSE/RESUME but figured out how to get a similar effect with TMMBR/TMMBN?

I'm guessing, of course :-)

In this text:

8.5.  Transmission Rules

  o  PAUSE SHOULD use Early or Immediate timing, except for
      retransmissions that SHOULD use Regular timing.
     
^ I understand this one.

  o  The first transmission of PAUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      PAUSED for that PauseID SHOULD use Regular timing.  Unsolicited
      PAUSED (sent when entering Local Paused State (Section 6.4))
      SHOULD always use Immediate or Early timing, until PAUSED for that
      PauseID is considered delivered at least once to all receivers of
      the paused RTP stream, after which it SHOULD use Regular timing.

^ I'm wondering why these are SHOULDs. Are they MUSTs except that some implementations don't do it, or recommendations but nothing breaks if you don't do them, or something else?

  o  RESUME SHOULD always use Immediate or Early timing.

^ I wonder why this is SHOULD. Is there any guidance you can provide about why RESUME would use Regular timing?

  o  The first transmission of REFUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      REFUSED for that PauseID SHOULD use Regular timing.

^ I am, of course, wondering about the corresponding SHOULDs for REFUSED.

In this text:

9.  Signaling

  When signaling a config value other than 1, an implementation MUST
  ignore non-supported messages on reception, and MAY omit sending non-
  supported messages.
 
is this saying that an implementation might send non-supported messages? I'm confused here.

[Ballot comment]
This draft was really easy for me to read (with some background in RTP/RTCP, but I'm no expert on the topic). Thank you for the work on it - the results show.

I have some questions, but nothing is a show-stopper.

In this text:

3.3.  RTP Mixer to Media Sender in Point-to-Multipoint

  In this use case there are several receivers of a stream and special
  care must be taken as not to pause a stream that is still wanted by
  some receivers.
 
I'm assuming that the Mixer is taking special care, but this is passive enough that I'm filling in blanks. If you like passive voice, perhaps something like

  In this use case there are several receivers of a stream and special
  care must be taken by the Mixer so as not to pause a stream that is
                      ^^^^^^^^^^^^^^^
  still wanted by some receivers.
 
would be easier to parse.

If you can do active voice, perhaps

  In this use case there are several receivers of a stream and the Mixer
                                                                ^^^^^^^^^
  must take special care so as not to pause a stream that is still
  ^^^^^^^^^^^^^^^^^^^^^^^^^
  wanted by some receivers.
 
In this text:

8.  Message Details

  Any references to PAUSE, PAUSED, RESUME and REFUSED in this section
  SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
  are used (Section 5.6) for this functionality.  TMMBR/TMMBN MAY be
                                                              ^^^
  used instead of the messages defined in this specification when the
  effective topology is point-to-point.  If either sender or receiver
  learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT
  be used for pause/resume functionality.  If the messages defined in
  this specification are supported in addition to TMMBR/TMMBN by all
  involved parties, pause/resume signaling MUST use messages from this
  specification.  If the topology is not point-to-point and the
  messages defined in this specification are not supported, pause/
  resume functionality with TMMBR/TMMBN MUST NOT be used.
 
All of this makes sense to me, except that I'm not understanding why TMMBR/TMMBN is a MAY. There's a lot of text that says you really need to use the messages from this specification in this case, and in that case, and ... but here, you MAY do something else.

I understand that TMMBR/TMMBN works in a point-to-point topology, but is there a reason to prefer TMMBR/TMMBN in that topology? If so, it would probably be good to explain why.

And as I read futher, I see this, in section 9:

      Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
      resume functionality (with the restrictions described in this
      specification), signaling rtcp-fb attribute with ccm tmmbr
      parameter is sufficient and no further signaling is necessary.
      There is however no guarantee that TMMBR/TMMBN implementations
                      ^^^^^^^^^^^^
      pre-dating this specification work exactly as described here when
      used with a bitrate value of 0.
     
and that really makes me wonder why this specification is also describing TMMBR/TMMBN. I'm sure there's a good reason, but can you understand my confusion?

Finally, I see this, in section 9.1,

  If both "pause" and "tmmbr" are present in the offer, both MAY be
  included also in the answer, in which case TMMBR/TMMBN MUST NOT be
  used for pause/resume purposes (with a bitrate value of 0), to avoid
  signaling ambiguity.
 
and in section 9.2,

  If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST
  NOT be used for pause/resume purposes (with a bitrate value of 0), to
  avoid signaling ambiguity.
 
I'm now wondering if the description of TMMBR/TMMBN in this specification just for interworking with older implementations that don't support PAUSE/RESUME but figured out how to get a similar effect with TMMBR/TMMBN?

I'm guessing, of course :-)

In this text:

8.5.  Transmission Rules

  o  PAUSE SHOULD use Early or Immediate timing, except for
      retransmissions that SHOULD use Regular timing.
     
^ I understand this one.

  o  The first transmission of PAUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      PAUSED for that PauseID SHOULD use Regular timing.  Unsolicited
      PAUSED (sent when entering Local Paused State (Section 6.4))
      SHOULD always use Immediate or Early timing, until PAUSED for that
      PauseID is considered delivered at least once to all receivers of
      the paused RTP stream, after which it SHOULD use Regular timing.

^ I'm wondering why these are SHOULDs. Are they MUSTs except that some implementations don't do it, or recommendations but nothing breaks if you don't do them, or something else?

  o  RESUME SHOULD always use Immediate or Early timing.

^ I wonder why this is SHOULD. Is there any guidance you can provide about why RESUME would use Regular timing?

  o  The first transmission of REFUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      REFUSED for that PauseID SHOULD use Regular timing.

^ I am, of course, wondering about the corresponding SHOULDs for REFUSED.

In this text:

9.  Signaling

  When signaling a config value other than 1, an implementation MUST
  ignore non-supported messages on reception, and MAY omit sending non-
  supported messages.
 
is this saying that an implementation might send non-supported messages? I'm confused here.

[Ballot comment]
This draft was really easy for me to read (with some background in RTP/RTCP, but I'm no expert on the topic). Thank you for the work on it - the results show.

I have some questions, but nothing is a show-stopper.

In this text:

3.3.  RTP Mixer to Media Sender in Point-to-Multipoint

  In this use case there are several receivers of a stream and special
  care must be taken as not to pause a stream that is still wanted by
  some receivers.
 
I'm assuming that the Mixer is taking special care, but this is passive enough that I'm filling in blanks. If you like passive voice, perhaps something like

  In this use case there are several receivers of a stream and special
  care must be taken by the Mixer so as not to pause a stream that is
                      ^^^^^^^^^^^^^^^
  still wanted by some receivers.
 
would be easier to parse.

If you can do active voice, perhaps

  In this use case there are several receivers of a stream and the Mixer
                                                                ^^^^^^^^^
  must take special care so as not to pause a stream that is still wanted by
  ^^^^^^^^^^^^^^^^^^^^^^^^^
  some receivers.
 
In this text:

8.  Message Details

  Any references to PAUSE, PAUSED, RESUME and REFUSED in this section
  SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
  are used (Section 5.6) for this functionality.  TMMBR/TMMBN MAY be
                                                              ^^^
  used instead of the messages defined in this specification when the
  effective topology is point-to-point.  If either sender or receiver
  learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT
  be used for pause/resume functionality.  If the messages defined in
  this specification are supported in addition to TMMBR/TMMBN by all
  involved parties, pause/resume signaling MUST use messages from this
  specification.  If the topology is not point-to-point and the
  messages defined in this specification are not supported, pause/
  resume functionality with TMMBR/TMMBN MUST NOT be used.
 
All of this makes sense to me, except that I'm not understanding why TMMBR/TMMBN is a MAY. There's a lot of text that says you really need to use the messages from this specification in this case, and in that case, and ... but here, you MAY do something else.

I understand that TMMBR/TMMBN works in a point-to-point topology, but is there a reason to prefer TMMBR/TMMBN in that topology? If so, it would probably be good to explain why.

And as I read futher, I see this, in section 9:

      Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
      resume functionality (with the restrictions described in this
      specification), signaling rtcp-fb attribute with ccm tmmbr
      parameter is sufficient and no further signaling is necessary.
      There is however no guarantee that TMMBR/TMMBN implementations
                      ^^^^^^^^^^^^
      pre-dating this specification work exactly as described here when
      used with a bitrate value of 0.
     
and that really makes me wonder why this specification is also describing TMMBR/TMMBN. I'm sure there's a good reason, but can you understand my confusion?

Finally, I see this, in section 9.1,

  If both "pause" and "tmmbr" are present in the offer, both MAY be
  included also in the answer, in which case TMMBR/TMMBN MUST NOT be
  used for pause/resume purposes (with a bitrate value of 0), to avoid
  signaling ambiguity.
 
and in section 9.2,

  If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST
  NOT be used for pause/resume purposes (with a bitrate value of 0), to
  avoid signaling ambiguity.
 
I'm now wondering if the description of TMMBR/TMMBN in this specification just for interworking with older implementations that don't support PAUSE/RESUME but figured out how to get a similar effect with TMMBR/TMMBN?

I'm guessing, of course :-)

In this text:

8.5.  Transmission Rules

  o  PAUSE SHOULD use Early or Immediate timing, except for
      retransmissions that SHOULD use Regular timing.
     
^ I understand this one.

  o  The first transmission of PAUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      PAUSED for that PauseID SHOULD use Regular timing.  Unsolicited
      PAUSED (sent when entering Local Paused State (Section 6.4))
      SHOULD always use Immediate or Early timing, until PAUSED for that
      PauseID is considered delivered at least once to all receivers of
      the paused RTP stream, after which it SHOULD use Regular timing.

^ I'm wondering why these are SHOULDs. Are they MUSTs except that some implementations don't do it, or recommendations that don't break if you don't do them, or something else?

  o  RESUME SHOULD always use Immediate or Early timing.

^ I wonder why this is SHOULD. Is there any guidance you can provide about why RESUME would use Regular timing?

  o  The first transmission of REFUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      REFUSED for that PauseID SHOULD use Regular timing.

^ I am, of course, wondering about the corresponding SHOULDs for REFUSED.

In this text:

9.  Signaling

  When signaling a config value other than 1, an implementation MUST
  ignore non-supported messages on reception, and MAY omit sending non-
  supported messages.
 
is this saying that an implementation might send non-supported messages? I'm confused here.

[Ballot comment]
The SecDir review brought up a couple of attack types and at least the first should be mentioned in the security considerations section, replay protection.  For the second, does it apply?

https://www.ietf.org/mail-archive/web/secdir/current/msg05921.html

Thank you.

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

IANA has reviewed draft-ietf-avtext-rtp-stream-pause-08.  Authors, please review the summary below and let us know if our understanding is incorrect.

IANA's reviewer has the following comments:

NOTE: Before publication, the URLs in the IANA Considerations should be shortened to "http://www.iana.org/assignments/rtp-parameters" and "http://www.iana.org/assignments/sdp-parameters".

ACTION 1: upon approval of this document, if the designated expert to be contacted by IANA approves the assignment, IANA will register the following value in the "FMT Values for RTPFB Payload Types" registry at http://www.iana.org/assignments/rtp-parameters:

Value:  TBA1
Name:  PAUSE-RESUME
Long Name:  Media Pause / Resume
Reference: this document

ACTION 2: upon approval of this document, if the designated expert to be contacted by IANA approves the assignment, IANA will register the following in the "Codec Control Messages" registry at http://www.iana.org/assignments/sdp-parameters:

Value Name:  pause
Long Name:  Media Pause / Resume
Usable with:  ccm
Reference:  This RFC

NOTE: this registry doesn't have a designated expert yet. We've submitted a management item requesting designation.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RTP Stream Pause and Resume) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Extensions
WG (avtext) to consider the following document:
- 'RTP Stream Pause and Resume'
  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 2015-08-13. 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


  With the increased popularity of real-time multimedia applications,
  it is desirable to provide good control of resource usage, and users
  also demand more control over communication sessions.  This document
  describes how a receiver in a multimedia conversation can pause and
  resume incoming data from a sender by sending real-time feedback
  messages when using Real-time Transport Protocol (RTP) for real time
  data transport.  This document extends the Codec Control Messages
  (CCM) RTCP feedback package by explicitly allowing and describing
  specific use of existing CCM messages and adding a group of new real-
  time feedback messages used to pause and resume RTP data streams.
  This document updates RFC 5104.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1641/
  https://datatracker.ietf.org/ipr/1935/

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?

A Proposed Standard RFC is being requested.  This document defines
normative behavior for RTP feedback messages, and updates RFC 5104,
which is a Proposed Standard.  The title page indicates "Standards Track".


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

This document provides a mechanism to use existing RTCP Feedback Codec
Control Messages (RFC 5104), as well as a group of new messages, to
pause and resume RTP media streams.

The document defines two separate mechanism for pausing and
resuming RTP streams.  One mechanism codifies existing practice of how
to use RFC 5104 messages to pause and resume streams, but is only
applicable to a subset of possible RTP topologies.  The other is a new
mechanism and is generally applicable.  Guidance is provided as to
when one or the other mechanism should be used.


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?

The two protocol mechanisms were the result of two separate proposals
as to how to solve the requirement; once the proposals were merged
into a single document, there were no objections to WG consensus.

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 deployed implementations of the RFC 5104-based
mechanisms to pause and resume RTP streams.

An SDP directorate review has been requested for the document's usage
of SDP.

Personnel

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

The Document Shepherd is Jonathan Lennox; the Responsible Area
Director is Ben Campbell.

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

The document shepherd read the submitted version of the document
fully, as well as reviewing several earlier versions of the document.

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

This document got good review by multiple members of the AVText
working group and all comments were addressed.

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

This document got good review by multiple people from AVText and all
comments were addressed.


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

All authors have confirmed that they know of no IPR disclosures
required beyond those already disclosed


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

Two IPR declarations have been made that reference this document.  The
Working Group considered the declarations and decided they were
acceptable.


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

While only a relatively small number of people have commented on the
draft, this is not atypical for the AVTEXT working group, and most of
the group's most active (and expert) participants have indicated
agreement with the document.


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

No.


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

http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-avtext-rtp-stream-pause-07.txt

Though the document updates RFC 5104 (which is pre-BCP78), it does not
incorporate any text from it.  All the text in this document was
submitted under the terms of BCP78.

Updated versions of some of the references have been published; these
can be updated as normal for a post IETF-LC version of the document.


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

Not applicable.


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

No.


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

No.


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

This document updates RFC 5104.  This is stated in its header and
abstract.


(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 makes two IANA registrations (Section 11), which are
described correctly.  No new registries are defined.


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

This document does not define any new registries.


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

The ABNF for the SDP extensions will be reviewed as part of the SDP
Directorate review.