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

From: Radia Perlman <[email-masked]>
Date: Sun, 6 May 2018 23:54:38 -0700

Sorry...resending because I mistyped the author address.

---------- Forwarded message ----------
From: Radia Perlman <[email-masked]>
Date: Sun, May 6, 2018 at 11:48 PM
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05
To: [email-masked], The IESG <
[email-masked]>, [email-masked]

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 7 May 2018 09:45:58 +0000

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:[email-masked]]
Sent: lunedì 7 maggio 2018 08:55
To: [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05

---------- Forwarded message ----------
From: Radia Perlman <[email-masked]<mailto:[email-masked]>>
Date: Sun, May 6, 2018 at 11:48 PM
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05
To: [email-masked]<mailto:[email-masked]>, The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>

Summary:  No security issues found, but I do have questions, and there are editing glitches

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

---

From: "Yemin (Amy)" <[email-masked]>
Date: Thu, 10 May 2018 08:07:29 +0000

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:[email-masked]]
Sent: Monday, May 07, 2018 5:46 PM
To: Radia Perlman <[email-masked]>; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: RE: Secdir review of draft-ietf-ccamp-microwave-framework-05

Hi Radia,

Thanks a lot
Daniele  (ccamp co-chair)

From: Radia Perlman [mailto:[email-masked]]
Sent: lunedì 7 maggio 2018 08:55
To: [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05

---------- Forwarded message ----------
From: Radia Perlman <[email-masked]<mailto:[email-masked]>>
Date: Sun, May 6, 2018 at 11:48 PM
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05
To: [email-masked]<mailto:[email-masked]>, The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Summary:  No security issues found, but I do have questions, and there are editing glitches

Radia

---

From: "Yemin (Amy)" <[email-masked]>
Date: Fri, 18 May 2018 02:03:16 +0000

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' <[email-masked]>; Radia Perlman <[email-masked]>; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: RE: Secdir review of draft-ietf-ccamp-microwave-framework-05

Hi Radia,

Thanks for your review.

BR,
Amy
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Monday, May 07, 2018 5:46 PM
To: Radia Perlman <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Secdir review of draft-ietf-ccamp-microwave-framework-05

Hi Radia,

Thanks a lot
Daniele  (ccamp co-chair)

---------- Forwarded message ----------
From: Radia Perlman <[email-masked]<mailto:[email-masked]>>
Date: Sun, May 6, 2018 at 11:48 PM
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05
To: [email-masked]<mailto:[email-masked]>, The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Summary:  No security issues found, but I do have questions, and there are editing glitches

Radia

---

From: Radia Perlman <[email-masked]>
Date: Thu, 17 May 2018 21:29:53 -0700

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) <[email-masked]> wrote:

> Hi Radia,
>
>
>
> We just updated the draft, https://datatracker.ietf.org/
> doc/draft-ietf-ccamp-microwave-framework/.
>
> *From:* Yemin (Amy)
> *Sent:* Thursday, May 10, 2018 4:07 PM
> *To:* 'Daniele Ceccarelli' <[email-masked]>; Radia
> Perlman <[email-masked]>; draft-ietf-ccamp-microwave-
> [email-masked]; The IESG <[email-masked]>; [email-masked]
> *Subject:* RE: Secdir review of draft-ietf-ccamp-microwave-framework-05
>
>
>
> Hi Radia,
>
>
>
> Thanks for your review.
>
>
>
> “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.”
>
>
>
> There’s another draft draft-ietf-ccamp-mw-yang, where the security
> consideration is addressed as you suggested.
>
>
>
> BR,
>
> Amy
>
> *From:* Daniele Ceccarelli [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, May 07, 2018 5:46 PM
> *To:* Radia Perlman <[email-masked]>; draft-ietf-ccamp-microwave-
> [email-masked]; The IESG <[email-masked]>; [email-masked]
> *Subject:* RE: Secdir review of draft-ietf-ccamp-microwave-framework-05
>
>
>
> Hi Radia,
>
>
>
> 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:[email-masked]
> <[email-masked]>]
> *Sent:* lunedì 7 maggio 2018 08:55
> *To:* [email-masked]; The IESG <
> [email-masked]>; [email-masked]
> *Subject:* Secdir review of draft-ietf-ccamp-microwave-framework-05
>
>
>
> From: *Radia Perlman* <[email-masked]>

---

From: "Yemin (Amy)" <[email-masked]>
Date: Fri, 18 May 2018 06:12:22 +0000

