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

[Young Lee <[e-mail]>]

Hi Lynne,

The document looks good to me. I approve the publication of this document.

Thanks.
Young

2022년 9월 7일 (수) 오후 4:56, Jensen Zhang <[e-mail]>님이 작성:

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