Re: [auth48] AUTH48: RFC-to-be 9275 <draft-ietf-alto-path-vector-25> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] We found the following "TODO" and "FIXME" comments in
the provided XML file.  Please confirm that the following items were
addressed.

Original:
 TODO: Error Handling
...
 TODO: the remaining issue is where to specify the json-merge-patch
   capability for each node
...
 FIXME: path-vector cannot be used in multi-cost, also no reason
...
 FIXME: using resource-id header in MIME part -->


2) <!-- [rfced] FYI, we updated the document title to follow the style of the published companion document RFC 9240.  Please let us know any concerns.

Original:
 An ALTO Extension: Path Vector

Currently:
 An Extension for Application-Layer Traffic Optimization (ALTO):
                           Path Vector -->


3) <!-- [rfced] Please provide any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. -->


4) <!-- [rfced] Abstract: In the following sentence, should "specified components" be instead "specific components"?

Current:
   This is useful for applications whose performance is impacted
   by specified components of a network on the end-to-end paths, e.g.,
   they may infer that several paths share common links and prevent
   traffic bottlenecks by avoiding such paths.  -->


5) <!-- [rfced] Section 1: Does reordering the end of the following sentence improve readability?

Current:
   While the existing extensions are sufficient for many overlay
   applications, the QoE of some overlay applications depends not only
   on the cost information for end-to-end paths but also on particular
   components of a network on the paths and their properties. 

Perhaps:
   While the existing extensions are sufficient for many overlay
   applications, the QoE of some overlay applications depends not only
   on the cost information for end-to-end paths but also on particular
   components and their properties on the paths of a network. -->


6) <!-- [rfced] Section 1: We had trouble following this sentence. Does making the sentence more parallel improve readability? 

Original:
 Despite the claimed benefits, ISPs are not likely to expose raw
 details on their network paths: first for the sake of topology hiding
 requirement, second because it may increase volume and computation
 overhead, and last because applications do not necessarily need all
 the network path details and are likely not able to understand them.

Suggested (using the "because" construction for the first reason and clarifying who has the topology-hiding requirement and what things may increase volume and overhead):
 Despite the claimed benefits, ISPs are not likely to expose raw
 details on their network paths: first because ISPs have requirements 
 to hide their network topologies, second because these details may 
 increase volume and computation overhead, and last because applications 
 do not necessarily need all the network path details and are likely not 
 able to understand them. -->


7) <!-- [rfced] Sections 1, 3, and 5: FYI, we have updated the extension label "Unified Property Map" to "entity property map" to match the label used by RFC 9240 (previously draft-ietf-alto-unified-props-new), which defines the extension.  Please review these updates and let us know if any changes are necessary. -->


8) <!-- [rfced] Section 2: FYI, we have removed the second sentence as it is already covered in RFC 8174:

Original:
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   When the words appear in lower case, they are to be interpreted with
   their natural language meanings.
-->


9) <!-- [rfced] Section 4.1:  Is the punctuation (the comma and the
period after "Mbps") needed?  We ask because we do not see any
punctuation following the next two such entries after mention of
"capacity region".

Original:
 x <= 100 Mbps,
 y <= 100 Mbps.

Perhaps:
 x <= 100 Mbps
 y <= 100 Mbps -->


10) <!-- [rfced] Section 4.1:  Please review the use of "->" and " - " in this section. Should the " - " pairs below use double dashes (like shown in Figure 1) to more clearly indicate that bandwidth between directly connected nodes is being discussed?

Original:
 *  The ALTO server must allow the client to distinguish the common
    ANE shared by "eh1 -> eh2" and "eh1 -> eh4", e.g., "eh1 - sw1" and
    "sw1 - sw5" in Case 1.

 *  The ALTO server must expose abstract information on the properties
    of the ANEs used by "eh1 -> eh2" and "eh1 -> eh4".  For example,
    an ALTO server can either expose the available bandwidth between
    "eh1 - sw1", "sw1 - sw5", "sw5 - sw7", "sw5 - sw6", "sw6 - sw7",
    "sw7 - sw2", "sw7 - sw4", "sw2 - eh2", "sw4 - eh4" in Case 1, or
    expose 3 abstract elements "A", "B" and "C", which represent the
    linear constraints that define the same capacity region in Case 1. -->


