Re: [AVTCORE] Éric Vyncke's Discuss on draft-ietf-avtcore-rtp-scip-08: (with DISCUSS and COMMENT)

[Bernard Aboba <[e-mail]>]

Eric --

Something along the lines you suggest seems viable.  Since Sahed's DISCUSS
comment relates to what is done in SCIP versus higher layers such (S)RTP
and cryptex, some discussion of the SCIP negotiation will be needed.

On Mon, Feb 5, 2024 at 3:40 AM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> Hello Bernard,
>
>
>
> The SCIP specification was indeed provided t*o *the IESG, thanks for that.
>
>
>
> My remaining issue should be trivial to address, let me repeat it with
> other words. There are two assertions in the text about the security of
> SCIP:
>
> - in the abstract: -`SCIP is an application layer protocol that provides
> ... security services such as confidentiality and integrity protection`
>
> - in section 2, 4th paragraph: `The SCIP protocol defined in SCIP-210
> [SCIP210] includes ... security services such as end-to-end confidentiality
> and integrity protection.`
>
>
>
> Those claims have not been verified explicitly by the IETF community,
> i.e., they cannot appear like that in an IETF stream document.
>
>
>
> As I suggested in my DISCUSS, restricting the claim by removing the
> implicit IETF support with statement like “The SCIP WG of ???” (with “???”
> being “NATO” or “US Department of Defense” or ...
>
>
>
> Or even a clear disclaimer at the abstract/introduction (or an IESG note)
> with text such as “The IETF has not conducted a security review of SCIP and
> therefore has not verified the claims contained in this document”.
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
>
>
> *From: *Bernard Aboba <[e-mail]>
> *Date: *Friday, 2 February 2024 at 22:19
> *To: *Eric Vyncke <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-avtcore-rtp-scip-08:
> (with DISCUSS and COMMENT)
>
>
>
> Eric said:
>
>
>
> "Indeed, all IETF stream documents require that the IETF community was
> able to
>
> review it. The nature of SCIP standard has prevented such review, therefore, it
>
> is not possible for an IETF stream document to make those claims (that are
>
> probably correct)."
>
>
>
> [BA] As has been the case with other RTP payload specifications (e.g. EVC
> RTP Payload), arrangements were made to provide the SCIP specification to
> the IETF community.  I as well as other WG participants made requests for
> the SCIP specification and were provided with it.
>
>
>
> Was an IESG member who requested the SCIP specification denied access?  If
> so, this is probably more of an oversight than an intentional denial.
>
>
>
>
>
>
>
> On Fri, Feb 2, 2024 at 5:34 AM Éric Vyncke via Datatracker <
> [e-mail]> wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-avtcore-rtp-scip-08: Discuss
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05
>
> Thank you for the work put into this document. Alas, even after some email
> discussions with the authors, the core of my discuss is still there. So, I
> cannot clear my discuss.
>
> Previous DISCUSS is at:
> https://mailarchive.ietf.org/arch/msg/avt/xFC3Ux9AfYt3e5T0GSzrasQe_j4/
>
> # DISCUSS
>
> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
> DISCUSS ballot is a request to have a discussion on the following topics:
>
> ## Section 3 and abstract
>
> I am afraid that without free and public access to the IETF community
> (whether
> informational or normative) to the SCIP protocol itself, the IETF stream
> cannot
> publish any document (even informational or experimental) with the
> following
> assertions/claims:
>
> - `SCIP is an application layer protocol that provides ... security
> services
> such as confidentiality and integrity protection` - `The SCIP protocol
> defined
> in SCIP-210 [SCIP210] includes ... security services such as end-to-end
> confidentiality and integrity protection.`
>
> Indeed, all IETF stream documents require that the IETF community was able
> to
> review it. The nature of SCIP standard has prevented such review,
> therefore, it
> is not possible for an IETF stream document to make those claims (that are
> probably correct).
>
> Suggest removing any such claim from the text or rephrasing them so that
> they
> do not appear as an IETF claim, e.g., "NATO claims that..." or "NATO
> certifies
> that ..."
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # COMMENTS
>
> ## Abstract
>
> Is there a reason why is SDP expanded and not RTP ?
>
> ## Section 1
>
> Unsure whether the following text has a place into an IETF RFC `This
> document
> provides a reference for network security policymakers, network equipment
> OEMs,
> procurement personnel, and government agency and commercial industry
> representatives.`. Suggest to remove it.
>
> I wonder to wonder whether the USA has left NATO ? The text `SCIP is
> presently
> implemented in United States and NATO` seems to indicate that the USA are
> not
> included in NATO.
>
> ## Section 1.2
>
> The DTX acronym is expanded twice and never used. Suggest to remove it.
>
> ## Section 2
>
> Per `Secure Communication Interoperability Protocol (SCIP) allows the
> negotiation of several voice, data, and video applications`, it appears
> that
> SCIP can also be used for *data*, but this document is only about
> video/audio.
> I.e., some text should explain to the reader what happens to the data.
>
> Please explain what is a STANAG or provide an informational reference to
> STANAG
> 5068.
>
> The reader will welcome explanations about the numbers in `scip/8000 and
> scip/90000` (e.g., by a reference to section 5)
>
> ## Section 3.1
>
> Should there be informative references for MELPe, G.729D ?
>
> Is this subsection useful ? This document is about RTP payload and this
> subsection is more fit for the SCIP endpoints themselves. But, I am
> neither a
> transport nor an application expert, so, feel free to keep this subsection.
>
> # NITS
>
> The official name of the UNO member state is "United States of America"
> and not
> simply "United States".
>
>
>