Note: This ballot was opened for revision 05 and is now closed.
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.
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.
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.)
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"
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.
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..." ^^
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"
I agree with Mirja and others that I don't see the need for this to be published in a stand-alone RFC, but I won't stand in the way of its publication. Ben listed most of the nits that I saw. I also think the last paragraph of Section 6.3 is superfluous and need not be included in the archival version.