11) <!-- [rfced] Figure 3 and Section 6.4.1:  We had trouble following
the meaning of "intents".  Do "Data Transfer Intents" and "SDN
network intents" mean "Intent-Based Data Transfer" and
"Intent-Based SDN" or something else?

Original:
...
          |   |                  On-demand resource   |
 (Data    |   | (Network         allocation, demand   |
 Transfer |   | Resource         vector, etc.         |
 Intents) |   | Constraints)     (Non-ALTO interfaces)|
...
 How the client makes resource requests based on the information and
 how the resource allocation is achieved respectively depend on
 interfaces between the management system and the users or a higher-
 layer protocol (e.g., SDN network intents or MPLS tunnels), which are
 out of the scope of this document. -->


12) <!-- [rfced] Section 4.2.1: FYI, to improve readability, we have moved the paragraph describing Figure 5 to be in front of the figure instead of after it. Please let us know of any concerns. -->


13) <!-- [rfced] Please review the "type" attribute of each sourcecode
element in the XML file to ensure correctness.  Please note that we
set the fourth and subsequent sourcecode items to "json".

If the current list of preferred values for "type"
(https://www.rfc-editor.org/materials/sourcecode-types.txt)  
does not contain an applicable type, please let us know. -->


14) <!-- [rfced] Section 4.2.2:  We removed "2021" here and, to avoid
constraining the timeframe with a specific year, we used "At the time
of this writing".  Also, please note that (1) for ease of the reader,
(2) to avoid confusion with "AR" as used in Section 4.1 to mean
"additional requirement", and (3) because "AR/VR" is not used again
in this document, we changed "AR/VR" to "augmented reality / virtual
reality".  Please let us know any objections.

Original:
 A growing trend in today's applications (2021) is to bring storage
 and computation closer to the end users for better QoE, such as
 Content Delivery Network (CDN), AR/VR, and cloud gaming, as reported
 in various documents (e.g., [SEREDGE] and [MOWIE]).

Currently:
 At the time of this writing, a growing trend in today's applications
 is to bring storage and computation closer to the end users for
 better QoE, such as CDNs, augmented reality / virtual reality, and 
 cloud gaming, as reported in various documents (e.g., [SEREDGE] and 
 [MOWIE]). -->


15) <!-- [rfced] Section 4.2.2 and Figure 7:  The abbreviations for "gigabytes" and "terabytes" ("G" and "T") used here are unorthodox. May we update to "GB" and "TB"?

Original:
 For example, Figure 6 illustrates a typical edge-cloud scenario where
 memory is measured in Gigabytes (G) and storage is measured in
 Terabytes (T).

Suggested:
 For example, Figure 6 illustrates a typical edge-cloud scenario where
 memory is measured in gigabytes (GB) and storage is measured in
 terabytes (TB). 
 
 Figure 7 (also adding spaces to match examples in Section 4.2.1):

 ane1: latency = 5 ms cpu = 2 memory = 8 GB storage = 10 TB
 (On premise, a)

 ane2: latency = 20 ms cpu = 4 memory = 8 GB storage = 10 TB
 (Site-radio Edge Node 1)
...
-->


16) <!-- [rfced] Section 4.2.2: FYI, to improve readability, we have moved the paragraph describing Figure 7 to be in front of the figure instead of after it. Please let us know of any concerns. -->


17) <!-- [rfced] Section 4.2.2:  Does "GPU" stand for "Graphics
Processing Unit" here, or should it be "CPU" as used earlier in this
section?

Original:
 With the extension defined in this document, an ALTO server can
 selectively reveal the CDNs and service edges that reside along the
 paths between different end hosts and/or the cloud servers, together
 with their properties such as capabilities (e.g., storage, GPU) and
 available Service Level Agreement (SLA) plans. -->


18) <!-- [rfced] Section 5:  This sentence is difficult to parse.  If
neither suggestion below is correct, please clarify the relationship
between "learn", "investigating", "identify", and "retrieve".

Original:
 Thus, an ALTO client can learn about the ANEs that are important to
 assess the QoE of different <source, destination> pairs by
 investigating the corresponding Path Vector value (AR1), identify
 common ANEs if an ANE appears in the Path Vectors of multiple
 <source, destination> pairs (AR2), and retrieve the properties of the
 ANEs by searching the Unified Property Map (AR3).

Suggestion #1:
 Thus, an ALTO client can learn about the ANEs that are important for
 assessing the QoE of different <source, destination> pairs by
 investigating the corresponding Path Vector value (AR1), identifying
 common ANEs if an ANE appears in the Path Vectors of multiple
 <source, destination> pairs (AR2), and retrieving the properties of
 the ANEs by searching the entity property map (AR3).

Suggestion #2:
 Thus, an ALTO client can learn about the ANEs that are important
 for assessing the QoE of different <source, destination> pairs by
 investigating the corresponding Path Vector value (AR1) and can
 also (1) identify common ANEs if an ANE appears in the Path Vectors
 of multiple <source, destination> pairs (AR2) and (2) retrieve the
 properties of the ANEs by searching the entity property map (AR3). -->


19) <!-- [rfced] Section 5.1.2:  Does "their" refer to the network
components (mentioned in the previous sentence) or to "A persistent
ANE" (in which case it should be "its")?  If the suggested text
(assuming that "their" should be "its") is not correct, please
clarify.

Original:
 A persistent ANE has a persistent ID that is
 registered in a Property Map, together with their properties.

Suggested:
 A persistent ANE has a persistent ID that is
 registered in a property map, together with its properties. -->


20) <!-- [rfced] Section 5.3:  We had trouble following this sentence.
We updated it as follows.  If this update is incorrect, please
clarify "on demand, and potentially based on".

Original:
 1.  ANEs may be constructed on demand, and potentially based on the
     requested properties (See Section 5.1 for more details).

Currently:
 1.  ANEs may be constructed on demand and, potentially, based on the
     requested properties (see Section 5.1 for more details). -->


21) <!-- [rfced] Section 6.4.1:  This sentence did not parse.  We changed
"this document that the" to "this document in that the".  If this
change is incorrect, please clarify the text.

Original:
 The encoding in [NOVA] differs from the
 Path Vector response defined in this document that the Path Vector
 part and Property Map part are put in the same JSON object.

Currently:
 The encoding
 in [NOVA] differs from the Path Vector response defined in this
 document in that the Path Vector part and property map part are
 placed in the same JSON object. -->


22) <!-- [rfced] Section 6.4.2:  We had trouble following the use of "presents" in this sentence. We did not see information in Section 5.1.2 on how an ephemeral ANE presents a persistent entity ID. We did see text that said the ALTO server provides this information. How may we update this sentence?

Original:
 The persistent entity ID property is the entity identifier of the
 persistent ANE which an ephemeral ANE presents (See Section 5.1.2 for
 details). -->


23) <!-- [rfced] Section 6.4.3:  As it appears that "they" in this
sentence means "service edges", we updated the text accordingly.
Please let us know if this is incorrect.

Original ("life cycle ... are" has been corrected):
 As the life cycle of service edges are
 typically long, they may contain information that is not specific to
 the query.

Currently:
 As the life cycles of service edges are
 typically long, the service edges may contain information that is not
 specific to the query. -->


24) <!-- [rfced] Section 6.5.1:  We did not see any instructions in
Section 8.3.4.3 of RFC 7285 ("the client can either choose another
server (if one is available) or ...").  Should "instructions" be
"guidance"?

Original:
 Otherwise, the client MUST
 discard the response and SHOULD follow the instructions in
 Section 8.3.4.3 of [RFC7285] to handle the error. -->


25) <!-- [rfced] Section 7.2.6:  We only see one parameter listed in this
paragraph and three parameters in the parameters list.  Please
clarify "both parameters"; was "permits parameters both with and
without double quotes" intended?

Original:
 type:  The type parameter is mandatory and MUST be "application/alto-
    costmap+json".  Note that [RFC2387] permits both parameters with
    and without the double quotes. -->


26) <!-- [rfced] Sections 7.2.6 and 7.3.6:  The all-capitals "NOT" is
unusual, and could be confusing to some readers, because it is not
used as part of a key word per RFC 2119.  May we change "NOT" to
"not" in these sentences and apply the <strong> element in the XML
file, per Section 2.50 of RFC 7991
(https://www.rfc-editor.org/info/rfc7991)?

The "not"s would then be emphasized in the .html and .pdf output
files for this document.  For an example of how this emphasis would
look, please see the first two instances of "singleton" in
Section 3.4 of <https://www.rfc-editor.org/rfc/rfc9198.html> or
<https://www.rfc-editor.org/rfc/rfc9198.pdf>.

Original text:
 If any part is
 NOT present, the client MUST discard the received information and
 send another request if necessary.
...
 If any part is
 NOT present, the client MUST discard the received information and
 send another request if necessary.

Suggested (in the XML file):
 If any part is <strong>not</strong> present, the ... -->


27) <!-- [rfced] Sections 7.2.6 and 7.3.6:  These sentences are confusing
as written, as RFC 2387 discusses the "object root" and the "root
body part" but does not mention "Path Vector" or "vector".  May we
update as suggested?  If not, please clarify the text.

