[avtext] Mirja Kühlewind's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT)

["Mirja Kuehlewind" <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-avtext-splicing-notification-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/



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