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
>
>
> &gt; -----Original Messages-----
> &gt; From: "Lynne Bartholomew" <lbartholomew@amsl.com>
> &gt; Sent Time: 2022-09-03 01:46:41 (Saturday)
> &gt; 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
> &gt; 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
> &gt; Subject: Re: *[AD]  Re: AUTH48: RFC-to-be 9275
> <draft-ietf-alto-path-vector-25> for your review
> &gt;
> &gt; Dear authors and *AD,
> &gt;
> &gt; Checking in with you regarding the status of this document.  Please
> let us know whether further changes are needed.
> &gt;
> &gt; The AUTH48 status page is here:
> &gt;
> &gt;    https://www.rfc-editor.org/auth48/rfc9275
> &gt;
> &gt; If no further changes are needed, please note that we will need
> explicit approvals from each of you.
> &gt;
> &gt; Thank you!
> &gt;
> &gt; RFC Editor/lb
> &gt;
> &gt; &gt; On Aug 25, 2022, at 8:53 AM, Lynne Bartholomew <
> lbartholomew@amsl.com> wrote:
> &gt; &gt;
> &gt; &gt; Hi, Kai.  No worries, and thank you for confirming!
> &gt; &gt;
> &gt; &gt; RFC Editor/lb
> &gt; &gt;
> &gt; &gt;&gt; On Aug 25, 2022, at 2:25 AM, kaigao@scu.edu.cn wrote:
> &gt; &gt;&gt;
> &gt; &gt;&gt; Hi Lynne,
> &gt; &gt;&gt;
> &gt; &gt;&gt; Sorry for the confusion. I have no further comments at this
> point.
> &gt; &gt;&gt;
> &gt; &gt;&gt; Thanks a lot!
> &gt; &gt;&gt;
> &gt; &gt;&gt; Best,
> &gt; &gt;&gt; Kai
> &gt; &gt;&gt;
> &gt; &gt;&gt;
> &gt; &gt;&gt; &gt; -----Original Messages-----
> &gt; &gt;&gt; &gt; From: "Lynne Bartholomew" <lbartholomew@amsl.com>
> &gt; &gt;&gt; &gt; Sent Time: 2022-08-24 23:38:53 (Wednesday)
> &gt; &gt;&gt; &gt; To: kaigao@scu.edu.cn
> &gt; &gt;&gt; &gt; 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
> &gt; &gt;&gt; &gt; Subject: Re: *[AD]  Re: AUTH48: RFC-to-be 9275
> <draft-ietf-alto-path-vector-25> for your review
> &gt; &gt;&gt; &gt;
> &gt; &gt;&gt; &gt; Hi, Kai.
> &gt; &gt;&gt; &gt;
> &gt; &gt;&gt; &gt; We found one new comment below -- your clarification
> regarding the boundary lines.  Thank you for the explanation!
> &gt; &gt;&gt; &gt;
> &gt; &gt;&gt; &gt; If we missed any other new comments from you, please
> let us know.
> &gt; &gt;&gt; &gt;
> &gt; &gt;&gt; &gt; Thanks again!
> &gt; &gt;&gt; &gt;
> &gt; &gt;&gt; &gt; RFC Editor/lb
> &gt; &gt;&gt; &gt;
> &gt; &gt;&gt; &gt; &gt; On Aug 23, 2022, at 6:16 PM, kaigao@scu.edu.cn
> wrote:
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; Hi Lynne,
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; Thanks for the updates! Please see the comments
> inline.
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; p.s. I switch to another edit mode on the mail
> client. Hope it handles the "&gt;" correctly.
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; Best,
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; Kai
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; -----Original Messages-----
> &gt; &gt;&gt; &gt; &gt; &gt; From: "Lynne Bartholomew" <
> lbartholomew@amsl.com>
> &gt; &gt;&gt; &gt; &gt; &gt; Sent Time: 2022-08-24 01:46:30 (Wednesday)
> &gt; &gt;&gt; &gt; &gt; &gt; To: kaigao@scu.edu.cn, alto-ads@ietf.org
> &gt; &gt;&gt; &gt; &gt; &gt; 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
> &gt; &gt;&gt; &gt; &gt; &gt; Subject: *[AD]  Re: AUTH48: RFC-to-be 9275
> <draft-ietf-alto-path-vector-25> for your review
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; Dear Kai and *AD (Zahed or Martin),
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; * Zahed or Martin, as we don't know whether
> (1) the changes to "Content-Length:" values and (2) the updated
> '"property-map": {' entry at the end of Section 8.3 would be considered
> editorial or technical, please review, and let us know if you approve these
> updates.
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; Kai, thank you for your prompt reply and
> updated XML file!  We have made further updates per your notes below.
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; -- It appears that "we also find that
> multipart examples are missing the last boundary line" refers to the
> changes to "Content-Length:" values.  If we misunderstand this note, please
> clarify.
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; We add a boundary line to each multipart example
> before recalculating the "Content-Length" value.
> &gt; &gt;&gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; -- Regarding our question 11) (the meaning of
> "intents"):  We have added a citation and Informative Reference entry for
> draft-irtf-nmrg-ibn-concepts-definitions; thank you for the suggestion.
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; -- Regarding our question 13) and your
> reply:  We updated as follows; thank you for your advice on these as well:
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Line 1138-1140:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; The content is a simple string. I am not
> sure which type fits the best here, though (maybe empty?).
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; Changed to <artwork>; <sourcecode> might not
> be appropriate for a simple string.
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Line 1375-1379, Line 1420-1424, Line
> 1713-1717:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; The content is related to JSON but more
> like type definitions instead of data. Looks like "json-dtd" to me but I'm
> fine with using "json" here. By the way, I see in the XML of RFC 9240, such
> definitions are encoded as <artwork>. Maybe <artwork> could also be an
> option here?
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; Changed to <artwork> per the XML of RFC 9240.
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Line 1394-1413, Line 1626-1671, Line
> 1771-1790, Line 1904-1949, Line 2170-2188, Line 2189-2239, Line 2310-2340,
> Line 2341-2409, Line 2422-2484, Line 2490-2505, Line 2509-2530, Line
> 2534-2540, Line 2583-2613, Line 2614-2676:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; It seems to me that "http-message" is
> more suitable here as the content contains the HTTP header.
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; Thank you for making these updates in the XML.
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Line 1519-1521, Line 1855-1857:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Maybe "rbnf" is more suitable here.
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; Thank you for making these XML updates as
> well.
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; = = = = = = = =
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; The latest files are posted here:
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275.txt
> &gt; &gt;&gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275.pdf
> &gt; &gt;&gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275.html
> &gt; &gt;&gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275.xml
> &gt; &gt;&gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275-diff.html
> &gt; &gt;&gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275-alt-diff.html
> &gt; &gt;&gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275-rfcdiff.html
> &gt; &gt;&gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275-auth48diff.html
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275-xmldiff1.html
> &gt; &gt;&gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275-xmldiff2.html
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; Thanks again!
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; RFC Editor/lb
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; On Aug 20, 2022, at 7:58 AM,
> kaigao@scu.edu.cn wrote:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Dear RFC Editor,
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Thanks a lot for the review! Please see
> our responses inline.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; In addition to the comments, we also
> find that multipart examples are missing the last boundary line.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; The attached XML adopts some of the
> changes (preferred <sourcecode> type, updated examples). Please let us know
> if there are further questions.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Best,
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Kai
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; -----Original Messages-----
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; From: rfc-editor@rfc-editor.org
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Sent Time: 2022-08-19 05:37:47
> (Friday)
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; To: kaigao@scu.edu.cn,
> younglee.tx@gmail.com, sabine.randriamasy@nokia-bell-labs.com,
> yry@cs.yale.edu, jingxuan.n.zhang@gmail.com
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 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
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: AUTH48: RFC-to-be 9275
> <draft-ietf-alto-path-vector-25> for your review
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Authors,
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; While reviewing this document
> during AUTH48, please resolve (as necessary) the following questions, which
> are also in the XML file.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 1) <!-- [rfced] We found the
> following "TODO" and "FIXME" comments in
> > >>>>>>> the provided XML file.  Please confirm that the following items
> were
> > >>>>>>> addressed.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> TODO: Error Handling
> > >>>>>>> ...
> > >>>>>>> TODO: the remaining issue is where to specify the
> json-merge-patch
> > >>>>>>> capability for each node
> > >>>>>>> ...
> > >>>>>>> FIXME: path-vector cannot be used in multi-cost, also no reason
> > >>>>>>> ...
> > >>>>>>> FIXME: using resource-id header in MIME part -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We confirm the items are addressed.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 2) <!-- [rfced] FYI, we updated the
> document title to follow the style of the published companion document RFC
> 9240.  Please let us know any concerns.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> An ALTO Extension: Path Vector
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> An Extension for Application-Layer Traffic Optimization (ALTO):
> > >>>>>>>                         Path Vector -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 3) <!-- [rfced] Please provide any
> keywords (beyond those that appear in the title) for use on <
> https://www.rfc-editor.org/search>. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Keywords: network visibility, abstract
> network element, shared bottleneck
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 4) <!-- [rfced] Abstract: In the
> following sentence, should "specified components" be instead "specific
> components"?
> > >>>>>>>
> > >>>>>>> Current:
> > >>>>>>> This is useful for applications whose performance is impacted
> > >>>>>>> by specified components of a network on the end-to-end paths,
> e.g.,
> > >>>>>>> they may infer that several paths share common links and prevent
> > >>>>>>> traffic bottlenecks by avoiding such paths.  -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Nice catch! Yes, it should be "specific
> components".
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 5) <!-- [rfced] Section 1: Does
> reordering the end of the following sentence improve readability?
> > >>>>>>>
> > >>>>>>> Current:
> > >>>>>>> While the existing extensions are sufficient for many overlay
> > >>>>>>> applications, the QoE of some overlay applications depends not
> only
> > >>>>>>> on the cost information for end-to-end paths but also on
> particular
> > >>>>>>> components of a network on the paths and their properties.
> > >>>>>>>
> > >>>>>>> Perhaps:
> > >>>>>>> While the existing extensions are sufficient for many overlay
> > >>>>>>> applications, the QoE of some overlay applications depends not
> only
> > >>>>>>> on the cost information for end-to-end paths but also on
> particular
> > >>>>>>> components and their properties on the paths of a network. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Indeed the original sentence is a bit
> difficult to parse. We propose the following text:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     While numerical/ordinal cost values
> for end-to-end paths provided by
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     the existing extensions is
> sufficient to optimize the QoE of many
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     overlay applications, the QoE of
> some overlay applications also
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     depends on the properties of
> particular components on the paths.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 6) <!-- [rfced] Section 1: We had
> trouble following this sentence. Does making the sentence more parallel
> improve readability?
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> Despite the claimed benefits, ISPs are not likely to expose raw
> > >>>>>>> details on their network paths: first for the sake of topology
> hiding
> > >>>>>>> requirement, second because it may increase volume and
> computation
> > >>>>>>> overhead, and last because applications do not necessarily need
> all
> > >>>>>>> the network path details and are likely not able to understand
> them.
> > >>>>>>>
> > >>>>>>> Suggested (using the "because" construction for the first reason
> and clarifying who has the topology-hiding requirement and what things may
> increase volume and overhead):
> > >>>>>>> Despite the claimed benefits, ISPs are not likely to expose raw
> > >>>>>>> details on their network paths: first because ISPs have
> requirements
> > >>>>>>> to hide their network topologies, second because these details
> may
> > >>>>>>> increase volume and computation overhead, and last because
> applications
> > >>>>>>> do not necessarily need all the network path details and are
> likely not
> > >>>>>>> able to understand them. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 7) <!-- [rfced] Sections 1, 3, and
> 5: FYI, we have updated the extension label "Unified Property Map" to
> "entity property map" to match the label used by RFC 9240 (previously
> draft-ietf-alto-unified-props-new), which defines the extension.  Please
> review these updates and let us know if any changes are necessary. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 8) <!-- [rfced] Section 2: FYI, we
> have removed the second sentence as it is already covered in RFC 8174:
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT",
> > >>>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
> and
> > >>>>>>> "OPTIONAL" in this document are to be interpreted as described in
> > >>>>>>> BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in
> all
> > >>>>>>> capitals, as shown here.
> > >>>>>>>
> > >>>>>>> When the words appear in lower case, they are to be interpreted
> with
> > >>>>>>> their natural language meanings.
> > >>>>>>> -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Sounds good.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 9) <!-- [rfced] Section 4.1:  Is
> the punctuation (the comma and the
> > >>>>>>> period after "Mbps") needed?  We ask because we do not see any
> > >>>>>>> punctuation following the next two such entries after mention of
> > >>>>>>> "capacity region".
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> x <= 100 Mbps,
> > >>>>>>> y <= 100 Mbps.
> > >>>>>>>
> > >>>>>>> Perhaps:
> > >>>>>>> x <= 100 Mbps
> > >>>>>>> y <= 100 Mbps -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; I tend to remove the command but keep
> the period as it is the end of the sentence. Other mentions of capacity
> region are in the middle of a sentence.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 10) <!-- [rfced] Section 4.1:
> Please review the use of "->" and " - " in this section. Should the " - "
> pairs below use double dashes (like shown in Figure 1) to more clearly
> indicate that bandwidth between directly connected nodes is being discussed?
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> *  The ALTO server must allow the client to distinguish the
> common
> > >>>>>>>  ANE shared by "eh1 -> eh2" and "eh1 -> eh4", e.g., "eh1 - sw1"
> and
> > >>>>>>>  "sw1 - sw5" in Case 1.
> > >>>>>>>
> > >>>>>>> *  The ALTO server must expose abstract information on the
> properties
> > >>>>>>>  of the ANEs used by "eh1 -> eh2" and "eh1 -> eh4".  For example,
> > >>>>>>>  an ALTO server can either expose the available bandwidth between
> > >>>>>>>  "eh1 - sw1", "sw1 - sw5", "sw5 - sw7", "sw5 - sw6", "sw6 - sw7",
> > >>>>>>>  "sw7 - sw2", "sw7 - sw4", "sw2 - eh2", "sw4 - eh4" in Case 1, or
> > >>>>>>>  expose 3 abstract elements "A", "B" and "C", which represent the
> > >>>>>>>  linear constraints that define the same capacity region in Case
> 1. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree it is better to use double
> dashes to be coherent with Figure 1.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 11) <!-- [rfced] Figure 3 and
> Section 6.4.1:  We had trouble following
> > >>>>>>> the meaning of "intents".  Do "Data Transfer Intents" and "SDN
> > >>>>>>> network intents" mean "Intent-Based Data Transfer" and
> > >>>>>>> "Intent-Based SDN" or something else?
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> ...
> > >>>>>>>        |   |                  On-demand resource   |
> > >>>>>>> (Data    |   | (Network         allocation, demand   |
> > >>>>>>> Transfer |   | Resource         vector, etc.         |
> > >>>>>>> Intents) |   | Constraints)     (Non-ALTO interfaces)|
> > >>>>>>> ...
> > >>>>>>> How the client makes resource requests based on the information
> and
> > >>>>>>> how the resource allocation is achieved respectively depend on
> > >>>>>>> interfaces between the management system and the users or a
> higher-
> > >>>>>>> layer protocol (e.g., SDN network intents or MPLS tunnels),
> which are
> > >>>>>>> out of the scope of this document. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; The term "intent" here is a bit
> misleading. "Data Transfer Intents" here should be interpreted as
> "potential data transfers that the clients intend to schedule". Maybe we
> can replace "Data Transfer Intents" with "Potential Data Transfers".
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; The term "SDN network intents" is from
> intent-based SDN. An intent is basically a request to the SDN system to
> route the traffic or make bandwidth reservations. Maybe we can add an
> informative reference to
> https://www.ietf.org/archive/id/draft-irtf-nmrg-ibn-concepts-definitions-04.html?
> &gt
> <https://www.ietf.org/archive/id/draft-irtf-nmrg-ibn-concepts-definitions-04.html?&gt>;
> &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 12) <!-- [rfced] Section 4.2.1:
> FYI, to improve readability, we have moved the paragraph describing Figure
> 5 to be in front of the figure instead of after it. Please let us know of
> any concerns. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 13) <!-- [rfced] Please review the
> "type" attribute of each sourcecode
> > >>>>>>> element in the XML file to ensure correctness.  Please note that
> we
> > >>>>>>> set the fourth and subsequent sourcecode items to "json".
> > >>>>>>>
> > >>>>>>> If the current list of preferred values for "type"
> > >>>>>>> (https://www.rfc-editor.org/materials/sourcecode-types.txt)
> > >>>>>>> does not contain an applicable type, please let us know. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Line 1138-1140:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; The content is a simple string. I am not
> sure which type fits the best here, though (maybe empty?).
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Line 1375-1379, Line 1420-1424, Line
> 1713-1717:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; The content is related to JSON but more
> like type definitions instead of data. Looks like "json-dtd" to me but I'm
> fine with using "json" here. By the way, I see in the XML of RFC 9240, such
> definitions are encoded as <artwork>. Maybe <artwork> could also be an
> option here?
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Line 1394-1413, Line 1626-1671, Line
> 1771-1790, Line 1904-1949, Line 2170-2188, Line 2189-2239, Line 2310-2340,
> Line 2341-2409, Line 2422-2484, Line 2490-2505, Line 2509-2530, Line
> 2534-2540, Line 2583-2613, Line 2614-2676:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; It seems to me that "http-message" is
> more suitable here as the content contains the HTTP header.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Line 1519-1521, Line 1855-1857:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Maybe "rbnf" is more suitable here.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 14) <!-- [rfced] Section 4.2.2:  We
> removed "2021" here and, to avoid
> > >>>>>>> constraining the timeframe with a specific year, we used "At the
> time
> > >>>>>>> of this writing".  Also, please note that (1) for ease of the
> reader,
> > >>>>>>> (2) to avoid confusion with "AR" as used in Section 4.1 to mean
> > >>>>>>> "additional requirement", and (3) because "AR/VR" is not used
> again
> > >>>>>>> in this document, we changed "AR/VR" to "augmented reality /
> virtual
> > >>>>>>> reality".  Please let us know any objections.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> A growing trend in today's applications (2021) is to bring
> storage
> > >>>>>>> and computation closer to the end users for better QoE, such as
> > >>>>>>> Content Delivery Network (CDN), AR/VR, and cloud gaming, as
> reported
> > >>>>>>> in various documents (e.g., [SEREDGE] and [MOWIE]).
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> At the time of this writing, a growing trend in today's
> applications
> > >>>>>>> is to bring storage and computation closer to the end users for
> > >>>>>>> better QoE, such as CDNs, augmented reality / virtual reality,
> and
> > >>>>>>> cloud gaming, as reported in various documents (e.g., [SEREDGE]
> and
> > >>>>>>> [MOWIE]). -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 15) <!-- [rfced] Section 4.2.2 and
> Figure 7:  The abbreviations for "gigabytes" and "terabytes" ("G" and "T")
> used here are unorthodox. May we update to "GB" and "TB"?
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> For example, Figure 6 illustrates a typical edge-cloud scenario
> where
> > >>>>>>> memory is measured in Gigabytes (G) and storage is measured in
> > >>>>>>> Terabytes (T).
> > >>>>>>>
> > >>>>>>> Suggested:
> > >>>>>>> For example, Figure 6 illustrates a typical edge-cloud scenario
> where
> > >>>>>>> memory is measured in gigabytes (GB) and storage is measured in
> > >>>>>>> terabytes (TB).
> > >>>>>>>
> > >>>>>>> Figure 7 (also adding spaces to match examples in Section 4.2.1):
> > >>>>>>>
> > >>>>>>> ane1: latency = 5 ms cpu = 2 memory = 8 GB storage = 10 TB
> > >>>>>>> (On premise, a)
> > >>>>>>>
> > >>>>>>> ane2: latency = 20 ms cpu = 4 memory = 8 GB storage = 10 TB
> > >>>>>>> (Site-radio Edge Node 1)
> > >>>>>>> ...
> > >>>>>>> -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 16) <!-- [rfced] Section 4.2.2:
> FYI, to improve readability, we have moved the paragraph describing Figure
> 7 to be in front of the figure instead of after it. Please let us know of
> any concerns. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 17) <!-- [rfced] Section 4.2.2:
> Does "GPU" stand for "Graphics
> > >>>>>>> Processing Unit" here, or should it be "CPU" as used earlier in
> this
> > >>>>>>> section?
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> With the extension defined in this document, an ALTO server can
> > >>>>>>> selectively reveal the CDNs and service edges that reside along
> the
> > >>>>>>> paths between different end hosts and/or the cloud servers,
> together
> > >>>>>>> with their properties such as capabilities (e.g., storage, GPU)
> and
> > >>>>>>> available Service Level Agreement (SLA) plans. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; I think we intend to say "Graphics
> Processing Unit" here.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 18) <!-- [rfced] Section 5:  This
> sentence is difficult to parse.  If
> > >>>>>>> neither suggestion below is correct, please clarify the
> relationship
> > >>>>>>> between "learn", "investigating", "identify", and "retrieve".
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> Thus, an ALTO client can learn about the ANEs that are important
> to
> > >>>>>>> assess the QoE of different <source, destination> pairs by
> > >>>>>>> investigating the corresponding Path Vector value (AR1), identify
> > >>>>>>> common ANEs if an ANE appears in the Path Vectors of multiple
> > >>>>>>> <source, destination> pairs (AR2), and retrieve the properties
> of the
> > >>>>>>> ANEs by searching the Unified Property Map (AR3).
> > >>>>>>>
> > >>>>>>> Suggestion #1:
> > >>>>>>> Thus, an ALTO client can learn about the ANEs that are important
> for
> > >>>>>>> assessing the QoE of different <source, destination> pairs by
> > >>>>>>> investigating the corresponding Path Vector value (AR1),
> identifying
> > >>>>>>> common ANEs if an ANE appears in the Path Vectors of multiple
> > >>>>>>> <source, destination> pairs (AR2), and retrieving the properties
> of
> > >>>>>>> the ANEs by searching the entity property map (AR3).
> > >>>>>>>
> > >>>>>>> Suggestion #2:
> > >>>>>>> Thus, an ALTO client can learn about the ANEs that are important
> > >>>>>>> for assessing the QoE of different <source, destination> pairs by
> > >>>>>>> investigating the corresponding Path Vector value (AR1) and can
> > >>>>>>> also (1) identify common ANEs if an ANE appears in the Path
> Vectors
> > >>>>>>> of multiple <source, destination> pairs (AR2) and (2) retrieve
> the
> > >>>>>>> properties of the ANEs by searching the entity property map
> (AR3). -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We prefer suggestion #2.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 19) <!-- [rfced] Section 5.1.2:
> Does "their" refer to the network
> > >>>>>>> components (mentioned in the previous sentence) or to "A
> persistent
> > >>>>>>> ANE" (in which case it should be "its")?  If the suggested text
> > >>>>>>> (assuming that "their" should be "its") is not correct, please
> > >>>>>>> clarify.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> A persistent ANE has a persistent ID that is
> > >>>>>>> registered in a Property Map, together with their properties.
> > >>>>>>>
> > >>>>>>> Suggested:
> > >>>>>>> A persistent ANE has a persistent ID that is
> > >>>>>>> registered in a property map, together with its properties. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 20) <!-- [rfced] Section 5.3:  We
> had trouble following this sentence.
> > >>>>>>> We updated it as follows.  If this update is incorrect, please
> > >>>>>>> clarify "on demand, and potentially based on".
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> 1.  ANEs may be constructed on demand, and potentially based on
> the
> > >>>>>>>   requested properties (See Section 5.1 for more details).
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> 1.  ANEs may be constructed on demand and, potentially, based on
> the
> > >>>>>>>   requested properties (see Section 5.1 for more details). -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 21) <!-- [rfced] Section 6.4.1:
> This sentence did not parse.  We changed
> > >>>>>>> "this document that the" to "this document in that the".  If this
> > >>>>>>> change is incorrect, please clarify the text.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> The encoding in [NOVA] differs from the
> > >>>>>>> Path Vector response defined in this document that the Path
> Vector
> > >>>>>>> part and Property Map part are put in the same JSON object.
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> The encoding
> > >>>>>>> in [NOVA] differs from the Path Vector response defined in this
> > >>>>>>> document in that the Path Vector part and property map part are
> > >>>>>>> placed in the same JSON object. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 22) <!-- [rfced] Section 6.4.2:  We
> had trouble following the use of "presents" in this sentence. We did not
> see information in Section 5.1.2 on how an ephemeral ANE presents a
> persistent entity ID. We did see text that said the ALTO server provides
> this information. How may we update this sentence?
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> The persistent entity ID property is the entity identifier of the
> > >>>>>>> persistent ANE which an ephemeral ANE presents (See Section
> 5.1.2 for
> > >>>>>>> details). -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; The idea is that all ANEs that appear in
> the path vector response are "ephemeral". Some ephemeral ANEs may represent
> a network component (i.e., persistent ANE) whose properties can be queried
> from another entity map service.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We propose the following text:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;    This document enables the discovery
> of a persistent ANE by
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;    by exposing its entity identifier as
> the persistent entity ID
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;    property of an ephemeral ANE in the
> path vector response.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 23) <!-- [rfced] Section 6.4.3:  As
> it appears that "they" in this
> > >>>>>>> sentence means "service edges", we updated the text accordingly.
> > >>>>>>> Please let us know if this is incorrect.
> > >>>>>>>
> > >>>>>>> Original ("life cycle ... are" has been corrected):
> > >>>>>>> As the life cycle of service edges are
> > >>>>>>> typically long, they may contain information that is not
> specific to
> > >>>>>>> the query.
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> As the life cycles of service edges are
> > >>>>>>> typically long, the service edges may contain information that
> is not
> > >>>>>>> specific to the query. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 24) <!-- [rfced] Section 6.5.1:  We
> did not see any instructions in
> > >>>>>>> Section 8.3.4.3 of RFC 7285 ("the client can either choose
> another
> > >>>>>>> server (if one is available) or ...").  Should "instructions" be
> > >>>>>>> "guidance"?
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> Otherwise, the client MUST
> > >>>>>>> discard the response and SHOULD follow the instructions in
> > >>>>>>> Section 8.3.4.3 of [RFC7285] to handle the error. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Yes, please use "guidance".
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 25) <!-- [rfced] Section 7.2.6:  We
> only see one parameter listed in this
> > >>>>>>> paragraph and three parameters in the parameters list.  Please
> > >>>>>>> clarify "both parameters"; was "permits parameters both with and
> > >>>>>>> without double quotes" intended?
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> type:  The type parameter is mandatory and MUST be
> "application/alto-
> > >>>>>>>  costmap+json".  Note that [RFC2387] permits both parameters with
> > >>>>>>>  and without the double quotes. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; It is "permits parameters both with and
> without double quotes".
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 26) <!-- [rfced] Sections 7.2.6 and
> 7.3.6:  The all-capitals "NOT" is
> > >>>>>>> unusual, and could be confusing to some readers, because it is
> not
> > >>>>>>> used as part of a key word per RFC 2119.  May we change "NOT" to
> > >>>>>>> "not" in these sentences and apply the <strong> element in the
> XML
> > >>>>>>> file, per Section 2.50 of RFC 7991
> > >>>>>>> (https://www.rfc-editor.org/info/rfc7991)?
> > >>>>>>>
> > >>>>>>> The "not"s would then be emphasized in the .html and .pdf output
> > >>>>>>> files for this document.  For an example of how this emphasis
> would
> > >>>>>>> look, please see the first two instances of "singleton" in
> > >>>>>>> Section 3.4 of <https://www.rfc-editor.org/rfc/rfc9198.html> or
> > >>>>>>> <https://www.rfc-editor.org/rfc/rfc9198.pdf>.
> > >>>>>>>
> > >>>>>>> Original text:
> > >>>>>>> If any part is
> > >>>>>>> NOT present, the client MUST discard the received information and
> > >>>>>>> send another request if necessary.
> > >>>>>>> ...
> > >>>>>>> If any part is
> > >>>>>>> NOT present, the client MUST discard the received information and
> > >>>>>>> send another request if necessary.
> > >>>>>>>
> > >>>>>>> Suggested (in the XML file):
> > >>>>>>> If any part is <strong>not</strong> present, the ... -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed changes.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 27) <!-- [rfced] Sections 7.2.6 and
> 7.3.6:  These sentences are confusing
> > >>>>>>> as written, as RFC 2387 discusses the "object root" and the "root
> > >>>>>>> body part" but does not mention "Path Vector" or "vector".  May
> we
> > >>>>>>> update as suggested?  If not, please clarify the text.
> > >>>>>>>
> > >>>>>>> Also, should the other instances of "root object" in this
> document be
> > >>>>>>> updated as well?  We do not see "root object" used in RFC 2387.
> > >>>>>>> If yes, please specify how to update.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> According to [RFC2387], the Path Vector part, whose media type
> is the
> > >>>>>>> same as the "type" parameter of the multipart response message,
> is
> > >>>>>>> the root object.
> > >>>>>>> ...
> > >>>>>>> According to [RFC2387], the Path Vector part, whose media type
> is the
> > >>>>>>> same as the "type" parameter of the multipart response message,
> is
> > >>>>>>> the root object.
> > >>>>>>>
> > >>>>>>> Suggested:
> > >>>>>>> The Path Vector part, whose media type is the same as the "type"
> > >>>>>>> parameter of the multipart response message, is the root body
> part
> > >>>>>>> as defined in [RFC2387].
> > >>>>>>> ...
> > >>>>>>> The Path Vector part, whose media type is the same as the "type"
> > >>>>>>> parameter of the multipart response message, is the root body
> part
> > >>>>>>> as defined in [RFC2387]. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed changes. The
> other "root object" should be replaced with "object root" or "root body
> part" as well.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 28) <!-- [rfced] Sections 7.2.6 and
> 7.3.6:  Would you like to add
> > >>>>>>> spaces between the square brackets and the quotes for these two
> > >>>>>>> items, as was done for other such items (e.g., [ "PID1" ])?
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> "PID1": { "PID2": ["ANE1"] }
> > >>>>>>> ...
> > >>>>>>> "ipv4:192.0.2.2": { "ipv4:192.0.2.18": ["ANE1"] }
> > >>>>>>>
> > >>>>>>> Perhaps:
> > >>>>>>> "PID1": { "PID2": [ "ANE1" ] }
> > >>>>>>> ...
> > >>>>>>> "ipv4:192.0.2.2": { "ipv4:192.0.2.18": [ "ANE1" ] } -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Yes.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 29) <!-- [rfced] Section 7.3.3:  We
> see "ReqEndpointCostMap" in
> > >>>>>>> Section 4.2.2 of RFC 8189 but not "ReqEndpointCost" or
> > >>>>>>> "ReqEndpointcostMap".  May we update as suggested, to match RFC
> 8189?
> > >>>>>>> If not, please provide clarifying text.
> > >>>>>>>
> > >>>>>>> Also, please review the capitalization of the following terms
> and let us know if any changes are necessary (e.g., should "cost" in
> "PVReqEndpointcost" be "PVReqEndpointCost"?)
> > >>>>>>>
> > >>>>>>> PVEndpointcostCapabilities
> > >>>>>>> PVFilteredCostMapCapabilities
> > >>>>>>> PVReqEndpointCost
> > >>>>>>> PVReqEndpointcost
> > >>>>>>> PVReqFilteredCostMap
> > >>>>>>> ReqEndpointCost
> > >>>>>>> ReqEndpointcostMap
> > >>>>>>> ReqFilteredCostMap
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> This document
> > >>>>>>> extends the input parameters to an Endpoint Cost Service, which
> is
> > >>>>>>> defined as a JSON object of type ReqEndpointCost in Section
> 4.2.2 of
> > >>>>>>> [RFC8189], with a data format indicated by the media type
> > >>>>>>> "application/alto-endpointcostparams+json", which is a JSON
> object of
> > >>>>>>> type PVReqEndpointCost:
> > >>>>>>>
> > >>>>>>> object {
> > >>>>>>> [EntityPropertyName ane-property-names<0..*>;]
> > >>>>>>> } PVReqEndpointcost : ReqEndpointcostMap;
> > >>>>>>>
> > >>>>>>> Suggested:
> > >>>>>>> This document
> > >>>>>>> extends the input parameters to an Endpoint Cost Service, which
> is
> > >>>>>>> defined as a JSON object of type ReqEndpointCostMap in Section
> 4.2.2
> > >>>>>>> of [RFC8189], with a data format indicated by the media type
> > >>>>>>> "application/alto-endpointcostparams+json", which is a JSON
> object of
> > >>>>>>> type PVReqEndpointCost:
> > >>>>>>>
> > >>>>>>> object {
> > >>>>>>> [EntityPropertyName ane-property-names<0..*>;]
> > >>>>>>> } PVReqEndpointcost : ReqEndpointCostMap; -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the change. For
> consistency, we propose to use the following terms (capitalize "C" in cost):
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; PVEndpointcostCapabilities =&gt;
> PVEndpointCostCapabilities
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; PVFilteredCostMapCapabilities
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; PVReqEndpointCost =&gt;
> PVReqEndpointCostMap
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; PVReqEndpointcost =&gt;
> PVReqEndpointCostMap
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; PVReqFilteredCostMap
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; ReqEndpointCost =&gt; ReqEndpointCostMap
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; ReqEndpointcostMap =&gt;
> ReqEndpointCostMap
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; ReqFilteredCostMap
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 30) <!-- [rfced] Section 7.3.6:
> Because RFC 7285 does not use
> > >>>>>>> "multipart/related" or "multipart", we changed "[RFC7285]" to
> > >>>>>>> "[RFC2387]" per RFC 2387 and per the (otherwise) same sentence
> in the
> > >>>>>>> second paragraph of Section 7.2.6.  Please let us know any
> > >>>>>>> objections.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> The "Content-Type" header of the response MUST be
> "multipart/related"
> > >>>>>>> as defined by [RFC7285] with the following parameters:
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> The "Content-Type" header field of the response MUST be
> "multipart/related"
> > >>>>>>> as defined by [RFC2387], with the following parameters: -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 31) <!-- [rfced] Section 8.1: FYI,
> to improve readability, we have moved the paragraph describing Figure 10 to
> be in front of the figure instead of after it. Please let us know of any
> concerns. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 32) <!-- [rfced] Section 8.1:  We
> could not see any indication of message
> > >>>>>>> contents in Figure 10.  If the suggested text is not correct,
> please
> > >>>>>>> clarify the meaning.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> In this document, Figure 10 is used to illustrate the message
> > >>>>>>> contents.
> > >>>>>>>
> > >>>>>>> Suggested:
> > >>>>>>> Figure 10 illustrates the network properties and thus the
> message
> > >>>>>>> contents. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 33) <!-- [rfced] Section 8.2:  This
> item reads oddly.  Are some words
> > >>>>>>> missing?
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> *  "multicost-pv": A Multipart Endpoint Cost Service with both
> Multi-
> > >>>>>>>  Cost and Path Vector.
> > >>>>>>>
> > >>>>>>> Possibly:
> > >>>>>>> *  "multicost-pv": A multipart Endpoint Cost Service with both a
> Multi-
> > >>>>>>>  Cost resource and a Path Vector resource. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We propose the following text:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;   *  "multicost-pv": A multipart
> Endpoint Cost Service with both the
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;      Multi-Cost extension and Path
> Vector extension enabled.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 34) <!-- [rfced] Section 8.2:
> Section 6.5 does not mention "path-vector";
> > >>>>>>> this sentence is the first mention of it.  We updated this
> sentence
> > >>>>>>> so that the information is clearer.  Please let us know any
> > >>>>>>> objections.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> To enable the extension defined in this document, the "path-
> > >>>>>>> vector" cost type (Section 6.5) is defined in the "cost-types"
> of the
> > >>>>>>> "meta" field, and is included in the "cost-type-names" of
> resources
> > >>>>>>> "filtered-cost-map-pv" and "endpoint-cost-pv".
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> To enable the extension
> > >>>>>>> defined in this document, the Path Vector cost type (Section
> 6.5),
> > >>>>>>> represented by "path-vector" below, is defined in the
> "cost-types" of
> > >>>>>>> the "meta" field and is included in the "cost-type-names" of
> > >>>>>>> resources "filtered-cost-map-pv" and "endpoint-cost-pv". -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the propose change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 35) <!-- [rfced] Sections 8.3 and
> 8.4:  Would it improve readability to update "array of ANEName" to "array
> of data type ANEName"?
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> The first part returns the array
> > >>>>>>> of ANEName for each source and destination pair.
> > >>>>>>> ...
> > >>>>>>> The first part returns the array
> > >>>>>>> of ANEName for each valid source and destination pair. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed changes.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 36) <!-- [rfced] Section 8.3:  We
> could not see a relationship between
> > >>>>>>> Section 3.1 of draft-ietf-alto-unified-props-new (now RFC 9240)
> and
> > >>>>>>> this sentence (i.e., we did not see any mention of "empty",
> "omit",
> > >>>>>>> or "no properties".  Please confirm that this sentence will be
> clear
> > >>>>>>> to readers.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> The second part returns an empty Property Map. Note that the ANE
> > >>>>>>> entries are omitted since they have no properties (See Section
> 3.1 of
> > >>>>>>> [I-D.ietf-alto-unified-props-new]). -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; The reference should be Section 8.3 of
> RFC 9240, which says:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;      If it is absent, the Server returns
> a property
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;      value equal to the literal string
> "{}" for all the entity
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;      identifiers of the "entities" field
> for which at least one
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;      property is defined.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; and we propose the following changes:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; OLD EXAMPLE:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;   {
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     "meta": {
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;       "dependent-vtags": [
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;         {
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;           "resource-id":
> "filtered-cost-map-pv.costmap",
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;           "tag":
> "d827f484cb66ce6df6b5077cb8562b0a"
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;         }
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;       ]
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     },
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     "property-map": {
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     }
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;   }
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; NEW EXAMPLE:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;   {
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     "meta": {
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;       "dependent-vtags": [
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;         {
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;           "resource-id":
> "filtered-cost-map-pv.costmap",
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;           "tag":
> "d827f484cb66ce6df6b5077cb8562b0a"
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;         }
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;       ]
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     },
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     "property-map": {
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;       ".ane:L1": {},
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;       ".ane:L2": {}
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;     }
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;   }
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; NEW TEXT:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;   The second part returns the property
> map. Note that the
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;   properties of the ANE entries is equal
> to the literal
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;   string "{}" (See Section 8.3 of
> [RFC9240]). --&gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 37) <!-- [rfced] Section 8.4:
> Regarding these two paragraphs, Figure 10,
> > >>>>>>> and the example shown after the "Both NET1 and NET2" paragraph:
> > >>>>>>>
> > >>>>>>> a) The "[ "NET3", "L1", "NET1" ]" entry in the example does not
> > >>>>>>> appear to us to match "traverses NET2, L1 and NET1" in the text.
> > >>>>>>> Please confirm that the text and example are correct.
> > >>>>>>>
> > >>>>>>
> > >>>>>> It should be NET3, L1 and NET1.
> > >>>>>>
> > >>>>>>> b) We do not see how "ane-props.ane:MEC2" corresponds to NET3; it
> > >>>>>>> appears to us to correspond to NET2 and AGGR2 (we see AGGR2
> listed as
> > >>>>>>> an aggregate of NET2 and L2 in the "Under certain scenarios"
> > >>>>>>> paragraph).  Please confirm that "NET3" is correct.
> > >>>>>>>
> > >>>>>>
> > >>>>>> It should be NET2.
> > >>>>>>
> > >>>>>>> Original:
> > >>>>>>> The response consists of two parts.  The first part returns the
> array
> > >>>>>>> of ANEName for each valid source and destination pair.  As one
> can
> > >>>>>>> see in Figure 10, flow 192.0.2.34 -> 192.0.2.2 traverses NET2,
> L1 and
> > >>>>>>> NET1, and flows 192.0.2.34 -> 192.0.2.50 and 2001:db8::3:1 ->
> > >>>>>>> 2001:db8::4:1 traverse NET2, L2 and NET3.
> > >>>>>>> ...
> > >>>>>>> Both NET1 and NET2 have a mobile edge deployed, i.e., MEC1 in
> NET1
> > >>>>>>> and MEC2 in NET2.  Assume the ANEName for MEC1 and MEC2 are
> "MEC1"
> > >>>>>>> and "MEC2" and their properties can be retrieved from the
> Property
> > >>>>>>> Map "ane-props".  Thus, the "persistent-entity-id" property of
> NET1
> > >>>>>>> and NET3 are "ane-props.ane:MEC1" and "ane-props.ane:MEC2"
> > >>>>>>> respectively.
> > >>>>>>> ...
> > >>>>>>> "endpoint-cost-map": {
> > >>>>>>> "ipv4:192.0.2.34": {
> > >>>>>>>   "ipv4:192.0.2.2":   [ "NET3", "L1", "NET1" ],
> > >>>>>>>   "ipv4:192.0.2.50":   [ "NET3", "L2", "NET2" ]
> > >>>>>>> },
> > >>>>>>> "ipv6:2001:db8::3:1": {
> > >>>>>>>   "ipv6:2001:db8::4:1": [ "NET3", "L2", "NET2" ]
> > >>>>>>> ...
> > >>>>>>> ".ane:NET1": {
> > >>>>>>> "max-reservable-bandwidth": 50000000000,
> > >>>>>>> "persistent-entity-id": "ane-props.ane:MEC1"
> > >>>>>>> },
> > >>>>>>> ".ane:NET2": {
> > >>>>>>> "max-reservable-bandwidth": 50000000000,
> > >>>>>>> "persistent-entity-id": "ane-props.ane:MEC2" -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 38) <!-- [rfced] Section 8.5:
> These lines result in "Warning: Too long
> > >>>>>>> line found" xml2rfc output for the .txt file.  May we add line
> breaks
> > >>>>>>> as suggested?  If not, please specify where line breaks should be
> > >>>>>>> placed.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> event: application/merge-patch+json,
> 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> -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed changes.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 39) <!-- [rfced] Section 9.4:  Does
> "calendar extension" here mean
> > >>>>>>> "ALTO Calendar extension" (Section 5.2.4 of RFC 8896), "Cost
> > >>>>>>> Calendar extension", or something else?  (It appears to us to
> > >>>>>>> mean "Cost Calendar extension", but we need to confirm.)
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> The
> > >>>>>>> Path Vector part is calendared in a compatible way, and the
> Property
> > >>>>>>> Map part is not affected by the calendar extension. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Yes, the text is referring to the ALTO
> Cost Calendar extension (RFC 8896).
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 40) <!-- [rfced] Section 10.1:  We
> had trouble following this sentence,
> > >>>>>>> as we only see "constraints" in RFC 7285 and we see "A Client is
> > >>>>>>> therefore allowed to express either "constraints" or
> "or-constraints"
> > >>>>>>> but not both" in Section 3.6.2 of RFC 8189.  Please let us know
> if
> > >>>>>>> any updates are needed to clarify this text.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> [RFC7285] and [RFC8189] allow ALTO clients to specify the
> > >>>>>>> "constraints" and "or-constraints" tests to better filter the
> result.
> > >>>>>>>
> > >>>>>>> Possibly:
> > >>>>>>> ALTO clients are permitted to specify either the "constraints"
> test
> > >>>>>>> [RFC7285] [RFC8189] or the "or-constraints" test [RFC8189] to
> better
> > >>>>>>> filter the results. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 41) <!-- [rfced] Section 10.2:  It
> was difficult to determine what "This
> > >>>>>>> extension" refers to, given "incremental update extension" four
> lines
> > >>>>>>> earlier.  Because "This extension" appears to mean "The extension
> > >>>>>>> specified in this document" here, we updated accordingly.  If
> this is
> > >>>>>>> incorrect, please provide clarifying text.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> This extension gives an example of using a multipart message to
> > >>>>>>> encode the responses from two specific ALTO information
> resources: a
> > >>>>>>> Filtered Cost Map or an Endpoint Cost Service, and a Property
> Map.
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> The extension specified in this document gives an example of
> using a
> > >>>>>>> multipart message to encode the responses from two specific ALTO
> > >>>>>>> information resources: a filtered cost map or an Endpoint Cost
> > >>>>>>> Service, and a property map. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 42) <!-- [rfced] Section 10.2:
> Does "which provides" refer to upgrading
> > >>>>>>> to HTTP/2 and HTTP/3, or does it also refer to extending the SSE
> > >>>>>>> mechanism (in which case "provides" should be "provide")?
> > >>>>>>>
> > >>>>>>> Original ("to allow servers proactively send" has been
> corrected):
> > >>>>>>> Thus, it is worth looking into the direction of extending the SSE
> > >>>>>>> mechanism as used in the incremental update extension [RFC8895],
> or
> > >>>>>>> upgrading to HTTP/2 [RFC9113] and HTTP/3 [RFC9114], which
> provides
> > >>>>>>> the ability to multiplex queries and to allow servers proactively
> > >>>>>>> send related information resources. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; It refers to upgrading to HTTP/2 and
> HTTP/3.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 43) <!-- [rfced] Section 11: In the
> following sentence, should "CDNi" be "CDNI" instead?
> > >>>>>>>
> > >>>>>>> Current:
> > >>>>>>> Thus, they should only be used when exposing public
> > >>>>>>> service access points (e.g., API gateways, CDNi)
> > >>>>>>>
> > >>>>>>> Perhaps:
> > >>>>>>> Thus, they should only be used when exposing public
> > >>>>>>> service access points (e.g., API gateways, CDN Interconnections)
> -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 44) <!-- [rfced] Section 12: FYI,
> we have updated the tables in the IANA Considerations section to better
> match the tables in the IANA registries. Please let us know of any
> concerns.-->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed changes.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 45) <!-- [rfced] Section 12.3:  The
> information in this text and the
> > >>>>>>> data in Table 3 seem to point to Section 12.3 ("ALTO Entity
> Domain
> > >>>>>>> Types Registry") of draft-alto-unified-props-new (now RFC 9240)
> and
> > >>>>>>> not to Section 12.2 ("alto-propmapparams+json Media Type") of
> that
> > >>>>>>> document.  We updated the section number accordingly.  Please
> let us
> > >>>>>>> know if this is incorrect.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> This document registers a new entry to the ALTO Domain Entity
> Type
> > >>>>>>> Registry, as instructed by Section 12.2 of
> > >>>>>>> [I-D.ietf-alto-unified-props-new].  The new entry is as shown
> below
> > >>>>>>> in Table 3.
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> This document registers a new entry in the "ALTO Entity Domain
> Types"
> > >>>>>>> registry, per Section 12.3 of [RFC9240]. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 46) <!-- [rfced] Section 12.3: Is
> the sentence below talking about issue (2) in the Security Considerations
> section? Is a bis already in progress for this document or does another I-D
> that covers the topic exist?
> > >>>>>>>
> > >>>>>>> Current:
> > >>>>>>> Applications and ALTO
> > >>>>>>> service providers using addresses of ANEs will be made aware of
> > >>>>>>> how (or if) the addressing scheme relates to private information
> > >>>>>>> and network proximity, in further iterations of this document.
> > >>>>>>>
> > >>>>>>> Perhaps (reordering and saying "update" rather than "further
> iterations", and also changing "applications" to "implementers"):
> > >>>>>>> A future update of this document will explain to ALTO
> implementers
> > >>>>>>> and service providers using ANE addresses how (or if) the
> > >>>>>>> addressing scheme relates to private information and network
> > >>>>>>> proximity.  -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; Yes, an example is Section 10.9 of RFC
> 9240, where the ANE name is following a schema of
> "[datacenter-id]-[cluster-id]". However, there is no bis or I-D in progress
> yet. We probably need to discuss this with AD and the chairs. We propose
> the following text:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;    If a naming schema is used to
> generate ANE names, either
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;    used privately or standardized by a
> future extension, how
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;    (or if) the naming schema relates to
> private information
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;    and network proximity must be
> explained to ALTO implementers
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;    and service providers.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 47) <!-- [rfced] Section 12.4:  The
> information in this text and the
> > >>>>>>> data in Table 4 seem to point to Section 12.4 ("ALTO Entity
> Property
> > >>>>>>> Types Registry") of draft-alto-unified-props-new (now RFC 9240)
> and
> > >>>>>>> not to Section 12.3 ("ALTO Entity Domain Types Registry") of that
> > >>>>>>> document.  We updated the section number accordingly.  Please
> let us
> > >>>>>>> know if this is incorrect.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> Two initial entries "max-reservable-bandwidth" and "persistent-
> > >>>>>>> entity-id" are registered to the ALTO Domain "ane" in the "ALTO
> > >>>>>>> Entity Property Type Registry", as instructed by Section 12.3 of
> > >>>>>>> [I-D.ietf-alto-unified-props-new].  The two new entries are shown
> > >>>>>>> below in Table 4 and their details can be found in Section
> 12.4.1 and
> > >>>>>>> Section 12.4.2.
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> Two initial entries - "max-reservable-bandwidth" and "persistent-
> > >>>>>>> entity-id" - are registered for the ALTO domain "ane" in the
> "ALTO
> > >>>>>>> Entity Property Types" registry, per Section 12.4 of [RFC9240].
> -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 48) <!-- [rfced] Section 12.4.2:
> This sentence was difficult to follow,
> > >>>>>>> as it appeared to say that the entity IDs might consider
> something.
> > >>>>>>> We updated it per the "Security Considerations:" paragraph in
> > >>>>>>> Section 12.3.2 of RFC 9240 (formerly
> > >>>>>>> [I-D.ietf-alto-unified-props-new]).  If this update is incorrect,
> > >>>>>>> please provide clarifying text.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> The entity IDs
> > >>>>>>> may consider sensitive information about the underlying network,
> > >>>>>>> and an ALTO server should follow the security considerations in
> > >>>>>>> Section 11 of [I-D.ietf-alto-unified-props-new].
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> As mentioned
> > >>>>>>> in Section 12.3.2 of [RFC9240], the entity IDs may reveal
> > >>>>>>> sensitive information about the underlying network.  An ALTO
> > >>>>>>> server should follow the security considerations provided in
> > >>>>>>> Section 11 of [RFC9240]. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 49) <!-- [rfced] Informative
> References:  The provided link for [NOVA],
> > >>>>>>> which indicates the year 2017, redirects to a page listing the
> same
> > >>>>>>> authors, but the listed title is different - "NOVA: Towards
> on-demand
> > >>>>>>> equivalent network view abstraction for network optimization" -
> and
> > >>>>>>> the listed year is 2019.  Also listed via the provided link is
> "2017
> > >>>>>>> IEEE/ACM 25th International Symposium on Quality of Service
> (IWQoS),
> > >>>>>>> pp. 1-10, June 2017".
> > >>>>>>>
> > >>>>>>> Note:  We have added the DOI for now but will remove or change it
> > >>>>>>> as appropriate.
> > >>>>>>>
> > >>>>>>> Please review, and let us know which listing is correct.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> [NOVA]     Gao, K., Xiang, Q., Wang, X., Yang, Y.R., and J. Bi,
> "An
> > >>>>>>>          objective-driven on-demand network abstraction for
> > >>>>>>>          adaptive applications", IEEE/ACM Transactions on
> > >>>>>>>          Networking (TON) Vol 27, no. 2 (2019): 805-818., 2019,
> > >>>>>>>          <https://doi.org/10.1109/IWQoS.2017.7969117>. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; The DOI for the reference should be:
> https://doi.org/10.1109/TNET.2019.2899905
> &gt <https://doi.org/10.1109/TNET.2019.2899905&gt>; &gt;&gt; &gt; &gt;
> &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; The TON version includes an encoding of
> the messages and should be used.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 50) <!-- [rfced] Informative
> References:  The provided author list,
> > >>>>>>> conference information, and date for [UNICORN] ("Unicorn: Unified
> > >>>>>>> resource orchestration for multi-domain, geo-distributed data
> > >>>>>>> analytics") did not match what we found on
> > >>>>>>> <https://www.sciencedirect.com/science/article/abs/pii/
> > >>>>>>> S0167739X18302413?via%3Dihub> or via DOI search on
> > >>>>>>> 10.1016/j.future.2018.09.048.  Because the document title was the
> > >>>>>>> same, we updated the information according to the provided page.
> > >>>>>>> Please let us know any objections; for example, should a
> different
> > >>>>>>> paper or conference be listed here?  If yes, please provide the
> > >>>>>>> correct information.
> > >>>>>>>
> > >>>>>>> Original (the bad spacing has been corrected):
> > >>>>>>> [UNICORN]  Xiang, Q., Chen, S., Gao, K., Newman, H., Taylor, I.,
> > >>>>>>>          Zhang, J., and Y.R. Yang, "Unicorn: Unified Resource
> > >>>>>>>          Orchestration for Multi-Domain, Geo-Distributed Data
> > >>>>>>>          Analytics", 2017 IEEE SmartWorld, Ubiquitous
> Intelligence
> > >>>>>>>          Computing, Advanced Trusted Computed, Scalable Computing
> > >>>>>>>          Communications, Cloud Big Data Computing, Internet of
> > >>>>>>>          People and Smart City Innovation
> > >>>>>>>          (SmartWorld/SCALCOM/UIC/ATC/CBDCom/IOP/SCI) (Aug. 2017),
> > >>>>>>>          1-6. , 2017,
> > >>>>>>>          <https://doi.org/10.1016/j.future.2018.09.048>.
> > >>>>>>>
> > >>>>>>> Currently:
> > >>>>>>> [UNICORN]  Xiang, Q., Wang, T., Zhang, J., Newman, H., Yang,
> Y.R.,
> > >>>>>>>          and Y. Liu, "Unicorn: Unified resource orchestration for
> > >>>>>>>          multi-domain, geo-distributed data analytics", Future
> > >>>>>>>          Generation Computer Systems, Volume 93, pp. 188-197,
> > >>>>>>>          DOI 10.1016/j.future.2018.09.048, April 2019,
> > >>>>>>>          <https://www.sciencedirect.com/science/article/abs/pii/
> > >>>>>>>          S0167739X18302413?via%3Dihub>. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the proposed change.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 51) <!-- [rfced] Acknowledgments:
> Please confirm that you would like to
> > >>>>>>> list Qiao Xiang twice in this section.
> > >>>>>>>
> > >>>>>>> Original:
> > >>>>>>> The authors would like to thank discussions with Andreas Voellmy,
> > >>>>>>> Erran Li, Haibin Song, Haizhou Du, Jiayuan Hu, Qiao Xiang,
> Tianyuan
> > >>>>>>> ...
> > >>>>>>> Vyncke, Samuel Weiler, and Qiao Xiang whose feedback and
> suggestions
> > >>>>>>> -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We intend to only keep Qiao Xiang in the
> second paragraph.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 52) <!-- [rfced] Please review the
> "Inclusive Language" portion of the
> > >>>>>>> online Style Guide at
> > >>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language
> >,
> > >>>>>>> and let us know if any changes are needed. -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; No changes are needed.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; 53) <!-- [rfced] Terminology:
> Please let us know if any changes are needed for the following:
> > >>>>>>>
> > >>>>>>> a) The following terms were used inconsistently in this document.
> > >>>>>>> We chose to use the latter forms.  Please let us know any
> objections.
> > >>>>>>>
> > >>>>>>> ALTO Cost Map / ALTO cost map (per companion document RFC 9240,
> > >>>>>>> published 14 July 2022)
> > >>>>>>>
> > >>>>>>> ALTO protocol / ALTO Protocol (per RFC 9240)
> > >>>>>>>
> > >>>>>>> ANE Name / ANE name (per RFC 9240)
> > >>>>>>>
> > >>>>>>> Cost Map / cost map (per RFC 9240)
> > >>>>>>>
> > >>>>>>> Filtered Cost Map / filtered cost map (per RFC 9240)
> > >>>>>>>
> > >>>>>>> Network Element (used generally) / network element
> > >>>>>>> (per RFCs 2216 and 9240)
> > >>>>>>>
> > >>>>>>> Network Map / network map (per RFC 9240)
> > >>>>>>>
> > >>>>>>> Property Map / property map (per RFC 9240)
> > >>>>>>>
> > >>>>>>
> > >>>>>> We agree with the changes.
> > >>>>>>
> > >>>>>>> b) Because network element examples, parameter names, and HTTP
> header field names were mostly quoted, we quoted all of them.  Please let
> us know any concerns.  For example, we used the latter forms:
> > >>>>>>>
> > >>>>>>> eh1 / "eh1"
> > >>>>>>> sw1 / "sw1"
> > >>>>>>> start parameter / "start" parameter
> > >>>>>>> type parameter / "type" parameter
> > >>>>>>> Accept header field / "Accept" header field
> > >>>>>>>
> > >>>>>>
> > >>>>>> We agree with the changes.
> > >>>>>>
> > >>>>>>> c) When an HTTP header field was discussed (e.g.,
> "Content-Type"), we updated "header" to "header field" to match the usage
> in HTTP RFCs.
> > >>>>>>> -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; We agree with the changes.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Thank you.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; RFC Editor/lb/jm
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; On 8/18/22 4:34 PM,
> rfc-editor@rfc-editor.org wrote:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; *****IMPORTANT*****
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Updated 2022/08/18
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; RFC Author(s):
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; --------------
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Instructions for Completing AUTH48
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Your document has now entered
> AUTH48.  Once it has been reviewed and
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; approved by you and all coauthors,
> it will be published as an RFC.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; If an author is no longer
> available, there are several remedies
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; available as listed in the FAQ (
> https://www.rfc-editor.org/faq/).
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; You and you coauthors are
> responsible for engaging other parties
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; (e.g., Contributors or Working
> Group) as necessary before providing
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; your approval.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Planning your review
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; ---------------------
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Please review the following aspects
> of your document:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; *  RFC Editor questions
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    Please review and resolve any
> questions raised by the RFC Editor
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    that have been included in the
> XML file as comments marked as
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    follows:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    <!-- [rfced] ... -->
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    These questions will also be
> sent in a subsequent email.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; *  Changes submitted by coauthors
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    Please ensure that you review
> any changes submitted by your
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    coauthors.  We assume that if
> you do not speak up that you
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    agree to changes submitted by
> your coauthors.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; *  Content
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    Please review the full content
> of the document, as this cannot
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    change once the RFC is
> published.  Please pay particular attention to:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    - IANA considerations updates
> (if applicable)
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    - contact information
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    - references
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; *  Copyright notices and legends
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    Please review the copyright
> notice and legends as defined in
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    RFC 5378 and the Trust Legal
> Provisions
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    (TLP –
> https://trustee.ietf.org/license-info/).
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; *  Semantic markup
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    Please review the markup in the
> XML file to ensure that elements of
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    content are correctly tagged.
> For example, ensure that <sourcecode>
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    and <artwork> are set
> correctly.  See details at
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    <https: authors.ietf.org=""
> rfcxml-vocabulary="">.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; *  Formatted output
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    Please review the PDF, HTML, and
> TXT files to ensure that the
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    formatted output, as generated
> from the markup in the XML file, is
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    reasonable.  Please note that
> the TXT will have formatting
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    limitations compared to the PDF
> and HTML.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Submitting changes
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; ------------------
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; To submit changes, please reply to
> this email using ‘REPLY ALL’ as all
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; the parties CCed on this message
> need to see your changes. The parties
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; include:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    *  your coauthors
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    *  rfc-editor@rfc-editor.org
> (the RPC team)
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    *  other document participants,
> depending on the stream (e.g.,
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;       IETF Stream participants are
> your working group chairs, the
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;       responsible ADs, and the
> document shepherd).
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;    *  auth48archive@rfc-editor.org,
> which is a new archival mailing list
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;       to preserve AUTH48
> conversations; it is not an active discussion
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;       list:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;      *  More info:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> &gt
> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc&gt>;
> &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;      *  The archive itself:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://mailarchive.ietf.org/arch/browse/auth48archive/
> &gt <https://mailarchive.ietf.org/arch/browse/auth48archive/&gt>;
> &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;      *  Note: If only absolutely
> necessary, you may temporarily opt out
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;         of the archiving of
> messages (e.g., to discuss a sensitive matter).
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;         If needed, please add a
> note at the top of the message that you
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;         have dropped the address.
> When the discussion is concluded,
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> auth48archive@rfc-editor.org will be re-added to the CC list and
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;         its addition will be noted
> at the top of the message.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; You may submit your changes in one
> of two ways:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; An update to the provided XML file
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;  — OR —
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; An explicit list of changes in this
> format
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Section # (or indicate Global)
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; OLD:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; old text
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; NEW:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; new text
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; You do not need to reply with both
> an updated XML file and an explicit
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; list of changes, as either form is
> sufficient.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; We will ask a stream manager to
> review and approve any changes that seem
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; beyond editorial in nature, e.g.,
> addition of new text, deletion of text,
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; and technical changes.  Information
> about stream managers can be found in
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; the FAQ.  Editorial changes do not
> require approval from a stream manager.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Approving for publication
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; --------------------------
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; To approve your RFC for
> publication, please reply to this email stating
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; that you approve this RFC for
> publication.  Please use ‘REPLY ALL’,
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; as all the parties CCed on this
> message need to see your approval.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Files
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; -----
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; The files are available here:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275.xml
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275.html
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275.pdf
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275.txt
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Diff file of the text:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275-diff.html
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275-rfcdiff.html (side by side)
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Diff of the XML:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275-xmldiff1.html
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; The following files are provided to
> facilitate creation of your own
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; diff files of the XML.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Initial XMLv3 created using XMLv2
> as input:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275.original.v2v3.xml
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; XMLv3 file that is a best effort to
> capture v3-related format updates
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; only:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/authors/rfc9275.form.xml
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Tracking progress
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; -----------------
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; The details of the AUTH48 status of
> your document are here:
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> https://www.rfc-editor.org/auth48/rfc9275
> &gt <https://www.rfc-editor.org/auth48/rfc9275&gt>; &gt;&gt; &gt; &gt;
> &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Please let us know if you have any
> questions.
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Thank you for your cooperation,
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; RFC Editor
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> --------------------------------------
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; RFC9275
> (draft-ietf-alto-path-vector-25)
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Title            : An ALTO
> Extension: Path Vector
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Author(s)        : K. Gao, Y. Lee,
> S. Randriamasy, Y.R. Yang, J. Zhang
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; WG Chair(s)      : Jan Seedorf,
> Mohamed Boucadair, Qin Wu
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt; Area Director(s) : Martin Duke,
> Zaheduzzaman Sarker
> &gt; &gt;&gt; &gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> &gt; &gt;&gt; &gt; &gt; &gt; &gt;
> </https:></artwork></sourcecode></artwork></artwork></draft-ietf-alto-path-vector-25></sourcecode><rfc9275.xml>
> &gt; &gt;&gt;
> </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>
> &gt; &gt;
> </lbartholomew@amsl.com></draft-ietf-alto-path-vector-25></
> martin.h.duke@gmail.com></rfc-editor@rfc-editor.org></
> lbartholomew@amsl.com>