Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-alto-performance-metrics-28> for your review

["Sabine Randriamasy (Nokia)" <[e-mail]>]

Hi Lynne,
Thanks a lot for the updates on the figures and addresses. 
Everything is fine on my side now.
Best regards,
Sabine

>-----Original Message-----
>From: Lynne Bartholomew <[e-mail]>
>Sent: Tuesday, July 11, 2023 5:46 PM
>To: Dhruv Dhody <[e-mail]>;
><[e-mail]> <[e-mail]>;
>Sabine Randriamasy (Nokia) <[e-mail]>
>Cc: Qin Wu <bill.wu=[e-mail]>; [e-mail]; rfc-
>[e-mail]; [e-mail];
>[e-mail]; [e-mail]; alto-
>[e-mail]; [e-mail]; [e-mail]; auth48archive@rfc-
>editor.org
>Subject: Re: AUTH48: RFC-to-be 9439 <draft-ietf-alto-performance-metrics-28>
>for your review
>
>
>CAUTION: This is an external email. Please be very careful when clicking links
>or opening attachments. See the URL nok.it/ext for additional information.
>
>
>
>Hi, Dhruv, Med, and Sabine.
>
>Thank you for your examples as related to Figures 2 and 5.  It's not clear to us
>what caused the issue with the figures in the first place, but we believe that it's
>now resolved.
>
>Dhruv and Sabine, we have updated your contact information per your notes
>below.
>
>Please refresh your browser to view the latest updates, and let us know if
>anything is incorrect:
>
>   https://www.rfc-editor.org/authors/rfc9439.txt
>   https://www.rfc-editor.org/authors/rfc9439.pdf
>   https://www.rfc-editor.org/authors/rfc9439.html
>   https://www.rfc-editor.org/authors/rfc9439.xml
>   https://www.rfc-editor.org/authors/rfc9439-diff.html
>   https://www.rfc-editor.org/authors/rfc9439-rfcdiff.html
>   https://www.rfc-editor.org/authors/rfc9439-auth48diff.html
>   https://www.rfc-editor.org/authors/rfc9439-lastdiff.html
>   https://www.rfc-editor.org/authors/rfc9439-lastrfcdiff.html
>
>   https://www.rfc-editor.org/authors/rfc9439-xmldiff1.html
>   https://www.rfc-editor.org/authors/rfc9439-xmldiff2.html
>   https://www.rfc-editor.org/authors/rfc9439-alt-diff.html
>
>Sabine, now that the figures have been updated, after you have reviewed,
>please confirm that you approve this document (and if not, please let us know
>how this document should be further updated).
>
>Thanks again for your help with this document!
>
>RFC Editor/lb
>
>> On Jul 7, 2023, at 10:14 AM, Lynne Bartholomew
><[e-mail]> wrote:
>>
>> Hi, Dhruv.
>>
>> I'll give it a try.  If I get it wrong, we can revert to the previous iteration and
>try again.
>>
>> Thanks for the info.!
>>
>> RFC Editor/lb
>>
>>> On Jul 7, 2023, at 9:38 AM, Dhruv Dhody <[e-mail]> wrote:
>>>
>>> Hi Lynne,
>>>
>>> No, the changes are not technical in nature, they are because of the XML.
>>>
>>> Let's compare the XML around figure 2 and figure 5.
>>>
>>> This is figure 2 ->
>>>
>>>      <figure anchor="example-1">
>>>        <name>Delay Value on Source-Destination Endpoint Pairs (Example
>1)</name>
>>>          <artwork name="" type="" align="left" alt=""><![CDATA[
>>> POST /endpointcost/lookup HTTP/1.1
>>> Host: alto.example.com
>>> Content-Length: 239
>>> Content-Type: application/alto-endpointcostparams+json
>>> Accept:
>>>  application/alto-endpointcost+json,application/alto-error+json
>>>
>>> {
>>>  "cost-type": {
>>>    "cost-mode":   "numerical",
>>>    "cost-metric": "delay-ow"
>>>  },
>>>  "endpoints": {
>>>    "srcs": [
>>>      "ipv4:192.0.2.2"
>>>    ],
>>>    "dsts": [
>>>      "ipv4:192.0.2.89",
>>>      "ipv4:198.51.100.34"
>>>    ]
>>>  }
>>> }
>>> ]]></artwork>
>>>      </figure>
>>>          <sourcecode type="json"><![CDATA[
>>> HTTP/1.1 200 OK
>>> Content-Length: 247
>>> Content-Type: application/alto-endpointcost+json
>>>
>>> {
>>>  "meta": {
>>>    "cost-type": {
>>>      "cost-mode":   "numerical",
>>>      "cost-metric": "delay-ow"
>>>    }
>>>  },
>>>  "endpoint-cost-map": {
>>>    "ipv4:192.0.2.2": {
>>>      "ipv4:192.0.2.89":    10,
>>>      "ipv4:198.51.100.34": 20
>>>    }
>>>  }
>>> }
>>> ]]></sourcecode>
>>>
>>> This is figure 5 ->
>>>
>>>          <figure anchor="example-3">
>>>           <name>Delay Variation Value on Source-Destination Endpoint Pairs
>(Example 3)</name>
>>>          <sourcecode type="json"><![CDATA[
>>> POST /endpointcost/lookup HTTP/1.1
>>> Host: alto.example.com
>>> Content-Length: 245
>>> Content-Type: application/alto-endpointcostparams+json
>>> Accept:
>>>   application/alto-endpointcost+json,application/alto-error+json
>>>
>>> {
>>>  "cost-type": {
>>>    "cost-mode":   "numerical",
>>>    "cost-metric": "delay-variation"
>>>  },
>>>  "endpoints": {
>>>    "srcs": [
>>>      "ipv4:192.0.2.2"
>>>    ],
>>>    "dsts": [
>>>      "ipv4:192.0.2.89",
>>>      "ipv4:198.51.100.34"
>>>    ]
>>>  }
>>> }
>>>
>>> HTTP/1.1 200 OK
>>> Content-Length: 252
>>> Content-Type: application/alto-endpointcost+json
>>>
>>> {
>>>  "meta": {
>>>    "cost-type": {
>>>      "cost-mode":   "numerical",
>>>      "cost-metric": "delay-variation"
>>>    }
>>>  },
>>>  "endpoint-cost-map": {
>>>    "ipv4:192.0.2.2": {
>>>      "ipv4:192.0.2.89":    0,
>>>      "ipv4:198.51.100.34": 1
>>>    }
>>>  }
>>> }
>>> ]]></sourcecode>
>>> </figure>
>>>
>>> In case of figure 5 you consider the whole block as one figure
>(<figure><sourcecode>...</sourcecode></figure>) and thus we have figure's
>title at the end, where as everywhere else you have <figure> first followed by
><sourcecode> (<figure..</figure><sourcecode>...</sourcecode>) where figure
>portion gets a title and sourcecode does not. Please use
>(<figure><sourcecode>...</sourcecode></figure>) everywhere. I hope this
>explains it and you agree that this is not a technical change! I guess the v2 to
>v3 conversion is to blame?
>>>
>>> Thanks!
>>> Dhruv
>>>
>>>
>>> On Fri, Jul 7, 2023 at 9:28 PM Lynne Bartholomew
><[e-mail]> wrote:
>>> Hi, Med and Sabine.
>>>
>>> Thank you for clarifying.  As it appears that the changes you request are
>technical in nature (for example, we at the RPC are not familiar with the
>intricacies of HTTP POST), we will need to ask that one of you do one of the
>following:
>>>
>>> 1.  Send us the requested updates for each figure, using "OLD" and "NEW"
>entries.
>>> 2.  Update the latest XML file and send us the updated copy when you are
>finished.
>>>
>>> Also, the figure captions, which we understand to be the figure titles, are
>always under the HTTP information in question.  If you want to make changes
>in this regard as well, we will need your help.
>>>
>>> After the changes are complete, as they are technical in nature, we will then
>ask for AD approval.
>>>
>>> Thank you for your patience.
>>>
>>> RFC Editor/lb
>>>
>>>> On Jul 7, 2023, at 8:42 AM, Sabine Randriamasy (Nokia)
><[e-mail]> wrote:
>>>>
>>>> Hi Lynne,
>>>> If I may, since I found the same issue: looking at least at  https://www.rfc-
>editor.org/authors/rfc9439.txt and https://www.rfc-
>editor.org/authors/rfc9439.html I found the following:
>>>> in figures 2,3,4,6,7,8,9,10 the caption is between the POST request and the
>HTTP/1.1 response, which suggests that these figures only illustrate POST
>requests.
>>>> Instead, in figure 5, the caption is below the HTTP response, which is "the
>right thing to do" as Dhruv says.
>>>> So, on my side, I suggest to put the figure caption under the HTTP response
>in figures 2,3,4,6,7,8,9,10.
>>>> I leave it to Dhruv to tell if he agrees.
>>>>
>>>> Thanks and best regards,
>>>> Sabine
>>>
>>>> On Jul 7, 2023, at 8:41 AM, [e-mail] wrote:
>>>>
>>>> Hi Lynne,
>>>>
>>>> I agree with Dhruv. I think the formatting of Figure 5 is OK, while the others
>have to be fixed. See for example, Figure 4:
>>>>
>>>> ==
>>>>  POST /endpointcost/lookup HTTP/1.1
>>>>  Host: alto.example.com
>>>>  Content-Length: 238
>>>>  Content-Type: application/alto-endpointcostparams+json
>>>>  Accept:
>>>>    application/alto-endpointcost+json,application/alto-error+json
>>>>
>>>>  {
>>>>    "cost-type": {
>>>>      "cost-mode":   "numerical",
>>>>      "cost-metric": "delay-rt"
>>>>    },
>>>>    "endpoints": {
>>>>      "srcs": [
>>>>        "ipv4:192.0.2.2"
>>>>      ],
>>>>      "dsts": [
>>>>        "ipv4:192.0.2.89",
>>>>        "ipv4:198.51.100.34"
>>>>      ]
>>>>    }
>>>>  }
>>>>
>>>> ===>  Figure 4: Round-Trip Delay of Source-Destination Endpoint Pairs
>>>>                               (Example 2)
>>>>
>>>>  HTTP/1.1 200 OK
>>>>  Content-Length: 245
>>>>  Content-Type: application/alto-endpointcost+json
>>>>
>>>>  {
>>>>    "meta": {
>>>>      "cost-type": {
>>>>        "cost-mode":   "numerical",
>>>>        "cost-metric": "delay-rt"
>>>>      }
>>>>    },
>>>>    "endpoint-cost-map": {
>>>>      "ipv4:192.0.2.2": {
>>>>        "ipv4:192.0.2.89":    4,
>>>>        "ipv4:198.51.100.34": 3
>>>>      }
>>>>    }
>>>>  }
>>>> ==
>>>>
>>>> While, this should be:
>>>>
>>>> NEW:
>>>>
>>>>  POST /endpointcost/lookup HTTP/1.1
>>>>  Host: alto.example.com
>>>>  Content-Length: 238
>>>>  Content-Type: application/alto-endpointcostparams+json
>>>>  Accept:
>>>>    application/alto-endpointcost+json,application/alto-error+json
>>>>
>>>>  {
>>>>    "cost-type": {
>>>>      "cost-mode":   "numerical",
>>>>      "cost-metric": "delay-rt"
>>>>    },
>>>>    "endpoints": {
>>>>      "srcs": [
>>>>        "ipv4:192.0.2.2"
>>>>      ],
>>>>      "dsts": [
>>>>        "ipv4:192.0.2.89",
>>>>        "ipv4:198.51.100.34"
>>>>      ]
>>>>    }
>>>>  }
>>>>
>>>>  HTTP/1.1 200 OK
>>>>  Content-Length: 245
>>>>  Content-Type: application/alto-endpointcost+json
>>>>
>>>>  {
>>>>    "meta": {
>>>>      "cost-type": {
>>>>        "cost-mode":   "numerical",
>>>>        "cost-metric": "delay-rt"
>>>>      }
>>>>    },
>>>>    "endpoint-cost-map": {
>>>>      "ipv4:192.0.2.2": {
>>>>        "ipv4:192.0.2.89":    4,
>>>>        "ipv4:198.51.100.34": 3
>>>>      }
>>>>    }
>>>>  }
>>>>
>>>>   Figure 4: Round-Trip Delay of Source-Destination Endpoint Pairs
>>>>                               (Example 2)
>>>>
>>>>
>>>> This applies to all the figures listed by Dhruv.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -----Message d'origine-----
>>>>> De : Lynne Bartholomew <[e-mail]>
>>>>> Envoyé : vendredi 7 juillet 2023 17:29
>>>>> À : Dhruv Dhody <[e-mail]>
>>>>> Cc : Qin Wu <bill.wu=[e-mail]>;
>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>> [e-mail];
>>>>> [e-mail]; [e-mail];
>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>> [e-mail]
>>>>> Objet : Re: AUTH48: RFC-to-be 9439 <draft-ietf-alto-performance-
>>>>> metrics-28> for your review
>>>>>
>>>>> Hi, Dhruv.
>>>>>
>>>>> Before we make any further changes, would you please clarify the
>>>>> issue with Figure 5?  We could not find a problem.
>>>>>
>>>>> Does "at the bottom" mean "at the end of the section"?  If yes,
>>>>> please let us know where Figure 5 should appear in Section 4.3.3,
>>>>> as opposed to its current placement.
>>>>>
>>>>> Thank you!
>>>>>
>>>>> RFC Editor/lb
>
>>>>> On Jul 7, 2023, at 3:43 AM, Sabine Randriamasy (Nokia)
><[e-mail]> wrote:
>>>>>
>>>>> Dear Lynne,
>>>>> Thanks a lot for the editing, and same comment on my side as Dhruv’s,
>regarding the caption of Figures 2,3,4,6,7,8,9,10.
>>>>> I have one update request: can you please update my address as follows:
>>>>> OLD
>>>>>    Sabine Randriamasy
>>>>>    Nokia Bell Labs
>>>>>    Route de Villejust
>>>>>    91460 Nozay
>>>>>    France
>>>>>    Email: [e-mail]
>>>>>  NEW
>>>>>    Sabine Randriamasy
>>>>>    Nokia Networks France
>>>>>    France
>>>>>    Email: [e-mail]
>>>>>  With that, please note my approval,
>>>>> Thanks again and best regards,
>>>>> Sabine
>
>
>
>>>>>
>>>>>> On Jul 6, 2023, at 11:17 PM, Dhruv Dhody <[e-mail]>
>>>>> wrote:
>>>>>>
>>>>>> Hi Lynne,
>>>>>>
>>>>>> Thanks for editing. The diff looks good to me. Two changes
>>>>>>
>>>>>> (1) Can you update my address as
>>>>>>
>>>>>> OLD
>>>>>> Dhruv Dhody
>>>>>> Huawei
>>>>>> Leela Palace
>>>>>> Bangalore 560008
>>>>>> Karnataka
>>>>>> India
>>>>>> Email: [e-mail]
>>>>>> NEW
>>>>>> Dhruv Dhody
>>>>>> Huawei
>>>>>> India
>>>>>> Email: [e-mail]
>>>>>> END
>>>>>>
>>>>>> (2) I find the number of figures to be a bit weird. Figure
>>>>> 2,3,4,6,7,8,9,10 are shown in the middle, whereas Figure 5 at the
>>>>> bottom. IMO the bottom is the right thing to do. BTW in the
>>>>> author's version we did not have figure numbering.
>>>>>>
>>>>>>
>>>>>> With that, please note my approval.
>>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Dhruv
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 7, 2023 at 2:17 AM Lynne Bartholomew
>>>>> <[e-mail]> wrote:
>>>>>> Hi, Qin and Richard.
>>>>>>
>>>>>> Qin, thank you for your replies.  We have some follow-up items
>>>>> for you:
>>>>>>
>>>>>> Regarding this question and your reply:
>>>>>>
>>>>>>>> 3) <!-- [rfced] Sections 1 and 3.1:  Are the quotes around
>>>>> the words "where" and "how" necessary?
>>>>>>>>
>>>>>>>> Original:
>>>>>>>> This document registers a set of new cost metrics (Table 1)
>>>>> to allow  applications to determine "where" to connect based on
>>>>> network  performance criteria including delay and bandwidth
>>>>> related metrics.
>>>>>>>> ...
>>>>>>>> The core additional details of a performance metric specify
>>>>> "how" the  metric is obtained. -->
>>>>>>>
>>>>>>>
>>>>>>> [Qin Wu] I think the quotes can be deleted. What it does is
>>>>> just to put emphasize on the key words.
>>>>>>
>>>>>> We have left the quotes in place for now.  We'd like to point
>>>>> out that one available option in xml2rfc v3 is to replace the
>>>>> quotes with "<em>"; per Section 2.2 of RFC 7991, <em> indicates
>>>>> "text that is semantically emphasized.  Text enclosed within this
>>>>> element will be displayed as italic after processing."
>>>>>>
>>>>>> Another option is to use <strong>; per Section 2.50 of RFC 7991,
>>>>> <strong> indicates "text that is semantically strong.  Text
>>>>> enclosed within this element will be displayed as bold after
>>>>> processing."
>>>>>>
>>>>>> Would you like to implement either of these options?  Please
>>>>> note that <em> would italicize the text in the HTML and PDF output
>>>>> and yield underscores in the TXT output, and <strong> would
>>>>> boldface the text in the HTML and PDF output and yield asterisks
>>>>> in the TXT output.  Please advise; if you'd prefer not to use <em>
>>>>> or <strong>, we will then remove the quotes.
>>>>>>
>>>>>> = = = = =
>>>>>>
>>>>>> Regarding this question and your reply:
>>>>>>
>>>>>>>> 5) <!-- [rfced] Section 1:  This sentence is difficult to
>>>>> interpret.
>>>>>>>> Please clarify "... metrics, to expose to application-layer
>>>>> traffic  optimization, can be a typical mechanism by network
>>>>> operators".
>>>>>>>>
>>>>>>>> Original:
>>>>>>>> Deriving ALTO cost
>>>>>>>> performance metrics from existing network-layer traffic
>>>>> engineering  performance metrics, to expose to application-layer
>>>>> traffic  optimization, can be a typical mechanism by network
>>>>> operators to  deploy ALTO [RFC7971], [FlowDirector]. -->
>>>>>>> [Qin Wu] Here is the proposed change:
>>>>>>> OLD TEXT:
>>>>>>> "
>>>>>>> Deriving ALTO cost performance metrics from existing network-
>>>>> layer traffic engineering performance metrics, and making it
>>>>> exposed to application-layer traffic optimization, can be a
>>>>> typical mechanism by network operators to deploy ALTO [RFC7971],
>>>>> [FlowDirector].
>>>>>>> "
>>>>>>
>>>>>>
>>>>>> Does "making it" mean "making the metrics", in which case "it"
>>>>> should be either "them" or "the metrics"?
>>>>>>
>>>>>> = = = = =
>>>>>>
>>>>>> Regarding this item:  Please review our updates in the XML file,
>>>>> and let us know if (1) any of the remaining <artwork> items should
>>>>> be <sourcecode> with type="json" or (2) we mislabeled any artwork
>>>>> as <sourcecode> and should change it back to <artwork>:
>>>>>>
>>>>>>>> 8) <!-- [rfced] Please review each artwork element in this
>>>>> document.
>>>>>>>> Should any of the artwork elements be tagged as sourcecode
>>>>> (e.g., perhaps "http-message" or "json") or another type of
>>>>> element?
>>>>>>>> Please see
>>>>>>>>
>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fwww.rfc-editor.org%2Fmaterials%2Fsourcecode-
>>>>>
>types.txt&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07cd3b
>74
>>>>>
>01424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
>C
>>>>>
>0%7C638243408046242871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>AwMDA
>>>>>
>iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>d
>>>>>
>ata=WBSm0g18xIXi8P%2BE7vAaqra65M6dLDXQsx0NcvzU%2FoI%3D&reserved
>=0;
>>>>> if the list on that page does not contain an applicable type,
>>>>> please let us know. -->
>>>>>>> [Qin Wu] Yes, most of artwork elements are json examples, but
>>>>> table 1,2,3 are not.
>>>>>>
>>>>>>
>>>>>> = = = = =
>>>>>>
>>>>>> Regarding our question 14)c):  We could not find a reply to this
>>>>> question; apologies if we missed it:
>>>>>>
>>>>>>>> We found "value on" a bit confusing.  Does it mean "value
>>>>> for", "value of", or something else?
>>>>>>
>>>>>> = = = = =
>>>>>>
>>>>>> Regarding our question 27)c) and your reply:  The first reply
>>>>> ("Security consideration doesn't need to be reflected in the IANA
>>>>> registry") conflicts with the subsequent July 4 email from you in
>>>>> the thread below ("One more suggested change to section 8.2 ...
>>>>> Please help sync up with IANA to update their page accordingly,
>>>>> thanks!").  The updated table includes the Security Considerations
>>>>> column:
>>>>>>
>>>>>> Please let us know how Table 3 should look, and we will ensure
>>>>> that this document and the IANA page in question are in sync.
>>>>> before this document is published.
>>>>>>
>>>>>>>> c) Section 8.2. The last column in Table 3 does not match the
>>>>> last column in the "ALTO Cost Source" registry at
>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fwww.iana.org%2Fassignments%2Falto-
>>>>>
>protocol%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07c
>d3b
>>>>>
>7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
>>>>>
>7C0%7C638243408046242871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>LjAwM
>>>>>
>DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>&
>>>>>
>sdata=HAPGNwAHXbJFR5r0Brza%2FNtAnEFdSxXqCafOo9Q2X9Q%3D&reserved
>=0>
>>>>> . In Table 3, the column is named "Security Considerations" and
>>>>> points to Section 7 of this document whereas the column in the
>>>>> IANA registry is named "References" and points to this document.
>>>>> Should the IANA registry be updated to match Table 3? -->
>>>>>>>
>>>>>>> [Qin Wu] I can see inconsistency issue but to align with other
>>>>> registries at
>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fwww.iana.org%2Fassignments%2Falto-
>>>>>
>protocol%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07c
>d3b
>>>>>
>7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
>>>>>
>7C0%7C638243408046242871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>LjAwM
>>>>>
>DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>&
>>>>>
>sdata=HAPGNwAHXbJFR5r0Brza%2FNtAnEFdSxXqCafOo9Q2X9Q%3D&reserved
>=0>
>>>>> , I prefer to keep as it does. Security consideration doesn't need
>>>>> to be reflected in the IANA registry in my understanding.
>>>>>>
>>>>>>
>>>>>> = = = = =
>>>>>>
>>>>>> Please advise regarding the following items from our question
>>>>> 30):
>>>>>>
>>>>>>>> an "sla" value (Sections 5.2.4 and 5.3.4) /
>>>>>>>> an SLA value (Sections 4.5.4 and 5.1.4)
>>>>>>
>>>>>>
>>>>>>> Hop Count / hop count (in running text)*
>>>>>>
>>>>>> [rfced]  Should "Hop Count is specified to be an integer" be
>>>>> "hop count is specified to be an integer"?
>>>>>>
>>>>>>
>>>>>>>> method of measurement or calculation /
>>>>>>>> Method of Measurement or Calculation (e.g., "about the
>>>>>>>>  method of measurement or calculation",
>>>>>>>>  "such as Method of Measurement or Calculation")
>>>>>>
>>>>>>
>>>>>> = = = = =
>>>>>>
>>>>>> The latest files are posted here (please refresh your browser):
>>>>>>
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauthors%2Frfc9439.txt&data=05%7C01%7Cmohamed.boucadai
>>>>>
>r%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b4
>0
>>>>>
>bfbc48b9253b6f5d20%7C0%7C0%7C638243408046399099%7CUnknown%7CT
>WFpbG
>>>>>
>Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>>>>>
>Mn0%3D%7C3000%7C%7C%7C&sdata=qr%2FYVsIAyXZ2KUwPAuwy3TEoR28pf
>m5EQEz
>>>>> Knz%2BtpeA%3D&reserved=0
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauthors%2Frfc9439.pdf&data=05%7C01%7Cmohamed.boucadai
>>>>>
>r%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b4
>0
>>>>>
>bfbc48b9253b6f5d20%7C0%7C0%7C638243408046399099%7CUnknown%7CT
>WFpbG
>>>>>
>Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>>>>>
>Mn0%3D%7C3000%7C%7C%7C&sdata=8c7GUHrs4H5DJOnZ%2FsKq%2FxxB%2F
>Ixbzul
>>>>> IA1BvyVqkhd0%3D&reserved=0
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauthors%2Frfc9439.html&data=05%7C01%7Cmohamed.boucada
>>>>>
>ir%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b4
>>>>>
>0bfbc48b9253b6f5d20%7C0%7C0%7C638243408046399099%7CUnknown%7C
>TWFpb
>>>>>
>GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
>>>>>
>6Mn0%3D%7C3000%7C%7C%7C&sdata=xHazTSZjCi%2FVN8WFj2R7gHWPQgSP
>5Li1sI
>>>>> 90KVQRYWE%3D&reserved=0
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauthors%2Frfc9439.xml&data=05%7C01%7Cmohamed.boucadai
>>>>>
>r%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b4
>0
>>>>>
>bfbc48b9253b6f5d20%7C0%7C0%7C638243408046399099%7CUnknown%7CT
>WFpbG
>>>>>
>Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>>>>>
>Mn0%3D%7C3000%7C%7C%7C&sdata=h%2BeZVlONDX5YJyUs5VigDrISdseJCPf
>SEML
>>>>> AatrMI1A%3D&reserved=0
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-editor.org%2Fauthors%2Frfc9439-
>>>>>
>diff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07cd3b
>74
>>>>>
>01424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
>C
>>>>>
>0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>AwMDA
>>>>>
>iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>d
>>>>>
>ata=MtaUn2CI2cmjsEYBXKC3TPtm3P1Ft6%2Ffc4QoE%2BnmVLI%3D&reserved=
>0
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-editor.org%2Fauthors%2Frfc9439-
>>>>>
>rfcdiff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07cd
>3
>>>>>
>b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
>>>>>
>%7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
>wLjAw
>>>>>
>MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
>C
>>>>>
>&sdata=Q888HxPVrPby0tpSOWtd%2B0iBRQSgnsRRXwH8yStK2CA%3D&reserve
>d=0
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-editor.org%2Fauthors%2Frfc9439-
>>>>>
>auth48diff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C0
>7
>>>>>
>cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%
>>>>>
>7C0%7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
>MC4wL
>>>>>
>jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
>C
>>>>>
>%7C&sdata=psKpd25XmDplF%2FiYbRN6vvoyE78k2ujL6V3nVZYUpSY%3D&reser
>ve
>>>>> d=0
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-editor.org%2Fauthors%2Frfc9439-
>>>>>
>lastdiff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07cd
>>>>>
>3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
>>>>>
>0%7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
>4wLjA
>>>>>
>wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
>%7
>>>>>
>C&sdata=KYiRZ5JbkP5c%2BO7%2FnuVb503Bwr%2BTF17kGI61KnwOo5I%3D&re
>ser
>>>>> ved=0
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-editor.org%2Fauthors%2Frfc9439-
>>>>>
>lastrfcdiff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C0
>>>>>
>7cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20
>>>>>
>%7C0%7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIj
>oiMC4w
>>>>>
>LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
>7
>>>>>
>C%7C&sdata=IANpCb0HoM3619dJTaWQ5vCVbiT9Ec3yWoK%2BljW%2BKiM%3
>D&rese
>>>>> rved=0
>>>>>>
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-editor.org%2Fauthors%2Frfc9439-
>>>>>
>xmldiff1.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07
>cd
>>>>>
>3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
>>>>>
>0%7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
>4wLjA
>>>>>
>wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
>%7
>>>>>
>C&sdata=ogF%2FxQ1l6Gj4OkLt%2Bz66Wbunyvlt6aCiLU9DOu1S1Ik%3D&reserv
>e
>>>>> d=0
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-editor.org%2Fauthors%2Frfc9439-
>>>>>
>xmldiff2.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07
>cd
>>>>>
>3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
>>>>>
>0%7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
>4wLjA
>>>>>
>wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
>%7
>>>>>
>C&sdata=bYkWvoximHRTdfNZTKi0BtEH5oHtcC2t9tY%2F2Q%2Ffpxo%3D&reser
>ve
>>>>> d=0
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-editor.org%2Fauthors%2Frfc9439-alt-
>>>>>
>diff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07cd3b
>74
>>>>>
>01424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
>C
>>>>>
>0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>AwMDA
>>>>>
>iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>d
>>>>>
>ata=6leUYcaziC6m6BmNboxYCXZ6mhALXPA%2BPsDlymIt3IE%3D&reserved=0
>>>>>>
>>>>>> Richard, we have noted your approval on the AUTH48 status page.
>>>>> Because updates to this document are ongoing, we assume that if
>>>>> you object to any subsequent changes you will let us know:
>>>>>>
>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauth48%2Frfc9439&data=05%7C01%7Cmohamed.boucadair%40
>o
>>>>>
>range.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc4
>>>>>
>8b9253b6f5d20%7C0%7C0%7C638243408046399099%7CUnknown%7CTWFpb
>GZsb3d
>>>>>
>8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>
>D%7C3000%7C%7C%7C&sdata=1En7ViA8bwNwnXdaAQQGWmnBmYv0vFXxHQ
>VENvVph9
>>>>> k%3D&reserved=0
>>>>>>
>>>>>> Thanks again!
>>>>>>
>>>>>> RFC Editor/lb
>>>>>>
>>>>>>
>>>>>>> On Jul 5, 2023, at 12:47 PM, Y. Richard Yang <[e-mail]>
>>>>> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Sorry for the late reply. I looked at all of the changes and
>>>>> do not have anything to add and sign it off.
>>>>>>>
>>>>>>> Thank you so much!
>>>>>>> Richard
>>>>>>
>>>>>>
>>>>>>> On Jul 4, 2023, at 7:28 AM, Qin Wu
>>>>> <bill.wu=[e-mail]> wrote:
>>>>>>>
>>>>>>> One more suggested change to section 8.2
>>>>>>> OLD TEXT:
>>>>>>> "
>>>>>>>
>>>>>
>+============+===============================+================+
>>>>>>>    | Identifier | Intended Semantics            | Security
>>>>> |
>>>>>>>    |            |                               |
>>>>> Considerations |
>>>>>>>
>>>>>
>+============+===============================+================+
>>>>>>>    | nominal    | Values in nominal cases       | Section 7
>>>>> |
>>>>>>>    |            | (Section 3.1)                 |
>>>>> |
>>>>>>>    +------------+-------------------------------+-----------
>>>>> -----+
>>>>>>>    | sla        | Values reflecting service     | Section 7
>>>>> |
>>>>>>>    |            | level agreement (Section 3.1) |
>>>>> |
>>>>>>>    +------------+-------------------------------+-----------
>>>>> -----+
>>>>>>>    | estimation | Values by estimation          | Section 7
>>>>> |
>>>>>>>    |            | (Section 3.1)                 |
>>>>> |
>>>>>>>    +------------+-------------------------------+-----------
>>>>> -----+
>>>>>>>
>>>>>>> "
>>>>>>> NEW TEXT:
>>>>>>> "
>>>>>>>
>>>>>
>+============+===============================+================+==
>=
>>>>> ========+
>>>>>>> | Identifier | Intended Semantics            | Security
>>>>> | Reference |
>>>>>>> |            |                               | Considerations
>>>>> |           |
>>>>>>>
>>>>>
>+============+===============================+================+==
>=
>>>>> ========+
>>>>>>> | nominal    | Values in nominal cases       | Section 7
>>>>> | RFC 9439  |
>>>>>>> |            | (Section 3.1)                 |
>>>>> |           |
>>>>>>> +------------+-------------------------------+----------------
>>>>> +-----------+
>>>>>>> | sla        | Values reflecting service     | Section 7
>>>>> | RFC 9439  |
>>>>>>> |            | level agreement (Section 3.1) |
>>>>> |           |
>>>>>>> +------------+-------------------------------+----------------
>>>>> +-----------+
>>>>>>> | estimation | Values by estimation          | Section 7
>>>>> | RFC 9439  |
>>>>>>> |            | (Section 3.1)                 |
>>>>> |           |
>>>>>>> +------------+-------------------------------+----------------
>>>>> +-----------+
>>>>>>> "
>>>>>>> Please help sync up with IANA to update their page
>>>>> accordingly, thanks!
>>>>>>>
>>>>>>> -Qin
>>>>>>
>>>>>>> On Jul 4, 2023, at 6:42 AM, Qin Wu
>>>>> <bill.wu=[e-mail]> wrote:
>>>>>>>
>>>>>>> Hi, RFC Editors:
>>>>>>> Sorry for late followup, please see my reply inline below on
>>>>> behalf of all other authors.
>>>>>>>
>>>>>>> -----邮件原件-----
>>>>>>> 发件人: [e-mail] [mailto:rfc-editor@rfc-
>>>>> editor.org]
>>>>>>> 发送时间: 2023年6月24日 7:53
>>>>>>> 收件人: Qin Wu <[e-mail]>; [e-mail];
>>>>> [e-mail]; [e-mail];
>>>>> [e-mail];
>>>>> [e-mail]
>>>>>>> 抄送: [e-mail]; [e-mail]; alto-
>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>> [e-mail]
>>>>>>> 主题: Re: AUTH48: RFC-to-be 9439 <draft-ietf-alto-performance-
>>>>> metrics-28> for your review
>>>>>>>
>>>>>>> Authors,
>>>>>>>
>>>>>>> While reviewing this document during AUTH48, please resolve
>>>>> (as necessary) the following questions, which are also in the XML
>>>>> file.
>>>>>>>
>>>>>>> 1) <!-- [rfced] Please note that we expanded "ALTO" in the
>>>>> document title, per Section 3.6 of RFC 7322 ("RFC Style Guide")
>>>>> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fwww.rfc-
>>>>>
>editor.org%2Finfo%2Frfc7322&data=05%7C01%7Cmohamed.boucadair%40ora
>>>>>
>nge.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b
>>>>>
>9253b6f5d20%7C0%7C0%7C638243408046399099%7CUnknown%7CTWFpbGZ
>sb3d8e
>>>>>
>yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>>>>>
>7C3000%7C%7C%7C&sdata=DLvgA7yd4dtVfsPvXzIYV%2BX7WoLl0iPMQZP1C8FY
>Gq
>>>>> 0%3D&reserved=0).  Please review.
>>>>>>>
>>>>>>> Original:
>>>>>>> ALTO Performance Cost Metrics
>>>>>>>
>>>>>>> Currently:
>>>>>>> Application-Layer Traffic Optimization (ALTO) Performance Cost
>>>>> Metrics
>>>>>>> -->
>>>>>>> [Qin Wu] Sounds good to me.
>>>>>>>
>>>>>>> 2) <!-- [rfced] Authors' Addresses:  Please advise regarding
>>>>> the listed zip code for Y. Richard Yang.  We see "06520" here, but
>>>>> please note that RFCs 7285, 9240, 9241, and 9275 use 06511 but RFC
>>>>> 8896 uses 06520.  Which is correct?
>>>>>>>
>>>>>>> Original:
>>>>>>> Y. Richard Yang
>>>>>>> Yale University
>>>>>>> 51 Prospect St
>>>>>>> New Haven, CT 06520
>>>>>>> United States of America
>>>>>>> Email: [e-mail] -->
>>>>>>>
>>>>>>> [Qin Wu] I google address of Yale University, I believe
>>>>> '06520' is correct one.
>>>>>>>
>>>>>>> 3) <!-- [rfced] Sections 1 and 3.1:  Are the quotes around the
>>>>> words "where" and "how" necessary?
>>>>>>>
>>>>>>> Original:
>>>>>>> This document registers a set of new cost metrics (Table 1) to
>>>>> allow  applications to determine "where" to connect based on
>>>>> network  performance criteria including delay and bandwidth
>>>>> related metrics.
>>>>>>> ...
>>>>>>> The core additional details of a performance metric specify
>>>>> "how" the  metric is obtained. -->
>>>>>>>
>>>>>>>
>>>>>>> [Qin Wu] I think the quotes can be deleted. What it does is
>>>>> just to put emphasize on the key words.
>>>>>>>
>>>>>>> 4) <!-- [rfced] Table 1:
>>>>>>>
>>>>>>> a) Should "sum Unidirectional Delay" be "sum of Unidirectional
>>>>> Delays"?  It appears that one or more words are missing.
>>>>>>> [Qin Wu] Yes, For space limit in the table, the "of" is
>>>>> omitted but I believe we should make it complete, I agree to make
>>>>> the change, for the first word, we should use Capital letter,
>>>>> i.e.,
>>>>>>> s/sum Unidirectional Delay/Sum of Unidirectional Delay of
>>>>> links along the path
>>>>>>> b) To what does "from above" refer?
>>>>>>> [Qin Wu] "from above" is referred to one way delay in
>>>>> direction or Unidirectional Delay
>>>>>>> c) Should "sum of Unidirectional Delay Variation" be "sum of
>>>>> Unidirectional Delay Variations"?
>>>>>>> [Qin Wu] No, sum of Unidirectional Delay Variation is referred
>>>>> to Sum of Unidirectional Delay Variation of links along the path
>>>>>>> Original:
>>>>>>> sum Unidirectional Delay
>>>>>>> ...
>>>>>>> Base: Sum of two directions
>>>>>>> from above
>>>>>>> ...
>>>>>>> sum of Unidirectional Delay Variation -->
>>>>>>> [Qin Wu] Here is the proposed changes:
>>>>>>> OLD TEXT:
>>>>>>> "
>>>>>>> sum Unidirectional Delay
>>>>>>> ...
>>>>>>> Base: Sum of two directions
>>>>>>> from above
>>>>>>> ...
>>>>>>> sum of Unidirectional Delay Variation -->
>>>>>>> "
>>>>>>> NEW TEXT：
>>>>>>> "
>>>>>>> Sum of Unidirectional Delay of links along the path
>>>>>>> Base: Sum of two directions of unidirectional delay
>>>>>>>
>>>>>>> Sum of Unidirectional Delay Variation of links along the path
>>>>>>> "
>>>>>>> 5) <!-- [rfced] Section 1:  This sentence is difficult to
>>>>> interpret.
>>>>>>> Please clarify "... metrics, to expose to application-layer
>>>>> traffic  optimization, can be a typical mechanism by network
>>>>> operators".
>>>>>>>
>>>>>>> Original:
>>>>>>> Deriving ALTO cost
>>>>>>> performance metrics from existing network-layer traffic
>>>>> engineering  performance metrics, to expose to application-layer
>>>>> traffic  optimization, can be a typical mechanism by network
>>>>> operators to  deploy ALTO [RFC7971], [FlowDirector]. -->
>>>>>>> [Qin Wu] Here is the proposed change:
>>>>>>> OLD TEXT:
>>>>>>> "
>>>>>>> Deriving ALTO cost performance metrics from existing network-
>>>>> layer traffic engineering performance metrics, and making it
>>>>> exposed to application-layer traffic optimization, can be a
>>>>> typical mechanism by network operators to deploy ALTO [RFC7971],
>>>>> [FlowDirector].
>>>>>>> "
>>>>>>>
>>>>>>> 6) <!-- [rfced] Section 1:  Because the capitalization of the
>>>>> terms in this paragraph indicates that these are proper terms but
>>>>> we could not find these specific terms in the RFCs cited here, may
>>>>> we update as suggested?  If not, please provide clarifying text.
>>>>>>>
>>>>>>> Original:
>>>>>>> The common metrics Min/Max Unidirectional Delay defined in
>>>>> [RFC8570][RFC8571] and Max Link Bandwidth defined in
>>>>> [RFC3630,RFC5305] are not listed in Table 1 because they can be
>>>>> handled by applying the statistical operators defined in this
>>>>> document.  The metrics related with utilized bandwidth and
>>>>> reservable  bandwidth (i.e., Max Reservable BW and Unreserved BW
>>>>> defined in
>>>>>>> [RFC3630,RFC5305]) are outside the scope of this document.
>>>>>>>
>>>>>>> Suggested:
>>>>>>> The Min/Max Unidirectional Link Delay metric as defined in
>>>>> [RFC8570] and [RFC8571], and Maximum (Link) Bandwidth as defined
>>>>> in  [RFC3630] and [RFC5305], are not listed in Table 1 because
>>>>> they can  be handled by applying the statistical operators defined
>>>>> in this  document.  The metrics related to utilized bandwidth and
>>>>> reservable  bandwidth (i.e., Maximum Reservable (Link) Bandwidth
>>>>> and Unreserved  Bandwidth as defined in [RFC3630] and [RFC5305])
>>>>> are outside the  scope of this document. -->
>>>>>>> [Qin Wu] The proposed changes sound good to me.
>>>>>>>
>>>>>>> 7) <!-- [rfced] Section 3:  As this list indicated five items
>>>>> but only contained four (i, ii, iv, and v), we renumbered it.  If
>>>>> a fifth item is missing here, please let us know what it is.
>>>>>>>
>>>>>>> Original:
>>>>>>> To address the issue and realize ALTO use cases, for metrics
>>>>> in  Table 1, this document defines performance metric identifiers
>>>>> which  can be used in the ALTO protocol with well-defined (i)
>>>>> Metric Name,
>>>>>>> (ii) Metric Description, (iv) Units of Measurement, and (v)
>>>>> Measurement Points, which are always specified by the specific
>>>>> ALTO  services; for example, endpoint cost service is between the
>>>>> two  endpoints.
>>>>>>>
>>>>>>> Currently:
>>>>>>> To address the issue and realize ALTO use cases for the
>>>>> metrics  listed in Table 1, this document defines performance
>>>>> metric  identifiers that can be used in the ALTO protocol with the
>>>>> following  well-defined items: (1) Metric Name, (2) Metric
>>>>> Description, (3)  Units of Measurement, and (4) Measurement
>>>>> Points, which are always  specified by the specific ALTO services;
>>>>> for example, the endpoint  cost service is between the two
>>>>> endpoints.  Hence, the ALTO  performance metric identifiers
>>>>> provide basic metric attributes. -->
>>>>>>>
>>>>>>> [Qin Wu] The proposed change looks good, thanks.
>>>>>>> 8) <!-- [rfced] Please review each artwork element in this
>>>>> document.
>>>>>>> Should any of the artwork elements be tagged as sourcecode
>>>>> (e.g., perhaps "http-message" or "json") or another type of
>>>>> element?
>>>>>>> Please see
>>>>>>>
>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fwww.rfc-editor.org%2Fmaterials%2Fsourcecode-
>>>>>
>types.txt&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07cd3b
>74
>>>>>
>01424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
>C
>>>>>
>0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>AwMDA
>>>>>
>iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>d
>>>>>
>ata=4KSDG9urwxW0fjOd8A0%2BM9Bq0H4veyC%2BEk1fxYsobys%3D&reserve
>d=0;
>>>>> if the list on that page does not contain an applicable type,
>>>>> please let us know. -->
>>>>>>> [Qin Wu] Yes, most of artwork elements are json examples, but
>>>>> table 1,2,3 are not.
>>>>>>>
>>>>>>> 9) <!-- [rfced] Figure 1:  Please clarify the meaning of
>>>>> "estimation to".
>>>>>>> Does it mean "estimation of" or something else?
>>>>>>>
>>>>>>> Original:
>>>>>>> Figure 1. A framework to compute estimation to performance
>>>>> metrics -->
>>>>>>> [Qin Wu] Yes, s/estimation to/estimation of
>>>>>>>
>>>>>>> 10) <!-- [rfced] Section 3.2:  "99% percentile" and "99.9%
>>>>> percentile"
>>>>>>> read oddly, because they read as "99 percent percentile" and
>>>>> "99.9 percent percentile".  Should these be "99th percentile" and
>>>>> "99.9th percentile", per "95th percentile" as used in Section 4?
>>>>>>> [Qin Wu] Your understanding is correct.
>>>>>>> Original:
>>>>>>> For example, delay-
>>>>>>> ow:p99 gives the 99% percentile of observed one-way delay;
>>>>> delay-
>>>>>>> ow:p99.9 gives the 99.9% percentile. -->
>>>>>>> [Qin Wu] s/99% percentile/99th percentile,  s/99.9%
>>>>> percentile/99.9th percentile
>>>>>>>
>>>>>>> 11) <!-- [rfced] Section 3.2:  Please note that because we did
>>>>> not see any mention of "32", "character", or "metric" in RFC 7258
>>>>> ("Pervasive Monitoring Is an Attack"), we did a search and found
>>>>> the relevant text in Section 10.6 of RFC 7285.  We updated the
>>>>> number accordingly.
>>>>>>> Please let us know any concerns.
>>>>>>>
>>>>>>> Original:
>>>>>>> Note that RFC 7258 limits the overall cost metric identifier
>>>>> to 32  characters.
>>>>>>>
>>>>>>> Currently:
>>>>>>> Note that [RFC7285] limits the overall cost metric identifier
>>>>> to 32  characters. -->
>>>>>>>
>>>>>>> [Qin Wu] Sounds good, thanks.
>>>>>>>
>>>>>>> 12) <!-- [rfced] Section 4:  Should "set of delays
>>>>> {pkt.delay}" be "set of (pkt.delay) entries" per "(pkt.delay)",
>>>>> "(pkt.dropped)", and "(pkt.hopcount)" earlier in this paragraph?
>>>>> We ask because we do not see curly brackets used around "pkt."
>>>>> items anywhere else in this document.
>>>>>>> [Qin Wu] I want other authors to confirm this. My
>>>>> understanding is YES.
>>>>>>> Original (the previous sentence is included for context):
>>>>>>> The measures of each individual packet (pkt) can include the
>>>>> delay from  the time when the packet enters the network to the
>>>>> time when the  packet leaves the network (pkt.delay); whether the
>>>>> packet is dropped  before reaching the destination (pkt.dropped);
>>>>> the number of network  hops that the packet traverses
>>>>> (pkt.hopcount).  The semantics of the  performance metrics defined
>>>>> in this section are that they are  statistics computed from these
>>>>> measures; for example, the  x-percentile of the one-way delay is
>>>>> the x-percentile of the set of  delays {pkt.delay} for the packets
>>>>> in the stream. -->
>>>>>>> [Qin Wu] I prefer to keep as it does.
>>>>>>>
>>>>>>> 13) <!-- [rfced] Sections 4.1.3, 4.2.3, and 4.3.3:  We had
>>>>> trouble following the meaning of these sentences.  If the
>>>>> suggested text is not correct, please provide clarifying text.
>>>>>>>
>>>>>>> Original:
>>>>>>> A non-normative reference definition of end-to-end one-way
>>>>> delay is  [RFC7679].
>>>>>>> ...
>>>>>>> A non-normative reference definition of end-to-end  round-trip
>>>>> delay is [RFC2681].
>>>>>>> ...
>>>>>>> A non-normative reference definition of end-to-end  one-way
>>>>> delay variation is [RFC3393].
>>>>>>>
>>>>>>> Suggested:
>>>>>>> A non-normative definition of the end-to-end one-way delay
>>>>> metric is  provided in [RFC7679].
>>>>>>> ...
>>>>>>> A non-normative definition of the end-to-end round-trip delay
>>>>> metric  is provided in [RFC2681].
>>>>>>> ...
>>>>>>> A non-normative definition of the one-way delay variation
>>>>> metric is  provided in [RFC3393]. -->
>>>>>>>
>>>>>>> [Qin Wu] I believe it is correct, thanks.
>>>>>>>
>>>>>>> 14) <!-- [rfced] Examples 1 through 8 (Sections 4.1.3 and
>>>>> subsequent):
>>>>>>>
>>>>>>> a) We moved the "Example" information (e.g., "Example 1") from
>>>>> the body of the <artwork> elements to figure titles.  Please let
>>>>> us know any concerns.
>>>>>>>
>>>>>>> b) As the numbering scheme for the examples was misordered
>>>>> (... 3, 5, 4, 5, 7, 8), we also ordered the numbering.
>>>>>>>
>>>>>>> c) We found "value on" a bit confusing.  Does it mean "value
>>>>> for", "value of", or something else?
>>>>>>>
>>>>>>> Original numbering scheme:
>>>>>>> Example 1: Delay value on source-destination endpoint pairs
>>>>> ...
>>>>>>> Example 1a: Delay value on source-destination endpoint pairs
>>>>> for IPv6 ...
>>>>>>> Example 2: Round-trip Delay of source-destination endpoint
>>>>> pairs ...
>>>>>>> Example 3: Delay variation value on source-destination
>>>>> endpoint pairs ...
>>>>>>> Example 5: Loss rate value on source-destination endpoint
>>>>> pairs ...
>>>>>>> Example 4: hopcount value on source-destination endpoint pairs
>>>>> ...
>>>>>>> Example 5: TCP throughput value on source-destination endpoint
>>>>> pairs ...
>>>>>>> Example 7: bw-residual value on source-destination endpoint
>>>>> pairs ...
>>>>>>> Example 8: bw-available value on source-destination endpoint
>>>>> pairs
>>>>>>>
>>>>>>> Currently:
>>>>>>>       Figure 2: Delay Value on Source-Destination Endpoint
>>>>> Pairs
>>>>>>>                              (Example 1) ...
>>>>>>>     Figure 3: Delay Value on Source-Destination Endpoint
>>>>> Pairs for
>>>>>>>                           IPv6 (Example 1a) ...
>>>>>>>    Figure 4: Round-Trip Delay of Source-Destination Endpoint
>>>>> Pairs
>>>>>>>                             (Example 2) ...
>>>>>>>     Figure 5: Delay Variation Value on Source-Destination
>>>>> Endpoint
>>>>>>>                          Pairs (Example 3) ...
>>>>>>>     Figure 6: Loss Rate Value on Source-Destination Endpoint
>>>>> Pairs
>>>>>>>                              (Example 4) ...
>>>>>>>     Figure 7: Hop Count Value on Source-Destination Endpoint
>>>>> Pairs
>>>>>>>                              (Example 5) ...
>>>>>>>     Figure 8: TCP Throughput Value on Source-Destination
>>>>> Endpoint
>>>>>>>                           Pairs (Example 6) ...
>>>>>>>   Figure 9: Residual Bandwidth Value on Source-Destination
>>>>> Endpoint
>>>>>>>                           Pairs (Example 7) ...
>>>>>>>       Figure 10: Available Bandwidth Value on Source-
>>>>> Destination
>>>>>>>                       Endpoint Pairs (Example 8) -->
>>>>>>>
>>>>>>> [Qin Wu] Sounds good to me.
>>>>>>> 15) <!-- [rfced] Section 4.1.4:  Please clarify the meaning of
>>>>> "the URI to the URI field" in this sentence.
>>>>>>>
>>>>>>> Original ("RECOMMEDED" has been fixed):
>>>>>>> If the estimation is from the IPPM measurement framework, it
>>>>> is  RECOMMEDED that the "parameters" field of an "estimation" one-
>>>>> way  delay metric includes the following information: the URI to
>>>>> the URI  field of the IPPM metric defined in the IPPM performance
>>>>> metric  [IANA-IPPM] registry (e.g.,
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>
>www.iana.org%2Fassignments%2F&data=05%7C01%7Cmohamed.boucadair%
>40o
>>>>>
>range.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc4
>>>>>
>8b9253b6f5d20%7C0%7C0%7C638243408046399099%7CUnknown%7CTWFpb
>GZsb3d
>>>>>
>8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>
>D%7C3000%7C%7C%7C&sdata=50IbogbDI9XU7ox6Pjh%2FPhzIoFueEBay5KxRq
>SBx
>>>>> 6Cc%3D&reserved=0
>>>>>>> performance-metrics/OWDelay_Active_IP-UDP-Poisson-
>>>>>>> Payload250B_RFC8912sec7_Seconds_95Percentile).
>>>>>>>
>>>>>>> Possibly (as we see that all other field names are quoted):
>>>>>>> If the estimation is from the IPPM measurement framework, it
>>>>> is  RECOMMENDED that the "parameters" field of an "estimation"
>>>>> one-way  delay metric include the URI in the "URI" field of the
>>>>> IPPM metric  defined in the IPPM "Performance Metrics" registry
>>>>> [IANA-IPPM]  (e.g.,
>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fwww.iana.org%2Fassignments%2Fperformance-
>>>>>
>metrics%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07cd
>3b7
>>>>>
>401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
>>>>>
>C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
>jAwMD
>>>>>
>AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
>s
>>>>>
>data=r1%2FMaJl3VM%2BEP2RG7tsLKssfm3yKzOZqZt75UzX5%2F%2FI%3D&rese
>rv
>>>>> ed=0
>>>>>>> OWDelay_Active_IP-UDP-Poisson-
>Payload250B_RFC8912sec7_Seconds_
>>>>>>> 95Percentile>). -->
>>>>>>>
>>>>>>> [Qin Wu] your proposed change seems more clear than the
>>>>> original one, thanks!
>>>>>>>
>>>>>>> 16) <!-- [rfced] Section 4.3.3:  To what does "the one" refer
>>>>> in this sentence?  If the suggested text is not correct, please
>>>>> provide clarifying text.
>>>>>>>
>>>>>>> Original:
>>>>>>> This document defines the specific case that F selects as the
>>>>> "first"
>>>>>>> packet the one with the smallest one-way delay.
>>>>>>>
>>>>>>> Suggested:
>>>>>>> This document defines the specific case where F selects the
>>>>> packet  with the smallest one-way delay as the "first" packet. -->
>>>>>>>
>>>>>>> [Qin Wu] I believe the original and suggested text is
>>>>> equivalent, your suggested change works for me.
>>>>>>>
>>>>>>> 17) <!-- [rfced] Section 4.3.3:  To what does "it" refer in
>>>>> this sentence - the mean, or something else?
>>>>>>>
>>>>>>> Original (the previous sentence is included for context):
>>>>>>> Note that in statistics, variations are typically evaluated by
>>>>> the  distance from samples relative to the mean.  In networking
>>>>> context,  it is more commonly defined from samples relative to the
>>>>> min. -->
>>>>>>>
>>>>>>> [Qin Wu] It is referred to variation. To avoid confusion,
>>>>> suggested to make change to the previous sentence
>>>>>>> OLD TEXT:
>>>>>>> " variations are typically evaluated by the distance from
>>>>> samples relative to the mean. "
>>>>>>> NEW TEXT:
>>>>>>> " variation is typically evaluated by the distance from
>>>>> samples relative to the mean. "
>>>>>>> 18) <!-- [rfced] Section 4.4.4:  Does "of the average of loss
>>>>> rate" mean "of the average loss rate" or something else?
>>>>>>>
>>>>>>> Original ("link link" has been fixed):
>>>>>>> For estimation by aggregation of routing protocol link
>>>>> metrics, the  default aggregation of the average of loss rate is
>>>>> the sum of the  link link loss rates. -->
>>>>>>>
>>>>>>> [Qin Wu] Here is the proposed change:
>>>>>>> NEW TEXT:
>>>>>>> "
>>>>>>> For estimation by aggregation of routing protocol link
>>>>> metrics, the default aggregation of the average loss rate is the
>>>>> sum of the link loss rates.
>>>>>>> "
>>>>>>>
>>>>>>> 19) <!-- [rfced] Section 4.5.4:  Does "hop count" in these
>>>>> sentences mean "the hop count", "the hop count metric", or
>>>>> something else?
>>>>>>>
>>>>>>> Also, we see "estimating hopcounts" a couple lines later; does
>>>>> that mean "hopcount values", "hop counts", or something else?
>>>>>>>
>>>>>>> Original:
>>>>>>> "nominal": Typically hop count does not have a nominal value.
>>>>>>> ...
>>>>>>> [Qin Wu] I believe "the" is needed before "hop count does
>>>>> not".
>>>>>>> "sla": Typically hop count does not have an SLA value.
>>>>>>> [Qin Wu] same as above, s/ hop count does not have/ the hop
>>>>> count does not have
>>>>>>> "estimation": The exact estimation method is out of the scope
>>>>> of this document.  An example of estimating hopcounts is by
>>>>> importing from IGP routing protocols. -->
>>>>>>>
>>>>>>> [Qin Wu] s/ An example of estimating hopcounts/ An example of
>>>>> estimating hop count values
>>>>>>>
>>>>>>> 20) <!-- [rfced] Section 5:  We could only find three metrics
>>>>> related to throughput and bandwidth:  "tput", "bw-residual", and
>>>>> "bw-available".
>>>>>>> What is the fourth metric?
>>>>>>>
>>>>>>> Original:
>>>>>>> This section introduces four throughput/bandwidth related
>>>>> metrics. -->
>>>>>>>
>>>>>>> [Qin Wu] s/ This section introduces four throughput/bandwidth
>>>>> related metrics./ This section introduces three
>>>>> throughput/bandwidth related metrics.
>>>>>>>
>>>>>>> 21) <!-- [rfced] Section 5.1.3:  "a TCP congestion-control
>>>>> conforming flow" reads a bit oddly.  Does it mean "a conformant
>>>>> TCP congestion control flow" or something else?
>>>>>>>
>>>>>>> [Qin Wu] Maybe we should change "a TCP congestion-control
>>>>> conforming flow" into "a congestion-control conforming TCP flow"
>>>>> or ""a TCP flow"".
>>>>>>> Original:
>>>>>>> Intended Semantics: To give the throughput of a TCP
>>>>> congestion-  control conforming flow from the specified source to
>>>>> the specified  destination. -->
>>>>>>>
>>>>>>>
>>>>>>> 22) <!-- [rfced] Section 5.1.4: This sentence does not parse.
>>>>> Please clarify "provide estimation to", "set to [I-D.ietf-tcpm-
>>>>> rfc8312bis]", and "for an ongoing congestion control algorithm
>>>>> such as BBR, a a link to its specification".
>>>>>>> Also, should "Cubic" be "CUBIC" per [I-D.ietf-tcpm-
>>>>> rfc8312bis]?
>>>>>>>
>>>>>>> Original ("a a" has been fixed):
>>>>>>> To specify (1), it is RECOMMENDED that the "parameters"
>>>>>>> field (object) include a field named "congestion-control-
>>>>> algorithm", which provides a URI for the specification of the
>>>>> algorithm; for example, for an ALTO server to provide estimation
>>>>> to the throughput  of a Cubic Congestion control flow,
>>>>>>> [Qin Wu] s/ provide estimation to the throughput of a Cubic
>>>>> Congestion control flow,/ provide estimation of the throughput for
>>>>> a CUBIC Congestion control flow,
>>>>>>> its "parameters" includes a field "congestion-control-
>>>>> algorithm", with value being set to [I-D.ietf-tcpm-rfc8312bis];
>>>>> for an ongoing congestion control algorithm such as BBR, a a link
>>>>> to its specification. -->
>>>>>>> [Qin Wu] s/ with value being set to [I-D.ietf-tcpm-
>>>>> rfc8312bis]/ with value being set to the URI for [I-D.ietf-tcpm-
>>>>> rfc8312bis]
>>>>>>> [Qin Wu] s/ for an ongoing congestion control algorithm such
>>>>> as BBR, a a link to its specification. / for an ongoing congestion
>>>>> control algorithm such as BBR, a link to its specification can be
>>>>> added.
>>>>>>>
>>>>>>> 23) <!-- [rfced] Section 5.2.3:  Should "residual bandwidth
>>>>> from the specified source and the specified destination" be
>>>>> "residual bandwidth from the specified source to the specified
>>>>> destination"?
>>>>>>> We ask because we see "available bandwidth from the specified
>>>>> source to the specified destination" in Section 5.3.3.
>>>>>>>
>>>>>>> [Qin Wu] Correct.
>>>>>>> Also, we could not find the word "capacity" or the string
>>>>> "max"
>>>>>>> used in the context of maximum bandwidth in RFC 8571.  Will
>>>>> this particular citation be clear to readers?  (We see "Maximum
>>>>> Bandwidth (i.e., the link capacity)" and "maximum bandwidth (i.e.,
>>>>> the link capacity)" in RFCs 7471 and 8570, respectively, but
>>>>> nothing similar in RFC 8571.)
>>>>>>> [Qin Wu] I think it has explained the relation between "
>>>>> residual bandwidth " and " link capacity ". I think it is clear.
>>>>>>> Original:
>>>>>>> Intended Semantics: To specify temporal and spatial residual
>>>>> bandwidth from the specified source and the specified destination.
>>>>>>> ...[Qin Wu] s/ from the specified source and the specified
>>>>> destination./ from the specified source to the specified
>>>>> destination.
>>>>>>> When the max statistical operator is defined for the metric,
>>>>> it typically provides the minimum of the link capacities along the
>>>>> path, as the default value of the residual bandwidth of a link is
>>>>> its link capacity [RFC8571,8570,7471]. -->
>>>>>>>
>>>>>>>
>>>>>>> 24) <!-- [rfced] Sections 5.2.4 and 5.3.4:  "entry in Section
>>>>> 4.1.4 on aggregation of routing protocol link metrics" in these
>>>>> two sentences reads oddly and doesn't seem necessary.  If the
>>>>> suggested text is not correct, please clarify.
>>>>>>>
>>>>>>> Original:
>>>>>>> "estimation": See the "estimation" entry in Section 4.1.4 on
>>>>> aggregation of routing protocol link metrics.
>>>>>>> ...
>>>>>>> "estimation": See the "estimation" entry in Section 4.1.4 on
>>>>> aggregation of routing protocol link metrics.
>>>>>>>
>>>>>>> Suggested:
>>>>>>> "estimation":  See the "estimation" entry in Section 4.1.4.
>>>>>>> ...
>>>>>>> "estimation":  See the "estimation" entry in Section 4.1.4. --
>>>>>>
>>>>>>> [Qin Wu] Sounds good to me.
>>>>>>>
>>>>>>> 25) <!-- [rfced] Section 6:  This sentence is not clear as
>>>>> written.
>>>>>>> If the suggested text is not correct, please clarify the
>>>>> meaning of "this document specifies common issues unless one
>>>>> metric has its unique challenges".
>>>>>>>
>>>>>>> Original (the previous sentence is included for context):
>>>>>>> Also, the performance metrics specified in this document are
>>>>> similar,  in that they may use similar data sources and have
>>>>> similar issues in  their calculation.  Hence, this document
>>>>> specifies common issues  unless one metric has its unique
>>>>> challenges.
>>>>>>>
>>>>>>> Suggested:
>>>>>>> Hence, this document specifies issues that the  performance
>>>>> metrics might have in common and also discusses  challenges
>>>>> regarding the computation of ALTO performance metrics  (Section
>>>>> 6.4). -->
>>>>>>> [Qin Wu] Sounds good to me.
>>>>>>>
>>>>>>> 26) <!-- [rfced] Section 7:  Please review the following.  In
>>>>> the case of item c), please let us know how this document should
>>>>> be updated.
>>>>>>>
>>>>>>> a) We changed "ALTO Server" and "ALTO Client" to "ALTO server"
>>>>> and "ALTO client" per usage in RFC 7285.
>>>>>>>
>>>>>>> b) We removed the quotes in the second sentence, as the
>>>>> comparable sentence in Section 8.3.5 of RFC 7285 cites RFCs 2818
>>>>> and 5246, both of which are obsolete.  From Section 8.3.5 of RFC
>>>>> 7285:
>>>>>>>
>>>>>>> ALTO server implementations as well as ALTO client
>>>>> implementations  MUST support the "https" URI scheme [RFC2818] and
>>>>> Transport Layer  Security (TLS) [RFC5246].
>>>>>>>
>>>>>>> c) RFC 7230 has been obsoleted by RFCs 9110 and 9112.  In the
>>>>> case of this document, it is not clear whether we should cite RFC
>>>>> 9110 and/or RFC 9112.  Please let us know which RFC should be
>>>>> cited.
>>>>>>>
>>>>>>> Original (this document):
>>>>>>> As specified in "Protection Strategies" (Section 15.3.2 of
>>>>> [RFC7285]),  the ALTO Server should authenticate ALTO Clients when
>>>>> transmitting an  ALTO information resource containing sensitive TE
>>>>> performance  metrics.  "Authentication and Encryption" (Section
>>>>> 8.3.5 of
>>>>>>> [RFC7285]) specifies that "ALTO Server implementations as well
>>>>> as  ALTO Client implementations MUST support the "https" URI
>>>>> scheme of  [RFC7230] and Transport Layer Security (TLS) of
>>>>> [RFC8446]".
>>>>>>>
>>>>>>> Currently (still cites obsoleted RFC 7230):
>>>>>>> As specified in Section 15.3.2 ("Protection Strategies") of
>>>>> [RFC7285],  the ALTO server should authenticate ALTO clients when
>>>>> transmitting an  ALTO information resource containing sensitive TE
>>>>> performance  metrics.  Section 8.3.5 ("Authentication and
>>>>> Encryption") of  [RFC7285] specifies that ALTO server
>>>>> implementations as well as ALTO  client implementations MUST
>>>>> support the "https" URI scheme [RFC7230]  and Transport Layer
>>>>> Security (TLS) [RFC8446]. -->
>>>>>>>
>>>>>>> [Qin Wu] The proposed change looks good, I believe RFC7230
>>>>> should be replaced by RFC9110 since https URI scheme is defined in
>>>>> RFC9110.
>>>>>>>
>>>>>>> 27) <!-- [rfced] We have included some specific questions
>>>>> about the IANA text below. In addition to responding to those
>>>>> questions, please review all of the IANA-related updates carefully
>>>>> and let us know if any further updates are needed.
>>>>>>>
>>>>>>> a) FYI - For clarity, we created subsections within Section 8.
>>>>>>>
>>>>>>> Currently:
>>>>>>> 8.1 ALTO Cost Metric Registry
>>>>>>> 8.2 ALTO Cost Source Registry
>>>>>>>
>>>>>>> b) Section 8.2. May we change '"ALTO Cost Source" registry'
>>>>>>> here and in Section 3.1 to '"ALTO Cost Source Types"
>>>>> registry', to match the plural style used for all other registries
>>>>> listed on
>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fwww.iana.org%2Fassignments%2Falto-
>>>>>
>protocol%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07c
>d3b
>>>>>
>7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
>>>>>
>7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>LjAwM
>>>>>
>DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>&
>>>>>
>sdata=o07T4EFxzWEGUJQF0j7RM8G7iByJUferJ5j0WpjoCsg%3D&reserved=0>?
>>>>> If you agree to this change, we will ask IANA to update their page
>>>>> accordingly.
>>>>>>>
>>>>>>> Original (Section 3.1 and this section):
>>>>>>> The "cost-source" field
>>>>>>> of the "cost-context" field MUST be one registered in "ALTO
>>>>> Cost  Source" registry (Section 8).
>>>>>>> ...
>>>>>>> This document requests the creation of the "ALTO Cost Source"
>>>>>>> registry.
>>>>>>>
>>>>>>> Suggested:
>>>>>>> The "cost-source" field
>>>>>>> of the "cost-context" field MUST be one that is registered in
>>>>> the  "ALTO Cost Source Types" registry (Section 8).
>>>>>>> ...
>>>>>>> This document has created the "ALTO Cost Source Types"
>>>>> registry.
>>>>>>>
>>>>>>> [Qin Wu] Sounds good to me.
>>>>>>> c) Section 8.2. The last column in Table 3 does not match the
>>>>> last column in the "ALTO Cost Source" registry at
>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fwww.iana.org%2Fassignments%2Falto-
>>>>>
>protocol%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07c
>d3b
>>>>>
>7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
>>>>>
>7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>LjAwM
>>>>>
>DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>&
>>>>>
>sdata=o07T4EFxzWEGUJQF0j7RM8G7iByJUferJ5j0WpjoCsg%3D&reserved=0>.
>>>>> In Table 3, the column is named "Security Considerations" and
>>>>> points to Section 7 of this document whereas the column in the
>>>>> IANA registry is named "References" and points to this document.
>>>>> Should the IANA registry be updated to match Table 3? -->
>>>>>>>
>>>>>>> [Qin Wu] I can see inconsistency issue but to align with other
>>>>> registries at
>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fwww.iana.org%2Fassignments%2Falto-
>>>>>
>protocol%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07c
>d3b
>>>>>
>7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
>>>>>
>7C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>LjAwM
>>>>>
>DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>&
>>>>>
>sdata=Nl4JMYkf1yCGoGaE2nEvR8EVYz7R2IShz2j2sO2refc%3D&reserved=0> ,
>>>>> I prefer to keep as it does. Security consideration doesn't need
>>>>> to be reflected in the IANA registry in my understanding.
>>>>>>>
>>>>>>> 28) <!-- [rfced] References:  We could not find a URL or DOI
>>>>> for [Prophet].  Also, we couldn't locate it via ACM/IEEE
>>>>> Transactions on Networking 2020.  Is this article available online
>>>>> somewhere and not behind a paywall?
>>>>>>>
>>>>>>> Original:
>>>>>>> [Prophet]  Gao, K., Zhang, J., and YR. Yang, "Prophet: Fast,
>>>>> Accurate
>>>>>>>          Throughput Prediction with Reactive Flows",
>>>>> ACM/IEEE
>>>>>>>          Transactions on Networking July, 2020. -->
>>>>>>>
>>>>>>> [Qin Wu] The Prophet paper can be found at the following URL:
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>
>dl.acm.org%2Fdoi%2F10.1109%2FTNET.2020.3016838&data=05%7C01%7Cmo
>ha
>>>>>
>med.boucadair%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7C9
>0
>>>>>
>c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7CU
>nkn
>>>>>
>own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
>>>>>
>aWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=L6eQtYNhoboIK9WofpvP
>McfH%
>>>>> 2BeUhZsrYO3uE%2BFFpAX0%3D&reserved=0
>>>>>>>
>>>>>>> 29) <!-- [rfced] Please review the "Inclusive Language"
>>>>> portion of the online Style Guide at
>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fwww.rfc-
>>>>>
>editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C
>>>>>
>01%7Cmohamed.boucadair%40orange.com%7C07cd3b7401424247f58f08db7
>eff
>>>>>
>3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63824340804671
>15
>>>>>
>26%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
>LCJ
>>>>>
>BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ltLeGKgyI5AB4g
>xI
>>>>> HVT9ROQTzjYy9gb%2F55DWLswXOCE%3D&reserved=0>,
>>>>>>> and let us know if any changes are needed.
>>>>>>>
>>>>>>> Note that our script did not flag any words in particular, but
>>>>> this should still be reviewed as a best practice. -->
>>>>>>>
>>>>>>> [Qin Wu] No, thanks.
>>>>>>>
>>>>>>> 30) <!-- [rfced] The following terms appear to be used
>>>>> inconsistently in this document.  Please let us know which form is
>>>>> preferred.
>>>>>>>
>>>>>>> an "sla" value (Sections 5.2.4 and 5.3.4) /
>>>>>>> an SLA value (Sections 4.5.4 and 5.1.4)
>>>>>>>
>>>>>>> Available Bandwidth / available bandwidth (used generally in
>>>>>>> running text)
>>>>>>>
>>>>>>> Delay Variation / delay variation (in running text)*
>>>>>>>
>>>>>>> Hop Count / hop count (in running text)*
>>>>>>>
>>>>>>> Loss Rate / loss rate (in running text)*
>>>>>>>
>>>>>>> method of measurement or calculation /
>>>>>>> Method of Measurement or Calculation (e.g., "about the
>>>>>>>  method of measurement or calculation",
>>>>>>>  "such as Method of Measurement or Calculation")
>>>>>>>
>>>>>>> One-way Delay / one-way delay (in running text)*
>>>>>>>
>>>>>>> Residual Bandwidth / Residual bandwidth (metric)
>>>>>>> (in running text) (We also see "residual bandwidth".)
>>>>>>>
>>>>>>> Round-trip Delay / round-trip delay (in running text)*
>>>>>>>
>>>>>>> * For example, compare the sentence just after Table 1, the
>>>>>>> "These eight performance metrics can be classified"
>>>>> sentence, and
>>>>>>> the first sentence of Section 4. -->
>>>>>>> [Qin Wu] Here is the proposed change to section 1:
>>>>>>> OLD TEXT:
>>>>>>> "
>>>>>>> The first six metrics listed in Table 1 (i.e., One-way Delay,
>>>>> Round-
>>>>>>> trip Delay, Delay Variation, Loss Rate, Residual Bandwidth,
>>>>> and
>>>>>>> Available Bandwidth)
>>>>>>> "
>>>>>>> NEW TEXT:
>>>>>>> "
>>>>>>> The first six metrics listed in Table 1 (i.e., one-way delay,
>>>>> round-
>>>>>>> trip delay, delay variation, loss rate, residual bandwidth,
>>>>> and
>>>>>>> available bandwidth)
>>>>>>> "
>>>>>>> OLD TEXT:
>>>>>>> "
>>>>>>> These eight performance metrics can be classified into two
>>>>>>> categories: those derived from the performance of individual
>>>>> packets
>>>>>>> (i.e., One-way Delay, Round-trip Delay, Delay Variation,
>>>>> Loss Rate,
>>>>>>> and Hop Count) and those related to bandwidth/throughput
>>>>> (Residual
>>>>>>> bandwidth, Available Bandwidth, and TCP throughput).
>>>>>>> "
>>>>>>> NEW TEXT:
>>>>>>> "
>>>>>>> These eight performance metrics can be classified into two
>>>>>>> categories: those derived from the performance of individual
>>>>> packets
>>>>>>> (i.e., one-way delay, round-trip delay, delay variation,
>>>>> loss rate,
>>>>>>> and hop count) and those related to bandwidth/throughput
>>>>> (residual
>>>>>>> bandwidth, available bandwidth, and TCP throughput).
>>>>>>> "
>>>>>>> Thank you.
>>>>>>>
>>>>>>> RFC Editor/lb/kc
>>>>>>>
>>>>>>>
>>>>>>> On Jun 23, 2023, at 4:50 PM, [e-mail] wrote:
>>>>>>>
>>>>>>> *****IMPORTANT*****
>>>>>>>
>>>>>>> Updated 2023/06/23
>>>>>>>
>>>>>>> RFC Author(s):
>>>>>>> --------------
>>>>>>>
>>>>>>> Instructions for Completing AUTH48
>>>>>>>
>>>>>>> Your document has now entered AUTH48.  Once it has been
>>>>> reviewed and approved by you and all coauthors, it will be
>>>>> published as an RFC.
>>>>>>> If an author is no longer available, there are several
>>>>> remedies available as listed in the FAQ
>>>>> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fwww.rfc-
>>>>>
>editor.org%2Ffaq%2F&data=05%7C01%7Cmohamed.boucadair%40orange.co
>m%
>>>>>
>7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5
>>>>>
>d20%7C0%7C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJ
>WIjoiM
>>>>>
>C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
>7
>>>>>
>C%7C%7C&sdata=gNPDBQHI60IZxLobMyWLRYYAfgeDxyvtx98jdJ5wxRs%3D&re
>ser
>>>>> ved=0).
>>>>>>>
>>>>>>> You and you coauthors are responsible for engaging other
>>>>> parties (e.g., Contributors or Working Group) as necessary before
>>>>> providing your approval.
>>>>>>>
>>>>>>> Planning your review
>>>>>>> ---------------------
>>>>>>>
>>>>>>> Please review the following aspects of your document:
>>>>>>>
>>>>>>> *  RFC Editor questions
>>>>>>>
>>>>>>> Please review and resolve any questions raised by the RFC
>>>>> Editor
>>>>>>> that have been included in the XML file as comments marked as
>>>>>>> follows:
>>>>>>>
>>>>>>> <!-- [rfced] ... -->
>>>>>>>
>>>>>>> These questions will also be sent in a subsequent email.
>>>>>>>
>>>>>>> *  Changes submitted by coauthors
>>>>>>>
>>>>>>> Please ensure that you review any changes submitted by your
>>>>>>> coauthors.  We assume that if you do not speak up that you
>>>>>>> agree to changes submitted by your coauthors.
>>>>>>>
>>>>>>> *  Content
>>>>>>>
>>>>>>> Please review the full content of the document, as this
>>>>> cannot
>>>>>>> change once the RFC is published.  Please pay particular
>>>>> attention to:
>>>>>>> - IANA considerations updates (if applicable)
>>>>>>> - contact information
>>>>>>> - references
>>>>>>>
>>>>>>> *  Copyright notices and legends
>>>>>>>
>>>>>>> Please review the copyright notice and legends as defined in
>>>>>>> RFC 5378 and the Trust Legal Provisions
>>>>>>> (TLP –
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> trustee.ietf.org%2Flicense-
>>>>>
>info%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07cd3b7
>401
>>>>>
>424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0
>%
>>>>>
>7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
>MDAiL
>>>>>
>CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda
>t
>>>>>
>a=juG6zt1Fuoy3e638nB4pabkEnINkW4W%2FHbx%2BOY%2F3VKQ%3D&reserv
>ed=0)
>>>>> .
>>>>>>>
>>>>>>> *  Semantic markup
>>>>>>>
>>>>>>> Please review the markup in the XML file to ensure that
>>>>> elements of
>>>>>>> content are correctly tagged.  For example, ensure that
>>>>> <sourcecode>
>>>>>>> and <artwork> are set correctly.  See details at
>>>>>>>
>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fauthors.ietf.org%2Frfcxml-
>>>>>
>vocabulary&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07cd
>3b7
>>>>>
>401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
>>>>>
>C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
>jAwMD
>>>>>
>AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
>s
>>>>>
>data=vNBNRyCSLphb4SclrNVF3vVTbxviA12gsVYvjezEz8M%3D&reserved=0>.
>>>>>>>
>>>>>>> *  Formatted output
>>>>>>>
>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the
>>>>>>> formatted output, as generated from the markup in the XML
>>>>> file, is
>>>>>>> reasonable.  Please note that the TXT will have formatting
>>>>>>> limitations compared to the PDF and HTML.
>>>>>>>
>>>>>>>
>>>>>>> Submitting changes
>>>>>>> ------------------
>>>>>>>
>>>>>>> To submit changes, please reply to this email using ‘REPLY
>>>>> ALL’ as all the parties CCed on this message need to see your
>>>>> changes. The parties
>>>>>>> include:
>>>>>>>
>>>>>>> *  your coauthors
>>>>>>>
>>>>>>> *  [e-mail] (the RPC team)
>>>>>>>
>>>>>>> *  other document participants, depending on the stream
>>>>> (e.g.,
>>>>>>>   IETF Stream participants are your working group chairs,
>>>>> the
>>>>>>>   responsible ADs, and the document shepherd).
>>>>>>>
>>>>>>> *  [e-mail], which is a new archival
>>>>> mailing list
>>>>>>>   to preserve AUTH48 conversations; it is not an active
>>>>> discussion
>>>>>>>   list:
>>>>>>>
>>>>>>>  *  More info:
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> mailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-
>>>>>
>4Q9l2USxIAe6P8O4Zc&data=05%7C01%7Cmohamed.boucadair%40orange.co
>m%7
>>>>>
>C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d
>>>>>
>20%7C0%7C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJ
>WIjoiMC
>>>>>
>4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
>C
>>>>>
>%7C%7C&sdata=uWfZC6nogEkNzmkWicF0TW1Jv0MXNzAjGbNIQV6tWso%3D&
>reserv
>>>>> ed=0
>>>>>>>
>>>>>>>  *  The archive itself:
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>
>mailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C
>>>>>
>01%7Cmohamed.boucadair%40orange.com%7C07cd3b7401424247f58f08db7
>eff
>>>>>
>3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63824340804671
>15
>>>>>
>26%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
>LCJ
>>>>>
>BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OH%2FztdkbqX
>tmn4
>>>>> FpK3WLHhrAeCT6%2FwqEbbQx%2BZNg1mk%3D&reserved=0
>>>>>>>
>>>>>>>  *  Note: If only absolutely necessary, you may temporarily
>>>>> opt out
>>>>>>>     of the archiving of messages (e.g., to discuss a
>>>>> sensitive matter).
>>>>>>>     If needed, please add a note at the top of the message
>>>>> that you
>>>>>>>     have dropped the address. When the discussion is
>>>>> concluded,
>>>>>>>     [e-mail] will be re-added to the CC
>>>>> list and
>>>>>>>     its addition will be noted at the top of the message.
>>>>>>>
>>>>>>> You may submit your changes in one of two ways:
>>>>>>>
>>>>>>> An update to the provided XML file
>>>>>>> — OR —
>>>>>>> An explicit list of changes in this format
>>>>>>>
>>>>>>> Section # (or indicate Global)
>>>>>>>
>>>>>>> OLD:
>>>>>>> old text
>>>>>>>
>>>>>>> NEW:
>>>>>>> new text
>>>>>>>
>>>>>>> You do not need to reply with both an updated XML file and an
>>>>> explicit list of changes, as either form is sufficient.
>>>>>>>
>>>>>>> We will ask a stream manager to review and approve any changes
>>>>> that seem beyond editorial in nature, e.g., addition of new text,
>>>>> deletion of text, and technical changes.  Information about stream
>>>>> managers can be found in the FAQ.  Editorial changes do not
>>>>> require approval from a stream manager.
>>>>>>>
>>>>>>>
>>>>>>> Approving for publication
>>>>>>> --------------------------
>>>>>>>
>>>>>>> To approve your RFC for publication, please reply to this
>>>>> email stating that you approve this RFC for publication.  Please
>>>>> use ‘REPLY ALL’, as all the parties CCed on this message need to
>>>>> see your approval.
>>>>>>>
>>>>>>>
>>>>>>> Files
>>>>>>> -----
>>>>>>>
>>>>>>> The files are available here:
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauthors%2Frfc9439.xml&data=05%7C01%7Cmohamed.boucadai
>>>>>
>r%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b4
>0
>>>>>
>bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUnknown%7CT
>WFpbG
>>>>>
>Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>>>>>
>Mn0%3D%7C3000%7C%7C%7C&sdata=y8BztBEayU8%2B6u2caB%2FomQdmq7
>LXbqXXl
>>>>> 9Re%2ByLWzIg%3D&reserved=0
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauthors%2Frfc9439.html&data=05%7C01%7Cmohamed.boucada
>>>>>
>ir%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b4
>>>>>
>0bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUnknown%7C
>TWFpb
>>>>>
>GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
>>>>>
>6Mn0%3D%7C3000%7C%7C%7C&sdata=ACgjKoNrnvxNBAWWKPwkrDkIQnyT1i
>19R%2F
>>>>> d1u2cByu4%3D&reserved=0
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauthors%2Frfc9439.pdf&data=05%7C01%7Cmohamed.boucadai
>>>>>
>r%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b4
>0
>>>>>
>bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUnknown%7CT
>WFpbG
>>>>>
>Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>>>>>
>Mn0%3D%7C3000%7C%7C%7C&sdata=AWulkhOnPqC94fC3VjEP2pRPmdT7q6S
>E3u%2F
>>>>> DtpkjNIc%3D&reserved=0
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauthors%2Frfc9439.txt&data=05%7C01%7Cmohamed.boucadai
>>>>>
>r%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b4
>0
>>>>>
>bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUnknown%7CT
>WFpbG
>>>>>
>Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>>>>>
>Mn0%3D%7C3000%7C%7C%7C&sdata=EUaRdzzzfCOneUrfe%2FeW%2FrdxOm
>67Srxgn
>>>>> Z5ULx9AAUk%3D&reserved=0
>>>>>>>
>>>>>>> Diff file of the text:
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-editor.org%2Fauthors%2Frfc9439-
>>>>>
>diff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07cd3b
>74
>>>>>
>01424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
>C
>>>>>
>0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>AwMDA
>>>>>
>iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>d
>>>>>
>ata=0CIDL6rEsGEAQfNRq7P%2B7ppLRfmlo2n7K%2Fl1CuYjUrw%3D&reserved=
>0
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-editor.org%2Fauthors%2Frfc9439-
>>>>>
>rfcdiff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07cd
>3
>>>>>
>b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
>>>>>
>%7C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
>wLjAw
>>>>>
>MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
>C
>>>>>
>&sdata=7fdyq5PaFyGVveNxdUHEnQ0nanrbI8ie3Hv9lZ4W5N8%3D&reserved=0
>>>>> (side by side)
>>>>>>>
>>>>>>> Diff of the XML:
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-editor.org%2Fauthors%2Frfc9439-
>>>>>
>xmldiff1.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C07
>cd
>>>>>
>3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
>>>>>
>0%7C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
>4wLjA
>>>>>
>wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
>%7
>>>>>
>C&sdata=LF5AgZ3o85L%2BV9qNJ3r%2BDJOfmCyiYMV%2FG9KCO8wWo8o%3D
>&reser
>>>>> ved=0
>>>>>>>
>>>>>>> The following files are provided to facilitate creation of
>>>>> your own diff files of the XML.
>>>>>>>
>>>>>>> Initial XMLv3 created using XMLv2 as input:
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauthors%2Frfc9439.original.v2v3.xml&data=05%7C01%7Cmo
>>>>>
>hamed.boucadair%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7
>C
>>>>>
>90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7C
>Un
>>>>>
>known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
>>>>>
>1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D6GpAjd%2BhpCKfOu
>Xj8BM0
>>>>> KHKxw0xLPQVTtobQHYmIS4%3D&reserved=0
>>>>>>>
>>>>>>> XMLv3 file that is a best effort to capture v3-related format
>>>>> updates
>>>>>>> only:
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauthors%2Frfc9439.form.xml&data=05%7C01%7Cmohamed.bou
>>>>>
>cadair%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af
>>>>>
>34b40bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUnknown
>%7CT
>>>>>
>WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
>>>>>
>XVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jTxQ5mIr0DcY3SfYdWhGCgWCXYs
>6yGIr
>>>>> asXhn4aPp30%3D&reserved=0
>>>>>>>
>>>>>>>
>>>>>>> Tracking progress
>>>>>>> -----------------
>>>>>>>
>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> www.rfc-
>>>>>
>editor.org%2Fauth48%2Frfc9439&data=05%7C01%7Cmohamed.boucadair%40
>o
>>>>>
>range.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc4
>>>>>
>8b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUnknown%7CTWFpb
>GZsb3d
>>>>>
>8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>
>D%7C3000%7C%7C%7C&sdata=f4CF6spHte2HYt4lqynWv3IMCDiUMIEDnjhBwr
>n92H
>>>>> k%3D&reserved=0
>>>>>>>
>>>>>>> Please let us know if you have any questions.
>>>>>>>
>>>>>>> Thank you for your cooperation,
>>>>>>>
>>>>>>> RFC Editor
>>>>>>>
>>>>>>> --------------------------------------
>>>>>>> RFC9439 (draft-ietf-alto-performance-metrics-28)
>>>>>>>
>>>>>>> Title            : ALTO Performance Cost Metrics
>>>>>>> Author(s)        : Q. Wu, Y. Yang, Y. Lee, D. Dhody, S.
>>>>> Randriamasy, L. Contreras
>>>>>>> WG Chair(s)      : Jan Seedorf, Mohamed Boucadair, Qin Wu
>>>>>>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>_________________________________________________________________
>___________________________________________
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
>ce message par erreur, veuillez le signaler
>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou
>falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>>>> they should not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and delete
>this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have been
>modified, changed or falsified.
>>>> Thank you.
>>>
>>