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

[Dhruv Dhody <[e-mail]>]

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 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.
>
>