Also, should the other instances of "root object" in this document be
updated as well?  We do not see "root object" used in RFC 2387.
If yes, please specify how to update.

Original:
 According to [RFC2387], the Path Vector part, whose media type is the
 same as the "type" parameter of the multipart response message, is
 the root object.
...
 According to [RFC2387], the Path Vector part, whose media type is the
 same as the "type" parameter of the multipart response message, is
 the root object.

Suggested:
 The Path Vector part, whose media type is the same as the "type"
 parameter of the multipart response message, is the root body part
 as defined in [RFC2387].
...
 The Path Vector part, whose media type is the same as the "type"
 parameter of the multipart response message, is the root body part
 as defined in [RFC2387]. -->


28) <!-- [rfced] Sections 7.2.6 and 7.3.6:  Would you like to add
spaces between the square brackets and the quotes for these two
items, as was done for other such items (e.g., [ "PID1" ])?

Original:
 "PID1": { "PID2": ["ANE1"] }
...
 "ipv4:192.0.2.2": { "ipv4:192.0.2.18": ["ANE1"] }

Perhaps:
 "PID1": { "PID2": [ "ANE1" ] }
...
 "ipv4:192.0.2.2": { "ipv4:192.0.2.18": [ "ANE1" ] } -->


29) <!-- [rfced] Section 7.3.3:  We see "ReqEndpointCostMap" in
Section 4.2.2 of RFC 8189 but not "ReqEndpointCost" or
"ReqEndpointcostMap".  May we update as suggested, to match RFC 8189?
If not, please provide clarifying text.

Also, please review the capitalization of the following terms and let us know if any changes are necessary (e.g., should "cost" in "PVReqEndpointcost" be "PVReqEndpointCost"?)

 PVEndpointcostCapabilities
 PVFilteredCostMapCapabilities
 PVReqEndpointCost
 PVReqEndpointcost
 PVReqFilteredCostMap
 ReqEndpointCost
 ReqEndpointcostMap
 ReqFilteredCostMap

Original:
 This document
 extends the input parameters to an Endpoint Cost Service, which is
 defined as a JSON object of type ReqEndpointCost in Section 4.2.2 of
 [RFC8189], with a data format indicated by the media type
 "application/alto-endpointcostparams+json", which is a JSON object of
 type PVReqEndpointCost:

 object {
   [EntityPropertyName ane-property-names<0..*>;]
 } PVReqEndpointcost : ReqEndpointcostMap;

Suggested:
 This document
 extends the input parameters to an Endpoint Cost Service, which is
 defined as a JSON object of type ReqEndpointCostMap in Section 4.2.2
 of [RFC8189], with a data format indicated by the media type
 "application/alto-endpointcostparams+json", which is a JSON object of
 type PVReqEndpointCost:

 object {
   [EntityPropertyName ane-property-names<0..*>;]
 } PVReqEndpointcost : ReqEndpointCostMap; -->


30) <!-- [rfced] Section 7.3.6:  Because RFC 7285 does not use
"multipart/related" or "multipart", we changed "[RFC7285]" to
"[RFC2387]" per RFC 2387 and per the (otherwise) same sentence in the
second paragraph of Section 7.2.6.  Please let us know any
objections.

Original:
 The "Content-Type" header of the response MUST be "multipart/related"
 as defined by [RFC7285] with the following parameters:

Currently:
 The "Content-Type" header field of the response MUST be "multipart/related"
 as defined by [RFC2387], with the following parameters: -->


31) <!-- [rfced] Section 8.1: FYI, to improve readability, we have moved the paragraph describing Figure 10 to be in front of the figure instead of after it. Please let us know of any concerns. -->


32) <!-- [rfced] Section 8.1:  We could not see any indication of message
contents in Figure 10.  If the suggested text is not correct, please
clarify the meaning.

Original:
 In this document, Figure 10 is used to illustrate the message
 contents.

Suggested:
 Figure 10 illustrates the network properties and thus the message 
 contents. -->


33) <!-- [rfced] Section 8.2:  This item reads oddly.  Are some words
missing?

