Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9275 <draft-ietf-alto-path-vector-25> for your review
Martin Duke <martin.h.duke@gmail.com> Tue, 06 September 2022 14:59 UTC
Return-Path: <martin.h.duke@gmail.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 17FE1C152596; Tue, 6 Sep 2022 07:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 S0VFN3eHOu2v; Tue, 6 Sep 2022 07:59:37 -0700 (PDT)
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 57B83C14CF0C; Tue, 6 Sep 2022 07:59:37 -0700 (PDT)
Received: by mail-qv1-xf33.google.com with SMTP id s13so5314001qvq.10; Tue, 06 Sep 2022 07:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=UxD9Hmjb4BJBjNTeTIsStZziR9vPl7qr1L6E0ZRsIgA=; b=dX86coH6ZZhsav4M+nKHHw5sugFqce85biepzGR80x9DEEVTbOABJBM5ckqHZMkJQa bLwDLHgf5ZnboCLbrBKfbOZEizhuEkSXt92SRJBchjFQwlTNa8C3IUBptQtcp27VPY+Q r/eVYDCV3MZh1TqdTs56EflJhyuXhMk64b64uW7QUF6W7i0vUri/r7KIP8FM+yxub/ou gPNb60QuZ9MUj0zPaIZxU/bTq9sOERHX0iQwt0s5Ux2MOjJwL3Xe32b9oh2IJCMNNypK 04X2LoBcmeX8G7wFurHL2I8oXs3m0bgknBK/KZwy5+kwwHjS1YlAi8zr2vcSmSdxFPaq wwYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=UxD9Hmjb4BJBjNTeTIsStZziR9vPl7qr1L6E0ZRsIgA=; b=cQZYaKORhsKJk6R3loDGU57nQznZtOwKl5rHRVw23JC/hPxHC51N5I1ma++D02yk4z pj48fjiHcQNRyK2nla5iP0Il0nRFeqvmiov4KJHOg6c0sZFb3XqyyUK8T5+1J2qM9Hdq yx7apT3rrkCDCS+H503iJj7tomwXirsaJhPL7UHwteQ5gn4ZZkN3prWudRJMGlvDYsX1 p/bu/u8GGk1L4WqA9RkkOVMdwHqZwJLwTfclYkDd/Ocw2kNdaY7kSyThff7b85q3SNrA cQh7HHmsT1s9Hjj3FJeZZKckDe0UKwULM+mZC+FidX2UQVe3Vlzdl/3ic98ZnufaPnGW HwYA==
X-Gm-Message-State: ACgBeo0F9gRcUWxnrQG3EegH2778OYGv7JUkQG6aWTuZPlSiEtpHF+lh g3Qsbbwgl3l6M1l3+tmBuoTAaKxxsxqqmMUt8JY=
X-Google-Smtp-Source: AA6agR67LWO3S3KmHKmbHQFswHonXnbk1ViY/oakGBrtObpYTzSJ2jjdq3Oi/ktBRws5RZMRyNS8qnko1egotYM3T/Q=
X-Received: by 2002:a05:6214:519d:b0:498:fe52:d14b with SMTP id kl29-20020a056214519d00b00498fe52d14bmr39407432qvb.120.1662476375672; Tue, 06 Sep 2022 07:59:35 -0700 (PDT)
MIME-Version: 1.0
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> <9673BC03-1130-4EC0-BCB1-2E7CACB3884B@amsl.com> <E20433E2-2645-4AB3-8BC1-5578A412091E@amsl.com> <8c880ef.f6da.18310fad1c1.Coremail.kaigao@scu.edu.cn>
In-Reply-To: <8c880ef.f6da.18310fad1c1.Coremail.kaigao@scu.edu.cn>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 06 Sep 2022 07:59:19 -0700
Message-ID: <CAM4esxRJ6jPeD70hbv7xaA78UAXe8EqxvLhfh_wxk1puuV55Gw@mail.gmail.com>
To: Kai Gao <kaigao@scu.edu.cn>
Cc: Lynne Bartholomew <lbartholomew@amsl.com>, Young Lee <younglee.tx@gmail.com>, "Randriamasy, Sabine (Nokia - FR)" <sabine.randriamasy@nokia-bell-labs.com>, "Y. Richard Yang" <yry@cs.yale.edu>, Jensen Zhang <jingxuan.n.zhang@gmail.com>, alto-ads@ietf.org, RFC System <rfc-editor@rfc-editor.org>, alto-chairs <alto-chairs@ietf.org>, Vijay Gurbani <vijay.gurbani@gmail.com>, auth48archive@rfc-editor.org
Content-Type: multipart/alternative; boundary="000000000000d1cd1705e8037162"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/9WE7ec8T_5DRSo4zUq69EoQnfpM>
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: Tue, 06 Sep 2022 14:59:42 -0000
LGTM On Mon, Sep 5, 2022 at 9:07 PM <kaigao@scu.edu.cn> wrote: > Hi Lynne, > > I approve the document once we get confirmation from the AD. Thanks a lot! > > Best, > Kai > > > > -----Original Messages----- > > From: "Lynne Bartholomew" <lbartholomew@amsl.com> > > Sent Time: 2022-09-03 01:46:41 (Saturday) > > To: kaigao@scu.edu.cn, younglee.tx@gmail.com, > sabine.randriamasy@nokia-bell-labs.com, yry@cs.yale.edu, > jingxuan.n.zhang@gmail.com, alto-ads@ietf.org > > Cc: "RFC System" <rfc-editor@rfc-editor.org>, 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 > > > > 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 < > lbartholomew@amsl.com> wrote: > > > > > > 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? > > > <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 > > <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 > > > <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>>; > >> > > > > > > > >> > > > > > * The archive itself: > > >> > > > > > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > <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 > > <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> > > > > </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