Re: [secdir] Secdir last call review of draft-ietf-mops-streaming-opcons-10

[Spencer Dawkins at IETF <[e-mail]>]

Nancy,

On Thu, Aug 4, 2022 at 9:25 PM Nancy Cam-Winget (ncamwing) <
[e-mail]> wrote:

> Hi Spencer,
>
> Just took a quick skim at comment resolutions with closer inspection of
> section 5.4 which is
>
> much improved.  I’ve added a similar comment to the GitHub as well.
>

Thank you very much for the feedback! I'll close this issue as resolved in
GitHub,

That gets us down to one open issue, with Roman still proposing text to
resolve his Discuss ballot.

Best,

Spencer


> Thanks!
>
>    Nancy
>
>
>
> *From: *Spencer Dawkins at IETF <[e-mail]>
> *Date: *Thursday, August 4, 2022 at 1:03 PM
> *To: *Nancy Cam-Winget (ncamwing) <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *Re: Secdir last call review of
> draft-ietf-mops-streaming-opcons-10
>
> Hi, Nancy,
>
>
>
> Thank you for your review (and text suggestions).
>
>
>
> I think we've been able to address all of your comments on -10, but your
> comment on 5.4 may have already been addressed in -11. We were working on
> this section, because Roman had also pointed to it in his IESG Evaluation
> ballot, so the -10 text about personalized ads has been changed
> significantly.
>
>
>
> Could I ask you to take a look at section 5.4 in
> https://www.ietf.org/rfcdiff?url2=draft-ietf-mops-streaming-opcons-11.txt,
> and see what you think?
>
>
>
> You can reply here, or in the Github issue I created for this comment in
> your review, at
> https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/181
> .
>
>
>
> Best,
>
>
>
> Spencer
>
>
>
> On Thu, Jun 30, 2022 at 1:48 PM Nancy Cam-Winget via Datatracker <
> [e-mail]> wrote:
>
> Reviewer: Nancy Cam-Winget
> Review result: Ready
>
> Ready with Nits
>
> Reviewer: Nancy Cam-Winget
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> This document describes how streaming applications may use network and
> transport protocol and presents some challenges or issues as either or both
> the use cases and protocols continue to evolve.  The goal of the authors is
> to provide a snapshot overview of the requirements and challenges current
> streaming applications on the network protocols to serve as a reference
> for future design and protocol proposals.
>
> I have reviewed the document from the perspective of security requirements/
> considerations. Section 7 focuses on this topic and scopes the description
> to
> how media is encrypted at the transport layer only and asserts that it
> does not
> validate the encryption goals.  With that in mind, the subsections do
> provide
> a cursory view of how encryption is applied.  As it is not a security
> considerations
> section (or security focused document) it lacks depth in the security and
> privacy
> requirements or challenges.  For instance, no mention to the use of
> specific
> cipher suites nor requiring strong authentication and
> key management mechanisms when using the encryption.
>
> I have a couple of nits that can help clarify intent and descriptions in
> the
> document:
> -       Section 3.2: I believe the last paragraph is trying to point out
> that there
> bottlenecks can exist at both different nodes/hops in the network, endpoint
> and service but I believe there are also bottlenecks that can exist or be
> addressed
> by proper configuration at the different levels of the OSI stack
> (e.g. Wifi/cellular/ethernet link layer, TCP/UDP to application layer).
> But the
> reference to a “link” can benefit from including better qualification.
>
> -       Section 4.1: better quantification of the number of users it can
> serve is needed
> as better guidance (vs. “…do not need to scale to more than a few users at
> a time”)
> As I can see live media events (like conference calls?) where there could
> be up to
> a hundred users (whether recommended or not!) attempting to hold a
> collaborative
> conversation (e.g. live video, audio and other resources like
> whiteboarding)
>
> -       Section 5.4 2nd paragraph pg. 20 speaks to potential privacy (and
> security)
> violations as ad fraud.  As a non-expert in the full live-streaming
> workflow with ads
> but a security expert, a better description of the current workflow or
> mention that the
> misreporting is out of scope (?) is needed.  If the intent is to provide
> guidance for future
> design and protocol improvements, at least a reference to how current
> solutions work
> and fail is required.
>
> -       Section 5.5.3 – have the authors considered how QoS signaling at
> the link layer
> like 802.11e and 802.11u help or affect performance?
>
> Editorial nits:
> -       Section 3.4 pg 10 last paragraph.  The 2nd sentence “For example,
> with the
> emergence of ultra-low-latency streaming…..” is an awkward sentence.  I
> suggest
> To break it into two sentences.
> -       Secion 5.5.3: typo “detection” is misspelled
>
>
>