Original:
 *  "multicost-pv": A Multipart Endpoint Cost Service with both Multi-
    Cost and Path Vector.

Possibly:
 *  "multicost-pv": A multipart Endpoint Cost Service with both a Multi-
    Cost resource and a Path Vector resource. -->


34) <!-- [rfced] Section 8.2:  Section 6.5 does not mention "path-vector";
this sentence is the first mention of it.  We updated this sentence
so that the information is clearer.  Please let us know any
objections.

Original:
 To enable the extension defined in this document, the "path-
 vector" cost type (Section 6.5) is defined in the "cost-types" of the
 "meta" field, and is included in the "cost-type-names" of resources
 "filtered-cost-map-pv" and "endpoint-cost-pv".

Currently:
 To enable the extension
 defined in this document, the Path Vector cost type (Section 6.5),
 represented by "path-vector" below, is defined in the "cost-types" of
 the "meta" field and is included in the "cost-type-names" of
 resources "filtered-cost-map-pv" and "endpoint-cost-pv". -->


35) <!-- [rfced] Sections 8.3 and 8.4:  Would it improve readability to update "array of ANEName" to "array of data type ANEName"? 

Original:
 The first part returns the array
 of ANEName for each source and destination pair.
...
 The first part returns the array
 of ANEName for each valid source and destination pair. -->


36) <!-- [rfced] Section 8.3:  We could not see a relationship between
Section 3.1 of draft-ietf-alto-unified-props-new (now RFC 9240) and
this sentence (i.e., we did not see any mention of "empty", "omit",
or "no properties".  Please confirm that this sentence will be clear
to readers.

Original:
 The second part returns an empty Property Map. Note that the ANE
 entries are omitted since they have no properties (See Section 3.1 of
 [I-D.ietf-alto-unified-props-new]). -->


37) <!-- [rfced] Section 8.4:  Regarding these two paragraphs, Figure 10,
and the example shown after the "Both NET1 and NET2" paragraph:

a) The "[ "NET3", "L1", "NET1" ]" entry in the example does not
appear to us to match "traverses NET2, L1 and NET1" in the text.
Please confirm that the text and example are correct.

b) We do not see how "ane-props.ane:MEC2" corresponds to NET3; it
appears to us to correspond to NET2 and AGGR2 (we see AGGR2 listed as
an aggregate of NET2 and L2 in the "Under certain scenarios"
paragraph).  Please confirm that "NET3" is correct.

Original:
 The response consists of two parts.  The first part returns the array
 of ANEName for each valid source and destination pair.  As one can
 see in Figure 10, flow 192.0.2.34 -> 192.0.2.2 traverses NET2, L1 and
 NET1, and flows 192.0.2.34 -> 192.0.2.50 and 2001:db8::3:1 ->
 2001:db8::4:1 traverse NET2, L2 and NET3.
...
 Both NET1 and NET2 have a mobile edge deployed, i.e., MEC1 in NET1
 and MEC2 in NET2.  Assume the ANEName for MEC1 and MEC2 are "MEC1"
 and "MEC2" and their properties can be retrieved from the Property
 Map "ane-props".  Thus, the "persistent-entity-id" property of NET1
 and NET3 are "ane-props.ane:MEC1" and "ane-props.ane:MEC2"
 respectively.
...
 "endpoint-cost-map": {
   "ipv4:192.0.2.34": {
     "ipv4:192.0.2.2":   [ "NET3", "L1", "NET1" ],
     "ipv4:192.0.2.50":   [ "NET3", "L2", "NET2" ]
   },
   "ipv6:2001:db8::3:1": {
     "ipv6:2001:db8::4:1": [ "NET3", "L2", "NET2" ]
...
 ".ane:NET1": {
   "max-reservable-bandwidth": 50000000000,
   "persistent-entity-id": "ane-props.ane:MEC1"
 },
 ".ane:NET2": {
   "max-reservable-bandwidth": 50000000000,
   "persistent-entity-id": "ane-props.ane:MEC2" -->


38) <!-- [rfced] Section 8.5:  These lines result in "Warning: Too long
line found" xml2rfc output for the .txt file.  May we add line breaks
as suggested?  If not, please specify where line breaks should be
placed.

Original:
 event: application/merge-patch+json, [e-mail]
 data: <Merge patch for endpoint-cost-map-update>

 event: application/merge-patch+json, [e-mail]
 data: <Merge patch for property-map-update>

Suggested:
 event: application/merge-patch+json,
    [e-mail]
 data: <Merge patch for endpoint-cost-map-update>

 event: application/merge-patch+json,
    [e-mail]
 data: <Merge patch for property-map-update> -->


39) <!-- [rfced] Section 9.4:  Does "calendar extension" here mean
"ALTO Calendar extension" (Section 5.2.4 of RFC 8896), "Cost
Calendar extension", or something else?  (It appears to us to
mean "Cost Calendar extension", but we need to confirm.)

