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

[Harald Alvestrand <[e-mail]>]

On 2/5/24 12:40, Eric Vyncke (evyncke) 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, 4^th 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.
>
This seems like a very finicky kind of requirement.

Possibly a more palatable way of stating this would be "The SCIP 
protocol defined in SCIP-210 [SCIP210] states that it includes security 
services such as ..." - making it clear that this is a statement of what 
the non-IETF document claims, not about what the protocol actually provides.

But in general, I find the argument about "IETF requires inspectability 
of the carried material" argument hard to follow - after all, TCP and 
UDP were explicitly defined not to make any claims about the bytes they 
carry.


> 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".
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt