Re: [CCAMP] Ben Campbell's No Objection on draft-ietf-ccamp-microwave-framework-06: (with COMMENT)

["Yemin (Amy)" <[e-mail]>]

Hi Ben,



Thanks very much for the detail comments, and sorry for the late response.

Please see reply inline in blue.



BR,

Amy



-----Original Message-----
From: Ben Campbell [mailto:[e-mail]]
Sent: Thursday, May 24, 2018 1:56 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; Daniele Ceccarelli <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Ben Campbell's No Objection on draft-ietf-ccamp-microwave-framework-06: (with COMMENT)



Ben Campbell has entered the following ballot position for

draft-ietf-ccamp-microwave-framework-06: No Objection



When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-ccamp-microwave-framework/







----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------



I agree with other comments that this document doesn't seem to need to be an RFC. It seems like, once the YANG model is complete, the content here will no longer be needed. It would be better documented outside of the RFC series (for example, in a wiki or left as an internet-draft). I further note that this document doesn't seem to be in the WG charter, but it's entirely possible I missed something.



Otherwise, I have some mostly editorial comments. In general, I think this could use more proofreading prior to publication.



§1.1

- 2nd paragraph: This contradicts the boilerplate that says these terms are  used as defined in 8174 and 2119. I don't think using the terms in this way  adds clarity to the document. In fact, I think it reduces clarity in some  cases; e.g. the difference of SHOULD vs MUST clearly isn't as described in  2119, so it's not clear how SHOULD should be interpreted when designing the  YANG model.  For example, should SHOULD items be interpreted as "desirable but  not required"?

[Amy] Martin suggested to update the reference sections, to keep only RFC2119 and RFC8174 as Normative ones and move all the other as Informative reference. I think it's a good idea.

Then 2nd and 3rd paragraph will be removed.



- 3rd paragraph: The paragraph gives an incorrect interpretation of the meaning of "normative references" The lack of protocol definition does not suggest that there should be no normative references. I suggest simply deleting the paragraph.
[Amy] Ok, will remove it.



§3, last paragraph:

-  " 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. " I don't understand that sentence. Are there missing words? - Please consider defining the operative difference between "management" and "control" plan in the context of this discussion, especially given the previous comment that the distinction between NMS and SDN is vague.
[Amy] We had a lot discussion about this sentence/paragraph in the list. The agreed text for paragraph is as following:
   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 for development of a common YANG Data Model for both management
  and control of microwave interfaces.
.



§3.2:

- 4th paragraph: s/potential/potentially
[Amy] will fix it.



- Last paragraph: "Effort on a standardizing operation mode is required to implement a smoothly operator environment." I don't understand that sentence.

Are there missing or incorrect words?

[Amy] How about simply remove the last sentence?



§4.11 and following sections: Many of these sections start out with a sentence fragment for the use case description  That would be reasonable in a table or list of cases, but is jarring to read in paragraph form.

[Amy] Thanks for the suggestion. will change the sub-section in 4.x into list, like this:
4.1 configuration management

  *   Understand the capabilities and limitations

Text…

  *   Initial Configuration

Text…

  *   Radio link re-configuration and optimization

Text…

  *   Radio link logical configuration

Text…



§4.1.2, first paragraph: The normative "MAY" seems wrong in context. I think it's a statement of fact, not a grant of permission. (In general, I don't see how normative keywords make sense in use cases like these.)
[Amy] will change to "may".



§4.1.4: "Radio link terminals comprising a group of carriers ..."

I don't think the terminals comprise carriers per se. Perhaps they are shared by a group of carriers, or provide access for a group of carriers?

[Amy] New text “Radio link terminals configured to include a group of multiple carriers are widely used in microwave networks.”



§4.4.1: The text is convoluted. Please consider simplifying it. Active voice might help.

[Amy] new text proposal for 4.4.1:
4.4.1. Configuration of historical performance measurements
   Configuration of historical performance measurements for a radio
   link interface and/or its constituent parts. See also Section 4.1 above.



§4.5.2:

- I don't understand what "should be supported accordingly" means in context.

Please describe how they should be supported. - The last sentence seems like a non sequitur, given that the last sentence explicitly said that these items were _not_ specific to a particular radio link interface.

[Amy] new text proposal:

Alarm synchronization, visualization, handling, notifications and

events are generic use cases for a device and should also be supported on a radio

