|
Hi Susan, Thank you very much for carefully consolidating all the comments and reviews. Version-18 has been submitted to address your comments.
A diff is at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-teas-ietf-network-slice-nbi-yang-18 And please see the responses inline. Thanks, Bo -----Original Message----- Reviewer: Susan Hares Review result: Has Nits Hello, I have been selected to do a routing directorate Last Call review of this draft. Version:draft-ietf-teas-ietf-network-slice-nbi-yang-17.txt. Status: Proposed Standard Summary: Ready with editorial nits. I agree with Ines who stated "the document is comprehensive and includes good examples, particularly in the appendices." The authors should be commended for a clearly written document on this topic. As part of the review, I reviewed the Early Reviews from RTG-DIR, Yang-DIR, SEC-DIR, TSV-ART, and GEN-DIR. I will highlight comments in each of these reviews that I agree with. These comments on reviews are to highlight
my view of other reviews as a service for the RTG-AD (Jim Guichard). The key one of the previous reviews for authors to consider is the GEN-ART review. After my comments on these reviews, I provide my editorial nits on -17. All of my editorial NITS refer to English language usage (see below). A big thanks to the authors for their hard work on this important draft. Sue Hares =========== Earlier RTG-DIR review Reviewer: Alvaro Retana Review Date: May 6, 2024 version: draft-ietf-teas-ietf-network-slice-nbi-yang-12 Sue Hares comment: I note Alvaro requested RFC5481 as normative, but I do not see a follow-up in the email. https://mailarchive.ietf.org/arch/msg/teas/2oK0a67X1xSWAzmMQwCUJiAODRA/
Perhaps the authors decided it should not be normative. [Bo Wu] After some investigation on https://datatracker.ietf.org/doc/html/rfc8407#section-3.9, the authors think that RFC 5481 does not need to be treated as normative,
even though the YANG model references this RFC. ------- Yang-Doctor review: Reviewer: Ladislav Lhotka Intended Status: Standards track Status: Ready with Nits Comment: Lada commented on clarity of names. Sue's comment: I did not find the names to be unclear. [Bo Wu] In rev-17, we have incorporated Lada's feedback and confirmed with him on the changes. ------- SEC-DIR review: Reviewer: Mike Ounsworth Version reviewed: draft-ietf-teas-ietf-network-slice-nbi-yang-17.txt. Summary: Ready to publish Comment: Mike felt the security consideration section was sufficient based on: 1) a secure transport protocol for NM, and 2) the authors indicating which portions of the yang model provide information that could have privacy concerns. Sue's comment: I find no other security concerns. [Bo Wu] Thanks. --------------- TSV-ART review Reviewer:Kyle Rose Version reviewed: draft-ietf-teas-ietf-network-slice-nbi-yang-17.txt. Kyle's Comments: Kyle asks two key questions: 1) Should the Appendix Examples be validated? 2) Should this yang model be on a wiki - to have it updated? Sue's Comment: On 1) The appendix examples are helpful for understanding the model. My understanding is that putting the examples in the appendix makes them non-normative. As non-normative examples, the authors are able to give examples that have not been deployed. If the authors wish to note whether
the examples have been tested, it might be useful. [Bo Wu] Yes, we have tested the examples. And the updated YANG examples in the new version have been validated using yanglint. On 2) Having worked a while with Yang models and Open-Config, I agree with the publication and posting of this model to the Yang model repository. [Bo Wu] Yes. The draft has requested to registered the YANG model in IETF YANG Module Names registry, and the model can be accessed through the IETF YANG catalog after publication. ------------ GEN-ART Review Reviewer: Ines Robles version: draft-ietf-teas-ietf-network-slice-nbi-yang-17.txt. Commennt: Ines brings up five points: 1- Section 4: What does "dynamic network slice" management? 2- Section 5.2.3: The draft defines precedence rules for SLO/SLE policies. It would be helpful to explain what happens if policies conflict or are ambiguous. 3 -Section 5.2.6: In "compute-only" mode, the document mentions feasibility checks. It would be helpful to describe what happens if the checks fail. 4- (Section 5.2.6) Does the YANG model support compute-only mode in multi-domain setups, and if so, are there any constraints or limitations that need to be addressed? 5- How does the model scale with an increasing number of slices or handle frequent modifications to existing slices? It would be helpful to include a sentence addressing this. Sue's comment: It would be good for the authors to address these points. My reading of section 5.2.6 for questions 3 and 4, indicates that a) the review comes back in the status b) It is unclear how multiple domain set-ups provide "compute-only" feedback for portions of the model. [Bo Wu] Thanks for the suggestion. We have updated Section 5.2.6, "Network Slice Service Compute," to provide further clarification on the failure process and the constrains for
multiple domain computation. Please let us know if this is clear:
https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-18#section-5.2.6 ============ My editorial NITS section 5.2.1 paragraph "**attachment-circuits". Old text:/ * "attachment-circuits": Specifies the list of ACs by which the service traffic is received. This is an optional SDP attribute. When an SDP has multiple ACs and some AC specific attributes are needed, each "attachment-circuit" can specify attributes, such as interface specific IP addresses, service MTU, etc./ Text to fix: old text: /interface specific IP addresses, service MTU, etc./ New text: /interface specific IP addresses, service MTU, and other attributes./ [Bo Wu] Thank you for catching this error. Fixed. 2) Section 5.2.2, connectivity-type paragraph Old text:/ * "connectivity-type": Indicates the type of the connection group, extending "vpn-common:vpn-topology" specified [RFC9181] with the NS connectivity type, e.g., P2P and P2MP./ Text to fix:/ NS connectivity type, e.g., P2P and P2MP./ New text:/ NS connectivity type, e.g., P2P or P2MP./ [Bo Wu] Fixed. 3) Section 6, Model, identity service Current text:/ identity service { base service-tag-type; description "The Network Slice Service tag type, which can indicate the technical constraints used during service realization, for example, Layer 2 or Layer 3 technologies."; }/ Fix: / technical constraints used during service realization, for example, Layer 2 or Layer 3 technologies.";/ New: /technical constraints used during service realization (for example - Layer 2 or Layer 3 technologies)."; [Bo Wu] Fixed. 4) Section 6 model, traffic-isolation old text:/ identity traffic-isolation { base service-isolation-type; description "Specify the requirement for separating the traffic of the customer's Network Slice Service from other services, which may be provided by the service provider using VPN technologies, such as L3VPN, L2VPN, EVPN, etc."; } / Fix text: / technologies, such as L3VPN, L2VPN, EVPN, etc.";/ new text: / technologies, such as L3VPN, L2VPN, EVPN, or others.";/ [Bo Wu] Fixed. 5. Section 6, leaf availability. old text:/ leaf availability { type identityref { base availability-type; } description "Service availability level"; }/ fix text:/"Service availability level";/ new text:/Service availability level.";/ [Bo Wu] Thanks for identifying this issue. Fixed. note: My understanding is that the Yang models require a period. If not, yhou can skip this editorial check. 6. Model 6, container protocols Old text:/ container protocols { description "Serves as an augmentation target. Protocols can be augmented into this container, e.g., BGP, static routing."; } / text to fix: /e.g., BGP, static routing.";/ New text: / e.g., BGP or static routing.";/ [Bo Wu] Thanks again. Fixed. Best regards, Bo |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
