|
Hi Tianran, We just updated the draft, https://datatracker.ietf.org/doc/draft-ietf-ccamp-microwave-framework/.
Your comments are addressed in the latest version. You can find the detail changes to your comments inline below.
BR, Amy -----Original Message----- Hi Tianran, Thank you for reviewing the microwave framework document. We will address your comments in the next revision of the document. Regards JonasA -----Original Message----- From: Tianran Zhou [mailto:zhoutianran@xxxxxxxxxx]
Sent: den 21 april 2018 06:58 To: ops-dir@xxxxxxxx Cc:
draft-ietf-ccamp-microwave-framework.all@xxxxxxxx;
ccamp@xxxxxxxx;
ietf@xxxxxxxx Subject: Opsdir last call review of draft-ietf-ccamp-microwave-framework-05 Reviewer: Tianran Zhou Review result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the
IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-ccamp-microwave-framework-05 Intended Status: Informational Summary: In general, this document is clear to me. I did not see any special operational or network management related issue. But there are several minor issues, for the authors consideration. Minor issues: 1. The last sentence in the abstract confused me. "Some parts of the resulting model may be generic which could also be used by other technologies." Both "some parts" and "other technologies" are not clear, which makes this words meaningless. At least, you may say what kind of technologies
may reuse this model. [Amy] The current text is " Some parts of the resulting model may be generic which could also be used by other technologies, e.g., ETH technology." 2. Both "packet interfaces" and "packet functionality" are not clear to me. Those terminologies appear many times in the draft. I am not familiar with transport network, not sure if those terminologies are commonly used. I think it's better to say "packet transport (link) interface" or so, compared to "radio
link interface". [Amy] We have went through the text, replace the packet with L2(ETH) or L3(IP) accordingly.
3. There are two solutions, "Network management solutions" and "SDN solution", under the Section 3. But: Firstly, it's hard to distinguish the network management and SDN, IMHO. Secondly, you actually did not describe the network management
solution. I think the SDN solution is the way you used in the framework. Your following use cases and modelling requirements are all based on the the so called SDN solution. So, I would suggest you do not distinguish network management solution and SDN solution.
But only to say "this is the target solution to manage and control radio link interface" in your proposed framework. [Amy] We received similar comments from Sec-dir review. We add the following text in section 3 to better explain about the NMS and SDN:
“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.” 4. You may need to update the contributors section. As far as I know, some people's contact and affiliation changed. [Amy] Done. |
