RTP/RTCP Extension for RTP Splicing Notification
draft-ietf-avtext-splicing-notification-09

[Ballot comment]

Thanks for handling my discuss points.

Old comments below, I didn't check those.

-----

- I agree with Alia's discuss, but suspect the ship has sailed.
(Sadly IMO, but sailed nonetheless.)

- The security considerations here are similar to but not quite
the same as those in RFC6828 which I think was the last time a
similar document was before the IESG. I wondered if those
differences were significant or not, it might be no harm to
commpare the two (if that's not already been done) since they
really ought be pretty much the same.

[Ballot comment]
I moved my discuss points into the comment now assuming that the discussed changes will be applied in the next version. I still support Alia's discuss, as this point must be addressed carefully, and I would like to review the next before final publications.

- The following action does not seem to be appropriate for a specification of an end-to-end protocol:
"And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST
  NOT forward the message."
I guess if a middlebox decides to drop the message, there is not much we can do. But I definitely would prefer to not see this specified in an RFC.

- Why is just having the RTCP message not sufficient? Why are the RTP extensions needed as well?

- And is the RTCP message send only once or multiple time? This is not specified.

- There is some discussion about the implementation of the slicer in section 5 (where btw. the title "Failure Cases" seems inappropriate), while there is one sentence saying: "If the splicer is implemented following [RFC6828], it will have its
  own SSRC and will send its own RTCP reports, and will forward
  translated RTCP reports from the receivers."
Why are alternatives discussed here, if there is already a recommendation given in RFC6828? And how would proper congestion handling be ensure in the other setups not described in RFC6828?

- As a general comment, I found it quite hard to read this doc without reading RFC6828 which is only listed as a informative reference as it is informational only. I think it is wrong. Further, RFC6828 describes some action that a slicers has to perform. However, all language in RFC6828 is non normative. This is slightly confusing to me as well. I would further recommend to briefly give an overview of the assumed scenario is this document.

- Minor comment: The definition of the new SDP grouping semantic should be mentioned in the abstract and RFC4566 should be referenced. And I don't think the SDP grouping registry requires a contact.

- Quick question: Maybe I'm missing something here but why do you need a splicer in a scenario where "the
  substitutive sender is implemented together with the main RTP sender inside a single device" (as written in section 2)?

[Ballot discuss]

(1) Section 7, 3rd para: Saying that "splicer works as a trusted
entity" seems wrong - you need to say who trusts whom for what I
think. I also don't get what you mean by saying there'll be a
security association between the splicer and the receiver, nor
how that might ever be possible if the splicer wants to hide
what it's doing.  I think what you're after is some general
statement that splicing breaks all security unless all the
parties involved share the same security association. IIRC there
is text like that in other RTP documents that might be copied
but I forget the detail.

(2) Section 7, 4th para: You say there is a case where header
extension encryption SHOULD be used - how would that work? If
there's a clear way to do it that'd get interop, then why is
that not described? If there are ways in which might or might
not work, or if some proprietary arrangements might be needed
then how is it ok to have a SHOULD there? I suspect that the
right thing here may be to not pretend that that can be done
but to just stick with saying that splicing is inherently
not going to work if you use any real security mechanisms, or
something similar.

(3) In discussion of RFC6828 there was some concern about
possible creation of loops. I forget the issues though, but
wanted to check this in case it also applies here.  (See 4.5 of
6828 maybe or the history for that RFC in the tracker.)

[Ballot comment]


- I agree with Alia's discuss, but suspect the ship has sailed.
(Sadly IMO, but sailed nonetheless.)

- The security considerations here are similar to but not quite
the same as those in RFC6828 which I think was the last time a
similar document was before the IESG. I wondered if those
differences were significant or not, it might be no harm to
commpare the two (if that's not already been done) since they
really ought be pretty much the same.

[Ballot comment]
I strongly support Mirja's and Alia's discuss points and would like to see more of a discussion of the capability to hide splicing in the security considerations text.  My ballot would be discuss, but they pulled out the relevant sections and that would be duplication.  I'd like to review agreed upon text though to address these concerns. 

I don't like the idea of enabling a MiTM, but do see the draft talks about how to protect headers when this happens and confidentiality is needed as well as session protection between the endpoints and the splicer (which I don't like either, but you do call out the security considerations of this and that's what is needed).

[Ballot discuss]
I believe this is more  a discussion for the IESG.

First, this is way out of my area and I'm not particularly commenting on the details - but
I do agree with Mirja's discuss about
"- The following action does not seem to be appropriate for a specification of an end-to-end protocol:
"And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST
  NOT forward the message.""

The full paragraph at the end of Sec 3.2 is: "When the splicer intercepts the RTCP splicing notification message,
  it SHOULD NOT forward the message to the down-stream receivers in
  order to reduce RTCP bandwidth consumption. And if the splicer wishes
  to prevent the downstream receivers from detecting splicing, it MUST
  NOT forward the message."

Even more specifically to me, superficially this seems to me to be a way to change what is in the
stream that a receiver has requested or subscribed to without permission or notification.  In that light,
the idea that the splicer is able to prevent downstream receivers from detecting the splicing does
not sound good.

Similarly, the end of Sec 3.1 says "After the splicer intercepts the RTP header extension and derives the
  Splicing Interval, it will generate its own stream and SHOULD NOT
  include the RTP header extension in outgoing packets to reduce header
  overhead."

This looks like another example of making the choice to hide information from the receiver.

I realize that there is probably an technical arms-race going on - of inserting advertisements and
building receivers to block undesired advertisements.  I am  not seeing a balanced solution that
considers the receivers as well as the senders.

I am startled that there is no consideration of the impact of this extension on the receivers
in the security considerations.

The only reference I see in the Security Considerations further assumes
that it is appropriate to have an undetectable splicing.

" A malicious endpoint may also break an undetectable splicing. To
  mitigate this effect, the splicer SHOULD NOT forward the splicing
  time information RTP header extension defined in Section 4.1 to the
  receivers. And it MUST NOT forward this header extension when
  considering an undetectable splicing. "

At a minimum, I feel like there should be a very clear consideration of the
pros and cons - including from the viewpoint of a receiver.

If we end up with this biased technology, then it should be clearly stated
- not hidden in assumptions.

[Ballot comment]
= Section 4 =

"Either the main RTP sender or the
  substitutive sender SHOULD send the synchronization metadata early
  enough so that the receivers can play out the multimedia in a
  synchronized fashion."

In Section 2 you gave a guideline for how to figure out how far in advance to send the splicing information. I think a similar guideline would be useful here.

s/e.g., choosing media sender/e.g., choosing main RTP sender/

= Section 7 =

What is undetectable splicing?

= Section 8.3 =

In the past when we've registered these there was no contact I don't think. Not sure what IANA would do with one here.

[Ballot discuss]
I have a few points which I would like to have answers for before moving the doc forward (which may not even results in text changes). I happy to clear my position when answered before the telechat:

- The following action does not seem to be appropriate for a specification of an end-to-end protocol:
"And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST
  NOT forward the message."
I guess if a middlebox decides to drop the message, there is not much we can do. But I definitely would prefer to not see this specified in an RFC.

- Why is just having the RTCP message not sufficient? Why are the RTP extensions needed as well?

- And is the RTCP message send only once or multiple time? This is not specified.

- There is some discussion about the implementation of the slicer in section 5 (where btw. the title "Failure Cases" seems inappropriate), while there is one sentence saying: "If the splicer is implemented following [RFC6828], it will have its
  own SSRC and will send its own RTCP reports, and will forward
  translated RTCP reports from the receivers."
Why are alternatives discussed here, if there is already a recommendation given in RFC6828? And how would proper congestion handling be ensure in the other setups not described in RFC6828?

[Ballot comment]
- As a general comment, I found it quite hard to read this doc without reading RFC6828 which is only listed as a informative reference as it is informational only. I think it is wrong. Further, RFC6828 describes some action that a slicers has to perform. However, all language in RFC6828 is non normative. This is slightly confusing to me as well. I would further recommend to briefly give an overview of the assumed scenario is this document.

- Minor comment: The definition of the new SDP grouping semantic should be mentioned in the abstract and RFC4566 should be referenced. And I don't think the SDP grouping registry requires a contact.

- Quick question: Maybe I'm missing something here but why do you need a splicer in a scenario where "the
  substitutive sender is implemented together with the main RTP sender inside a single device" (as written in section 2)?

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

IANA has completed its review of draft-ietf-avtext-splicing-notification-07.txt. If any part of this review is inaccurate, please let us know.

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

First, in the RTCP Control Packet types (PT) subregistry of the Real-Time Transport Protocol (RTP) Parameters registry located at:

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

a single new control packet type is to be registered as follows:

Value: [TBD-at-registration ]
Abbrev: SNM
Name: Splicing Notification Message
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the RTP Compact Header Extensions subregistry also in the Real-Time Transport Protocol (RTP) Parameters registry located at:

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

a single, new header extension is to be registered as follows:

Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval
Description: Splicing Interval
Contact: Jinwei Xia
Reference: [ RFC-to-be ]

Third, in the Semantics for the "group" SDP Attribute subregistry of the Session Description Protocol (SDP) Parameters registry located at:

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

a new registration will be made as follows:

Semantics: Splice
Token: SPLICE
Reference: [ RFC-to-be ]

IANA understands that these three 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. 


Thank you,

Sabrina tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, avtext@ietf.org, avtext-chairs@ietf.org, jonathan@vidyo.com, draft-ietf-avtext-splicing-notification@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RTP/RTCP extension for RTP Splicing Notification) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Extensions
WG (avtext) to consider the following document:
- 'RTP/RTCP extension for RTP Splicing Notification'
  as Proposed Standard

This is a shortened second last call to consider two  normative references to
informational RFCs that have been added as a result of comments from
the initial last call. The referenced RFCs are RFC 7201 and RFC 7667.

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 2016-06-01. 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


  Content splicing is a process that replaces the content of a main
  multimedia stream with other multimedia content, and delivers the
  substitutive multimedia content to the receivers for a period of
  time. The splicer is designed to handle RTP splicing and needs to
  know when to start and end the splicing.

  This memo defines two RTP/RTCP extensions to indicate the splicing
  related information to the splicer: an RTP header extension that
  conveys the information in-band and an RTCP packet that conveys the
  information out-of-band.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ballot/


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

  https://datatracker.ietf.org/ipr/2500/

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

IANA has completed its review of draft-ietf-avtext-splicing-notification-04.txt. If any part of this review is inaccurate, please let us know.

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

First, in the RTCP Control Packet types (PT) subregistry of the Real-Time Transport Protocol (RTP) Parameters registry located at:

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

a new packet type is to be registered as follows:

Value: [ TBD-at-Registration ]
Abbrev: SNM
Name: Splicing Notification Message
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the RTP Compact Header Extensions subregistry also in the Real-Time Transport Protocol (RTP) Parameters registry located at:

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

a new extension is to be registered as follows:

Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval
Description: Splicing Interval
Contact: Jinwei Xia
Reference: [ RFC-to-be ]

This registration also requires Expert Review. We will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the Semantics for the "group" SDP Attribute subregistry of the Session Description Protocol (SDP) Parameters registry located at:

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

a semantics registration is to be added as follows:

Semantics: Splice
Token: SPLICE
Reference: [ RFC-to-be ]

IANA understands that these are the only actions 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 Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, avtext@ietf.org, avtext-chairs@ietf.org, jonathan@vidyo.com, draft-ietf-avtext-splicing-notification@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RTP/RTCP extension for RTP Splicing Notification) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Extensions
WG (avtext) to consider the following document:
- 'RTP/RTCP extension for RTP Splicing Notification'
  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 2016-02-26. 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


  Content splicing is a process that replaces the content of a main
  multimedia stream with other multimedia content, and delivers the
  substitutive multimedia content to the receivers for a period of
  time. The splicer is designed to handle RTP splicing and needs to
  know when to start and end the splicing.

  This memo defines two RTP/RTCP extensions to indicate the splicing
  related information to the splicer: an RTP header extension that
  conveys the information in-band and an RTCP packet that conveys the
  information out-of-band.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ballot/


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

  https://datatracker.ietf.org/ipr/2500/

