Hi Qiufang, Thanks for the review! It is very helpful. Please see the responses inline.
Best, Kai > -----Original Messages----- > From: "maqiufang (A)" <[email protected]> > Sent Time: 2023-05-19 15:59:03 (Friday) > To: "[email protected]" <[email protected]> > Cc: "IETF ALTO" <[email protected]> > Subject: [alto] Comments on draft-ietf-alto-new-transport-08 > > 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. > KAI: Thanks for the comment. There might be a misunderstanding here -- this paragraph does not mean that the ALTO *client* should update the resource -- but I see your point. The proposed text is: * Extensions to the ALTO protocol to allow dynamic subscription and efficient uniform update delivery for an incrementally changing network information resource. > > Sec.2.1 Transport Requirements > s/direct/directly KAI: Good catch. Fixed. > > 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. > > KAI: Good point. We propose to follow the terms in RFC 7285 and replace "A static network information resource" with "An ALTO map service". > > * 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? > > KAI: Replacement means that the content returned by a resource is "replaced" by some other content and is also used to refer to the new content that replaces either all (i.e., full replacement) or only a subset (partial replacement) of the old content. I feel that replacement is the right term here. > > * 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). > > KAI: Good point. The update item is not properly defined. A new entry for update item is now added to the terminology, see below: Update item: Refers to the content on an edge of the updates graph, which can be either a snapshot or incremental update. An update item can be considered as a pair (op, data) where op denotes whether the item is an incremental update or a snapshot, and data is the content of the item. > > * 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". > > KAI: Good catch. Fixed. We have hanged the title to "Overview of ALTO TIPS" and the text has been expanded, see below: Figure 1 shows an example illustrating an overview of the ALTO TIPS service. The server provides the TIPS service of two information resources (#1 and #2) where we assume #1 is an ALTO map service, and #2 is a filterable service. There are 3 ALTO clients (Client 1, Client 2, and Client 3) that are connected to the ALTO server. Each client maintains a single HTTP connection with the ALTO server and uses the TIPS view to retrieve updates. Specifically, a TIPS view (tv1) is created for the map service #1, and is shared by multiple clients. For the filtering service #2, two different TIPS view (tv2 and tv3) are created upon different client requests. > > * 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. > > KAI: Good point. Fixed as suggested. > > * Note that you also refer to network Map as static resource here, see my similar comments above. > KAI: Fixed as in the previous comment. > > * Above Figure 1: tvi/ug = incremental updates graph associated with tsi > s/tsi/tvi? > KAI: Fixed. > 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. > KAI: Good point. We add the definitions of mandatory and optional incremental update as part of the incremental update, see below. Incremental update: Is a partial replacement of a resource contained within an updates graph, codified in this document as a JSON Merge Patch or JSON Patch. An incremental update is mandatory if the source version (i) and target version (j) are consecutive, i.e., i + 1 = j, and optional otherwise. Mandatory incremental updates are always in an updates graph, while optional incremental updates may or may not be included in an updates graph. > > 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. > KAI: Fair argument. We add a sentence to clarify the meaning of resource location schema: Update items are exposed as HTTP resources and the URLs of these items follow specific patterns that we call the resource location schema. > * 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. > KAI: The schema IS a tree structure. Note that <tvr>/ug/102/103 and <tvr>/ug/0/103 are two different nodes in the tree structure and represent two different edges in the updates graph. > * 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. > KAI: Figure 3 is the tree structure for the virtual file system. Indentation means that the items is in the subdirectory rooted at the parent. We redraw the figure to make the structure more explicit, see snippets below. <tips-view-root> |_ ug |_ 0 |_ 101 ... \_ 105 > > 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? > KAI: Modification invariants mean properties that must not change or be violated after a updates graph modification. > * 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 this mean that resource state prior to 105 is no longer reachable for clients? > KAI: Yes, when the server shrinks the updates graph to [105, 106], states prior to 105 are not reachable any more by intention. > > Sec.6.3 Open Example > > * The client sends a request to ALTO server, how its username and password is reflected on the request? It is the Authorization field? Maybe mention it more explicit like that: The user name and password are combined in the format of user:password and encoded using Base64 in the Authorization field. Otherwise I would rather not even mention this authorization thing KAI: The current text says: For simplicity, assume that the ALTO server is using the Basic authentication. ... Personally I think this is already clear enough how the username and password is reflected in the request.</tips-view-root></tvr></tvr></[email protected]></[email protected]></[email protected]> _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
