Thanks for the clarification and for addressing my comment. The proposed change looks good to me.
Regards, Dan On Thu, Apr 27, 2023 at 2:29 AM Jensen Zhang <jingxuan.n.zh...@gmail.com> wrote: > Hi Dan, > > Thanks for your feedback. See my response inline. > > On Wed, Apr 26, 2023 at 3:25 PM Dan Romascanu <droma...@gmail.com> wrote: > >> Hi Jensen, >> >> Thank you for your email and for addressing my comments. >> >> See in-line. >> >> Regards, >> >> Dan >> >> >> >> >> On Tue, Apr 25, 2023 at 4:01 PM Jensen Zhang <jingxuan.n.zh...@gmail.com> >> wrote: >> >>> Hi Dan, >>> >>> Sorry for the delay. Many thanks for your review. Please see our >>> response inline below. >>> >>> On Fri, Apr 21, 2023 at 4:00 PM Dan Romascanu via Datatracker < >>> nore...@ietf.org> wrote: >>> >>>> Reviewer: Dan Romascanu >>>> Review result: Has Nits >>>> >>>> Ready with Nits >>>> >>>> This document defines YANG data models for Operations, Administration, >>>> and >>>> Maintenance (OAM) & Management of ALTO. The operator can use these data >>>> models >>>> to set up an ALTO server, create, update and remove ALTO information >>>> resources, >>>> manage the access control, configure server discovery, and collect >>>> statistical >>>> data. >>>> >>>> I like this document. It is clearly written and very well structured. I >>>> liked >>>> the description of requirements, the information model corresponding to >>>> the >>>> requirements, and the extension example modules in the Appendices. >>>> These are >>>> all very useful for operators who need to understand and use the YANG >>>> modules. >>>> >>>> Understanding and using this document requires a good knowledge of ALTO. >>>> >>>> My review is focused on the design and data modelling issues relevant >>>> for >>>> operations and manageability. I did not perform a YANG review, I assume >>>> that >>>> YANG Doctors review is performed separately. >>>> >>>> This document is Ready with a couple of editorial comments. >>>> >>>> Editorial & Nits: >>>> >>>> 1. There are many more acronyms not included in Section 3 or expanded >>>> at first >>>> occurrence. Maybe the respective acronyms sections in the ALTO >>>> documents should >>>> be mentioned / referred >>>> >>> >>> Thanks for pointing out this issue. We have included all the acronyms >>> that occur in the document in Sec 3. You can check the changes in our early >>> edit [1]. >>> >>> [1]: >>> https://ietf-wg-alto.github.io/draft-ietf-alto-oam-yang/draft-ietf-alto-oam-yang.html#name-acronyms-and-abbreviations >>> >>> But we are not sure if the acronyms that only occur in the YANG modules >>> should also be included. >>> >> >> I believe that the answer is yes. There is no other separate >> abbreviations section for the YANG modules. >> >> >> >>> >>> >>>> >>>> 2. In Section 5.3.1.2 >>>> >>>> > In practice, multiple ALTO servers can be deployed for scalability. >>>> That may require communication among different ALTO servers. >>>> >>>> The "ietf-alto" module does not contain any configuration for the >>>> communication between peer ALTO servers. Instead, it provides the >>>> configuration for how an ALTO server can be discovered by another >>>> ALTO server on demand (Figure 6). >>>> >>>> I understand that the communication between ALTO servers is out of >>>> scope. >>>> However, I do not understand how is the scalability requirement met. Is >>>> there / >>>> Will there be another YANG module to define this data model? Something >>>> else >>>> than YANG? Maybe this is described in another ALTO document that I did >>>> not find. >>>> >>> >>> The scalability requirement is not explicitly defined in this document. >>> It looks like a part of R1 but is not mandatory. >>> >>> And I am not quite sure what is the scalability requirement that you >>> mentioned here. There can be two kinds of scalability issues: >>> >>> 1. The scalability of a large number of network domains and elements. >>> This issue requires the deployment of multiple ALTO server instances in >>> different domains and communications among different ALTO servers in >>> different domains. WG is still discussing the related topic [2]. The >>> solution is not mature. So we consider it to be out of the scope of this >>> document. >>> >>> [2]: >>> https://mailarchive.ietf.org/arch/msg/alto/Hpay0QShfob_3LR7ERfpIjXvGI0/ >>> >>> 2. The scalability of a large number of client connections. i.e., the >>> load balance issue. This may need some autoscaling or load-balancing >>> configuration parameters. Is this what you want to add? >>> >> >> I was referring to the scalability issue mentioned in the document in the >> sentence 'In practice, multiple ALTO servers can be deployed for >> scalability.'. This seems to be related to issue #1 in your answer. If the >> solution is considered not mature at this stage, maybe you should mention >> just that in the document, to explain why it is out of scope. >> > > Thanks for your clarification. I think the "scalability" in the original > text may be ambiguous. We made the following change: > > OLD: > > In practice, multiple ALTO servers can be deployed for scalability. > That may require communication among different ALTO servers. > > The "ietf-alto" module does not contain any configuration for the > communication between peer ALTO servers. Instead, it provides the > configuration for how an ALTO server can be discovered by another > ALTO server on demand (Figure 6). > > NEW: > > In practice, for a large-scale network consisting of multiple > administrative domains, the information about the network may be > partitioned and distributed over multiple ALTO servers. That may > require discovery and communication among different ALTO servers. > > The "ietf-alto" module provides the configuration for how an ALTO > server can be discovered by another ALTO server or client on demand > (Figure 6). But it does not contain any configuration for the > communication among ALTO servers because the related solution has not > become a standard. Future documents may extend it to fully support > multi-domain scenarios. > > Does the changed text address your concern? > > Thanks, > Jensen > >>
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
