Re: [AVTCORE] Lars Eggert's Abstain on draft-ietf-avtcore-rtp-scip-08: (with COMMENT)

[Bernard Aboba <[e-mail]>]

Lars said:

"SCIP cannot be treated as a black box"

[BA]. A (perhaps unappreciated) aspect of the SCIP RTP payload
specification is that unlike other RTP payload formats, the SCIP payload is
not to be parsed or transformed, either on sending or reception.   This is
an architectural constraint that SCIP has in common with other E2E
protocols including SFRAME, so it is not related to the status of the SCIP
document.

The reasoning behind the "no parsing or modification" rule derives not just
from the security services provided by SCIP (capability negotiation, key
management, integrity protection, replay protection), but more
fundamentally from the need to prevent ossification of the SCIP protocol,
which is still evolving.  It is my expectation that a "black box" treatment
requirement will also find its way into other RTP payload specs for E2E
payloads such as SFRAME.

One consequence of this architectural constraint is that in the SCIP RTP
payload specification there is no equivalent of H.264 NAL unit parsing,
addition/removal of start codes, fragmentation or aggregation units, etc.
Instead, on sending, SCIP provides MTU-sized payloads to the RTP
packetizer, which stuffs them into the payload field and sends them.
Similarly, on reception, my understanding is that the RTP de-packetizer
feeds the received payloads to the SCIP layer, without having to do
traditional operations such as filling in "holes" in the jitter buffer,
NACK/FEC robustness, etc.






On Fri, Feb 2, 2024 at 9:35 AM [e-mail] <[e-mail]>
wrote:

> Lars,
>
> Thank you for reviewing the document.
>
> Because the SCIP payload is encrypted, it cannot be parsed by the network
> (middle boxes).  Even the size of the payload can vary from packet to
> packet so there is essentially no meaningful information that can be
> interpreted from the data stream in middle boxes.
>
> We have provided the public link to the SCIP-210 specification in the
> Informative reference section so that reader can have some idea of the
> different types of messages and data streams that might appear in the
> packets.
>
> A Cisco rep has told us that he has all the information (in the draft RFC)
> he needs to support SCIP in their products.
>
>
> Regards,
> Dan Hanson
> General Dynamics Mission Systems
>
> This message and/or attachments may include information subject to GD
> Corporate Policies 07-103 and 07-105 and is intended to be accessed only by
> authorized recipients.  Use, storage and transmission are governed by
> General Dynamics and its policies. Contractual restrictions apply to third
> parties.  Recipients should refer to the policies or contract to determine
> proper handling.  Unauthorized review, use, disclosure or distribution is
> prohibited.  If you are not an intended recipient, please contact the
> sender and destroy all copies of the original message.
>
> -----Original Message-----
> From: Lars Eggert via Datatracker <[e-mail]>
> Sent: Friday, February 2, 2024 2:14 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Lars Eggert's Abstain on draft-ietf-avtcore-rtp-scip-08: (with
> COMMENT)
>
> ----
> External E-mail --- CAUTION: This email originated from outside GDMS. Do
> not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> Lars Eggert has entered the following ballot position for
> draft-ietf-avtcore-rtp-scip-08: Abstain
>
> 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-scip/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I would have been OK with this going forward as Informational, but for a
> Proposed Standard I have to agree with Roman that the SCIP specification
> is an
> integral part of this and cannot simply be treated as a black box.
>
>
>
>