[alto] Review for draft-ietf-alto-oam-yang-07

2023-05-19 Thread gd=40tongji . edu . cn
Dear ALTOers and authors of draft-ietf-alto-oam-yang,

Below is my review for draft-ietf-alto-oam-yang-07.

Since I'm new to ALTO, please consider my review comments as suggestions for 
reference purposes.
If you believe any of my comments are irrelevant, please feel free to ignore 
them.

Best regards,
Dong


==


Section 4.4., paragraph 11:

>   Figure 1: A Reference ALTO Server Architecture and YANG Modules

  In Figure 1, the arrow labels marked with "write" and "read"
  for the Data Broker can be confusing. If we follow the semantic
  of the "write" arrow, then the "read" arrow can be understood as
  Data Broker reads Algorithm Plugin. It would be better to maintain
  consistency in the semantic of the arrows by following the "src as
  subject, dst as object, and label as predicate" convention. This
  would help to clarify the direction and purpose of the data flow
  between components in the architecture.
 5.  Design of ALTO O&M Data Model


Section 5.1., paragraph 2:

>As shown in Figure 2, the top-level container 'alto' in the "ietf-
>alto" module contains a single 'alto-server' and a list of 'alto-
>client' that are uniquely identified.

  The document uses both single and double quotation marks (e.g.,
  'alto', "ietf-alto", 'alto-server'), are they written by design? Or
  a consistent format is possible?
>The list 'alto-client' defines a list of configurations for other
>applications to bootstrap an ALTO client.  These data nodes can also
>be used by data sources and information resource creation algorithms
>that are configured by an ALTO server instance.


Section 5.3.2., paragraph 1:

>To satisfy R2 in Section 4.2, the ALTO server instance contains the
>the logging data nodes shonw in Figure 7.

  s/shonw/shown
>The 'logging-system' data node provides configuration to select a
>logging system to capture log messages generated by an ALTO server.


Section 5.4.1., paragraph 5:

>*  A unique `source-id' for resource creation algorithms to
>   reference.

  s\`source-id'\'source-id'
>*  The 'source-type' attribute to declare the type of the data
>   source.


Section 7., paragraph 0:

> 7.  ALTO OAM YANG Modules

  This section has no description, or if the YANG spec has already
  explained everything, just ignore this comment.
> 7.1.  The "ietf-alto" YANG Module


Section 8., paragraph 8:

>The "ietf-alto" supports an HTTP listen mode to cover cases where the
>ALTO server stack does not handle the TLS termination itself, but is
>handled by a separate component.  Special care should be considered
>when such mode is enabled.  Note that the default listen mode is
>"https".

  s/"https"/HTTPS

  What is the HTTP listen mode and TLS termination? I think they refer to the 
implementation of an HTTP(s) server and closing HTTPS connection by server.
 If so, they are general processes which are out of the scope of OAM security,
 so I feel there is no need to list it here.
>Also, please be aware that these modules include choice nodes that
>can be augmented by other extended modules.  The augmented data nodes
>may be considered sensitive or vulnerable in some network
>environments.  For instance, an augmented case of the "source-params"
>choice in "data-source" may include authentication information about
>how to access a data source including private network information.
>The "yang-datastore" case in Appendix A.3 is such an example.  The
>"restconf" and "netconf" nodes in it may reveal the access to a
>private YANG datastore.  Thus, those extended modules may have the
>NACM extension "default-deny-all" set.


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


[alto] Comments on draft-ietf-alto-new-transport-08

2023-05-19 Thread maqiufang (A)
Hi, all

Notice that Jordi was asking for volunteers to review ALTO WG documents, I 
tried to spend some time reviewing this ALTO new transport document and my 
comments are following.
Note that some of my questions/comments may be due to my not fully 
understanding of this document(sorry!)...

Sec.1 Introduction
Specifically, this document specifies the
   following:

   *  Extensions to the ALTO Protocol to create, update, or remove an
  incrementally changing network information resource.
So I thought that the ALTO client can request to create and delete a TIPS view, 
and also query the content of the TIPS or receive push updates. But I am not 
sure how the ALTO protocol could be extended to allow the client to update that 
view. I thought ALTO is a network information exposure protocol, the capability 
to update a network information resource sounds surprising to me.


Sec.2.1 Transport Requirements
s/direct/directly

Sec.2.2 TIPS Terminology

* In the definition of Updates graph, the authors mention that:
  A static network information resource (e.g., Cost Map,
  Network Map) may need only a single updates graph. A dynamic
  network information resource (e.g., Filtered Cost Map) may create
  an updates graph (within a new TIPS view) for each unique filter
  request.

How to understand cost map and network map as static network information 
resource? I don't see the 7285 making that distinction, I think the cost map 
information could be dynamically changing. Maybe you mean something else I 
failed to get, but I don't think there exists static network information 
resource on a time span.



* The definition of snapshot/incremental update is a full/partial 
replacement of resource contained within an updates graph, but the word 
"replacement" sounds quite strange to me. Why it is a replacement? Could you 
clarify a little bit more? Or maybe you want to use generation/creation?



* The definition for ID#i-#j:

  Denotes the update item (op, data) on a specific edge in the
  updates graph to transition from version at node i to version at
  node j, where i and j are the respective sequence numbers of the
  nodes the edge connects.
  What's the abbreviation for op, operation? I don't see this field in the 
ALTO message. The update item is defined as either a snapshot or incremental 
update, I don't know how this is related to (op,data).



* The text below Information Resource Directory(IRD)

Figure 4 shows an example illustrating the TIPS abstraction.  Each

ALTO client (Client 1, Client 2, or Client 3) maintains a single HTTP

connection with the ALTO server.

s/Figure 4/Figure 1?  Also note that you described this figure as the TIPS 
abstraction, but the figure 1 title is "ALTO Transport Information".



* Regarding Figure 1, I found that description of information resource 
#2 is lost, is this intentional? Maybe add some description for resource #2 to 
communicate the intent? Or simply remove it and rename resource#3 to resource#2.



* Note that you also refer to network Map as static resource here, see 
my similar comments above.


* Above Figure 1: tvi/ug = incremental updates graph associated with tsi
s/tsi/tvi?

Sec.3.1 Basic Data Model of Updates Graph

* Mandatory incremental updates and optional incremental updates are 
mentioned in the explanation of Figure 2, but I never see this defined, so what 
is mandatory/optional incremental updates? What is the difference between 
mandatory and optional ones? Maybe point to some reference here, or clarify in 
the document.


Sec.3.2 Resource Location Schema

* I guess I don't really understand what is a location schema. Maybe 
add a reference or more text for clarity.

* At the very beginning of this section:

To access each individual update in an updates graph, consider the

   model represented as a "virtual" file system (adjacency list)...

In my opinion, it is not a real file system. The file system is a tree 
structure, each non-root node has and only has one parent, but in figure 3, for 
example, node 103 has both 0 and 102 as parents node, fine for a directed 
acyclic graph, but not a file  structure. Maybe I am wrong, but please check 
that.

* It is not easy to understand your figure 3. At first I was struggling 
to understand what the indentation means for each number, and what the shortcut 
means. Then I've got some understanding which I am not sure is correct. Maybe 
you want to add more explanation for this figure.


Sec.3.3 Updates Graph Modification Invariants

* Sorry, but I guess I still don't understand what the title means, 
what is the modification invariant?

* You mentioned in the last paragraph that a server might compact a 
resource's update graph to save space, and [105,106] are valid set for server 
to save. But then what if a client requests content from 101 to 105? Doesn't 
th