link interface. There are however radio-specific alarms that are

important to report, where signal degradation of the radio link is one example.



§6,

- "The purpose of the gap analysis is to identify and recommend what

   existing and established models as well as draft models under

   definition to support the use cases and requirements specified in the

   previous chapters. "

I don't understand the wording after "as well".

[Amy] new text proposal:
The purpose of the gap analysis is to identify and recommend what
 models to use in a microwave device to support the use cases and requirements
specified in the previous chapters.


The antecedent of "It" is unclear in the second sentence.
[Amy] New text “This draft shall also make …”





§6.1: Please proofread this section for missing articles and ambiguous pronoun antecedents. "IM is to model managed objects at a conceptual

   level for designers and operators, DM is defined at a lower level and

   includes many details for implementers."  - comma splice
[Amy] Thanks very much for the comment, the original text is not so good for understanding.
Below is the new text for section 6.1 with editorial improvement.

  [ONF-CIM] defines a CoreModel of the ONF Common Information Model.
   An information model describes the things in a domain in terms of
   objects, their properties (represented as attributes), and their
   relationships.  The ONF information model is expressed in Unified
   Modeling Language (UML).  The ONF CoreModel is independent of
   specific data plane technology.  The technology specific content,
  acquired in a runtime solution via "filled in" cases of specification,
  augment the CoreModel to provide a forwarding technology-specific
  representation.

   IETF Data Model defines implementation and protocol-specific
   details.  YANG is a data modeling language used to model the
   configuration and state data.  [RFC8343] defines a generic YANG data model
   for interface management which doesn't include technology specific
   information. To describe the technology specific information, several
   YANG data models have been proposed in IETF by augmenting [RFC8343],
   e.g.  [RFC8344]. This is a popular approach for modeling many packet
   transport technology interfaces, and it is thereby well positioned to
   become an industry standard. In light of this trend,
   [I-D.ietf-ccamp-mw-yang] provides a YANG data model proposal for radio
   interfaces, which is well aligned with the structure of other technology-specific
   YANG data models augmenting [RFC8343].

   [RFC3444] explains the difference between Information Model (IM) and
   Data Models (DM).  IM is to model managed objects at a conceptual
   level for designers and operators, while DM is defined at a lower level and
   includes many details for implementers.  In addition, the protocol-
   specific details are usually included in DM.  Since conceptual models
   can be implemented in different ways, multiple DMs can be derived
   from a single IM.

   It is recommended to use the structure of the IETF: Radio Link
   Model [I-D.ietf-ccamp-mw-yang] as the starting point, since
   [I-D.ietf-ccamp-mw-yang] is a data model providing the wanted alignment
   with [RFC8343].  To cover the identified gaps, it is recommended to
   define new leafs/parameters in [I-D.ietf-ccamp-mw-yang] while taking
   reference from [ONF-model]. It is also recommended to add the required
   data nodes to describe the interface layering for the capacity provided
   by a radio link terminal and the associated Ethernet and TDM interfaces
   in a microwave node. The principles and data nodes for interface layering
   described in [RFC8343] should be used as a basis.



- " To ensure better interoperability, it is better to

   focus on DM directly."

That sentence needs to be contextualized. It's not globally true.
[Amy] will remove this sentence.



- paragraph starting with "[RFC8343] describes..." Please clarify whether the mentioned models are IMs or DMs.
[Amy] New text: “[RFC8343] defines a YANG data model for interface management. “
It’s current in first paragraph of section 6.1, please see above.



-7: "Security issue concerning the access control to Management interfaces

   can be generally addressed..."

Please describe what those issues are. The security consideration section should discuss protections in the context of the threats that they mitigate.

For example, what would be the consequences of violations of origin authentication, integrity protection, or confidentiality?
[Amy] Add the following text to the draft:

   The configuration information may be considered sensitive or vulnerable
   in the network environments.  Unauthorized access to configuration data nodes
   can have a negative effect on network operations, e.g., interrupting the ability
   to forward traffic, or increasing the interference level of the network. The
   status and inventory reveal some network information that could be very helpful
   to an attacker. A malicious attack to those information may result in a loss of
   customer data.



§9.2: At least [I-D.ietf-ccamp-mw-yang] should be normative.
[Amy] Please see reply to the first comment, we will keep only RFC2119 and RFC8174 as Normative ones and move all the other as Informative reference.