[alto] Review of draft-ietf-alto-oam-yang

[Qin Wu <[e-mail]>]

Hi, authors of draft-ietf-alto-oam-yang:
Thank for the update of this important work, as we know ALTO simply provides a query interface for network information exposure, however,
how ALTO system is bootstrapped, how to capture all the network information needed such as network topology information, traffic flow information, network performance information
to build and update network map, cost map, property map, this require operation automation, ALTO OAM play a key role to address this gap. Therefore, I believe we need to rethink
the model design from a holistic view. Here are a few quick comments on the latest version of this draft:
1. We get one complaint from PYANG tool. Can you fix pyang error?
"[e-mail]:585: error: RFC 8407: 4.10: top-level node alto-server must not be mandatory"
2. Section 1 said:
"
   The operator can use the data model to create and update ALTO information
   resources, manage the access control, configure server-to-server
   communication and server discovery, and collect statistical data.
"
I am thinking who will be consumer of this document, the operators such as network operator, ISP, are one of them, how about regulators, the third party entity who can also benefit from using this model to benchmark ALTO service provide by different operators.
for server to server communication, I re-read ALTO deployment RFC7971 said:
"
ALTO is inherently
   designed for use in multi-domain environments.  Most importantly,
   ALTO is designed to enable deployments in which the ALTO server and
   the ALTO client are not located within the same administrative
   domain.
"
"
   o  Multiple administrative domains: The ALTO protocol is designed for
      use cases where the ALTO server and client can be located in
      different organizations or trust domains.  ALTO assumes a loose
      coupling between server and client.  In addition, ALTO does not
      assume that an ALTO client has any a priori knowledge about the
      ALTO server and its supported features.  An ALTO server can be
      discovered automatically.
"
I think we should support the case where the ALTO server and client can be located in
different organizations or trust domains. To support this case, server to server communication is needed,
otherwise,how do you evaluate the total amount of inter-domain traffic of an ISP,how do you assess
application performance improvement by the introduction of ALTO.

3. Section 1 said:
"
Although the scope of the YANG data
   model in this document mainly focuses on the support of the base ALTO
   protocol [RFC7285] and the existing ALTO standard extensions
   (including [RFC8189], [RFC8895], [RFC8896], [RFC9240], [RFC9241], and
   {RFC9275}), the design will also be extensible for future standard
   extensions (e.g., [I-D.ietf-alto-performance-metrics]).
"
When [I-D.ietf-alto-performance-metrics] gets published as RFC, the last sentence will not hold. I suggest to change
into something else, e.g., JOSE objects carrying ALTO payloads [RFC7165]

4. Section 4.1 said:
Data model for deploy an ALTO server/client.
Do we need to support ALTO client configuration, please consider Placement of ALTO Entities in section 2.1.2 of RFC7971
do we support ALTO client embeded in app case and ALTO client embeded in resource diretory cases?

5. Section 4.1 said:
"
   This document does not define any data model related to specific
   implementation, including:

   *  Data structures for how to store/deliver ALTO information
      resources (e.g., database schema to store a network map).

   *  Data structures for how to store information collected from data
      sources. (e.g., database schema to store topology collected from
      an Interface to the Routing System (I2RS) client [RFC7921])
"
I think we need to rethink this part from the holistic view, data structures for ALTO information storing is not in the scope,
but data structures for ALTO information export or delivering is not in the scope, I am not sure about this.
See figure 1 of RFC7285, RFC7285 said:
"
   Figure 1 illustrates that the ALTO information provided by an ALTO
   server may be influenced (at the service provider's discretion) by
   other systems.  In particular, the ALTO server can aggregate
   information from multiple systems to provide an abstract and unified
   view that can be more useful to applications.  Examples of other
   systems include (but are not limited to) static network configuration
   databases, dynamic network information, routing protocols,
   provisioning policies, and interfaces to outside parties.
"
I think we should support aggregating information from various different data source or system,
we can get data from routing protocol e.g.,RFC7752 defined in IDR WG, RFC8233 defined in PCE WG,RFC8671, RFC9069 defined in GROW WG,RFC8430 defined in I2RS WG, etc
we can get flow data from IPFIX protocol RFC7011,
OAM data from OAM protocol, tools, mechanism such as OAM tool set defined in table 5 of RFC7276,
PM data from IOAM protocol[RFC9197], TWMAP [RFC5357], etc

6. Section 4.2
what is the difference between security policy management and Access control requirements?
7. Section 6.1
Do you have model snippet for ALTO-specific Performance Monitoring? Or it is still open for further design?

7.Section 5.2.1.1 ALTO Server Listen Stack
It looks alto-server-grouping aligns with draft-ietf-tcpm-yang-tcp and draft-ietf-netconf-tls-client-server,draft-ietf-netconf-tcp-client-server-13,
I am wondering why we only support ALTO Server configuration without client configuration?  draft-ietf-netconf-tls-client-server,draft-ietf-netconf-tcp-client-server-13
did support client configuration.

8.5.2.1.2.  ALTO Server Discovery Setup
Why server to server communication is mixed with ALTO Server Discovery? they are in different phase, no?

-Qin