Original:
 The
 Path Vector part is calendared in a compatible way, and the Property
 Map part is not affected by the calendar extension. -->


40) <!-- [rfced] Section 10.1:  We had trouble following this sentence,
as we only see "constraints" in RFC 7285 and we see "A Client is
therefore allowed to express either "constraints" or "or-constraints"
but not both" in Section 3.6.2 of RFC 8189.  Please let us know if
any updates are needed to clarify this text.

Original:
 [RFC7285] and [RFC8189] allow ALTO clients to specify the
 "constraints" and "or-constraints" tests to better filter the result.

Possibly:
 ALTO clients are permitted to specify either the "constraints" test
 [RFC7285] [RFC8189] or the "or-constraints" test [RFC8189] to better
 filter the results. -->


41) <!-- [rfced] Section 10.2:  It was difficult to determine what "This
extension" refers to, given "incremental update extension" four lines
earlier.  Because "This extension" appears to mean "The extension
specified in this document" here, we updated accordingly.  If this is
incorrect, please provide clarifying text.

Original:
 This extension gives an example of using a multipart message to
 encode the responses from two specific ALTO information resources: a
 Filtered Cost Map or an Endpoint Cost Service, and a Property Map.

Currently:
 The extension specified in this document gives an example of using a
 multipart message to encode the responses from two specific ALTO
 information resources: a filtered cost map or an Endpoint Cost
 Service, and a property map. -->


42) <!-- [rfced] Section 10.2:  Does "which provides" refer to upgrading
to HTTP/2 and HTTP/3, or does it also refer to extending the SSE
mechanism (in which case "provides" should be "provide")?

Original ("to allow servers proactively send" has been corrected):
 Thus, it is worth looking into the direction of extending the SSE
 mechanism as used in the incremental update extension [RFC8895], or
 upgrading to HTTP/2 [RFC9113] and HTTP/3 [RFC9114], which provides
 the ability to multiplex queries and to allow servers proactively
 send related information resources. -->


43) <!-- [rfced] Section 11: In the following sentence, should "CDNi" be "CDNI" instead?

Current:
   Thus, they should only be used when exposing public
   service access points (e.g., API gateways, CDNi)

Perhaps:
   Thus, they should only be used when exposing public
   service access points (e.g., API gateways, CDN Interconnections) -->


44) <!-- [rfced] Section 12: FYI, we have updated the tables in the IANA Considerations section to better match the tables in the IANA registries. Please let us know of any concerns.-->


45) <!-- [rfced] Section 12.3:  The information in this text and the
data in Table 3 seem to point to Section 12.3 ("ALTO Entity Domain
Types Registry") of draft-alto-unified-props-new (now RFC 9240) and
not to Section 12.2 ("alto-propmapparams+json Media Type") of that
document.  We updated the section number accordingly.  Please let us
know if this is incorrect.

Original:
 This document registers a new entry to the ALTO Domain Entity Type
 Registry, as instructed by Section 12.2 of
 [I-D.ietf-alto-unified-props-new].  The new entry is as shown below
 in Table 3.

Currently:
 This document registers a new entry in the "ALTO Entity Domain Types"
 registry, per Section 12.3 of [RFC9240]. -->


46) <!-- [rfced] Section 12.3: Is the sentence below talking about issue (2) in the Security Considerations section? Is a bis already in progress for this document or does another I-D that covers the topic exist?  

Current:
 Applications and ALTO
 service providers using addresses of ANEs will be made aware of
 how (or if) the addressing scheme relates to private information
 and network proximity, in further iterations of this document.

Perhaps (reordering and saying "update" rather than "further iterations", and also changing "applications" to "implementers"):
 A future update of this document will explain to ALTO implementers
 and service providers using ANE addresses how (or if) the 
 addressing scheme relates to private information and network 
 proximity.  -->


