Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <draft-ietf-alto-path-vector-25> for your review
Lynne Bartholomew <lbartholomew@amsl.com> Thu, 25 August 2022 15:53 UTC
Return-Path: <lbartholomew@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370C7C157B37; Thu, 25 Aug 2022 08:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLhL7F7AQ1BX; Thu, 25 Aug 2022 08:53:12 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79DBCC15791D; Thu, 25 Aug 2022 08:53:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 290DB425C191; Thu, 25 Aug 2022 08:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ppe7MlMW3Hm; Thu, 25 Aug 2022 08:53:12 -0700 (PDT)
Received: from [IPv6:2601:646:8b00:70c0:69a2:d0f2:2f4d:2752] (unknown [IPv6:2601:646:8b00:70c0:69a2:d0f2:2f4d:2752]) by c8a.amsl.com (Postfix) with ESMTPSA id CCF524243E49; Thu, 25 Aug 2022 08:53:11 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Lynne Bartholomew <lbartholomew@amsl.com>
X-Priority: 3
In-Reply-To: <46a853f9.c3c1.182d4528897.Coremail.kaigao@scu.edu.cn>
Date: Thu, 25 Aug 2022 08:53:09 -0700
Cc: alto-ads@ietf.org, RFC System <rfc-editor@rfc-editor.org>, younglee.tx@gmail.com, sabine.randriamasy@nokia-bell-labs.com, yry@cs.yale.edu, jingxuan.n.zhang@gmail.com, alto-chairs@ietf.org, vijay.gurbani@gmail.com, Martin Duke <martin.h.duke@gmail.com>, auth48archive@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9673BC03-1130-4EC0-BCB1-2E7CACB3884B@amsl.com>
References: <20220818213747.F3B6316E4B8@rfcpa.amsl.com> <7d750c39.b0d1.182bbc39bd8.Coremail.kaigao@scu.edu.cn> <A3E064B8-7F26-4831-9422-CEA5B54DD4E8@amsl.com> <58cae015.bc17.182cd6c781b.Coremail.kaigao@scu.edu.cn> <EF7A0133-B3DE-4F81-BF2C-A1B154121736@amsl.com> <46a853f9.c3c1.182d4528897.Coremail.kaigao@scu.edu.cn>
To: kaigao@scu.edu.cn
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/AMDXcQGFZz0uquas9nbOqaths7U>
Subject: Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <draft-ietf-alto-path-vector-25> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Aug 2022 15:53:17 -0000
Hi, Kai. No worries, and thank you for confirming! RFC Editor/lb > On Aug 25, 2022, at 2:25 AM, kaigao@scu.edu.cn wrote: > > Hi Lynne, > > Sorry for the confusion. I have no further comments at this point. > > Thanks a lot! > > Best, > Kai > > > > -----Original Messages----- > > From: "Lynne Bartholomew" <lbartholomew@amsl.com> > > Sent Time: 2022-08-24 23:38:53 (Wednesday) > > To: kaigao@scu.edu.cn > > Cc: alto-ads@ietf.org, "RFC System" <rfc-editor@rfc-editor.org>, younglee.tx@gmail.com, sabine.randriamasy@nokia-bell-labs.com, yry@cs.yale.edu, jingxuan.n.zhang@gmail.com, alto-chairs@ietf.org, vijay.gurbani@gmail.com, "Martin Duke" <martin.h.duke@gmail.com>, auth48archive@rfc-editor.org > > Subject: Re: *[AD] Re: AUTH48: RFC-to-be 9275 <draft-ietf-alto-path-vector-25> for your review > > > > Hi, Kai. > > > > We found one new comment below -- your clarification regarding the boundary lines. Thank you for the explanation! > > > > If we missed any other new comments from you, please let us know. > > > > Thanks again! > > > > RFC Editor/lb > > > > > On Aug 23, 2022, at 6:16 PM, kaigao@scu.edu.cn wrote: > > > > > > Hi Lynne, > > > > > > Thanks for the updates! Please see the comments inline. > > > > > > > > > p.s. I switch to another edit mode on the mail client. Hope it handles the ">" correctly. > > > > > > > > > Best, > > > > > > Kai > > > > > > > > > > > > > -----Original Messages----- > > > > From: "Lynne Bartholomew" <lbartholomew@amsl.com> > > > > Sent Time: 2022-08-24 01:46:30 (Wednesday) > > > > To: kaigao@scu.edu.cn, alto-ads@ietf.org > > > > Cc: "RFC System" <rfc-editor@rfc-editor.org>, younglee.tx@gmail.com, sabine.randriamasy@nokia-bell-labs.com, yry@cs.yale.edu, jingxuan.n.zhang@gmail.com, alto-chairs@ietf.org, vijay.gurbani@gmail.com, "Martin Duke" <martin.h.duke@gmail.com>, auth48archive@rfc-editor.org > > > > Subject: *[AD] Re: AUTH48: RFC-to-be 9275 <draft-ietf-alto-path-vector-25> for your review > > > > > > > > Dear Kai and *AD (Zahed or Martin), > > > > > > > > * 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. > > > > > > > > Kai, thank you for your prompt reply and updated XML file! We have made further updates per your notes below. > > > > > > > > -- 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. > > > > > > > > > > We add a boundary line to each multipart example before recalculating the "Content-Length" value. > > > > > > > -- 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. > > > > > > > > -- Regarding our question 13) and your reply: We updated as follows; thank you for your advice on these as well: > > > > > > > > > Line 1138-1140: > > > > > The content is a simple string. I am not sure which type fits the best here, though (maybe empty?). > > > > > > > > Changed to <artwork>; <sourcecode> might not be appropriate for a simple string. > > > > > > > > > Line 1375-1379, Line 1420-1424, Line 1713-1717: > > > > > 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? > > > > > > > > Changed to <artwork> per the XML of RFC 9240. > > > > > > > > > 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: > > > > > It seems to me that "http-message" is more suitable here as the content contains the HTTP header. > > > > > > > > Thank you for making these updates in the XML. > > > > > > > > > Line 1519-1521, Line 1855-1857: > > > > > Maybe "rbnf" is more suitable here. > > > > > > > > Thank you for making these XML updates as well. > > > > > > > > = = = = = = = = > > > > > > > > The latest files are posted here: > > > > > > > > https://www.rfc-editor.org/authors/rfc9275.txt > > > > https://www.rfc-editor.org/authors/rfc9275.pdf > > > > https://www.rfc-editor.org/authors/rfc9275.html > > > > https://www.rfc-editor.org/authors/rfc9275.xml > > > > https://www.rfc-editor.org/authors/rfc9275-diff.html > > > > https://www.rfc-editor.org/authors/rfc9275-alt-diff.html > > > > https://www.rfc-editor.org/authors/rfc9275-rfcdiff.html > > > > https://www.rfc-editor.org/authors/rfc9275-auth48diff.html > > > > > > > > https://www.rfc-editor.org/authors/rfc9275-xmldiff1.html > > > > https://www.rfc-editor.org/authors/rfc9275-xmldiff2.html > > > > > > > > Thanks again! > > > > > > > > RFC Editor/lb > > > > > > > > > > > > > On Aug 20, 2022, at 7:58 AM, kaigao@scu.edu.cn wrote: > > > > > > > > > > Dear RFC Editor, > > > > > > > > > > Thanks a lot for the review! Please see our responses inline. > > > > > > > > > > In addition to the comments, we also find that multipart examples are missing the last boundary line. > > > > > > > > > > The attached XML adopts some of the changes (preferred <sourcecode> type, updated examples). Please let us know if there are further questions. > > > > > > > > > > Best, > > > > > Kai > > > > > > > > > > > > > > > > -----Original Messages----- > > > > > > From: rfc-editor@rfc-editor.org > > > > > > Sent Time: 2022-08-19 05:37:47 (Friday) > > > > > > To: kaigao@scu.edu.cn, younglee.tx@gmail.com, sabine.randriamasy@nokia-bell-labs.com, yry@cs.yale.edu, jingxuan.n.zhang@gmail.com > > > > > > Cc: rfc-editor@rfc-editor.org, alto-ads@ietf.org, alto-chairs@ietf.org, vijay.gurbani@gmail.com, martin.h.duke@gmail.com, auth48archive@rfc-editor.org > > > > > > Subject: Re: AUTH48: RFC-to-be 9275 <draft-ietf-alto-path-vector-25> for your review > > > > > > > > > > > > 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 --> > > > > > > > > > > > > > > > > We confirm the items are addressed. > > > > > > > > > > > > > > > > > 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 --> > > > > > > > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > 3) <!-- [rfced] Please provide any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. --> > > > > > > > > > > > > > > > > > > > > > > Keywords: network visibility, abstract network element, shared bottleneck > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > Nice catch! Yes, it should be "specific components". > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > Indeed the original sentence is a bit difficult to parse. We propose the following text: > > > > > > > > > > While numerical/ordinal cost values for end-to-end paths provided by > > > > > the existing extensions is sufficient to optimize the QoE of many > > > > > overlay applications, the QoE of some overlay applications also > > > > > depends on the properties of particular components on the paths. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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. >>>>>> --> > > > > > > > > > > > > > > > > > > > > > > Sounds good. > > > > > > > > > > > 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 --> > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > > > > > > > We agree it is better to use double dashes to be coherent with Figure 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. --> > > > > > > > > > > > > > > > > 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". > > > > > > > > > > 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? > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > Line 1138-1140: > > > > > The content is a simple string. I am not sure which type fits the best here, though (maybe empty?). > > > > > > > > > > Line 1375-1379, Line 1420-1424, Line 1713-1717: > > > > > 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? > > > > > > > > > > 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: > > > > > It seems to me that "http-message" is more suitable here as the content contains the HTTP header. > > > > > > > > > > Line 1519-1521, Line 1855-1857: > > > > > Maybe "rbnf" is more suitable here. > > > > > > > > > > > > > > > > > 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]). --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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) >>>>>> ... >>>>>> --> > > > > > > > > > > > > > > > > We agree with the change. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > We agree with the change. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > I think we intend to say "Graphics Processing Unit" here. > > > > > > > > > > > > > > > > > 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). --> > > > > > > > > > > > > > > > > We prefer suggestion #2. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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). --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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). --> > > > > > > > > > > > > > > > > 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. > > > > > > > > > > We propose the following text: > > > > > > > > > > This document enables the discovery of a persistent ANE by > > > > > by exposing its entity identifier as the persistent entity ID > > > > > property of an ephemeral ANE in the path vector response. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > Yes, please use "guidance". > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > > > > > > > It is "permits parameters both with and without 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 ... --> > > > > > > > > > > > > > > > > We agree with the proposed changes. > > > > > > > > > > > > > > > > > 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]. --> > > > > > > > > > > > > > > > > We agree with the proposed changes. The other "root object" should be replaced with "object root" or "root body part" as well. > > > > > > > > > > > > > > > > > 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" ] } --> > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > > > > 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; --> > > > > > > > > > > > > > > > > We agree with the change. For consistency, we propose to use the following terms (capitalize "C" in cost): > > > > > > > > > > PVEndpointcostCapabilities => PVEndpointCostCapabilities > > > > > PVFilteredCostMapCapabilities > > > > > PVReqEndpointCost => PVReqEndpointCostMap > > > > > PVReqEndpointcost => PVReqEndpointCostMap > > > > > PVReqFilteredCostMap > > > > > ReqEndpointCost => ReqEndpointCostMap > > > > > ReqEndpointcostMap => ReqEndpointCostMap > > > > > ReqFilteredCostMap > > > > > > > > > > > > > > > > > 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: --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > We propose the following text: > > > > > > > > > > * "multicost-pv": A multipart Endpoint Cost Service with both the > > > > > Multi-Cost extension and Path Vector extension enabled. > > > > > > > > > > > > > > > > > 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". --> > > > > > > > > > > > > > > > > We agree with the propose change. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > We agree with the proposed changes. > > > > > > > > > > > > > > > > > 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]). --> > > > > > > > > > > > > > > > > The reference should be Section 8.3 of RFC 9240, which says: > > > > > > > > > > If it is absent, the Server returns a property > > > > > value equal to the literal string "{}" for all the entity > > > > > identifiers of the "entities" field for which at least one > > > > > property is defined. > > > > > > > > > > and we propose the following changes: > > > > > > > > > > OLD EXAMPLE: > > > > > { > > > > > "meta": { > > > > > "dependent-vtags": [ > > > > > { > > > > > "resource-id": "filtered-cost-map-pv.costmap", > > > > > "tag": "d827f484cb66ce6df6b5077cb8562b0a" > > > > > } > > > > > ] > > > > > }, > > > > > "property-map": { > > > > > } > > > > > } > > > > > NEW EXAMPLE: > > > > > { > > > > > "meta": { > > > > > "dependent-vtags": [ > > > > > { > > > > > "resource-id": "filtered-cost-map-pv.costmap", > > > > > "tag": "d827f484cb66ce6df6b5077cb8562b0a" > > > > > } > > > > > ] > > > > > }, > > > > > "property-map": { > > > > > ".ane:L1": {}, > > > > > ".ane:L2": {} > > > > > } > > > > > } > > > > > > > > > > NEW TEXT: > > > > > > > > > > The second part returns the property map. Note that the > > > > > properties of the ANE entries is equal to the literal > > > > > string "{}" (See Section 8.3 of [RFC9240]). --> > > > > > > > > > > > > > > > > > 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" --> > > > > > > > > > > > > > > > > > > 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, ecspvsub1.ecsmap@alto.example.com >>>>>> data: <Merge patch for endpoint-cost-map-update> >>>>>> >>>>>> event: application/merge-patch+json, ecspvsub1.propmap@alto.example.com >>>>>> data: <Merge patch for property-map-update> >>>>>> >>>>>> Suggested: >>>>>> event: application/merge-patch+json, >>>>>> ecspvsub1.ecsmap@alto.example.com >>>>>> data: <Merge patch for endpoint-cost-map-update> >>>>>> >>>>>> event: application/merge-patch+json, >>>>>> ecspvsub1.propmap@alto.example.com >>>>>> data: <Merge patch for property-map-update> --> > > > > > > > > > > > > > > > > > > > > > > We agree with the proposed changes. > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > Yes, the text is referring to the ALTO Cost Calendar extension (RFC 8896). > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > It refers to upgrading to HTTP/2 and HTTP/3. > > > > > > > > > > > > > > > > > 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) --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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.--> > > > > > > > > > > > > > > > > We agree with the proposed changes. > > > > > > > > > > > > > > > > > 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]. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > 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: > > > > > > > > > > If a naming schema is used to generate ANE names, either > > > > > used privately or standardized by a future extension, how > > > > > (or if) the naming schema relates to private information > > > > > and network proximity must be explained to ALTO implementers > > > > > and service providers. > > > > > > > > > > > > > > > > > > > > > > 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]. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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]. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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>. --> > > > > > > > > > > > > > > > > The DOI for the reference should be: https://doi.org/10.1109/TNET.2019.2899905 > > > > > > > > > > The TON version includes an encoding of the messages and should be used. > > > > > > > > > > > > > > > > > 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>. --> > > > > > > > > > > > > > > > > We agree with the proposed change. > > > > > > > > > > > > > > > > > 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 >>>>>> --> > > > > > > > > > > > > > > > > We intend to only keep Qiao Xiang in the second paragraph. > > > > > > > > > > > > > > > > > 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. --> > > > > > > > > > > > > > > > > > > > > > > No 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) >>>>>> >>>>> >>>>> 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. >>>>>> --> > > > > > > > > > > We agree with the changes. > > > > > > > > > > > > > > > > > > Thank you. > > > > > > > > > > > > RFC Editor/lb/jm > > > > > > > > > > > > > > > > > > On 8/18/22 4:34 PM, rfc-editor@rfc-editor.org 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 > > > > > > > > > > > > * rfc-editor@rfc-editor.org (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). > > > > > > > > > > > > * auth48archive@rfc-editor.org, 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, > > > > > > auth48archive@rfc-editor.org 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 > > > > > > > > > > > > > > > > > > > > > </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></martin.h.duke@gmail.com></rfc-editor@rfc-editor.org></lbartholomew@amsl.com></draft-ietf-alto-path-vector-25></martin.h.duke@gmail.com></rfc-editor@rfc-editor.org></lbartholomew@amsl.com>
- [auth48] AUTH48: RFC-to-be 9275 <draft-ietf-alto-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9275 <draft-ietf-a… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9275 <draft-ietf-a… kaigao
- [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <draft-… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… kaigao
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… kaigao
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… kaigao
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Martin Duke
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Jensen Zhang
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Young Lee
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Sandy Ginoza
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Y. Richard Yang
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Sandy Ginoza
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <dr… Y. Richard Yang