"evolving toward a component" is to say that one single software (the component) has the functionality of both NMS and SDN.
If you think it’s not clear enough, we could replace with what you suggested.

Amy
From: Radia Perlman [mailto:[email-masked]]
Sent: Friday, May 18, 2018 12:30 PM
To: Yemin (Amy) <[email-masked]>
Cc: Daniele Ceccarelli <[email-masked]>; [email-masked]; The IESG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Secdir review of draft-ietf-ccamp-microwave-framework-05

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Radia,

BR,
Amy
From: Yemin (Amy)
Sent: Thursday, May 10, 2018 4:07 PM
To: 'Daniele Ceccarelli' <[email-masked]<mailto:[email-masked]>>; Radia Perlman <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Secdir review of draft-ietf-ccamp-microwave-framework-05

Hi Radia,

Thanks for your review.

BR,
Amy

Hi Radia,

Thanks a lot
Daniele  (ccamp co-chair)

---------- Forwarded message ----------
From: Radia Perlman <[email-masked]<mailto:[email-masked]>>
Date: Sun, May 6, 2018 at 11:48 PM
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05
To: [email-masked]<mailto:[email-masked]>, The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Summary:  No security issues found, but I do have questions, and there are editing glitches

Radia

---

From: Eric Gray <[email-masked]>
Date: Fri, 18 May 2018 20:27:34 +0000

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:[email-masked]] On Behalf Of Radia Perlman
Sent: Friday, May 18, 2018 12:30 AM
To: Yemin (Amy) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Secdir review of draft-ietf-ccamp-microwave-framework-05

Radia

BR,
Amy
From: Yemin (Amy)

Hi Radia,

Thanks for your review.

BR,
Amy

Hi Radia,

Thanks a lot
Daniele  (ccamp co-chair)

---------- Forwarded message ----------
From: Radia Perlman <[email-masked]<mailto:[email-masked]>>
Date: Sun, May 6, 2018 at 11:48 PM
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05
To: [email-masked]<mailto:[email-masked]>, The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Summary:  No security issues found, but I do have questions, and there are editing glitches

Radia

---

From: Radia Perlman <[email-masked]>
Date: Sat, 19 May 2018 20:34:37 -0700

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"

 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 <[email-masked]> 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:[email-masked]] *On Behalf Of *Radia Perlman
> *Sent:* Friday, May 18, 2018 12:30 AM
> *To:* Yemin (Amy) <[email-masked]>
> *Cc:* The IESG <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [CCAMP] Secdir review of draft-ietf-ccamp-microwave-
> framework-05
>
>
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Sun, 20 May 2018 20:25:37 +0000

Hi,

A bit late jumping in, but I was involved in a meeting and travelling to/from Europe.

There’s several RFCs providing a distinction on SDN and traditional NMS (Eric, we’ll have a bar chat on that😊). Here, I’d suggest an informative reference to RFC 7426 “SDN: Layers and Architecture Terminology”. For those wanting clarification on “one” component, check out Section 4’s advocated evolution direction.

Here in this microwave draft, the question is not how many interfaces or if components are one or two physically/functionally, but to address why there is interest in doing this work (to support multi-vendor (SDN NBI) environments vs. traditional one vendor using intermediate (proprietary) systems) and what is needed for management and control so as to identify a standard YANG model. These couple of sentences want to say this draft does not want to preclude implementations which still use the more traditional two interface approach (control, management) or a single entity doing the functionality over “one” interface.

I’d suggest on v06:
Software Defined Networking (SDN)
Section 2 (Definitions):
SDN… SDN can be used as a term for automation of traditional network management, which can be implemented using a similar approach.
/s/
SDN can be used for automation of traditional network management functionality using an SDN approach of standardized programmable interfaces for control and management [RFC7426].

Section 3:
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.  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 components.
/s/
SDN solutions with standardized interfaces can be used as part of the network management system.  As noted in [RFC7426], with the adoption of open and standardized interfaces, the partition of functionality and distinctions between an NMS controller and SDN controller are becoming less clear, and for some applications, have evolved to one controller/one interface.  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.

Hopefully this improves-
Thanks everyone for the comments/careful reading-
Deborah

From: CCAMP <[email-masked]> On Behalf Of Radia Perlman
Sent: Saturday, May 19, 2018 11:35 PM
To: Eric Gray <[email-masked]>
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] Secdir review of draft-ietf-ccamp-microwave-framework-05

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Radia.

