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

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Dear Lynne,
The documents looks good to me and I approve its publication.
Best regards,
Sabine

>-----Original Message-----
>From: Lynne Bartholomew <[e-mail]>
>Sent: Friday, September 2, 2022 7:47 PM
>To: [e-mail]; [e-mail]; Randriamasy, Sabine (Nokia
>- FR/Paris-Saclay) <[e-mail]>;
>[e-mail]; [e-mail]; [e-mail]
>Cc: RFC System <[e-mail]>; [e-mail];
>[e-mail]; Martin Duke <[e-mail]>;
>[e-mail]
>Subject: Re: *[AD] Re: AUTH48: RFC-to-be 9275 <draft-ietf-alto-path-vector-
>25> for your review
>
>Dear authors and *AD,
>
>Checking in with you regarding the status of this document.  Please let us
>know whether further changes are needed.
>
>The AUTH48 status page is here:
>
>   https://www.rfc-editor.org/auth48/rfc9275
>
>If no further changes are needed, please note that we will need explicit
>approvals from each of you.
>
>Thank you!
>
>RFC Editor/lb
>
>> On Aug 25, 2022, at 8:53 AM, Lynne Bartholomew
><[e-mail]> wrote:
>>
>> Hi, Kai.  No worries, and thank you for confirming!
>>
>> RFC Editor/lb
>>
>>> On Aug 25, 2022, at 2:25 AM, [e-mail] wrote:
>>>
>>> Hi Lynne,
>>>
>>> Sorry for the confusion. I have no further comments at this point.
>>>
>>> Thanks a lot!
>>>
>>> Best,
>>> Kai
>>>
>>>
>>> &gt; -----Original Messages-----
>>> &gt; From: "Lynne Bartholomew" <[e-mail]>
>>> &gt; Sent Time: 2022-08-24 23:38:53 (Wednesday)
>>> &gt; To: [e-mail]
>>> &gt; Cc: [e-mail], "RFC System" <[e-mail]>,
>[e-mail], [e-mail],
>[e-mail], [e-mail], [e-mail],
>[e-mail], "Martin Duke" <[e-mail]>,
>[e-mail]
>>> &gt; Subject: Re: *[AD]  Re: AUTH48: RFC-to-be 9275 <draft-ietf-alto-path-
>vector-25> for your review
>>> &gt;
>>> &gt; Hi, Kai.
>>> &gt;
>>> &gt; We found one new comment below -- your clarification regarding the
>boundary lines.  Thank you for the explanation!
>>> &gt;
>>> &gt; If we missed any other new comments from you, please let us know.
>>> &gt;
>>> &gt; Thanks again!
>>> &gt;
>>> &gt; RFC Editor/lb
>>> &gt;
>>> &gt; &gt; On Aug 23, 2022, at 6:16 PM, [e-mail] wrote:
>>> &gt; &gt;
>>> &gt; &gt; Hi Lynne,
>>> &gt; &gt;
>>> &gt; &gt; Thanks for the updates! Please see the comments inline.
>>> &gt; &gt;
>>> &gt; &gt;
>>> &gt; &gt; p.s. I switch to another edit mode on the mail client. Hope it
>handles the "&gt;" correctly.
>>> &gt; &gt;
>>> &gt; &gt;
>>> &gt; &gt; Best,
>>> &gt; &gt;
>>> &gt; &gt; Kai
>>> &gt; &gt;
>>> &gt; &gt;
>>> &gt; &gt;
>>> &gt; &gt; &gt; -----Original Messages-----
>>> &gt; &gt; &gt; From: "Lynne Bartholomew" <[e-mail]>
>>> &gt; &gt; &gt; Sent Time: 2022-08-24 01:46:30 (Wednesday)
>>> &gt; &gt; &gt; To: [e-mail], [e-mail]
>>> &gt; &gt; &gt; Cc: "RFC System" <[e-mail]>,
>[e-mail], [e-mail],
>[e-mail], [e-mail], [e-mail],
>[e-mail], "Martin Duke" <[e-mail]>,
>[e-mail]
>>> &gt; &gt; &gt; Subject: *[AD]  Re: AUTH48: RFC-to-be 9275 <draft-ietf-alto-
>path-vector-25> for your review
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; Dear Kai and *AD (Zahed or Martin),
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; * Zahed or Martin, as we don't know whether (1) the
>changes to "Content-Length:" values and (2) the updated '"property-map": {'
>entry at the end of Section 8.3 would be considered editorial or technical,
>please review, and let us know if you approve these updates.
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; Kai, thank you for your prompt reply and updated XML file!
>We have made further updates per your notes below.
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; -- It appears that "we also find that multipart examples are
>missing the last boundary line" refers to the changes to "Content-Length:"
>values.  If we misunderstand this note, please clarify.
>>> &gt; &gt; &gt;
>>> &gt; &gt;
>>> &gt; &gt; We add a boundary line to each multipart example before
>recalculating the "Content-Length" value.
>>> &gt; &gt;
>>> &gt; &gt; &gt; -- Regarding our question 11) (the meaning of "intents"):  We
>have added a citation and Informative Reference entry for draft-irtf-nmrg-ibn-
>concepts-definitions; thank you for the suggestion.
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; -- Regarding our question 13) and your reply:  We updated as
>follows; thank you for your advice on these as well:
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Line 1138-1140:
>>> &gt; &gt; &gt; &gt; The content is a simple string. I am not sure which type
>fits the best here, though (maybe empty?).
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; Changed to <artwork>; <sourcecode> might not be
>appropriate for a simple string.
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Line 1375-1379, Line 1420-1424, Line 1713-1717:
>>> &gt; &gt; &gt; &gt; The content is related to JSON but more like type
>definitions instead of data. Looks like "json-dtd" to me but I'm fine with using
>"json" here. By the way, I see in the XML of RFC 9240, such definitions are
>encoded as <artwork>. Maybe <artwork> could also be an option here?
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; Changed to <artwork> per the XML of RFC 9240.
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Line 1394-1413, Line 1626-1671, Line 1771-1790, Line
>1904-1949, Line 2170-2188, Line 2189-2239, Line 2310-2340, Line 2341-2409,
>Line 2422-2484, Line 2490-2505, Line 2509-2530, Line 2534-2540, Line 2583-
>2613, Line 2614-2676:
>>> &gt; &gt; &gt; &gt; It seems to me that "http-message" is more suitable
>here as the content contains the HTTP header.
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; Thank you for making these updates in the XML.
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Line 1519-1521, Line 1855-1857:
>>> &gt; &gt; &gt; &gt; Maybe "rbnf" is more suitable here.
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; Thank you for making these XML updates as well.
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; = = = = = = = =
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; The latest files are posted here:
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275.txt
>>> &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275.pdf
>>> &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275.html
>>> &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275.xml
>>> &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275-diff.html
>>> &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275-alt-diff.html
>>> &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275-rfcdiff.html
>>> &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275-
>auth48diff.html
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275-xmldiff1.html
>>> &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275-xmldiff2.html
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; Thanks again!
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; RFC Editor/lb
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; On Aug 20, 2022, at 7:58 AM, [e-mail] wrote:
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Dear RFC Editor,
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Thanks a lot for the review! Please see our responses
>inline.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; In addition to the comments, we also find that multipart
>examples are missing the last boundary line.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; The attached XML adopts some of the changes
>(preferred <sourcecode> type, updated examples). Please let us know if there
>are further questions.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Best,
>>> &gt; &gt; &gt; &gt; Kai
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; -----Original Messages-----
>>> &gt; &gt; &gt; &gt; &gt; From: [e-mail]
>>> &gt; &gt; &gt; &gt; &gt; Sent Time: 2022-08-19 05:37:47 (Friday)
>>> &gt; &gt; &gt; &gt; &gt; To: [e-mail], [e-mail],
>[e-mail], [e-mail],
>[e-mail]
>>> &gt; &gt; &gt; &gt; &gt; Cc: [e-mail], [e-mail],
>[e-mail], [e-mail], [e-mail],
>[e-mail]
>>> &gt; &gt; &gt; &gt; &gt; Subject: Re: AUTH48: RFC-to-be 9275 <draft-ietf-
>alto-path-vector-25> for your review
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Authors,
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; While reviewing this document during AUTH48,
>please resolve (as necessary) the following questions, which are also in the
>XML file.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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 -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We confirm the items are addressed.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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 -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 3) <!-- [rfced] Please provide any keywords (beyond
>those that appear in the title) for use on <https://www.rfc-editor.org/search>.
>-->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Keywords: network visibility, abstract network element,
>shared bottleneck
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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.  -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Nice catch! Yes, it should be "specific components".
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Indeed the original sentence is a bit difficult to parse.
>We propose the following text:
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;     While numerical/ordinal cost values for end-to-end
>paths provided by
>>> &gt; &gt; &gt; &gt;     the existing extensions is sufficient to optimize the
>QoE of many
>>> &gt; &gt; &gt; &gt;     overlay applications, the QoE of some overlay
>applications also
>>> &gt; &gt; &gt; &gt;     depends on the properties of particular components
>on the paths.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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.
>>>>>>>> -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Sounds good.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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 -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; I tend to remove the command but keep the period as it
>is the end of the sentence. Other mentions of capacity region are in the
>middle of a sentence.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree it is better to use double dashes to be
>coherent with Figure 1.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; The term "intent" here is a bit misleading. "Data
>Transfer Intents" here should be interpreted as "potential data transfers that
>the clients intend to schedule". Maybe we can replace "Data Transfer Intents"
>with "Potential Data Transfers".
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; The term "SDN network intents" is from intent-based
>SDN. An intent is basically a request to the SDN system to route the traffic or
>make bandwidth reservations. Maybe we can add an informative reference to
>https://www.ietf.org/archive/id/draft-irtf-nmrg-ibn-concepts-definitions-
>04.html?
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Line 1138-1140:
>>> &gt; &gt; &gt; &gt; The content is a simple string. I am not sure which type
>fits the best here, though (maybe empty?).
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Line 1375-1379, Line 1420-1424, Line 1713-1717:
>>> &gt; &gt; &gt; &gt; The content is related to JSON but more like type
>definitions instead of data. Looks like "json-dtd" to me but I'm fine with using
>"json" here. By the way, I see in the XML of RFC 9240, such definitions are
>encoded as <artwork>. Maybe <artwork> could also be an option here?
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Line 1394-1413, Line 1626-1671, Line 1771-1790, Line
>1904-1949, Line 2170-2188, Line 2189-2239, Line 2310-2340, Line 2341-2409,
>Line 2422-2484, Line 2490-2505, Line 2509-2530, Line 2534-2540, Line 2583-
>2613, Line 2614-2676:
>>> &gt; &gt; &gt; &gt; It seems to me that "http-message" is more suitable
>here as the content contains the HTTP header.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Line 1519-1521, Line 1855-1857:
>>> &gt; &gt; &gt; &gt; Maybe "rbnf" is more suitable here.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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]). -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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)
>>>>>>>> ...
>>>>>>>> -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; I think we intend to say "Graphics Processing Unit" here.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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). --
>>
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We prefer suggestion #2.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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). -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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). -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; The idea is that all ANEs that appear in the path vector
>response are "ephemeral". Some ephemeral ANEs may represent a network
>component (i.e., persistent ANE) whose properties can be queried from
>another entity map service.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We propose the following text:
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;    This document enables the discovery of a persistent
>ANE by
>>> &gt; &gt; &gt; &gt;    by exposing its entity identifier as the persistent entity
>ID
>>> &gt; &gt; &gt; &gt;    property of an ephemeral ANE in the path vector
>response.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Yes, please use "guidance".
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; It is "permits parameters both with and without double
>quotes".
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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 ... -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed changes.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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]. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed changes. The other "root
>object" should be replaced with "object root" or "root body part" as well.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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" ] } -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Yes.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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; -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the change. For consistency, we propose
>to use the following terms (capitalize "C" in cost):
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; PVEndpointcostCapabilities =&gt;
>PVEndpointCostCapabilities
>>> &gt; &gt; &gt; &gt; PVFilteredCostMapCapabilities
>>> &gt; &gt; &gt; &gt; PVReqEndpointCost =&gt; PVReqEndpointCostMap
>>> &gt; &gt; &gt; &gt; PVReqEndpointcost =&gt; PVReqEndpointCostMap
>>> &gt; &gt; &gt; &gt; PVReqFilteredCostMap
>>> &gt; &gt; &gt; &gt; ReqEndpointCost =&gt; ReqEndpointCostMap
>>> &gt; &gt; &gt; &gt; ReqEndpointcostMap =&gt; ReqEndpointCostMap
>>> &gt; &gt; &gt; &gt; ReqFilteredCostMap
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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: -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We propose the following text:
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;   *  "multicost-pv": A multipart Endpoint Cost Service
>with both the
>>> &gt; &gt; &gt; &gt;      Multi-Cost extension and Path Vector extension
>enabled.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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". -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the propose change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed changes.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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]). -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; The reference should be Section 8.3 of RFC 9240, which
>says:
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;      If it is absent, the Server returns a property
>>> &gt; &gt; &gt; &gt;      value equal to the literal string "{}" for all the entity
>>> &gt; &gt; &gt; &gt;      identifiers of the "entities" field for which at least one
>>> &gt; &gt; &gt; &gt;      property is defined.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; and we propose the following changes:
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; OLD EXAMPLE:
>>> &gt; &gt; &gt; &gt;   {
>>> &gt; &gt; &gt; &gt;     "meta": {
>>> &gt; &gt; &gt; &gt;       "dependent-vtags": [
>>> &gt; &gt; &gt; &gt;         {
>>> &gt; &gt; &gt; &gt;           "resource-id": "filtered-cost-map-pv.costmap",
>>> &gt; &gt; &gt; &gt;           "tag": "d827f484cb66ce6df6b5077cb8562b0a"
>>> &gt; &gt; &gt; &gt;         }
>>> &gt; &gt; &gt; &gt;       ]
>>> &gt; &gt; &gt; &gt;     },
>>> &gt; &gt; &gt; &gt;     "property-map": {
>>> &gt; &gt; &gt; &gt;     }
>>> &gt; &gt; &gt; &gt;   }
>>> &gt; &gt; &gt; &gt; NEW EXAMPLE:
>>> &gt; &gt; &gt; &gt;   {
>>> &gt; &gt; &gt; &gt;     "meta": {
>>> &gt; &gt; &gt; &gt;       "dependent-vtags": [
>>> &gt; &gt; &gt; &gt;         {
>>> &gt; &gt; &gt; &gt;           "resource-id": "filtered-cost-map-pv.costmap",
>>> &gt; &gt; &gt; &gt;           "tag": "d827f484cb66ce6df6b5077cb8562b0a"
>>> &gt; &gt; &gt; &gt;         }
>>> &gt; &gt; &gt; &gt;       ]
>>> &gt; &gt; &gt; &gt;     },
>>> &gt; &gt; &gt; &gt;     "property-map": {
>>> &gt; &gt; &gt; &gt;       ".ane:L1": {},
>>> &gt; &gt; &gt; &gt;       ".ane:L2": {}
>>> &gt; &gt; &gt; &gt;     }
>>> &gt; &gt; &gt; &gt;   }
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; NEW TEXT:
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;   The second part returns the property map. Note that
>the
>>> &gt; &gt; &gt; &gt;   properties of the ANE entries is equal to the literal
>>> &gt; &gt; &gt; &gt;   string "{}" (See Section 8.3 of [RFC9240]). --&gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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.
>>>>>>>>
>>>>>>>
>>>>>>> It should be NET3, L1 and NET1.
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>> It should be NET2.
>>>>>>>
>>>>>>>> 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" -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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> -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed changes.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Yes, the text is referring to the ALTO Cost Calendar
>extension (RFC 8896).
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; It refers to upgrading to HTTP/2 and HTTP/3.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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) -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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.-->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed changes.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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]. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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.  -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; Yes, an example is Section 10.9 of RFC 9240, where the
>ANE name is following a schema of "[datacenter-id]-[cluster-id]". However,
>there is no bis or I-D in progress yet. We probably need to discuss this with AD
>and the chairs. We propose the following text:
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;    If a naming schema is used to generate ANE names,
>either
>>> &gt; &gt; &gt; &gt;    used privately or standardized by a future extension,
>how
>>> &gt; &gt; &gt; &gt;    (or if) the naming schema relates to private
>information
>>> &gt; &gt; &gt; &gt;    and network proximity must be explained to ALTO
>implementers
>>> &gt; &gt; &gt; &gt;    and service providers.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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]. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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]. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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>. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; The DOI for the reference should be:
>https://doi.org/10.1109/TNET.2019.2899905
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; The TON version includes an encoding of the messages
>and should be used.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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>. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the proposed change.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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
>>>>>>>> -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We intend to only keep Qiao Xiang in the second
>paragraph.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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. -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; No changes are needed.
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; 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)
>>>>>>>>
>>>>>>>
>>>>>>> We agree with the changes.
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>> We agree with the changes.
>>>>>>>
>>>>>>>> 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.
>>>>>>>> -->
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; We agree with the changes.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Thank you.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; RFC Editor/lb/jm
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; On 8/18/22 4:34 PM, [e-mail]
>wrote:
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; *****IMPORTANT*****
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Updated 2022/08/18
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; RFC Author(s):
>>> &gt; &gt; &gt; &gt; &gt; --------------
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Instructions for Completing AUTH48
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Your document has now entered AUTH48.  Once it
>has been reviewed and
>>> &gt; &gt; &gt; &gt; &gt; approved by you and all coauthors, it will be
>published as an RFC.
>>> &gt; &gt; &gt; &gt; &gt; If an author is no longer available, there are several
>remedies
>>> &gt; &gt; &gt; &gt; &gt; available as listed in the FAQ (https://www.rfc-
>editor.org/faq/).
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; You and you coauthors are responsible for
>engaging other parties
>>> &gt; &gt; &gt; &gt; &gt; (e.g., Contributors or Working Group) as necessary
>before providing
>>> &gt; &gt; &gt; &gt; &gt; your approval.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Planning your review
>>> &gt; &gt; &gt; &gt; &gt; ---------------------
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Please review the following aspects of your
>document:
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; *  RFC Editor questions
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    Please review and resolve any questions raised by
>the RFC Editor
>>> &gt; &gt; &gt; &gt; &gt;    that have been included in the XML file as
>comments marked as
>>> &gt; &gt; &gt; &gt; &gt;    follows:
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    <!-- [rfced] ... -->
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    These questions will also be sent in a subsequent
>email.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; *  Changes submitted by coauthors
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    Please ensure that you review any changes
>submitted by your
>>> &gt; &gt; &gt; &gt; &gt;    coauthors.  We assume that if you do not speak
>up that you
>>> &gt; &gt; &gt; &gt; &gt;    agree to changes submitted by your coauthors.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; *  Content
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    Please review the full content of the document, as
>this cannot
>>> &gt; &gt; &gt; &gt; &gt;    change once the RFC is published.  Please pay
>particular attention to:
>>> &gt; &gt; &gt; &gt; &gt;    - IANA considerations updates (if applicable)
>>> &gt; &gt; &gt; &gt; &gt;    - contact information
>>> &gt; &gt; &gt; &gt; &gt;    - references
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; *  Copyright notices and legends
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    Please review the copyright notice and legends as
>defined in
>>> &gt; &gt; &gt; &gt; &gt;    RFC 5378 and the Trust Legal Provisions
>>> &gt; &gt; &gt; &gt; &gt;    (TLP – https://trustee.ietf.org/license-info/).
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; *  Semantic markup
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    Please review the markup in the XML file to
>ensure that elements of
>>> &gt; &gt; &gt; &gt; &gt;    content are correctly tagged.  For example, ensure
>that <sourcecode>
>>> &gt; &gt; &gt; &gt; &gt;    and <artwork> are set correctly.  See details at
>>> &gt; &gt; &gt; &gt; &gt;    <https: authors.ietf.org="" rfcxml-vocabulary="">.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; *  Formatted output
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    Please review the PDF, HTML, and TXT files to
>ensure that the
>>> &gt; &gt; &gt; &gt; &gt;    formatted output, as generated from the markup
>in the XML file, is
>>> &gt; &gt; &gt; &gt; &gt;    reasonable.  Please note that the TXT will have
>formatting
>>> &gt; &gt; &gt; &gt; &gt;    limitations compared to the PDF and HTML.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Submitting changes
>>> &gt; &gt; &gt; &gt; &gt; ------------------
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; To submit changes, please reply to this email using
>‘REPLY ALL’ as all
>>> &gt; &gt; &gt; &gt; &gt; the parties CCed on this message need to see your
>changes. The parties
>>> &gt; &gt; &gt; &gt; &gt; include:
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    *  your coauthors
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    *  [e-mail] (the RPC team)
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    *  other document participants, depending on the
>stream (e.g.,
>>> &gt; &gt; &gt; &gt; &gt;       IETF Stream participants are your working group
>chairs, the
>>> &gt; &gt; &gt; &gt; &gt;       responsible ADs, and the document shepherd).
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;    *  [e-mail], which is a new
>archival mailing list
>>> &gt; &gt; &gt; &gt; &gt;       to preserve AUTH48 conversations; it is not an
>active discussion
>>> &gt; &gt; &gt; &gt; &gt;       list:
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;      *  More info:
>>> &gt; &gt; &gt; &gt; &gt;         https://mailarchive.ietf.org/arch/msg/ietf-
>announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;      *  The archive itself:
>>> &gt; &gt; &gt; &gt; &gt;
>https://mailarchive.ietf.org/arch/browse/auth48archive/
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;      *  Note: If only absolutely necessary, you may
>temporarily opt out
>>> &gt; &gt; &gt; &gt; &gt;         of the archiving of messages (e.g., to discuss a
>sensitive matter).
>>> &gt; &gt; &gt; &gt; &gt;         If needed, please add a note at the top of the
>message that you
>>> &gt; &gt; &gt; &gt; &gt;         have dropped the address. When the
>discussion is concluded,
>>> &gt; &gt; &gt; &gt; &gt;         [e-mail] will be re-added
>to the CC list and
>>> &gt; &gt; &gt; &gt; &gt;         its addition will be noted at the top of the
>message.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; You may submit your changes in one of two ways:
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; An update to the provided XML file
>>> &gt; &gt; &gt; &gt; &gt;  — OR —
>>> &gt; &gt; &gt; &gt; &gt; An explicit list of changes in this format
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Section # (or indicate Global)
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; OLD:
>>> &gt; &gt; &gt; &gt; &gt; old text
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; NEW:
>>> &gt; &gt; &gt; &gt; &gt; new text
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; You do not need to reply with both an updated XML
>file and an explicit
>>> &gt; &gt; &gt; &gt; &gt; list of changes, as either form is sufficient.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; We will ask a stream manager to review and
>approve any changes that seem
>>> &gt; &gt; &gt; &gt; &gt; beyond editorial in nature, e.g., addition of new
>text, deletion of text,
>>> &gt; &gt; &gt; &gt; &gt; and technical changes.  Information about stream
>managers can be found in
>>> &gt; &gt; &gt; &gt; &gt; the FAQ.  Editorial changes do not require approval
>from a stream manager.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Approving for publication
>>> &gt; &gt; &gt; &gt; &gt; --------------------------
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; To approve your RFC for publication, please reply
>to this email stating
>>> &gt; &gt; &gt; &gt; &gt; that you approve this RFC for publication.  Please
>use ‘REPLY ALL’,
>>> &gt; &gt; &gt; &gt; &gt; as all the parties CCed on this message need to see
>your approval.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Files
>>> &gt; &gt; &gt; &gt; &gt; -----
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; The files are available here:
>>> &gt; &gt; &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275.xml
>>> &gt; &gt; &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275.html
>>> &gt; &gt; &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275.pdf
>>> &gt; &gt; &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275.txt
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Diff file of the text:
>>> &gt; &gt; &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275-
>diff.html
>>> &gt; &gt; &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275-
>rfcdiff.html (side by side)
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Diff of the XML:
>>> &gt; &gt; &gt; &gt; &gt;    https://www.rfc-editor.org/authors/rfc9275-
>xmldiff1.html
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; The following files are provided to facilitate
>creation of your own
>>> &gt; &gt; &gt; &gt; &gt; diff files of the XML.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Initial XMLv3 created using XMLv2 as input:
>>> &gt; &gt; &gt; &gt; &gt;    https://www.rfc-
>editor.org/authors/rfc9275.original.v2v3.xml
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; XMLv3 file that is a best effort to capture v3-related
>format updates
>>> &gt; &gt; &gt; &gt; &gt; only:
>>> &gt; &gt; &gt; &gt; &gt;    https://www.rfc-
>editor.org/authors/rfc9275.form.xml
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Tracking progress
>>> &gt; &gt; &gt; &gt; &gt; -----------------
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; The details of the AUTH48 status of your document
>are here:
>>> &gt; &gt; &gt; &gt; &gt;    https://www.rfc-editor.org/auth48/rfc9275
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Please let us know if you have any questions.
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Thank you for your cooperation,
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; RFC Editor
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; --------------------------------------
>>> &gt; &gt; &gt; &gt; &gt; RFC9275 (draft-ietf-alto-path-vector-25)
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt; &gt; Title            : An ALTO Extension: Path Vector
>>> &gt; &gt; &gt; &gt; &gt; Author(s)        : K. Gao, Y. Lee, S. Randriamasy, Y.R.
>Yang, J. Zhang
>>> &gt; &gt; &gt; &gt; &gt; WG Chair(s)      : Jan Seedorf, Mohamed Boucadair,
>Qin Wu
>>> &gt; &gt; &gt; &gt; &gt; Area Director(s) : Martin Duke, Zaheduzzaman
>Sarker
>>> &gt; &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
>>> &gt; &gt; &gt; &gt;
></https:></artwork></sourcecode></artwork></artwork></draft-ietf-alto-
>path-vector-25></sourcecode><rfc9275.xml>
>>>
></rfc9275.xml></artwork></artwork></artwork></sourcecode></artwork></
>draft-ietf-alto-path-vector-25></[e-mail]></rfc-editor@rfc-
>editor.org></[e-mail]></draft-ietf-alto-path-vector-
>25></[e-mail]></rfc-editor@rfc-
>editor.org></[e-mail]>
>>