Re: [secdir] [CCAMP] Secdir review of draft-ietf-ccamp-microwave-framework-05

Radia Perlman <radiaperlman@gmail.com> Sun, 20 May 2018 03:34 UTC

Return-Path: <radiaperlman@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 34FAD124B0A; Sat, 19 May 2018 20:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfSX7eQfa-eF; Sat, 19 May 2018 20:34:38 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 9740B1243F6; Sat, 19 May 2018 20:34:38 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id e20-v6so10676876iof.4; Sat, 19 May 2018 20:34:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bbj0XWnoaJ79yTHDOEtgFCKGAWw5UGzBwxSmAE2W9ik=; b=OWlg1Pvrcf1S2k8/RMN2CITQC7HXsh595eY35lAspnlwrSx2JCY9KHRQeuVKCIYjQF 3jd9xRaoeSf4cdo0KhIvajzr5oboqx7kRc3wS+T1f8fgMFBOHSEuAvbY1F5t4Uw1gIS2 xOoMG0OTvcoW0pbdfxfxLdPfdBM659gerUKiMDDKcirvRG2YLXlI+oJoXG7ifAHwbV/v FzHyZHf7yyRhqZtN7UaKF3gkn4fOk7kiu9Xy1aW8k3e/uCfy+hfGWU00hQTlQ5qpI4uR YFUJD7gJkXZ4mWheX1TWWX1ryf1lx6kAy9yv5NNlCpwbSugM5v4GspT8NlEZP2ibzYJY nyWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bbj0XWnoaJ79yTHDOEtgFCKGAWw5UGzBwxSmAE2W9ik=; b=psbcVugzh+QCe9tXDLnj3yo1loUedaH9rIfQ6rSmqiAB/1QdU8Gzy17baBwzwDzn9A an8j8xWojUhh4xc3dGX/dRYQWdNnI/UWipUV523DLiB1gt6oOIQE2sDi31z9/xDs7X3L 7zmPlNRdMmYnsQZ5wy7uJt6AXXFXchBNJhhLJNy1ifOfPv632O3NhYcm5ZGpWFhXp4j2 eu5DYTeYvus4tYoaWFsmAA+YUWJRlaNfyf8WY4OkK5S3bTm9jBKi+Zkt+wZheyYMUHwV 4bQYVYzAyAelG+WfCfE7bvJ07q0T751oVRVDz0t1DDASBpONoa7COFm0S5AWsX081RSj 0ZDw==
X-Gm-Message-State: ALKqPwe9KJOcuzTDNOemjKuuWi7scdmdxdpDF5Ri4Se9ZAtCnXLuEylI FWG1FByfDgZAYeDvEi/RxetDtRL5l1p5de3i6ZGOKw==
X-Google-Smtp-Source: AB8JxZo4jBxH1AEAtNbUVChWJvTRWuLhR8wNN1G9l4VDkNp5dYnUiSAiw9dXZC1Rxr+yDklBGg5C0ebAiwrH+AJEIyY=
X-Received: by 2002:a6b:b513:: with SMTP id e19-v6mr16932685iof.267.1526787277786; Sat, 19 May 2018 20:34:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:2a02:0:0:0:0:0 with HTTP; Sat, 19 May 2018 20:34:37 -0700 (PDT)
In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF64BA92606@eusaamb107.ericsson.se>
References: <CAFOuuo7PmeTWMYnetwi_8d-11UZmkPXx7WSje-coH_=ROfr9bA@mail.gmail.com> <VI1PR07MB3167FAE7BD03E6751047B60DF09B0@VI1PR07MB3167.eurprd07.prod.outlook.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCF004E74@dggema521-mbs.china.huawei.com> <CAFOuuo6XWv8NnWN2SDXDFJ-6FZVmvC-T8i8k+M3wXb2aARfqBg@mail.gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF64BA92606@eusaamb107.ericsson.se>
From: Radia Perlman <radiaperlman@gmail.com>
Date: Sat, 19 May 2018 20:34:37 -0700
Message-ID: <CAFOuuo5rZQpE7VrgRSxvMPJcC+3dRJco+a1S7BPEyqnCPmKBSA@mail.gmail.com>
To: Eric Gray <eric.gray@ericsson.com>
Cc: "Yemin (Amy)" <amy.yemin@huawei.com>, The IESG <iesg@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ccamp-microwave-framework.all@tools.ietf.org" <draft-ietf-ccamp-microwave-framework.all@tools.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005710d0056c9add87"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Z1UDhzR0TghPk1Zsul0od59w11A>
Subject: Re: [secdir] [CCAMP] Secdir review of draft-ietf-ccamp-microwave-framework-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 20 May 2018 03:34:43 -0000