--
Eric

From: CCAMP [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Radia Perlman
Sent: Friday, May 18, 2018 12:30 AM
To: Yemin (Amy) <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] Secdir review of draft-ietf-ccamp-microwave-framework-05

Radia

We just updated the draft, https://datatracker.ietf.org/doc/draft-ietf-ccamp-microwave-framework/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dccamp-2Dmicrowave-2Dframework_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=ZiUlWcJJ7Jqw2xxWyLHtyGaU2VIcOx9u6dyCoF4xdCo&s=GyHaqRUQk1DPFfttXa6FXUpNDB4rOnRXtk2p8mmvtog&e=>.
Your comments are addressed in the latest version.

BR,
Amy
From: Yemin (Amy)

Hi Radia,

Thanks for your review..

BR,
Amy

Hi Radia,

Thanks a lot
Daniele  (ccamp co-chair)

From: Radia Perlman [mailto:[email-masked]]
Sent: lunedì 7 maggio 2018 08:55
To: [email-masked]<mailto:draft-ietf-ccamp-microwave-framework.all@tools..ietf.org>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05

---------- Forwarded message ----------
From: Radia Perlman <[email-masked]<mailto:[email-masked]>>
Date: Sun, May 6, 2018 at 11:48 PM
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05
To: [email-masked]<mailto:[email-masked]>, The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Summary:  No security issues found, but I do have questions, and there are editing glitches

Radia

---

From: Eric Gray <[email-masked]>
Date: Mon, 21 May 2018 18:57:09 +0000

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

Cc: Yemin (Amy) <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Importance: High

Hi Eric,

Radia

--
Eric

Radia

BR,
Amy
From: Yemin (Amy)

Hi Radia,

Thanks for your review.

BR,
Amy

Hi Radia,

Thanks a lot
Daniele  (ccamp co-chair)

---------- Forwarded message ----------
From: Radia Perlman <[email-masked]<mailto:[email-masked]>>
Date: Sun, May 6, 2018 at 11:48 PM
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05
To: [email-masked]<mailto:[email-masked]>, The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Summary:  No security issues found, but I do have questions, and there are editing glitches

Radia

---

From: "Yemin (Amy)" <[email-masked]>
Date: Tue, 22 May 2018 02:51:40 +0000

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:[email-masked]]
Sent: Tuesday, May 22, 2018 2:57 AM
To: Radia Perlman <[email-masked]>
Cc: Yemin (Amy) <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Secdir review of draft-ietf-ccamp-microwave-framework-05

--
Eric

From: Radia Perlman [mailto:[email-masked]]
Sent: Saturday, May 19, 2018 11:35 PM
To: Eric Gray <[email-masked]<mailto:[email-masked]>>
Cc: Yemin (Amy) <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] Secdir review of draft-ietf-ccamp-microwave-framework-05
Importance: High

Hi Eric,

Radia

--
Eric

Radia

BR,
Amy
From: Yemin (Amy)

Hi Radia,

Thanks for your review.

BR,
Amy

Hi Radia,

Thanks a lot
Daniele  (ccamp co-chair)

---------- Forwarded message ----------
From: Radia Perlman <[email-masked]<mailto:[email-masked]>>
Date: Sun, May 6, 2018 at 11:48 PM
Subject: Secdir review of draft-ietf-ccamp-microwave-framework-05
To: [email-masked]<mailto:[email-masked]>, The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Summary:  No security issues found, but I do have questions, and there are editing glitches

Radia

---

From: Radia Perlman <[email-masked]>
Date: Tue, 22 May 2018 00:07:15 -0400

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

Radia

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

> Thanks for the discussion. Considering all the comments received, below is
> the new proposed text for this paragraph:
>
>
>
> interface for the
> *From:* Eric Gray [mailto:[email-masked]]
> *Sent:* Tuesday, May 22, 2018 2:57 AM
> *To:* Radia Perlman <[email-masked]>
> *Cc:* Yemin (Amy) <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked]; draft-ietf-ccamp-microwave-
> [email-masked]
> *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.
>
>
>
> 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
>
>
>
> *Sent:* Saturday, May 19, 2018 11:35 PM
> *To:* Eric Gray <[email-masked]>
> *Cc:* Yemin (Amy) <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked]; draft-ietf-ccamp-microwave-
> [email-masked]
> *Importance:* High
> " “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
> 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