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

[Dhruv Dhody <[e-mail]>]

Looks good now.

Thanks!
Dhruv

On Tue, Jul 11, 2023 at 9:16 PM Lynne Bartholomew <[e-mail]>
wrote:

> 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%7C07cd3b74
> >>>> 01424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> >>>> 0%7C638243408046242871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> >>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> >>>> 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%7C07cd3b
> >>>> 7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> >>>> 7C0%7C638243408046242871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> >>>> 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%7C07cd3b
> >>>> 7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> >>>> 7C0%7C638243408046242871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> >>>> 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%7C90c7a20af34b40
> >>>> bfbc48b9253b6f5d20%7C0%7C0%7C638243408046399099%7CUnknown%7CTWFpbG
> >>>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> >>>> Mn0%3D%7C3000%7C%7C%7C&sdata=qr%2FYVsIAyXZ2KUwPAuwy3TEoR28pfm5EQEz
> >>>> 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%7C90c7a20af34b40
> >>>> bfbc48b9253b6f5d20%7C0%7C0%7C638243408046399099%7CUnknown%7CTWFpbG
> >>>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> >>>> Mn0%3D%7C3000%7C%7C%7C&sdata=8c7GUHrs4H5DJOnZ%2FsKq%2FxxB%2FIxbzul
> >>>> 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%7CTWFpb
> >>>> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> >>>> 6Mn0%3D%7C3000%7C%7C%7C&sdata=xHazTSZjCi%2FVN8WFj2R7gHWPQgSP5Li1sI
> >>>> 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%7C90c7a20af34b40
> >>>> bfbc48b9253b6f5d20%7C0%7C0%7C638243408046399099%7CUnknown%7CTWFpbG
> >>>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> >>>> Mn0%3D%7C3000%7C%7C%7C&sdata=h%2BeZVlONDX5YJyUs5VigDrISdseJCPfSEML
> >>>> 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%7C07cd3b74
> >>>> 01424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> >>>> 0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> >>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> >>>> 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%7C07cd3
> >>>> b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> >>>> %7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> >>>> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> >>>> &sdata=Q888HxPVrPby0tpSOWtd%2B0iBRQSgnsRRXwH8yStK2CA%3D&reserved=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%7C07
> >>>> cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%
> >>>> 7C0%7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> >>>> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> >>>> %7C&sdata=psKpd25XmDplF%2FiYbRN6vvoyE78k2ujL6V3nVZYUpSY%3D&reserve
> >>>> 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%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> >>>> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> >>>> C&sdata=KYiRZ5JbkP5c%2BO7%2FnuVb503Bwr%2BTF17kGI61KnwOo5I%3D&reser
> >>>> 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%7CTWFpbGZsb3d8eyJWIjoiMC4w
> >>>> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> >>>> C%7C&sdata=IANpCb0HoM3619dJTaWQ5vCVbiT9Ec3yWoK%2BljW%2BKiM%3D&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%7C07cd
> >>>> 3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> >>>> 0%7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> >>>> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> >>>> C&sdata=ogF%2FxQ1l6Gj4OkLt%2Bz66Wbunyvlt6aCiLU9DOu1S1Ik%3D&reserve
> >>>> 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%7C07cd
> >>>> 3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> >>>> 0%7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> >>>> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> >>>> C&sdata=bYkWvoximHRTdfNZTKi0BtEH5oHtcC2t9tY%2F2Q%2Ffpxo%3D&reserve
> >>>> 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%7C07cd3b74
> >>>> 01424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> >>>> 0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> >>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> >>>> 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%40o
> >>>> range.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc4
> >>>> 8b9253b6f5d20%7C0%7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d
> >>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >>>> D%7C3000%7C%7C%7C&sdata=1En7ViA8bwNwnXdaAQQGWmnBmYv0vFXxHQVENvVph9
> >>>> 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%7CTWFpbGZsb3d8e
> >>>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> >>>> 7C3000%7C%7C%7C&sdata=DLvgA7yd4dtVfsPvXzIYV%2BX7WoLl0iPMQZP1C8FYGq
> >>>> 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%7C07cd3b74
> >>>> 01424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> >>>> 0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> >>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> >>>> ata=4KSDG9urwxW0fjOd8A0%2BM9Bq0H4veyC%2BEk1fxYsobys%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.
> >>>>>>
> >>>>>> 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%7CTWFpbGZsb3d
> >>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >>>> D%7C3000%7C%7C%7C&sdata=50IbogbDI9XU7ox6Pjh%2FPhzIoFueEBay5KxRqSBx
> >>>> 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%7C07cd3b7
> >>>> 401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> >>>> C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> >>>> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
> >>>> data=r1%2FMaJl3VM%2BEP2RG7tsLKssfm3yKzOZqZt75UzX5%2F%2FI%3D&reserv
> >>>> 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%7C07cd3b
> >>>> 7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> >>>> 7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> >>>> 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%7C07cd3b
> >>>> 7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> >>>> 7C0%7C638243408046399099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> >>>> 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%7C07cd3b
> >>>> 7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> >>>> 7C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> >>>> 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%7Cmoha
> >>>> med.boucadair%40orange.com%7C07cd3b7401424247f58f08db7eff3477%7C90
> >>>> c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUnkn
> >>>> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> >>>> aWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=L6eQtYNhoboIK9WofpvPMcfH%
> >>>> 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%7C07cd3b7401424247f58f08db7eff
> >>>> 3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382434080467115
> >>>> 26%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> >>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ltLeGKgyI5AB4gxI
> >>>> 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.com%
> >>>> 7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5
> >>>> d20%7C0%7C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> >>>> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> >>>> C%7C%7C&sdata=gNPDBQHI60IZxLobMyWLRYYAfgeDxyvtx98jdJ5wxRs%3D&reser
> >>>> 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%7C07cd3b7401
> >>>> 424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> >>>> 7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> >>>> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
> >>>> a=juG6zt1Fuoy3e638nB4pabkEnINkW4W%2FHbx%2BOY%2F3VKQ%3D&reserved=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%7C07cd3b7
> >>>> 401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> >>>> C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> >>>> 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.com%7
> >>>> C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d
> >>>> 20%7C0%7C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> >>>> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> >>>> %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%7C07cd3b7401424247f58f08db7eff
> >>>> 3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382434080467115
> >>>> 26%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> >>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OH%2FztdkbqXtmn4
> >>>> 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%7C90c7a20af34b40
> >>>> bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUnknown%7CTWFpbG
> >>>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> >>>> Mn0%3D%7C3000%7C%7C%7C&sdata=y8BztBEayU8%2B6u2caB%2FomQdmq7LXbqXXl
> >>>> 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%7CTWFpb
> >>>> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> >>>> 6Mn0%3D%7C3000%7C%7C%7C&sdata=ACgjKoNrnvxNBAWWKPwkrDkIQnyT1i19R%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%7C90c7a20af34b40
> >>>> bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUnknown%7CTWFpbG
> >>>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> >>>> Mn0%3D%7C3000%7C%7C%7C&sdata=AWulkhOnPqC94fC3VjEP2pRPmdT7q6SE3u%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%7C90c7a20af34b40
> >>>> bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUnknown%7CTWFpbG
> >>>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> >>>> Mn0%3D%7C3000%7C%7C%7C&sdata=EUaRdzzzfCOneUrfe%2FeW%2FrdxOm67Srxgn
> >>>> 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%7C07cd3b74
> >>>> 01424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> >>>> 0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> >>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> >>>> 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%7C07cd3
> >>>> b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> >>>> %7C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> >>>> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> >>>> &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%7C07cd
> >>>> 3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> >>>> 0%7C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> >>>> 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%7C
> >>>> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUn
> >>>> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> >>>> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D6GpAjd%2BhpCKfOuXj8BM0
> >>>> 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=jTxQ5mIr0DcY3SfYdWhGCgWCXYs6yGIr
> >>>> 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%40o
> >>>> range.com%7C07cd3b7401424247f58f08db7eff3477%7C90c7a20af34b40bfbc4
> >>>> 8b9253b6f5d20%7C0%7C0%7C638243408046711526%7CUnknown%7CTWFpbGZsb3d
> >>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >>>> D%7C3000%7C%7C%7C&sdata=f4CF6spHte2HYt4lqynWv3IMCDiUMIEDnjhBwrn92H
> >>>> 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.
> >>
> >
>
>