Re: [secdir] Secdir last call review of draft-ietf-ccamp-otn-topo-yang-17

Watson Ladd <watsonbladd@gmail.com> Sat, 20 April 2024 04:04 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B86C14F74A; Fri, 19 Apr 2024 21:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj3XKGBBZlkq; Fri, 19 Apr 2024 21:04:42 -0700 (PDT)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32594C14F749; Fri, 19 Apr 2024 21:04:39 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-419e0f57b4dso2130695e9.2; Fri, 19 Apr 2024 21:04:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713585877; x=1714190677; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TfK48flolZiOU09L2aWXAkvLMOzb4Ol26iqFmB7FSCA=; b=lkC6RVmfP+b+3wliQcRWB5xJWpku+6co3D55FULxyOBPCp6D5QQT2KSNKrHYzOjNSR IP+T9oi045/4rOsq9lIX2klXW6vcui13Q42T7O8IPFgpzIgBrnnb/X/VYnyhyMIZ1cQF ZsPav4Dqw9LpSUj28+5p1bd1v2OttKrY5f3jWqj3BcubR9K/wZ6BeCQFj/tFBiJrUsuw yeA074ciaicv58hp30xANaqh8bmfDu9IW+5lRPO/7sBesPFYRbbFuhrUPpyClqiX6Vcq yEw31cZ1FbTidZLEJfGGPE1qSk905MXfPomwHsCwM9bV6W1dwX/2dALiYJBvIOc2FAXE Zpdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713585877; x=1714190677; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TfK48flolZiOU09L2aWXAkvLMOzb4Ol26iqFmB7FSCA=; b=MHrsuQuNaXc+BGb/Gpl7pskev5cXDTd+HuAMFCzqt21Q9eb1GRfk2VAm3E0xhEWodb FDnlGTDRmRtqK6NtYz3reSrBreFmygDgwrPcnvfoaGTQ7hFcoRlMnHmguGMRU89heun8 TSYnAhYB4SykEbc/HyvFYHn6H/yOrhUdpqT2HlOFazL4uhqZVaTadhhaNrrRHdzim/hN r8hfnKWVJ68s9uIYnBg4Sw/oxig2BX3WbdIUgmQJ1pOaOjNldBdUHudav/Ph5L2dRI4i SK5MLp+VEgKSMHomANzPc5NHtFNTUA66EPVk1BlgLJPi2Pc+Gy5ZoLpXQARz/VTLbPRV 42Bg==
X-Forwarded-Encrypted: i=1; AJvYcCU18pH3+k7MHuDyoV8fTZpgccyTNPOO3gHahuTnEjZ8BalS/dkoCy3BLAW7qLP2AHfDVtpNKdSHpG8pXi6XZmGcUGxRRO6qEY9ao2Mxx/txALUD3e1ymNULINv8FF5Oh8JL7NLql2SK9T10p+d47yiU2S5SC0wF+eOHI1mnOr44
X-Gm-Message-State: AOJu0YxKlFXLJXf/A3QHIzI1A0/rZU9PCrWwvk3VLJUW0Q3trROKVhYg FCeI+wKSKhoNZ+dtkzVP5kn5pAI+Y8EDwcXI5kpnIBMisaYzsiXzP9VNvCZ52CgGuOy7+hOCj0H axRaqRfUWQVvbn+I0+4MQItJsvhU=
X-Google-Smtp-Source: AGHT+IFCDPC8QuZOSVHMqJrytwVA8FslqrWF33qWD6JN+gM3PDTAO9poylCFJiJE2W11F81LhVFOHJ+G+JB0V6kHoXQ=
X-Received: by 2002:a05:600c:3b1a:b0:418:a985:3ca with SMTP id m26-20020a05600c3b1a00b00418a98503camr3170172wms.31.1713585877125; Fri, 19 Apr 2024 21:04:37 -0700 (PDT)
MIME-Version: 1.0
References: <170896742027.58906.12731500706967830981@ietfa.amsl.com> <acfd807665f849e79b9ebdffbb395738@huawei.com>
In-Reply-To: <acfd807665f849e79b9ebdffbb395738@huawei.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Fri, 19 Apr 2024 21:04:26 -0700
Message-ID: <CACsn0cnvLEm6T2byqyncgnSdugh8-PWYjdjT2xn0JJe0t=29Ww@mail.gmail.com>
To: Zhenghaomian <zhenghaomian@huawei.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, "draft-ietf-ccamp-otn-topo-yang.all@ietf.org" <draft-ietf-ccamp-otn-topo-yang.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/qKUf6wHwR6LNH69MLLlWlF0tZs4>
Subject: Re: [secdir] Secdir last call review of draft-ietf-ccamp-otn-topo-yang-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Sat, 20 Apr 2024 04:04:42 -0000

On Fri, Apr 19, 2024 at 6:08 AM Zhenghaomian <zhenghaomian@huawei.com> wrote:
>
> Dear Watson,
>
> Thanks for the review and good suggestion. You are correct that we inherit some security sensitivity during the augmentation process, so we have clarified the document security text in the -18 version. We have also underlined that network topology may be considered confidential in some scenarios, and access should be carefully managed.

I think the revised text is fine.

>
> Thanks.
>
> Best wishes,
> Haomian (on behalf of authors & contributors)
>
> -----邮件原件-----
> 发件人: Watson Ladd via Datatracker <noreply@ietf.org>
> 发送时间: 2024年2月27日 1:10
> 收件人: secdir@ietf.org
> 抄送: ccamp@ietf.org; draft-ietf-ccamp-otn-topo-yang.all@ietf.org; last-call@ietf.org
> 主题: Secdir last call review of draft-ietf-ccamp-otn-topo-yang-17
>
> Reviewer: Watson Ladd
> Review result: Has Nits
>
> 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 copy-pastes the security considerations from RFC 8795 and says that the augmentations have the security properties inherited from where they are attached. However it isn't clear if this is the only way in which fields defined here are sensitive. I think some rewording may be in order to clarify.
> Otherwise I think this document is a straightforward augmentation of a YANG model.
>
> Sincerely,
> Watson Ladd
>
>


-- 
Astra mortemque praestare gradatim