Hi Eric,

I feel bad for the authors of this document to be burdened with clarifying
a distinction that has never been clear before (to lots of people,
including me),  but their proposed text doesn't make it clearer.

" “It's noted that there's idea that the NMS and SDN are evolving towards a
component, and the distinction between them is quite vague. Another fact is
that there is still plenty of networks where NMS is still considered as the
implementation of the management plane, while SDN is considered as the
centralization of the control plane. They are still kept as separate
component"

 Do you (or anyone else) have a suggestion for text that acknowledges to
the reader that it's not the reader's fault for not understanding the
difference?

It would be OK with me for them to leave out  the extra entirely, since I'm
sure this isn't the first RFC whose verbiage claims SDN and NMS are two
different concepts. But if I were trying to get up to speed about this area
by reading the documents, I'd be somewhat comforted by an acknowledgement
(such as the text they propose, but with the English fixed) that these are
fuzzy distinctions, so I wouldn't think it was just me....that if I only
read more things, or thought harder, or had more background, the
distinction would be clear.

Radia




On Fri, May 18, 2018 at 1:27 PM, Eric Gray <eric.gray@ericsson.com> wrote:

> Hi Radia.
>
>
>
> I agree that the English is awkward, but I would have interpreted
> “evolving toward a component” to mean something more along the lines of
> evolving toward the same (singular) thing.  Or perhaps another way to look
> at it might be that, because YANG is becoming a more popular mechanism for
> both NMS and SDN, it is likely that one or both of these may become
> components of a common management framework.
>
>
>
> I would interpret it this way precisely because – as you say – the
> distinction is not at all clear, though I would add that (to some of us)
> the distinction has never been very clear.  😊
>
>
>
> For this reason, I would have some small difficulty in seeing how it would
> make much sense to say that they are evolving toward increasing similarity.
>
>
>
> --
>
> Eric
>
>
>
> *From:* CCAMP [mailto:ccamp-bounces@ietf.org] *On Behalf Of *Radia Perlman
> *Sent:* Friday, May 18, 2018 12:30 AM
> *To:* Yemin (Amy) <amy.yemin@huawei.com>
> *Cc:* The IESG <iesg@ietf.org>; ccamp@ietf.org; secdir@ietf.org;
> draft-ietf-ccamp-microwave-framework.all@tools.ietf.org
> *Subject:* Re: [CCAMP] Secdir review of draft-ietf-ccamp-microwave-
> framework-05
>
>
>
> Thank you!  Though what you're suggesting is awkward English.
>
>
>
> Perhaps "We note that the distinction between NMS and SDN is not all that
> clear, and the two are evolving to be more and more similar." could replace
> the first sentence.  I'm really not sure what you meant by "evolving toward
> a component", so perhaps I'm not capturing what you are intending to say.
>
>
>
>
>
> Radia
>
>
>
> On Thu, May 17, 2018 at 7:03 PM, Yemin (Amy) <amy.yemin@huawei.com> wrote:
>
> Hi Radia,
>
>
>
> We just updated the draft, https://datatracker.ietf.org/
> doc/draft-ietf-ccamp-microwave-framework/.
>
> Your comments are addressed in the latest version.
>
>
>
> BR,
>
> Amy
>
> *From:* Yemin (Amy)
> *Sent:* Thursday, May 10, 2018 4:07 PM
> *To:* 'Daniele Ceccarelli' <daniele.ceccarelli@ericsson.com>; Radia
> Perlman <radiaperlman@gmail.com>; draft-ietf-ccamp-microwave-
> framework.all@tools.ietf.org; The IESG <iesg@ietf.org>; secdir@ietf.org
> *Subject:* RE: Secdir review of draft-ietf-ccamp-microwave-framework-05
>
>
>
> Hi Radia,
>
>
>
> Thanks for your review.
>
>
>
> Regarding the NMS and SDN, as Daniele suggested, we will add the following
> text in section 3:
>
> “It's noted that there's idea that the NMS and SDN are evolving towards a
> component, and the distinction between them is quite vague. Another fact is
> that there is still plenty of networks where NMS is still considered as the
> implementation of the management plane, while SDN is considered as the
> centralization of the control plane. They are still kept as separate
> component.”
>
>
>
> Regarding the security considerations, yes, this draft doesn’t specify the
> parameters.
>
> There’s another draft draft-ietf-ccamp-mw-yang, where the security
> consideration is addressed as you suggested.
>
>
>
> BR,
>
> Amy
>
> *From:* Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com
> <daniele.ceccarelli@ericsson.com>]
> *Sent:* Monday, May 07, 2018 5:46 PM
> *To:* Radia Perlman <radiaperlman@gmail.com>; draft-ietf-ccamp-microwave-
> framework.all@tools.ietf.org; The IESG <iesg@ietf.org>; secdir@ietf.org
> *Subject:* RE: Secdir review of draft-ietf-ccamp-microwave-framework-05
>
>
>
> Hi Radia,
>
>
>
> let me reply on behalf of the authors. First of all many thanks for your
> review.
>
>
>
> Regarding your question about traditional NMS vs SDN I agree with you on
> the fact that they are evolving towards a common component and the
> distinction is quite blurry, but there is still plenty of networks where
> NMS is still considered as the implementation of the management plane while
> SDN the centralization of the control plane and they are still kept as
> separate things.
>
>
>
> Hence, since the authors speak about “traditional” NMS and SDN I would
> tend to allow for the distinction to be kept. If you prefer a note speaking
> about the convergence of the two things can be added.
>
>
>
> Thanks a lot
>
> Daniele  (ccamp co-chair)
>
>
>
> *From:* Radia Perlman [mailto:radiaperlman@gmail.com
> <radiaperlman@gmail.com>]
> *Sent:* lunedì 7 maggio 2018 08:55
> *To:* draft-ietf-ccamp-microwave-framework.all@tools.ietf.org; The IESG <
> iesg@ietf.org>; secdir@ietf.org
> *Subject:* Secdir review of draft-ietf-ccamp-microwave-framework-05
>
>
>
> Sorry...resending because I mistyped the author address.
>
>
>
>
>
> ---------- Forwarded message ----------
> From: *Radia Perlman* <radiaperlman@gmail.com>
> Date: Sun, May 6, 2018 at 11:48 PM
> Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05
> To: draft-ietf-ccamp-microwave-framework-05.all@tools.ietf.org, The IESG <
> iesg@ietf.org>, secdir@ietf.org
>
> Summary:  No security issues found, but I do have questions, and there are
> editing glitches
>
>
>
> 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 describes the management interface for microwave radio links.
>
> It advocates (correctly, I believe) that such an interface should be
> extensible to provide for vendor-specific features.
>
>
>
> I don't understand the difference between a "a traditional network
> management system" and SDN.  Perhaps it is not the job of this document to
> clearly make the distinction, and I suspect there is no real
> distinction...setting parameters (traditional network management) is a way
> of "programming" an interface ("SDN").
>
>
>
> This document could use an editing pass for glitches, but these glitches
> do not impact its readability.
>
>
>
> The glitches consist  mostly of leaving out little words like "of" in the
> following sentence.
>
> "The adoption of an SDN framework for management and
>
>    control the microwave interface is one of the key applications for
>
>    this work."
>
>
>
> The security considerations say that they assume a secure transport layer
> (authenticated, probably encryption isn't necessary) for communication.
> Other than that, perhaps, there might be security considerations for
> inadvertently setting parameters incorrectly, or maliciously by a trusted
> administrator.  But this document does not specify the specific parameters
> to be managed, just a general framework.
>
>
>
> Radia
>
>
>
>
>
>
>