47) <!-- [rfced] Section 12.4:  The information in this text and the
data in Table 4 seem to point to Section 12.4 ("ALTO Entity Property
Types Registry") of draft-alto-unified-props-new (now RFC 9240) and
not to Section 12.3 ("ALTO Entity Domain Types Registry") of that
document.  We updated the section number accordingly.  Please let us
know if this is incorrect.

Original:
 Two initial entries "max-reservable-bandwidth" and "persistent-
 entity-id" are registered to the ALTO Domain "ane" in the "ALTO
 Entity Property Type Registry", as instructed by Section 12.3 of
 [I-D.ietf-alto-unified-props-new].  The two new entries are shown
 below in Table 4 and their details can be found in Section 12.4.1 and
 Section 12.4.2.

Currently:
 Two initial entries - "max-reservable-bandwidth" and "persistent-
 entity-id" - are registered for the ALTO domain "ane" in the "ALTO
 Entity Property Types" registry, per Section 12.4 of [RFC9240]. -->


48) <!-- [rfced] Section 12.4.2:  This sentence was difficult to follow,
as it appeared to say that the entity IDs might consider something.
We updated it per the "Security Considerations:" paragraph in
Section 12.3.2 of RFC 9240 (formerly
[I-D.ietf-alto-unified-props-new]).  If this update is incorrect,
please provide clarifying text.

Original:
 The entity IDs
 may consider sensitive information about the underlying network,
 and an ALTO server should follow the security considerations in
 Section 11 of [I-D.ietf-alto-unified-props-new].

Currently:
 As mentioned
 in Section 12.3.2 of [RFC9240], the entity IDs may reveal
 sensitive information about the underlying network.  An ALTO
 server should follow the security considerations provided in
 Section 11 of [RFC9240]. -->


49) <!-- [rfced] Informative References:  The provided link for [NOVA],
which indicates the year 2017, redirects to a page listing the same
authors, but the listed title is different - "NOVA: Towards on-demand
equivalent network view abstraction for network optimization" - and
the listed year is 2019.  Also listed via the provided link is "2017
IEEE/ACM 25th International Symposium on Quality of Service (IWQoS),
pp. 1-10, June 2017".

Note:  We have added the DOI for now but will remove or change it
as appropriate.

Please review, and let us know which listing is correct.

Original:
 [NOVA]     Gao, K., Xiang, Q., Wang, X., Yang, Y.R., and J. Bi, "An
            objective-driven on-demand network abstraction for
            adaptive applications", IEEE/ACM Transactions on
            Networking (TON) Vol 27, no. 2 (2019): 805-818., 2019,
            <https://doi.org/10.1109/IWQoS.2017.7969117>. -->


50) <!-- [rfced] Informative References:  The provided author list,
conference information, and date for [UNICORN] ("Unicorn: Unified
resource orchestration for multi-domain, geo-distributed data
analytics") did not match what we found on
<https://www.sciencedirect.com/science/article/abs/pii/
S0167739X18302413?via%3Dihub> or via DOI search on
10.1016/j.future.2018.09.048.  Because the document title was the
same, we updated the information according to the provided page.
Please let us know any objections; for example, should a different
paper or conference be listed here?  If yes, please provide the
correct information.

Original (the bad spacing has been corrected):
 [UNICORN]  Xiang, Q., Chen, S., Gao, K., Newman, H., Taylor, I.,
            Zhang, J., and Y.R. Yang, "Unicorn: Unified Resource
            Orchestration for Multi-Domain, Geo-Distributed Data
            Analytics", 2017 IEEE SmartWorld, Ubiquitous Intelligence
            Computing, Advanced Trusted Computed, Scalable Computing
            Communications, Cloud Big Data Computing, Internet of
            People and Smart City Innovation
            (SmartWorld/SCALCOM/UIC/ATC/CBDCom/IOP/SCI) (Aug. 2017),
            1-6. , 2017,
            <https://doi.org/10.1016/j.future.2018.09.048>.

Currently:
[UNICORN]  Xiang, Q., Wang, T., Zhang, J., Newman, H., Yang, Y.R.,
            and Y. Liu, "Unicorn: Unified resource orchestration for
            multi-domain, geo-distributed data analytics", Future
            Generation Computer Systems, Volume 93, pp. 188-197,
            DOI 10.1016/j.future.2018.09.048, April 2019,
            <https://www.sciencedirect.com/science/article/abs/pii/
            S0167739X18302413?via%3Dihub>. -->


51) <!-- [rfced] Acknowledgments:  Please confirm that you would like to
list Qiao Xiang twice in this section.