Here's my AD evaluation:

Substantive Comments:
=====================

- RFC 6828 informational. This draft depends heavily on behavior from that RFC (which needs to be a normative reference as things are currently written). I suspect this draft needs to be PS due to  the SDP group semantics registration,  but I think it really should be informational, or it should be written in a way to not depend on or assume behaviors from RFC 6828. (Especially for the security considerations)

- section 1, first paragraph: "the splicing duration MUST be inside of the specific, pre-designated time slot"

That sounds more like a statement of fact than a 2119 MUST.

- 2, 2nd paragraph: "When a new splicing is forthcoming, the main RTP sender MUST send the
  Splicing Interval to the mixer."

I don't think that needs to be a 2119 MUST. The sender does this, or it doesn't. In the latter case, this draft does not come into play.

-2, paragraph 3:

If I understand correctly, this mechanisms doesn't work unless the substitutive source knows the splice interval. Furthermore, it needs to know it in time to act on it. I'm not sure this mechanism is useful without at least some mechanism to share the SI. Do you assume they have a proprietary mechanism (i.e. they are from the same vendor) or perhaps the substitutive source is colocated with the main source or the mixer? If so, please mention that.

Is there a minimum required resolution and skew for the shared reference clock?

-2, paragraph 5:

Any guidance on how much ahead the substitutive packets should be sent?

