[Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-security-13: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Thu, 07 January 2021 13:55 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: detnet@ietf.org
Delivered-To: detnet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD623A113A; Thu, 7 Jan 2021 05:55:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-detnet-security@ietf.org, detnet-chairs@ietf.org, detnet@ietf.org, Lou Berger <lberger@labn.net>, lberger@labn.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <161002772940.25870.1767345558793174192@ietfa.amsl.com>
Date: Thu, 07 Jan 2021 05:55:29 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/GA5PGJ4XbXriSh-3S3Dp3h-gdJs>
Subject: [Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-security-13: (with COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 13:55:30 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-detnet-security-13: 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-detnet-security/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

Let's also try to address the COMMENT for section 4.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
In "best practices for security at both the data plane and controller plane",
is there a reason why the management/telemetry plane(s) is not included? Of
course, most of the time this plane is isolated from the others but anyway...
Also, is is "controller plane" or "control plane" ? or is the 'controller
plane' the plane connecting PCC to PCE ? (with an assumption that the ID is
also relying on PCC/PCE ?).

Section 8.3 (OAM) is welcome but why not already including OAM in the above
sentence ?

-- Section 5.2.3 & 6.3.1 --
May I assume that any layer-1 'jamming' (e.g., microwave link) is also covered
by this section ? If so, then I suggest to state it.

-- Section 3.3 --
"(Note that PREOF is not defined for a DetNet IP data plane)." will this note
be applicable forever ? Should the word 'currently' be used in this statement?
I also do not see the point of using parenthesis. I prefer the wording used in
section 7.1 "At the time of this writing, PREOF is not defined for the IP data
plane."

-- Section 3.4 --
Probably due to my ignorance about DetNet, but, I fail to understand why
"having the network shut down a link if a packet arrives outside of its
prescribed time window" and the rest of the section. Again, probably due to my
lack of context but you may want to explain the reasoning behind.

-- Section 4 --
There is no 'TOS' field in the IPv6 header, it is replaced by 'Traffic Class'.
So, please mention both of the fields.

-- Section 6 --
On figure 2, there are mentions of blockchain and network slicing without any
previous explanations (and I have hard time to see how blockchain traffic
should be detnet).

-- Section 8.3 --
This section seems to consider only OAM traffic added to the DetNet traffic
while there are a couple of in-band OAM techniques currently being specified at
the IETF.

-- Section 9 --
If the IPsec sessions are established by a controller, then this controller
could also send the Security Parameter Index (SPI) that is transmitted in the
clear and use this SPI to in addition to the pair of IP addresses.

== NITS ==

-- Section 1 --
s/A DetNet is one that/A DetNet is a network that/

-- Section 8.2 --
s/Figure 5maps/Figure 5 maps/

-- Authors --
The URL for http://www.mistiqtech.com does not work for me