Original:
 The authors would like to thank discussions with Andreas Voellmy,
 Erran Li, Haibin Song, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan
...
 Vyncke, Samuel Weiler, and Qiao Xiang whose feedback and suggestions
-->


52) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed. -->


53) <!-- [rfced] Terminology: Please let us know if any changes are needed for the following:

a) The following terms were used inconsistently in this document.
We chose to use the latter forms.  Please let us know any objections.

 ALTO Cost Map / ALTO cost map (per companion document RFC 9240,
   published 14 July 2022)

 ALTO protocol / ALTO Protocol (per RFC 9240)

 ANE Name / ANE name (per RFC 9240)

 Cost Map / cost map (per RFC 9240)

 Filtered Cost Map / filtered cost map (per RFC 9240)

 Network Element (used generally) / network element
   (per RFCs 2216 and 9240)

 Network Map / network map (per RFC 9240)

 Property Map / property map (per RFC 9240)

b) Because network element examples, parameter names, and HTTP header field names were mostly quoted, we quoted all of them.  Please let us know any concerns.  For example, we used the latter forms:

 eh1 / "eh1" 
 sw1 / "sw1"
 start parameter / "start" parameter
 type parameter / "type" parameter 
 Accept header field / "Accept" header field 

c) When an HTTP header field was discussed (e.g., "Content-Type"), we updated "header" to "header field" to match the usage in HTTP RFCs. 
-->


Thank you.

RFC Editor/lb/jm


On 8/18/22 4:34 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2022/08/18

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

   Please review and resolve any questions raised by the RFC Editor 
   that have been included in the XML file as comments marked as 
   follows:

   <!-- [rfced] ... -->

   These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

   Please ensure that you review any changes submitted by your 
   coauthors.  We assume that if you do not speak up that you 
   agree to changes submitted by your coauthors.

*  Content 

   Please review the full content of the document, as this cannot 
   change once the RFC is published.  Please pay particular attention to:
   - IANA considerations updates (if applicable)
   - contact information
   - references

*  Copyright notices and legends

   Please review the copyright notice and legends as defined in
   RFC 5378 and the Trust Legal Provisions 
   (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

   Please review the markup in the XML file to ensure that elements of  
   content are correctly tagged.  For example, ensure that <sourcecode> 
   and <artwork> are set correctly.  See details at 
   <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

   Please review the PDF, HTML, and TXT files to ensure that the 
   formatted output, as generated from the markup in the XML file, is 
   reasonable.  Please note that the TXT will have formatting 
   limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

   *  your coauthors
   
   *  [e-mail] (the RPC team)

   *  other document participants, depending on the stream (e.g., 
      IETF Stream participants are your working group chairs, the 
      responsible ADs, and the document shepherd).
     
   *  [e-mail], which is a new archival mailing list 
      to preserve AUTH48 conversations; it is not an active discussion 
      list:
     
     *  More info:
        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
     
     *  The archive itself:
        https://mailarchive.ietf.org/arch/browse/auth48archive/

     *  Note: If only absolutely necessary, you may temporarily opt out 
        of the archiving of messages (e.g., to discuss a sensitive matter).
        If needed, please add a note at the top of the message that you 
        have dropped the address. When the discussion is concluded, 
        [e-mail] will be re-added to the CC list and 
        its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
 — OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
   https://www.rfc-editor.org/authors/rfc9275.xml
   https://www.rfc-editor.org/authors/rfc9275.html
   https://www.rfc-editor.org/authors/rfc9275.pdf
   https://www.rfc-editor.org/authors/rfc9275.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9275-diff.html
   https://www.rfc-editor.org/authors/rfc9275-rfcdiff.html (side by side)

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9275-xmldiff1.html

The following files are provided to facilitate creation of your own 
diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
   https://www.rfc-editor.org/authors/rfc9275.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates 
only: 
   https://www.rfc-editor.org/authors/rfc9275.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9275

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9275 (draft-ietf-alto-path-vector-25)

Title            : An ALTO Extension: Path Vector
Author(s)        : K. Gao, Y. Lee, S. Randriamasy, Y.R. Yang, J. Zhang
WG Chair(s)      : Jan Seedorf, Mohamed Boucadair, Qin Wu
Area Director(s) : Martin Duke, Zaheduzzaman Sarker