-2, paragraph 6:

How. By selecting the correct packet? By adjusting the time stamp? Do we assume a main stream packet exists that starts at that exact timestamp?

-3.1, paragraph after figure 1:

This is at least partially redundant with previous guidance.

- 3.2, last paragraph:

Are there receivers that are not down-stream receivers? If so, there the SHOULD and MUST seem to conflict. Or does the MUST only apply if you want undetectable splicing?

- 4, last paragraph: "Either the main RTP sender or the substitutive sender SHOULD send..."

Assuming "either" means that exactly one SHOULD send, how do they coordinate? Or does it matter if both do it?

-5, 3rd paragraph:

What if the mixer uses a separate closed RCTP loop for senders and receivers? I think 6828 can be interpreted to allow that. (And see previous comment about assuming 6828 behavior.)

Also, please describe the process by which the RTP sender infers that splicing failed from the downstream sender reports. ( I think I know, but don't assume everyone will.)

-5, last paragraph:

What do you mean by "check the path"? Wouldn't it be up to the mixer to fall back to a payload specific mechanism?

-7, first paragraph:

If you depend on the security considerations in RFC 6828, that reference needs to be normative.

-7, 2nd paragraph: "authenticate the main and substitutive content sources?

I thought the paragraph was talking about SRTP on the main source but not on the substitutive source? If neither are protected, there’s a lot easier attacks than the one described.

-7, last paragraph:

The last two sentences conflict with slightly different normative statements earlier in the draft.

- 10.2:

The references for RFCs 3711, 5506, 6904, and 6828 need to be normative the way the draft is currently formulated. (See previous comments about 6828).


Editorial Comments:
===================

- 1, first paragraph: "refers to this information as Splicing Interval."

Missing article ("... the Splicing Interval")

- 1, last paragraph:

Do you mean to say you designed it in a complementary fashion, or it carries the SI in a complementary fashion?

- 2, 2nd paragraph: "Usually, the Splicing Interval SHOULD
  be sent more than once"

"Usually" is redundant to the SHOULD, and only serves to weaken it. If there are known circumstances where it does not make sense to send more than once, please mention them.

- 3.1, paragraph 2:

I think this would be easier to understand if you described how to calculate the absolute (64bit NTP) splicing out time by concatenating the first octet of the splice-in time with the 7 octets of the splice-out time.

also, s/referred/infer

- 3.1, 2nd to last paragraph:

Consider stating this in the positive, i.e. SHOULD strip the RTP extension from forwarded packets.

- 3.1, last paragraph:

This seems to belong with the following section. It needs a "the" before "RTCP splicing notification message". Also, please consider restating "MUST be sent to provide robustness " in the active voice. (That is, what MUST send it?)

-3.2, 2nd paragraph:

s/fix/fixed

- 3.2, definition of Timestamp:

s/"RTCP Sender Report" / "the RTCP Sender Report

- 4, 1st paragraph:

I don't understand the phrase "... provide the Reference Information align with its multimedia content ...".

- 5, 1st paragraph: "... other failure case..."

"... other failure cases..." or "... the other failure case..."

- 5, 2nd paragraph: "... splicing un-aware middlebox ..."

"... a splicing un-aware middlebox ..." or "... splicing un-aware middleboxes ..."

"one heuristics" -> "one heuristic"

What uses the heuristic? (consider active voice).

- 6, paragraph 2:

Please expand SDP on first mention in the body text.

-6, paragraph 3:

"multiple media": Does that mean multiple media streams? Multiple m-lines?

s / "This semantics" / "This semantic"  ; or "These semantics"

-7, 3rd paragraph: "To protect from different substitutive contents are inserted,
  the splicer MUST have some mechanisms to authenticate the
  substitutive stream source."

I don't understand the sentence.

-9: Acknowledgement section says "TBD" Also, s/Acknowledges/Acknowledgement

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 header extensions, RTCP packets, and SDP grouping.
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

Content splicing is a process that replaces the content of a main
multimedia stream with other multimedia content, and delivers the
substitutive multimedia content to the receivers for a period of
time. The splicer is designed to handle RTP splicing and needs to
know when to start and end the splicing.
This memo defines two RTP/RTCP extensions to indicate the splicing
related information to the splicer: an RTP header extension that
conveys the information in-band and an RTCP packet that conveys the
information out-of-band.

Working Group Summary

The document went through a working group last call.  There were
comments and the document was updated to resolve all comments.

The use case of this work (multimedia streaming over RTP) is somewhat
distant from the primary expertise of many AVTEXT working group
participants, so a call was specifically put out to constituencies
that would use the work in order to determine interest and
correctness.  A number of such constituencies responded that they were
interested in the work.

An IPR declaration was filed late, after the work had been accepted as
a work item of the working group, from the employer of some of the
document's authors.  (The authors indicated that the IPR was from a
different area of the company than the one they worked in.)  The
working group considered this and decided that this would not block
going forward with the document.

Document Quality

The document got good reviews from several AVTEXT members.

The document was reviewed by the SDP Directorate, and changes were
made following the comments that were received.

There are reports that at least one vendor has begun field trials of
the mechanism.

Personnel

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 people from AVTEXT 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.

The document was reviewed by the SDP Directorate, and changes were
made following the comments that were received.

(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 of the authors have confirmed that they are aware of no relevant
IPR other than the one declaration that has already been filed.


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

There was one IPR disclosure.  The working group considered this IPR
disclosure, and no objections were raised to continuing the work.

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

Few members of the working group had direct interest in the use cases
addressed by the document; as mentioned, a call was put out for
broader interest.  The document nonetheless got good review from a
number of participants.


(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 https://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-splicing-notification-02.txt

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

No formal review needed.

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

No.

(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 requests three new entries in existing IANA registries:
in RTCP Control Packet Type, RTP Compact Header Extension, and SDP
Grouping Semantic.  This matches the specifications in the draft.  No
new registries are created.

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

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

No formal language.