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

[Radia Perlman <[e-mail]>]

Amy...I think your proposed text is excellent.

Radia

On Mon, May 21, 2018 at 10:51 PM, Yemin (Amy) <[e-mail]> wrote:

> Hi Eric, Radia, and Deborah,
>
>
>
> Thanks for the discussion. Considering all the comments received, below is
> the new proposed text for this paragraph:
>
>
>
>    This framework addresses the definition of an open and standardized
> interface for the
>
>    radio link functionality in a microwave node.  The application of such
> an interface used
>
>    for management and control of nodes and networks typically vary from
> one operator
>
>    to another, in terms of the systems used and how they interact.
> Possible approaches
>
>    include via the use of a network management system (NMS), via software
> defined
>
>    networking (SDN) and via some combination of NMS and SDN. As there are
> still many
>
>    networks where the NMS is implemented as one component/interface and
> the SDN
>
>    controller is scoped to control plane functionality as a separate
> component/interface,
>
>    this document does not preclude either model. The aim of this document
> is to provide a
>
>    framework describing both management and control of microwave
> interfaces to support
>
>    development of a common YANG Data Model.
>
>
>
> Please check if the text is ok.
>
> Thanks.
>
>
>
> BR,
>
> Amy
>
> *From:* Eric Gray [mailto:[e-mail]]
> *Sent:* Tuesday, May 22, 2018 2:57 AM
> *To:* Radia Perlman <[e-mail]>
> *Cc:* Yemin (Amy) <[e-mail]>; The IESG <[e-mail]>;
> [e-mail]; [e-mail]; draft-ietf-ccamp-microwave-
> [e-mail]
> *Subject:* RE: [CCAMP] Secdir review of draft-ietf-ccamp-microwave-
> framework-05
>
>
>
> So, one could read this as saying that some people view network management
> (e.g. – use of an NMS) and centralized network control (e.g. – SDN) as
> being somehow at least marginally distinct, yet becoming increasingly less
> so.  Other people view them as completely disjoint, perhaps having a
> preference, and would like them to continue being considered completely
> separate and distinct concepts.
>
>
>
> While I think it is probably fair to say that this is very likely true,
> this has all the ear marks of being a rat hole, and I cannot imagine what
> value the proposed text adds to the draft.
>
>
>
> As I understand it, the intent was to clarify something to do with the
> following text:
>
>
>
>
>
>    This framework addresses the definition of an open and standardized
>
>    interface for the radio link functionality in a microwave node.  The
>
>    application of such an interface used for management and control of
>
>    nodes and networks typically vary from one operator to another, in
>
>    terms of the systems used and how they interact.  A traditional
>
>    solution is network management system, while an emerging one is SDN.
>
>    SDN solutions can be used as part of the network management system,
>
>    allowing for direct network programmability and automated
>
>    configurability by means of a centralized SDN control and
>
>    standardized interfaces to program the nodes.
>
>
>
> Your comment was that the distinction is not clear.  That is a fair
> point.  And it is probably not addressed by the proposal.
>
>
>
> I would further add that using emotionally freighted expressions
> (“classic”/”legacy”/”traditional” verses “innovative”/”novel”/”emerging”)
> doesn’t help and really isn’t appropriate in specification.
>
>
>
> I suspect that the reason for claiming a distinction exists (however
> difficult it may be to characterize that distinction) is in the part of the
> above text having to do with operator preferences.  These definitely do
> exist.  😊
>
>
>
> Perhaps a good way to address the issue is to replace the last two
> sentences in the text above with something along the lines of:
>
>
>
>     “Possible approaches include via the use of a network management
> system (NMS), via software defined networking (SDN) and via some
> combination of NMS and SDN.”
>
>
>
> Note that “automated configurability” is * not* a new concept in
> configuration of network devices, unique to SDN, hence the last part of the
> final sentence (starting with “allowing for …”) adds no value and should be
> left out.
>
>
>
> --
>
> Eric
>
>
>
> *From:* Radia Perlman [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Saturday, May 19, 2018 11:35 PM
> *To:* Eric Gray <[e-mail]>
> *Cc:* Yemin (Amy) <[e-mail]>; The IESG <[e-mail]>;
> [e-mail]; [e-mail]; draft-ietf-ccamp-microwave-
> [e-mail]
> *Subject:* Re: [CCAMP] Secdir review of draft-ietf-ccamp-microwave-
> framework-05
> *Importance:* High
>
>
>
> 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 <[e-mail]> 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:[e-mail]] *On Behalf Of *Radia Perlman
> *Sent:* Friday, May 18, 2018 12:30 AM
> *To:* Yemin (Amy) <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> *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) <[e-mail]> 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' <[e-mail]>; Radia
> Perlman <[e-mail]>; draft-ietf-ccamp-microwave-
> [e-mail]; The IESG <[e-mail]>; [e-mail]
> *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:[e-mail]
> <[e-mail]>]
> *Sent:* Monday, May 07, 2018 5:46 PM
> *To:* Radia Perlman <[e-mail]>; draft-ietf-ccamp-microwave-
> [e-mail]; The IESG <[e-mail]>; [e-mail]
> *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:[e-mail]
> <[e-mail]>]
> *Sent:* lunedì 7 maggio 2018 08:55
> *To:* [e-mail]; The IESG <
> [e-mail]>; [e-mail]
> *Subject:* Secdir review of draft-ietf-ccamp-microwave-framework-05
>
>
>
> Sorry...resending because I mistyped the author address.
>
>
>
>
>
> ---------- Forwarded message ----------
> From: *Radia Perlman* <[e-mail]>
> Date: Sun, May 6, 2018 at 11:48 PM
> Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05
> To: [e-mail], The IESG <
> [e-mail]>, [e-mail]
>
> 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
>
>
>
>
>
>
>
>
>