IETF Logo Mail Archive

Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT)

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 15 July 2021 15:18 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF3D3A0935; Thu, 15 Jul 2021 08:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTXc8S3iPl36; Thu, 15 Jul 2021 08:18:39 -0700 (PDT)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BEE3A092E; Thu, 15 Jul 2021 08:18:38 -0700 (PDT)
Received: by mail-ua1-x92f.google.com with SMTP id g4so2240797uap.5; Thu, 15 Jul 2021 08:18:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kOXgtEiU7i+oL6eIhjEd9aN7xjwpnfkmIprvNyX5UcI=; b=KEnPl9wHEU5DzcjP9xLPoH5C84xyz83hfwv19xQcJUvW0zA0W+Fpp7FISoDzRc0pjy 3ITziBAh7+qwnXNiApnDPhQGFAlOyMKs89QB3eS2smk+Ty+2QfbKMZvn0q0y5Yd5xoTO /vAga48s1Z/v/nz37aewSlKufd6WVLY5W6u4oKbR5SzrVONoF3TlmE2I1pgDx6Al9fjv 48txqfK1rGR/BG29QTdcRlOOlMya7/ER5kHru6+VqyqYAfrHrwX3c6wOpPNqhVF3vlTI 3gQ5WjpyvYKl/Ti9DA5uQ3kGriOZFVxaPpcIg54ZbfTqkvuNIumihVDcRL8QhdxSZPgg Vn6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kOXgtEiU7i+oL6eIhjEd9aN7xjwpnfkmIprvNyX5UcI=; b=Do/fD+DGUstfEK0DXstft7XGD80hkPnDDhrJrvka+z5kWhWgcWp1JVXXmgxnd0ykHv CvZunzf2H4R3+av7HkWZ7AgethP+0K7orDAGB0Ld64vJx41QNH1NWZEZZgd+6Nw5XM8b 6WgZ1/CJqcm9q1pCyE14K27myZj1ehAYu1ft3aJC90JqMJgkS39k5Sp/IloseDKnwIDi YNQ0SgLAtpSRvGJmcUUyQbYmJ8xUMlnDV/Z7Waeei0uwap29m9G9TzNO5DGl8EoRn6fV bOR1kRnKk7tfT1kIa2K+RC26vxt9T3RA+lvWWrsy2Z60f5e62hBB09g4H8BTx2sqwmw8 VMYg==
X-Gm-Message-State: AOAM531XDPxT+xKSdu6+QUKUID/zniEugDgr8vFpGVan4du+GB91n+nH it+KRY1rEct5PBkl7pIMO7nOzWTnf62LToh5aXA=
X-Google-Smtp-Source: ABdhPJyx1jeK21vDZjJsqIzofWl0hfDehXwbLSDavZbvEqFFLKRDWYDUoM8fOm0RLSE+Y3pZ3CyUx9cTkVK9Md+h7jE=
X-Received: by 2002:ab0:7305:: with SMTP id v5mr7762694uao.47.1626362317479; Thu, 15 Jul 2021 08:18:37 -0700 (PDT)
MIME-Version: 1.0
References: <162611498183.7775.3562397379733537345@ietfa.amsl.com> <f5961690-4496-7f85-74ca-f3705d5a1c2e@joelhalpern.com> <CAMMESszF+jc7WKkAwmzAFs0A7bsDqXJKA3p5+cyexdU3fvNnDQ@mail.gmail.com> <1a5ae768-bf12-6d94-819c-7923e1f816ee@joelhalpern.com> <CAL0qLwbb4L5LrtMNokzkWTag+oZTs6hFbBtbfCnthO-m_cpfiA@mail.gmail.com> <758d4dcf-5cdb-e493-a6bc-554024be6b62@joelhalpern.com>
In-Reply-To: <758d4dcf-5cdb-e493-a6bc-554024be6b62@joelhalpern.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 15 Jul 2021 08:18:25 -0700
Message-ID: <CAL0qLwaH0L=gmbRj6n6okwvNjTdQYHJKvOZ2+6j+s7eHoqgaUA@mail.gmail.com>
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>, Greg Mirsky <gregimirsky@gmail.com>, draft-ietf-sfc-nsh-integrity@ietf.org, Service Function Chaining IETF list <sfc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000035a27f05c72afc23"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/4RcNLrwJw_4b6pzS5Bq0QPrh2-w>
Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jul 2021 15:18:45 -0000

On Thu, Jul 15, 2021 at 7:47 AM Joel Halpern Direct <
jmh.direct@joelhalpern.com> wrote:

> Given that the WG intent was that this be an optional extension, can you
> please suggest how we clarify that?
>

It's obvious from this discussion that that was the WG intent, but is it
also your view that this WG intent was made clear in the document?  That
was certainly not my impression, and I infer from the number of ballot
comments that that's not a singular view, though certainly that might be
more obvious to someone directly involved in this space.

How about this, or something like it, in your Abstract:

CURRENT:

   This specification adds integrity protection directly to the Network
   Service Header (NSH) used for Service Function Chaining (SFC).  Also,
   this specification allows to encrypt sensitive metadata that is
   carried in the NSH.

NEW 1:
   This specification adds optional integrity protection directly to the Network
   Service Header (NSH) used for Service Function Chaining (SFC).  Also,
   this specification allows to encrypt sensitive metadata that is
   carried in the NSH.

NEW 2:
   This specification presents an optional method to add
   integrity protection directly to the Network
   Service Header (NSH) used for Service Function Chaining (SFC).  Also,
   this specification allows to encrypt sensitive metadata that is
   carried in the NSH.

...and in Section 1:

CURRENT:
   This specification fills that gap.  Concretely, this document adds
   integrity protection and optional encryption of sensitive metadata
   directly to the NSH [...]

NEW:
   This specification presents an optional extension that fills that gap.
   Concretely, this document adds optional
   integrity protection and encryption of sensitive metadata
   directly to the NSH [...]

-MSK

v2.23.0 | Report a Bug | By Email