A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters
draft-ietf-ccamp-microwave-framework-07

Thank you for a well written and understandable document.
Please also see Tianran Zhou's OpDir review at: https://datatracker.ietf.org/doc/review-ietf-ccamp-microwave-framework-05-opsdir-lc-zhou-2018-04-20/

I have some nits to help improve readability further -- the HTML / rich version is here: https://mozphab-ietf.devsvcdev.mozaws.net/D3500 

draft-ietf-ccamp-microwave-framework.txt:125
   "multiple gigabits in traditional frequency bands and beyond 10
   gigabits in higher frequency bands with more band width."
band width vs bandwidth


draft-ietf-ccamp-microwave-framework.txt:153
  " there are advantages if radio link interfaces can be modeled and be
   managed using the same structure and the same approach, "
Readability: I'd suggest "can be modeled and managed using..."


draft-ietf-ccamp-microwave-framework.txt:314
  " solution is network management system(NMS), while an emerging one is
   SDN.  "
is *a* network management system (NMS)


draft-ietf-ccamp-microwave-framework.txt:342
  " If nodes from different vendors shall be managed by the same SDN
   controller via a node management interface (north bound interface,"
I think that this would be better as:
"If nodes from different vendors will be managed by the same"
or "If nodes from different vendors are to be managed by the same"

I appreciate all the work that went into creating this requirements document.

I agree with the several other comments regarding the archival value of this
document. Generally, I don't object to the publication of support documents
that were established by a working group charter prior to the publication of
https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html
or those that were explicitly discussed as part of a chartering/rechartering.
I cannot find mention of a framework and/or requirements document for and
millimeter wave interfaces in the CCAMP charter. I concur with the suggestions
to use some other means (e.g., a wiki) to provide easy access to this
information while the corresponding YANG work is performed.

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

Abstract:

Please expand the acronym "ETH".

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

§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.

Nit: "...there's an idea..."
                 ^^

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"?

- 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.

§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.

§3.2:
- 4th paragraph: s/potential/potentially
- 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?

§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.

§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.)

§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?

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

§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.

§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".
The antecedent of "It" is unclear in the second sentence.

§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

- " To ensure better interoperability, it is better to
   focus on DM directly."
That sentence needs to be contextualized. It's not globally true.

- paragraph starting with "[RFC8343] describes..." Please clarify whether the mentioned models are IMs or DMs.

-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?

§9.2: At least [I-D.ietf-ccamp-mw-yang] should be normative.

I have a similar sentiment to Mirja, in that this document seems to
be describing the result of WG deliberations and the conclusions
that have been reached as to the path for future work.  As such,
it's unclear that there is lasting technical value to the Internet
Community from publication as an RFC (as opposed to remaining as a
WG-internal document until the publication of the associated
follow-up work).  That said, I am not making this a blocking
objection.

I'm happy to see the secdir thread coming to a conclusion about SDN
vs. NMS -- thanks for working to clear that up.

Otherwise, I just have some grammatical/style nits that I noted
while reading.

Is there any need to disambiguate "Wireless carrier" (i.e., a type of
company) vs. "carrier frequency"?  (I could certainly see an
argument for "no", given the target audience.)

Sections 1 and 2 differ about the lower bound for "microwave radio"
spectrum (1GHz vs. 1.4 GHz).

Section 2

   [...] Using multi-carrier systems operating in frequency bands
   with wider channels, the technology will be capable of providing
   capacities up 100 Gbps.

nit: "capacities of up to"

Section 3.2

   [...] Hence, an
   open and standardized node management interface are required in a
   multi-vendor environment.  Such standardized interface enables a
   unified management and configuration of nodes from different vendors
   by a common set of applications.

nit: singular/plural disagreement between "an" and "are"; also
between "such" (vs. "such a") and "interface enables" (vs.
"interfaces enable")

   On top of SDN applications to configure, manage and control the nodes
   and their associated transport interfaces including the L2 Ethernet
   and L3 IP interfaces as well as the radio interfaces, there are also
   a large variety of other more advanced SDN applications that can be
   exploited and/or developed.

FYI, the word "exploited" has connotations (in some circles) of a
malicious hack, i.e., that such an application has vulnerabilities
that are exploited for nefarious purposes.  (So far as I know,
"utilized" does not.)

The subsections in Section 4 read, stylistically, as if they are
bullet points under the heading of "use cases".  I wonder if there
would be benefit from adding some generic text about "This use
case involves ..." to them.

nit: In Section 6.1, "data plane technology specific" is used (multiple
times) as a compound adjective, which requires some hyphenation.  (I
believe different style guides have conflicting recommendations, but
at least a hyphen in "technology-specific" is generally accepted.)

Hello,

this document is well written and very clear. Thank you. 

In Section 1.1 you write:
   This document does not define any protocol extension, hence only
   [RFC2119] [RFC8174] can be considered as a normative reference.
   However, the list of normative references includes a number of
   documents that can be useful for a better understanding of the
   context.
I would then suggest to keep only these two refs as Normative ones and move all the other as Informative, the purpose of which is just to list documents "that can be useful for a better understanding of the context"

This document is well-written and it is absolutly clear that the authors did a very good job in identifying requirements and gaps, as such I think writing this document has for sure been useful for the progress of this work in the IETF! However, I think most of the information in this doc (if needed to be achieved at all) could have been added to an appendix of the actually Microwave Radio Link YANG Data Model that is to come, rather then publishing it as a stand-alone document.

Just to follow up, Deborah explained the answer to my question in private e-mail - so, no action needed from anyone else. 

Previous ballot comment:

I had a similar question to Mirja's - I wondered what the relationship between this draft and draft-ietf-teas-actn-framework might be. 

I'm not saying there should be a relationship, only that I wondered, and if there is a relationship, readers might benefit from understanding it.