[secdir] Secdir last call review of draft-ietf-ccamp-l1csm-yang-24

Yaron Sheffer via Datatracker <noreply@ietf.org> Sun, 28 January 2024 08:52 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DEFC18DB95; Sun, 28 Jan 2024 00:52:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yaron Sheffer via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: ccamp@ietf.org, draft-ietf-ccamp-l1csm-yang.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <170643195428.45880.18103846375441499172@ietfa.amsl.com>
Reply-To: Yaron Sheffer <yaronf.ietf@gmail.com>
Date: Sun, 28 Jan 2024 00:52:34 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/7ikvcMo2x2zqGgugYagK78gyVcs>
Subject: [secdir] Secdir last call review of draft-ietf-ccamp-l1csm-yang-24
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jan 2024 08:52:34 -0000

Reviewer: Yaron Sheffer
Review result: Has Nits

The document describes a simple YANG model for L1 service management. IMO it is
ready to go, with a few nits:

Sec. 1.2: the actual YANG module in Sec. 4 says "Refer to MEF 63 for all
terms", so I would expect MEF 63 to be used as a reference for terminology here
(and that document does have a very nice glossary).

Sec. 2, 2nd paragraph: the word "includes" is redundant.

Sec. 5: I'm a bit puzzled about the three IDs that were called out as
sensitive: uni-id, service-id and endpoint-id. One reason for sensitivity is
that they may disclose interesting information. Another reason is that "they
must also be correctly configured to ensure the Subscriber and Service Provider
connection is established." But I think the latter reason applies to everything
else, e.g. "protocol", "optical-interface". In other words, just about
everything in this module can be used to bring down the UNI, and therefore all
attributes should be considered sensitive.

Sec. 5: "These are the subtrees and data nodes and their
sensitivity/vulnerability" - but then we list the subtrees but no specific
details about sensitivity/vulnerability.