Content Splicing for RTP Sessions
draft-ietf-avtext-splicing-for-rtp-13

[Ballot comment]
At base, I disagree with the WG and some of the ADs that this document should include anything about user experience; that is not a requirement for the protocol. But the author and WG have done a good job of addressing all of my other concerns and the user experience discussion in the document is very limited, so I am clearly "in the rough" and it is only right that I not hold up the document.

[Ballot comment]
It is a pity that this design does not allow the content security domain to be separated from the content insertion trigger domain, since it exposes the content to an additional interception point. However the restriction is clearly described.

[Ballot comment]
Thank you for the extensive work on this document since the -07 version.  This is *much* clearer, and addresses all my significant concerns.

Only one, small, non-blocking point: I suggest expanding "SSRC" and "CSRC" on first use.

For the record, I have no issue with Section 4.3 -- I see nothing wrong with a non-normative section that calls out an issue (including a user-experience issue) that's likely to come up in implementations, and warns them about it.  If it tried to be normative, or if it went into a lot of detail about user interface design, I might agree that it's a problem... but it doesn't, and I don't.

[Ballot discuss]
REQ-7: There at least needs to be a forward reference to section 4.5 in this section. That said, I am still bothered by this section. The first sentence is written in the passive voice, so I can't tell what it's saying: Is it saying that splicing should not be easily detected *by the RTP receiving implementation* (in which case section 4.5 is really all that this is talking about), or is it saying that splicing should not be easily detected *by the RTP stream end-user* (in which case it's talking about section 4.3, which I think is bogus)? The second half of REQ-7 talks about both, but then goes on to say that this memo is only concerned with the RTP layer. Please rewrite this section to make it clear that you are only talking about the protocol, not the user experience.

Section 4.3: Similar to the above, this is really all user experience, not protocol clipping. I think this section should simply be dropped.

Section 4.5: "User Invisibility" is not the requirement in 4.5; it is "Receiving implementation invisibility." Section 4.5 does not address user experience invisibility and should be re-titled.

With regard to all of the above, if the WG insists on talking about user experience in this document, I will simply Abstain on it.

[Ballot comment]
I am ballotting No Objection on this document although I am not convinced by the Security thoughts. It doesn't seem to me to be impossible to construct a three-way security arrangement for source, splicer, and destination. But maybe the point here is that the very act of splicing *is* a violaiton of the source-destination relationship. Thus the destination correctly only has a relationship with the splicer.

[Ballot discuss]
I have a concern regarding requirement 4, since in some cases exposing the content in the clear at the ad insertion point would be considered a service security vulnerability. The basis for this vulnerability seems to be the need to provide access to the keying indicators. Surely it is possible to design an out of band, or a semi-out of band, indication system and not expose the content itself to this vulnerability?

[Ballot comment]

Thanks for addressing my discuss points. I think the current
version's truth-in-advertising approach to the fact that it
breaks e2e security is much better. (Though it'd be even better
if you could figure a way to do this that would not break e2e
security. I'd encourage folks wanting to insert advertisements
to try think about that.)

Resent to the AD for processing after addressing the IESG comments. The WG last call on the changes was commented by both Colin Perkins and Roni Even. The shepherd has also re-read the draft finding nothing substantial. The write-up has been updated. Mostly noting that the document was sent back, updated and reviewed in a last call.

[Ballot discuss]

- The new REQ-7 seems to be saying that we are
encouraging hosts on the Internet to fool one another
and engineering our protocols to make it harder for
some of them to figure out they are being fooled.
That doesn't seem like a good goal to me. I still
think you need to get rid of the "invisibility" concept
entirely. (Or perhaps explain it as someone's
bad idea.)

- As discussed via mail, the sharing of the SA
required for this only seems to be acceptable
if you say that it mustn't affect any other RTP
security. I don't think REQ-6 is there yet
and I'm not sure how it can get there, other
than if you say that you need some special setup
for IPTV with ads that can't leak over into other
RTP sessions.

- Sorry, but I still don't get the loop problem. I
think its needs to be better explained.

[Ballot comment]
New comments on -08

- 4.1, 1st sentence says how this "should" be implemented. Be
better to avoid 2119 language and say "could" there IMO.

- I just can't parse this, from 4.2:

  "The mixer can also inform the main RTP sender or the substitutive RTP
  sender of the reception quality of the content reaches the mixer
  during the time when the content is not sent to the RTP receiver."

(I didn't check these against -08)

section 1:
- s/into internet/into the Internet/
- s/changes to transport layer/changes to the
  transport layer/
- s/requirements of RTP splicing/requirements
  for RTP splicing/

- REQ-1, what environments other than unicast or
multicast might exist? If this isn't a tautology
then I don't know what's meant.

- REQ-3, I'm not clear what backward compatible
means here - the splicer seems to be talking
RTP/RTCP for both main and current content in Figure
1, so what element of backward compatibility is
meant here?

- Is the reference to SCTE30 meant to  be the 2001
version? I only found the 2009 version on scte.org,
but didn't hunt much. For SCTE35 2007 is referenced,
but there's a 2011. What's up there?  Stable URLs
for those and the ISMA document would be good.

[Ballot discuss]


- From the above, it seems to me that if there are
any security requirements here then the receiver
needs to have a direct relationship with the
splicer, as does the sender, so that e.g. any
encrypted traffic is decrypted at the splicer, and
then re-encrypted.

- The new REQ-7 and the text in the 1st two paragraphs
of 4.2 seem to be
saying that we are encouraging hosts on the Internet
to fool one another and engineering our protocols to
make it harder for some of them to figure out they
are being fooled?  That doesn't seem like a good
goal to me, without a lot more justification.

- Changes to RTCP reports and loss values as
suggested here would also seem to preclude any real
e2e security. I just don't get why that is ok.

- If so-called "user invisibility" is required (and
there is no REQ-X for that) and it has the
consequence of creating loops then that ought be
described, and it isn't.

- If "invisible" splicing were really possible, then
how could any supposedly "secure" RTP session ever
be trusted by a receiver?

[Ballot comment]

(I didn't check these against -08)

section 1:
- s/into internet/into the Internet/
- s/changes to transport layer/changes to the
  transport layer/
- s/requirements of RTP splicing/requirements
  for RTP splicing/

- REQ-1, what environments other than unicast or
multicast might exist? If this isn't a tautology
then I don't know what's meant.

- REQ-3, I'm not clear what backward compatible
means here - the splicer seems to be talking
RTP/RTCP for both main and current content in Figure
1, so what element of backward compatibility is
meant here?

- Is the reference to SCTE30 meant to  be the 2001
version? I only found the 2009 version on scte.org,
but didn't hunt much. For SCTE35 2007 is referenced,
but there's a 2011. What's up there?  Stable URLs
for those and the ISMA document would be good.

[Ballot discuss]
Given that advertisement insertion in IPTV seems to be a deployed technology, and given that there are television SDOs working on IPTV, I would like to understand what input those SDOs and vendors had into this requirements set.

Although this is a requirements specification, it seems to go into implementation detail, for example section 4.1

There needs to be considerably more thought given to the security model to protect both the content provider and the viewer.

Given the large number of comments and discusses, I request that a future revision of this document is brought back to the IESG for review.

[Ballot comment]
In view of the large number of Discuss and Comment issues raised, I am not going to spend time reviewing this version of the document. If the document returns to a future telechat I will review it then.

[Ballot comment]
Much has been said already with the multiple DISCUSS feedback on this draft. So, no need to repeat the information: I'll trust the other ADs will take care of this one.

[Ballot discuss]
This document is nowhere near ready for the IESG. The large number of things that are so poorly edited as to be unclear what the meaning is (i.e., not just grammatical mistakes which we see in all documents) indicates to me that it did not have sufficient review.

I don't think REQ-2 is an actionable protocol requirement. Given section 4.3, it appears that what you mean by REQ-2 is something like, "Make the sound and picture change be smooth", in which case it's not a protocol requirement at all. Making the media transition be smooth involves a great deal of knowledge about the nature of the media being sent. You may need to do fading, or some other thing to make sure that the boundary between the main media and the substitutive media is seamless. There's nothing to be done in protocol for this; you have to know something about the media itself. And it is hard to reconcile this with the statement in section 4 which says, "splicing is not a very complicated processing". Presumably REQ-2 is not really about the buffering, which should not be an issue at all because you are presumed to already know when splicing begins and ends:

  The methods how Splicer learns when to start and end the splicing is
  out of scope for this document.

So you should already know where you're going to start inserting your data into the stream.

REQ-6 is not a requirement at all. First, as Stephen says, it conflicts with REQ-4. But even beyond that, the body of the requirement is basically saying, "Do it if it is convenient." The document does no analysis as to the effectiveness of the "trade-off" invisibility (simply maintaining RTP header params) to see if it's even worth doing so. I don't see what an implementer reading REQ-6 would do.

[Ballot discuss]
This document is nowhere near ready for the IESG. The large number of things that are so poorly edited as to be unclear what the meaning is (i.e., not just grammatical mistakes which we see in all documents) indicates to me that it did not have sufficient review.

I don't think REQ-2 is not an actionable protocol requirement. Given section 4.3, it appears that what you mean by REQ-2 is something like, "Make the sound and picture change be smooth", in which case it's not a protocol requirement at all. Making the media transition be smooth involves a great deal of knowledge about the nature of the media being sent. You may need to do fading, or some other thing to make sure that the boundary between the main media and the substitutive media is seamless. There's nothing to be done in protocol for this; you have to know something about the media itself. And it is hard to reconcile this with the statement in section 4 which says, "splicing is not a very complicated processing". Presumably REQ-2 is not really about the buffering, which should not be an issue at all because you are presumed to already know when splicing begins and ends:

  The methods how Splicer learns when to start and end the splicing is
  out of scope for this document.

So you should already know where you're going to start inserting your data into the stream.

REQ-6 is not a requirement at all. First, as Stephen says, it conflicts with REQ-4. But even beyond that, the body of the requirement is basically saying, "Do it if it is convenient." The document does no analysis as to the effectiveness of the "trade-off" invisibility (simply maintaining RTP header params) to see if it's even worth doing so. I don't see what an implementer reading REQ-6 would do.

[Ballot comment]
4.1 - I don't see what the first paragraph is telling anyone. Presumably if you are a splicer, you know that you will need data to insert into the stream and that it will be coming from somewhere. What is the purpose of the first paragraph?


Paragraph 2 starts, "Even if splicing does not begin". Do you simply mean, "Before splicing begins"? Otherwise, I don't understand what this sentence is saying. Also, unlike the rest of the paragraphs, it does not talk about "encapsulating". I assume it should, yes?

Paragraph 3 only mentions a substitutive RTP stream and not local media.

I agree with Barry that the pseudo code is useless, if not just confusing, and should be removed. The prior text should include all of the information that would have been in the pseudocode.

  Note that, the substitutive content should be outputted in the range
  of splicing duration.

I do not understand the above sentence.

4.3 -

  If the time slot for substitutive RTP stream mismatches (shorter or
  longer than) the duration of the reserved main RTP stream for
  replacing, the media clipping may occur at the splicing point which
  usually is the joint between two independently decodable frames.

I understood everything up to the word "which", but I don't understand the importance of what comes after that. But even before that, I'm not clear on whether you mean "clipping" or simply "truncation". The last paragraph of 4.3 seems to talk about true clipping, but the rest of this seems to be about extending media that does not fill a time slot or truncating media which overfills a slot and how to make those transitions look smooth. I wouldn't call all of these "clipping".

[Ballot comment]
I support Stephen's DISCUSS points.

REQ-3 seems broad and unspecific given the range of RTP/RTCP extensions.  REQ-4 is vague on what it really means technically, and REQ-5 is also vague in regards to what the performance consists of and lacks rationale for why it needs to be relayed back.  REQ-6 seems misformatted.

As written, I do not think this document is useful to be permanently published as an RFC.  It starts with the assumption that splicing is necessary for some use case and doesn't consider whether other approaches can meet the same actual requirements (of the use case, NOT of the splicing solution chosen).  It recommends a solution without clearly comparing any alternatives.

[Ballot discuss]
- REQ-4: What exactly does it mean to say that the
splicer must be trusted by the receiver? I would
have guessed that most receivers would not know of
the splicer's existence. The reason this is a
discuss is that I am worried that the consequences
of treating a "transparent proxy" (as they're called
in HTTP) as if it were "trusted" could be damaging
to the Internet.

- REQ-4 and REQ-6 seem to me to be in conflict.  How
can a receiver "trust" a splicer and yet be
prevented from knowing what the splicer has done?

- From the above, it seems to me that if there are
any security requirements here then the receiver
needs to have a direct relationship with the
splicer, as does the sender, so that e.g. any
encrypted traffic is decrypted at the splicer, and
then re-encrypted.

- Is the text in the 1st two paragraphs of 4.2
saying that we are encouraging hosts on the Internet
to fool one another and engineering our protocols to
make it harder for some of them to figure out they
are being fooled?  That doesn't seem like a good
goal to me, without a lot more justification.

- Changes to RTCP reports and loss values as
suggested here would also seem to preclude any real
e2e security. I just don't get why that is ok.

- If so-called "user invisibility" is required (and
there is no REQ-X for that) and it has the
consequence of creating loops then that ought be
described, and it isn't.

- If "invisible" splicing were really possible, then
how could any supposedly "secure" RTP session ever
be trusted by a receiver?

[Ballot comment]

section 1:
- s/into internet/into the Internet/
- s/changes to transport layer/changes to the
  transport layer/
- s/requirements of RTP splicing/requirements
  for RTP splicing/

- REQ-1, what environments other than unicast or
multicast might exist? If this isn't a tautology
then I don't know what's meant.

- REQ-3, I'm not clear what backward compatible
means here - the splicer seems to be talking
RTP/RTCP for both main and current content in Figure
1, so what element of backward compatibility is
meant here?

- Is the reference to SCTE30 meant to  be the 2001
version? I only found the 2009 version on scte.org,
but didn't hunt much. For SCTE35 2007 is referenced,
but there's a 2011. What's up there?  Stable URLs
for those and the ISMA document would be good.

[Ballot discuss]
(Clearing up some minor typos to make these easier to read)

It's not clear what a mixer implementer should be doing with the advice in the last full paragraph on page 12. How is that implementer supposed to apply something like RFC5348 or RFC5762? Is this feedback running between the mixer and the receiver, the mixer and the source, or something else? In any case, it should be made explicit that this isn't asking the mixer to begin transcoding.

The pseudo code blocks each say "the timestamp of the current RTP packet increments linearly" and that is unclear. Is this trying to say that the mapping from the timestamp in the input packet to the mixer and the output packet be linear?

The implementations considerations section says there is a potential issue with loop detection, but doesn't actually describe the issue, or how satisfying the user invisibility requirement makes it more likely to occur.

The document should be explicit about the expected trust model if SRTP is used. I believe it is currently assuming that media from either source would be decrypted at the mixer and re-encrypted towards the receiver(s). The first paragraph in section 6 could be read to imply that the mixer is just forwarding SRTP packets.

[Ballot discuss]
It's not clear what a mixer implementer should be going with the advice in the last full paragraph on page 12. How is that implementer supposed to apply something like RFC5348 or RFC5762? Is this feedback running between the mixer and the receiver, the mixer and the source, or something else? In any case, it should be made explicit that this isn't asking the mixer to begin transcoding.

The pseudo code blocks each say "the timestamp of the current RTP packet increments linearly" is unclear. Is this trying to say that the mapping from the timestamp in the input packet to the mixer and the output packet be linear?

The implementations considerations section says there is a potential issue with loop detection, but doesn't actually describe the issue, or how satisfying the user invisibility requirement makes it more likely to occur.

The document should be explicit about the expected trust model if SRTP is used. I believe it is currently assuming that media from either source would be decrypted at the mixer and re-encrypted towards the receiver(s). The first paragraph in section 6 could be read to imply that the mixer is just forwarding SRTP packets.

[Ballot comment]
When considering the clarification for the first point above, consider making the first two paragraphs of section 4.2 clearer as well.

CSRC is typo'd as CRSC in a few places.

[Ballot discuss]
Section 4.1., paragraph 3:

>    When splicing begins, mixer chooses the substitutive RTP stream as
>    input stream at splicing in point, and extracts the payload data
>    (i.e., substitutive content).  After that, mixer encapsulates
>    substitutive content instead of main content as the payload of the
>    current media stream, and then outputs the current media stream to
>    receiver.  Moreover, mixer may insert the SSRC of substitutive RTP
>    stream into CSRC list in the current media stream.

  What happens if the payload of the received substitutive RTP stream
  is larger than the maximum RTP payload of the outgoing RTP stream?

[Ballot comment]
  General comment: This document is in need of a lot of language
  improvements, e.g., replacing 'Splicer' with 'the Splicer' all over
  to improve readability. It seems that almost no arcticles have been
  used. This makes reading the text very, very hard, at least for me
  as non-native speaker.


Section 1., paragraph 4:

>    So far [SCTE30] and [SCTE35] have standardized MPEG2-TS splicing
>    running over cable.  The introduction of multimedia splicing into
>    internet requires changes to transport layer, but to date there is no
>    guideline for how to handle content splicing for RTP sessions
>    [RFC3550].

  Curious to see what the required changes to the transport layer are?!
  I have not found any change required to the transport layer, e.g., TCP, UDP, DCCP, etc.


Section 3., paragraph 4:

>    When RTP splicing begins, Splicer stops delivering the main content,
>    instead delivering the substitutive content to RTP receiver for a
>    period of time, and then resumes the main content when splicing ends.
>    The methods how Splicer learns when to start and end the splicing is
>    out of scope for this document.  The RTP splicing may happen more
>    than once in case that substitutive content will be dispersedly
>    inserted in multiple time slots during the lifetime of the main RTP
>    stream.

  Trying to improve the readability by suggesting this:
OLD:
Splicer stops delivering the main content,
NEW:
the Splicer stops delivering the main content to the RTP receiver,


Section 3., paragraph 7:

>      Splicer must operate in either unicast or multicast session
>      environment.

  Shouldn't this better read
"The Splicer must support either unicast delivery or multicast delivery."
or should the Splicer be able to support both modes at the same time and not just one at a time. If so, the sentence should read
"The Splicer must support unicast delivery or multicast delivery."


Section 3., paragraph 11:

>      Splicer must be backward compatible with RTP/RTCP protocols, and
>      its associated profiles and extensions to those protocols.  For
>      example, Splicer must be robust to packet loss, network congestion
>      etc.

  I do not see what the relationship between "backward compatible
  with RTP/RTCP protocols " and robust to packet loss, etc is.


Section 3., paragraph 15:

>      Splicer should allow the media source to learn the performance of
>      the downstream receiver when its content is being passed to RTP
>      receiver.

  What does this mean on the protocol level?  Is this referring to
  support RTCP relaying, an out-of-band mechanism, or what?


Section 4.1., paragraph 13:

>      the CSRC list of the current RTP may include SSRC of main RTP
>      stream;
>    }
>    Splicing may occur more than one time during the lifetime of main RTP
>    stream, this means mixer needs to output main content and
>    substitutive content in turn with its own SSRC identifier.  From
>    receiver point of view, the only source of the current stream is
>    mixer wherever the content comes from.

  The last sentence is a potentially misleading, as the receiver can
  identify the last mixer wherever the content comes from.


Section 4.2., paragraph 2:

>    According to the description in section 7.3 of [RFC3550], mixer
>    divides RTCP flow between media source and receiver into two separate
>    RTCP loops, media source probably has no idea about the situation on
>    receiver.  Hence, mixer can use some mechanisms, allowing media
>    source to at least some degree to have some knowledge of the
>    situation on receiver when its content is being passed to receiver.

  The last sentence is not making any point, other saying that there
  is something which isn't specified here. Not sure if this sentence
  is needed and if yes, it should reworded to make clear that there
  are mechanisms and reference to those.


Section 4.2., paragraph 3:

>    Because splicing is a processing that mixer selects one media stream
>    from multiple streams but neither mixing nor transcoding them, upon
>    receiving an RTCP receiver report from downstream receiver, mixer can
>    forward it to original media source with its SSRC identifier intact
>    (i.e., the SSRC of downstream receiver).  Given that the number of

  I'm lost by this sentence, as I have difficulties in parsing it. It
  is too long and needs some re-wording.


Section 4.2., paragraph 8:

>    If the substitutive content comes from local media file storage (
>    i.e., mixer can be regarded as the substitutive media source), the
>    reception reports received from downstream relate to the substitutive
>    content should be terminated on mixer without any further processing.

  the reports **must** be terminated, instead of using **should*, on the mixer,
  if the content is served from a local file.


Section 4.4., paragraph 1:

>    Provided that the substitutive content has somewhat different
>    characteristics to the main content it replaces (e.g., the more
>    dynamic content, the higher bandwidth occupation), or substitutive
>    content may be encoded with different codec and has different
>    encoding bitrate, some challenge raise to network capacity and
>    receiver buffer size.  A more dynamic content or a higher encoding
>    bitrate stream might overload the network and possibly exceed the
>    receiver's media consumption rate, which might flood receiver's
>    buffer and eventually result in a buffer overflow.  Either network
>    overload or buffer overflow would induce network congestion and
>    congestion-caused packet loss.

  overload is quite a generic term. Since you are pointing at causing
  congestion, it might be good to say that congestion can occur in
  the network due to sending the content.


Section 4.4., paragraph 1:

>    Upon detection of above three types of RTCP reports during splicing,
>    mixer will treat them with three different manners as following:

  This sentence is really hard to parse. Do you mean to say:



Section 4.4

>    Once mixer learns that congestion is being experienced on its
>    downstream link by means of above three detection mechanisms, it
>    should adapt the bitrate of output stream in response to network
>    congestion.  The bitrate adaptation may be determined by a TCP-
>    friendly bitrate adaptation algorithm specified in [RFC5348], or by a
>    DCCP congestion control algorithms defined in [RFC5762].

  adapting the bitrate depending on the outcome of TCP-friendly rate
  control or DCCP congestion control might not be an option, if the
  content requires a certain bitrate. It might be worth mentioning it
  here that congestion may result in stopping the delivery completely.


Section 6., paragraph 1:

>    If any payload internal security mechanisms (e.g., ISMACryp
>    [ISMACryp]) are used, only media source and RTP receiver can learn
>    the security keying material generated by such internal security
>    mechanism, any middlebox (e.g., mixer) between media source and RTP
>    receiver can't get such keying material.  Only when regular transport
>    security mechanisms (e.g., SRTP, IPSec, etc) are used, mixer will
>    process the packets passing through it.
COMMENT:A nit: IPSec is not a transport security mechanism.
To be even more nitty: IPSec delivery might also block a mixer if the security association is set up between the media source and the RTP receiver. This is similar to payload internal security mechanism.

[Ballot comment]
Substantive but non-blocking comments; please adopt or respond to these:

-- General --
I see from the mailing list discussion that there had been some consideration of using an RTP translator, rather than an RTP mixer.  It appears that mixer was chosen more or less by default -- there was a concrete proposal for it, and none for the other.  Given that, it might be nice to have a few words (maybe a small section at the end, maybe an appendix, something like that) about the possibility of using an RTP translator, and why using a mixer is better.  If the WG considered the issue, others are likely to as well.  But feel free to respond, "Yes, it might, but that is not this document."  :-)

-- Abstract --
You talk about proposing the use of "an existing RTP level middlebox", and you do know what that middlebox is.  I suggest saying so.  Maybe like this:
NEW
  and analyze whether an RTP mixer (an
  existing RTP level middlebox) can meet these requirements.  Finally,
  we provide concrete guidelines for how the RTP mixer can work to
  handle RTP splicing.

You might also mention this in the last paragraph of the Introduction.

-- Section 4 --

Where is an "RTP mixer" defined?  Should there be a reference?  I don't see a definition in RFC 3550 -- the term is used there, but not defined.

I also suggest expanding SSRC and CSRC on first use.

-- Section 4.1 --

I really dislike the odd "pseudo-code" format to illustrate the process.  It's already more prose than pseudo-code, and I strongly urge you to re-cast it as normal text.

-- Security Considerations --
The first paragraph is a little fluffy about what the issue is.  What makes "regular transport security mechanisms" different here... that is, what's the *real* point?  Is it that end-to-end encryption makes it impossible for the middlebox to play with the stream, but hop-by-hop encryption allows it?  I'd like to see this be clearer about what the conditions are that makes this feasible vs impossible, and then whether there are any security issues involved with allowing a middlebox to replace parts of the stream.  (It's possible that there are none, when the trust model in the second paragraph is correct.)

========
Editorial suggestions.  No need to respond to these; take them or modify them as you please:

-- General --
There are numerous English-language issues with the document, too many to detail with OLD/NEW suggestions.  The document would benefit from a pass by a native English speaker to fix the grammar, punctuation, and such, and I strongly suggest such an edit.  That said, the document is readable as it is, and these are edits the RFC Editor will make if we don't do it before.  (Note that this is a complaint against the WG, not against the editor.  WGs should be addressing this sort of issue in their review, and should appoint a co-editor in cases where the primary editor needs help getting the English right.)

-- Section 4.4 --
One language thing that I think really does have to be fixed now, for clarity:
OLD
  In practice, during splicing, the real reason to cause congestion
  usually is the different characteristic of substitutive RTP stream
  (more dynamic content or higher encoding bitrate) with main RTP
  stream, and that stream transcoding or thinning on mixer is very
  inefficient and difficult operation.

NEW
  In practice, the usual real causes of congestion during splicing
  are the differences in characteristics between the substitutive RTP
  stream and the main RTP stream -- when the former has more dynamic
  content or a higher encoding bitrate -- and that stream transcoding
  or thinning on the mixer is very inefficient and difficult.

-- IANA Considerations --

I suggest adding a sentence asking the RFC Editor to remove this section before publication, which is usual practice for empty IANA Considerations sections.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (Content Splicing for RTP Sessions) to Informational RFC





The IESG has received a request from the Audio/Video Transport Extensions

WG (avtext) to consider the following document:

- 'Content Splicing for RTP Sessions'

  as an Informational RFC



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 2012-04-03. 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 memo outlines RTP splicing.  Splicing is a process that replaces

  the content of the main multimedia stream with other multimedia

  content, and delivers the substitutive multimedia content to receiver

  for a period of time.  This memo provides some RTP splicing use

  cases, then we enumerate a set of requirements and analyze whether an

  existing RTP level middlebox can meet these requirements, at last we

  provide concrete guidelines for how the chosen middlebox works to

  handle RTP splicing.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for-rtp/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for-rtp/ballot/





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

Shepherd writeup for Content Splicing for RTP Sessions
(draft-ietf-avtext-splicing-for-rtp-07) requested to be published
as Informational RFC.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?
       
        Magnus Westerlund is the document shepherd.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 
       
        The document has had okay number of reviews in the WG. There has
        been no review outside of the WG to my knowledge. No significant
        concern over the amount of review.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?
       
        No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues 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. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.
       
        No concerns and no IPR disclosure has been submitted.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?
       
        There was significant amount of discussion around the direction
        of the approach that is recommended. This resulted in the end
        a strong consensus and many active WG participants has particpated
        in that part.

  (1.f) 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
        entered into the ID Tracker.)
       
        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?
       
        Yes.

  (1.h) Has the document split its references into normative and
        informative? 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
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].
       
        Yes, it has a split list. Although that isn't necessary considering
        it is an informational document.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?
       
        Yes, it is correct.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?
       
        No formal language.

  (1.k) 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
        This memo outlines how to perform RTP splicing.  Splicing is a process
        that replaces the content of the main multimedia stream with other
        multimedia content, and delivers the substitutive multimedia content to
        receiver for a period of time.  This memo provides some RTP splicing use
        cases, then we enumerate a set of requirements and analyze whether an
        existing RTP level middlebox can meet these requirements, at last we
        provide concrete guidelines for how the chosen middlebox works to handle
        RTP splicing.

    Working Group Summary
        This document has firm WG consensus behind it and has been
        advequate reviewed.

    Document Quality
        The sheperd is unaware of any specific implementation but
        expect this functionality to be implemented in the field.
        How well they follow the proposed method is unknown.