Re: [auth48] AUTH48: RFC-to-be 9544 <draft-ietf-ippm-pam-09> for your review

[Alexander L Clemm <[e-mail]>]

Hello Rebecca,

thank you for the updates.  I have reviewed the updates and the document
looks good to me.  You have my approval.

That being said, I realize there is always a delay involved until the
actual document publication occurs after approvals are received.  If
document publication were to occur April 1st or later, I would
appreciate if you could let me know as in that case I would like to
update my affiliation to the then current.

I have not seen Jerome's reply on this thread and I am not sure if
Jerome's inria.fr address is still being monitored; just in case I am
adding him in the "To:" addressees with his Uni Luxembourg email; I
would leave it to him to respond as to whether his email address in the
document should be updated.

Thank you

--- Alex

On 2/22/2024 10:39 AM, Rebecca VanRheenen wrote:
> Hi John and Xiao,
>
> We have noted your approvals on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9544).
>
> Thank you,
> RFC Editor/rv
>
>
>
>> On Feb 21, 2024, at 10:12 PM, [e-mail] wrote:
>>
>> Many thanks Rebecca! I also approve this document.
>>
>>
>> Best Regards,
>>
>> Xiao Min
>>
>> Original
>> From: RebeccaVanRheenen <[e-mail]>
>> To: Joel Halpern <[e-mail]>;Greg Mirsky <[e-mail]>;John Strassner <[e-mail]>;肖敏10093570;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
>> Cc: RFC Editor <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
>> Date: 2024年02月22日 13:05
>> Subject: Re: AUTH48: RFC-to-be 9544 <draft-ietf-ippm-pam-09> for your review
>> Hi Greg and Joel,
>>
>> We have noted your approvals on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9544).
>>
>> Thank you,
>> RFC Editor/rv
>>
>>
>>
>>> On Feb 21, 2024, at 5:24 PM, Joel Halpern <[e-mail]> wrote:
>>>
>>> Thank you.  Looks good to me.
>>> Yours,
>>> Joel
>>>
>>> -----Original Message-----
>>> From: Rebecca VanRheenen <[e-mail]>
>>> Sent: Wednesday, February 21, 2024 4:57 PM
>>> To: Greg Mirsky <[e-mail]>; John Strassner <[e-mail]>; Joel Halpern <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
>>> Cc: RFC Editor <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>>> Subject: Re: AUTH48: RFC-to-be 9544 <draft-ietf-ippm-pam-09> for your review
>>>
>>> Hi authors,
>>>
>>> Thanks for the quick responses! We have updated the document. All questions have been resolved.
>>>
>>> Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form.  We will await approvals from each author prior to moving forward in the publication process.
>>>
>>> Updated XML file:
>>>   https://www.rfc-editor.org/authors/rfc9544.xml
>>>
>>> Updated output files:
>>>   https://www.rfc-editor.org/authors/rfc9544.txt
>>>   https://www.rfc-editor.org/authors/rfc9544.pdf
>>>   https://www.rfc-editor.org/authors/rfc9544.html
>>>
>>> Diff file showing all changes made during AUTH48:
>>>   https://www.rfc-editor.org/authors/rfc9544-auth48diff.html
>>>
>>> Diff files showing all changes:
>>>   https://www.rfc-editor.org/authors/rfc9544-diff.html
>>>   https://www.rfc-editor.org/authors/rfc9544-rfcdiff.html (side-by-side diff)
>>>   https://www.rfc-editor.org/authors/rfc9544-alt-diff.html (diff showing changes where text is moved or deleted)
>>>
>>> Note that it may be necessary for you to refresh your browser to view the most recent version.
>>>
>>> For the AUTH48 status of this document, please see:
>>>   https://www.rfc-editor.org/auth48/rfc9544
>>>
>>> Thank you,
>>>
>>> RFC Editor/rv
>>>
>>>
>>>
>>>> On Feb 20, 2024, at 4:18 PM, Greg Mirsky <[e-mail]> wrote:
>>>>
>>>> Hi John,
>>>> thank you for your prompt response. I like "identified in" and support your proposal.
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Tue, Feb 20, 2024 at 4:13 PM John Strassner <[e-mail]> wrote:
>>>> Hi Greg, et al.,
>>>>
>>>> Greg wrote:
>>>> John:
>>>>> #7: I think that "between the elements of the network that are referred to for
>>>>>       the SLO corresponding to the performance parameter" is incorrect.
>>>>>       The SLO defines both the metric and where the metric is measured.
>>>>>       The SLO does not "refer" to anything.
>>>>>       Hence, I would instead say: "between the elements of the network that
>>>>>       are defined by the SLO corresponding to the performance parameter."
>>>> GIM2>> I agree with "referred to by" suggested by Joel. I think that "defined by" suggested by John is closer to "identified in" as a performance metric is firstly defined and then can be used in the SLO. Similarly, in my opinion, network elements are identified in the SLO. Thus, I think that "referred to by" most accurately characterizes the relationship.
>>>>
>>>> <jcs>
>>>> The SLO does define the metric. If you are more comfortable with identified in, that is fine.
>>>> I think that "referred to by" is awkward. So how about "between the elements of the network that are identified in the SLO corresponding to the performance parameter."?
>>>>
>>>> best regards,
>>>> John
>>>>
>>>> On Tue, Feb 20, 2024 at 3:11 PM Greg Mirsky <[e-mail]> wrote:
>>>> Hi Rebecca,
>>>> thank you for careful consolidation of our proposals. Please find my responses to the outstanding questions below tagged GIM2>>.
>>>>
>>>> Kind regards,
>>>> Greg
>>>>
>>>> On Tue, Feb 20, 2024 at 2:24 PM Rebecca VanRheenen <[e-mail]> wrote:
>>>> Hi authors,
>>>>
>>>> Thank you all for your replies! We have updated the document accordingly (see list of updated files below) and have a few followup questions:
>>>>
>>>>
>>>> 1) There were several suggestions in response to this question (listed below). Please discuss and let us know how to update.
>>>>
>>>>>> 7) <!-- [rfced] Please confirm that "referred to for" is correct.
>>>>>> Or should this be updated to "referred to", "referred for", or something else?
>>>>>>
>>>>>> Original:
>>>>>>    The monitoring of performance parameters to determine the quality of
>>>>>>    an interval is performed between the elements of the network that are
>>>>>>    referred to for the SLO corresponding to the performance parameter.
>>>>
>>>> Greg:
>>>>> I think that it should be "referred to".
>>>>
>>>> Joel:
>>>>> If I am reading item 7 correctly, I think that is “referred to by”.  I can live with many forms, but I think “between the elements of the network that are referred to the SLO” will cause many people reading difficulty.
>>>>
>>>> John:
>>>>> #7: I think that "between the elements of the network that are referred to for
>>>>>       the SLO corresponding to the performance parameter" is incorrect.
>>>>>       The SLO defines both the metric and where the metric is measured.
>>>>>       The SLO does not "refer" to anything.
>>>>>       Hence, I would instead say: "between the elements of the network that
>>>>>       are defined by the SLO corresponding to the performance parameter."
>>>> GIM2>> I agree with "referred to by" suggested by Joel. I think that "defined by" suggested by John is closer to "identified in" as a performance metric is firstly defined and then can be used in the SLO. Similarly, in my opinion, network elements are identified in the SLO. Thus, I think that "referred to by" most accurately characterizes the relationship.
>>>>
>>>>
>>>> 2)
>>>>
>>>>>> 11) <!-- [rfced] May we change the first bulleted list in Sections
>>>>>> 3.1 and all the bulleted lists in Section 3.2 to definition lists?
>>>>>> See https://authors.ietf.org/en/rfcxml-vocabulary#dl.
>>>>>>
>>>>>> One example:
>>>>>>
>>>>>> Current:
>>>>>>    *  VI is a time interval during which at least one of the performance
>>>>>>       parameters degraded below its configurable optimal level
>>>>>>       threshold.
>>>>>>
>>>>>>    *  SVI is a time interval during which at least one of the
>>>>>>       performance parameters degraded below its configurable critical
>>>>>>       threshold.
>>>>>>
>>>>>>    *  Consequently, VFI is a time interval during which all performance
>>>>>>       parameters are at or better than their respective pre-defined
>>>>>>       optimal levels.
>>>>>>
>>>>>> Perhaps:
>>>>>>    VI: A time interval during which at least one of the performance
>>>>>>       parameters degraded below its configurable optimal level
>>>>>>       threshold.
>>>>>>
>>>>>>    SVI: A time interval during which at least one of the
>>>>>>       performance parameters degraded below its configurable critical
>>>>>>       threshold.
>>>>>>
>>>>>>    VFI: A time interval during which all performance
>>>>>>       parameters are at or better than their respective pre-defined
>>>>>>       optimal levels.
>>>>>
>>>>> GIM>> I slightly prefer the current format, but I can live with the update.
>>>>> —>
>>>>
>>>> We did not make any changes here, per your preference.
>>>> GIM2>> Thank you
>>>>
>>>>
>>>> 3)
>>>>
>>>>>> a) We see both of the following as the expansion for PAM.
>>>>>>
>>>>>>   Precision Availability Metric (1 instance)
>>>>>>   Precision Availability Metrics (8 instances)
>>>>>>
>>>>>> We updated to use the latter form (i.e., the form with "Metrics").
>>>>>> Please let us know any objections.
>>>>> GIM>> Thank you for the question. I think that the use of singular, i.e., "Metric", in Acronyms is valid. Consequently, all acronyms in the document, in my opinion, should be changed to "PAMs".
>>>>
>>>> We updated PAM to PAMs in all instances except the following (when used as an adjective). In a few instances, we also updated verbs from singular to plural when “PAMs" is used as a subject, so please review those for correctness.
>>>>
>>>> Current (“PAM” as adjective):
>>>>    3.3.  PAM Configuration Settings and Service Availability
>>>>
>>>>    5.  Other Expected PAM Benefits
>>>>
>>>>    … per some predefined PAM settings.
>>>>
>>>>    … of PAM-related settings.
>>>>
>>>> GIM2>> Thank you for your thoughtful handling of the use of this acronym in the document.
>>>>
>>>>
>>>> 4)
>>>>
>>>>>> d) FYI - We have added an expansion for the following abbreviation
>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>>>>>> expansion in the document carefully to ensure correctness.
>>>>>>
>>>>>>   IP Flow Information Export (IPFIX)
>>>>
>>>> Greg:
>>>>> It seems that IPFIX is used only one time in the document. Do you think that the expanded form without the acronym is sufficient? I'm okay with any form.
>>>>
>>>> John:
>>>>> #17d: I would rather spell out IPFIX (since it is only used once) but am also ok with adding it to the list of abbreviations.
>>>>
>>>> We chose to add this to the list of abbreviations as suggested by John. Omitting the acronym might make the sentence a bit harder to read because of the two instances of “Information”. Please let us know any concerns.
>>>>
>>>> Text without acronym:
>>>>    *  A set of IP Flow Information Export Information Elements
>>>>       will allow PAM ...
>>>> GIM2>> I agree with John's proposal to add IPFIX to the list of acronyms and use the abbreviated form in the body of the document.
>>>>
>>>>
>>>> 5) Would you like to alphabetize the acronyms in Section 2.2, or do you prefer the current order? The current ordering seems to be intentional (similar terms grouped together), but we want to check after adding IPFIX to the end of the list.
>>>> GIM2>> I find the alphabetical order to be more reader-friendly.
>>>> _______________
>>>>
>>>> Updated XML file:
>>>>    https://www.rfc-editor.org/authors/rfc9544.xml
>>>>
>>>> Updated output files:
>>>>    https://www.rfc-editor.org/authors/rfc9544.txt
>>>>    https://www.rfc-editor.org/authors/rfc9544.pdf
>>>>    https://www.rfc-editor.org/authors/rfc9544.html
>>>>
>>>> Diff file showing all changes made during AUTH48:
>>>>    https://www.rfc-editor.org/authors/rfc9544-auth48diff.html
>>>>
>>>> Diff files showing all changes:
>>>>    https://www.rfc-editor.org/authors/rfc9544-diff.html
>>>>    https://www.rfc-editor.org/authors/rfc9544-rfcdiff.html (side-by-side diff)
>>>>    https://www.rfc-editor.org/authors/rfc9544-alt-diff.html(diff
>>>> showing changes where text is moved or deleted)
>>>>
>>>> Note that it may be necessary for you to refresh your browser to view the most recent version.
>>>>
>>>> For the AUTH48 status of this document, please see:
>>>>    https://www.rfc-editor.org/auth48/rfc9544
>>>>
>>>> Thank you,
>>>>
>>>> RFC Editor/rv
>>>>
>>>>
>>>>
>>>>> On Feb 19, 2024, at 9:44 PM, John Strassner <[e-mail]> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> MY comments are as follows:
>>>>> YES with no additional comments to what Greg made: 1, 2, 4, 5, 6, 8,
>>>>> 9, 10, 11,12, 13, 14, 15, 16, 17 (a and b and c), 18, 19
>>>>>
>>>>> #3: YES, but I do not like changing "or" to "nor"
>>>>>
>>>>> #17d: I would rather spell out IPFIX (since it is only used once) but am also ok with adding it to the list of abbreviations.
>>>>>
>>>>> #7: I think that "between the elements of the network that are referred to for
>>>>>       the SLO corresponding to the performance parameter" is incorrect.
>>>>>       The SLO defines both the metric and where the metric is measured.
>>>>>       The SLO does not "refer" to anything.
>>>>>       Hence, I would instead say: "between the elements of the network that
>>>>>       are defined by the SLO corresponding to the performance parameter."
>>>>>
>>>>> On Feb 15, 2024, at 5:34 PM, [e-mail] wrote:
>>>>>
>>>>>
>>>>> *****IMPORTANT*****
>>>>>
>>>>> Updated 2024/02/15
>>>>>
>>>>> 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://www.rfc-editor.org/faq/).
>>>>>
>>>>> 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://trustee.ietf.org/license-info/).
>>>>>
>>>>> *  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://authors.ietf.org/rfcxml-vocabulary>.
>>>>>
>>>>> *  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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2US
>>>>> xIAe6P8O4Zc
>>>>>
>>>>>     *  The archive itself:
>>>>>        https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>
>>>>>     *  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.
>>>>>
>>>>>
>>>>> best regards,
>>>>> John
>>>>>
>>>>> On Sun, Feb 18, 2024 at 8:04 PM Joel Halpern <[e-mail]> wrote:
>>>>> I can live with all the changes as proposed.
>>>>>
>>>>>
>>>>>
>>>>> If I am reading item 7 correctly, I think that is “referred to by”.  I can live with many forms, but I think “between the elements of the network that are referred to the SLO” will cause many people reading difficulty.
>>>>>
>>>>> Yours,
>>>>> Joel
>>>>>
>>>>>
>>>>>
>>>>> From: Greg Mirsky <[e-mail]>
>>>>> Sent: Friday, February 16, 2024 8:45 PM
>>>>> To: [e-mail]
>>>>> Cc: Joel Halpern <[e-mail]>; [e-mail];
>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>> [e-mail]; [e-mail]
>>>>> Subject: Re: AUTH48: RFC-to-be 9544 <draft-ietf-ippm-pam-09> for
>>>>> your review
>>>>>
>>>>>
>>>>>
>>>>> Dear RFC Editor,
>>>>>
>>>>> thank you for your thoughtful proposals helping in improving the document. Please find my responses and notes below tagged GIM>>.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Greg
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 15, 2024 at 5:39 PM <[e-mail]> wrote:
>>>>>
>>>>> Authors,
>>>>>
>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>>>>
>>>>>
>>>>> 1) <!-- [rfced] FYI - We updated the abbreviated title (appears in
>>>>> the center of the running header in the pdf output) to more closely
>>>>> align with the document title. Please let us know any objections.
>>>>>
>>>>> Original:
>>>>>    Framework of PAM
>>>>>
>>>>> Current:
>>>>>    PAM for Services Governed by SLOs
>>>>>
>>>>> GIM>> I agree with the update with a minor modification
>>>>>
>>>>> PAMs for Service Governed by SLOs
>>>>>
>>>>> I've looked at the title itself and wanted to ask you and the
>>>>> co-authors a question. The title introduces the SLO acronym, should
>>>>> the PAM acronym also be introduced in the title as
>>>>>
>>>>>
>>>>>
>>>>> Precision Availability Metrics (PAMs) for Services Governed by
>>>>> Service Level Objectives (SLOs)
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 2) <!-- [rfced] How may we update the text after the comma to improve clarity?
>>>>>
>>>>> Original:
>>>>>    Hence it is not sufficient to measure service levels
>>>>>    per se over time, but to assess the quality of the service being
>>>>>    contextually provided (e.g., with the applicable SLO in mind).
>>>>>
>>>>> Perhaps:
>>>>>    Hence, it is not sufficient to measure service levels
>>>>>    per se over time; the quality of the service being
>>>>>    contextually provided (e.g., with the applicable SLO in mind) must be also assessed.
>>>>>
>>>>> GIM>> I agree with the proposed update. It makes the text more readable.
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 3) <!-- [rfced] May we update the text starting with ", and whether
>>>>> their SLOs..." as follows for to create parallel structure?
>>>>>
>>>>> Original:
>>>>>    However, at this point, there are no standard metrics that can be
>>>>>    used to account for the quality with which services are delivered
>>>>>    relative to their SLOs, and whether their SLOs are being met at all
>>>>>    times.
>>>>>
>>>>> Perhaps:
>>>>>    However, at this point, there are no standard metrics that can be
>>>>>    used to account for the quality with which services are delivered
>>>>>    relative to their SLOs or to determine whether their SLOs are being met at all
>>>>>    times.
>>>>>
>>>>> GIM>> I agree with the proposed update that improves the text. I wonder if s/or/nor/ is acceptable in this sentence?
>>>>>
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 4) <!-- [rfced] We see the term "Flow Record" in RFC 7011 but not in
>>>>> RFC 7012 (though "flow" does appear). Please review the citations
>>>>> and let us know if any updates are needed.
>>>>>
>>>>> Original:
>>>>>    Flow records [RFC7011] and
>>>>>    [RFC7012] maintain statistics about flows, including flow volume and
>>>>>    flow duration, but again, contain very little information about
>>>>>    service levels, let alone whether the service levels delivered meet
>>>>>    their respective targets, i.e., their associated SLOs.
>>>>>
>>>>> GIM>> Thank you for your thoughtful question. I think that reference to RFC 7012 is justified as it refers, as you've noted, to 'Flow' and 'Flow information'.
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 5) <!-- [rfced] FYI - We updated the title of Section 2 from
>>>>> "Conventions and Terminology" to "Conventions" because "Terminology"
>>>>> is one of the subsections. Please review and let us know any concerns.
>>>>>
>>>>> Original:
>>>>>    2.  Conventions and Terminology
>>>>>      2.1. Terminology
>>>>>      2.2. Acronyms
>>>>>
>>>>> Current:
>>>>>    2.  Conventions
>>>>>      2.1. Terminology
>>>>>      2.2. Acronyms
>>>>>
>>>>> GIM>> I agree with the update
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 6) <!-- [rfced] Is "configurable optimal level threshold" correct
>>>>> here? Should this read "configurable optimal threshold" (i.e., no
>>>>> "level") or "configurable optimal level (i.e., no "threshold")?
>>>>>
>>>>> Original:
>>>>>    *  VI is a time interval during which at least one of the performance
>>>>>       parameters degraded below its configurable optimal level
>>>>>       threshold.
>>>>>
>>>>> Perhaps:
>>>>>    *  VI is a time interval during which at least one of the performance
>>>>>       parameters degraded below its configurable optimal
>>>>>       threshold.
>>>>>
>>>>> GIM>> Thank you for pointing out that "threshold" and "level" are
>>>>> GIM>> synonyms. I slightly prefer the first option (above), but I
>>>>> GIM>> can live with the other proposal (below)
>>>>>
>>>>>
>>>>> Or:
>>>>>    *  VI is a time interval during which at least one of the performance
>>>>>       parameters degraded below its configurable optimal
>>>>>       level.
>>>>> -->
>>>>>
>>>>>
>>>>> 7) <!-- [rfced] Please confirm that "referred to for" is correct. Or
>>>>> should this be updated to "referred to", "referred for", or something else?
>>>>>
>>>>> Original:
>>>>>    The monitoring of performance parameters to determine the quality of
>>>>>    an interval is performed between the elements of the network that are
>>>>>    referred to for the SLO corresponding to the performance parameter.
>>>>>
>>>>> GIM>> I think that it should be "referred to".
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 8) <!-- [rfced] How may we update "this allows distinguishing" here?
>>>>>
>>>>> Original:
>>>>>    For example, this allows distinguishing between cases in
>>>>>    which violated intervals are caused by isolated violation occurrences
>>>>>    (such as, a sporadic issue that may be caused by a temporary spike in
>>>>>    a queue depth along the packet's path) or by broad violations across
>>>>>    multiple packets (such as a problem with slow route convergence
>>>>>    across the network or more foundational issues such as insufficient
>>>>>    network resources).
>>>>>
>>>>> Perhaps ("this allows a service provider to distinguish"):
>>>>>    For example, this allows a service provider to distinguish between cases in
>>>>>    which violated intervals are caused by isolated violation occurrences
>>>>>    (such as a sporadic issue that may be caused by a temporary spike in
>>>>>    a queue depth along the packet's path) or by broad violations across
>>>>>    multiple packets (such as a problem with slow route convergence
>>>>>    across the network or more foundational issues such as insufficient
>>>>>    network resources).
>>>>>
>>>>> Or ("this allows for distinguishing"):
>>>>>    For example, this allows for distinguishing between cases in
>>>>>    which violated intervals are caused by isolated violation occurrences
>>>>>    (such as a sporadic issue that may be caused by a temporary spike in
>>>>>    a queue depth along the packet's path) or by broad violations across
>>>>>    multiple packets (such as a problem with slow route convergence
>>>>>    across the network or more foundational issues such as insufficient
>>>>>    network resources).
>>>>>
>>>>> GIM>> I slightly prefer the latter option as the act of attributing degradation to a cause could be performed by a function, not an operator. But I can live with the former option.
>>>>>
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 9) <!-- [rfced] This sentence appears in Section 3.2 and points to
>>>>> Section 3. Should "introduced in Section 3" either be removed or
>>>>> updated to "introduced in this document"? Also, is this sentence
>>>>> introducing the bulleted list that appear after the paragraph? If
>>>>> so, would adding "The following" be helpful?
>>>>>
>>>>> Original:
>>>>>    A set of metrics can be created based on PAM introduced in Section 3.
>>>>>
>>>>> Perhaps (omit section pointer):
>>>>>    The following set of metrics can be created based on PAM.
>>>>>
>>>>> Or (use "in this document" instead of section pointer):
>>>>>    The following set of metrics can be created based on PAM as introduced
>>>>>    in this document.
>>>>>
>>>>> GIM>> I slightly prefer the latter option, but I can live with the first one.
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 10) <!-- [rfced] We updated the first two bulleted lists in Section
>>>>> 3.2 (created parallel structure and removed the parentheses around
>>>>> sentences). Please review these changes in the diff file and let us know any concerns.
>>>>>
>>>>> GIM>> I agree with the update that makes looks of lists in the document consistent.
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 11) <!-- [rfced] May we change the first bulleted list in Sections
>>>>> 3.1 and all the bulleted lists in Section 3.2 to definition lists?
>>>>> See https://authors.ietf.org/en/rfcxml-vocabulary#dl.
>>>>>
>>>>> One example:
>>>>>
>>>>> Current:
>>>>>    *  VI is a time interval during which at least one of the performance
>>>>>       parameters degraded below its configurable optimal level
>>>>>       threshold.
>>>>>
>>>>>    *  SVI is a time interval during which at least one of the
>>>>>       performance parameters degraded below its configurable critical
>>>>>       threshold.
>>>>>
>>>>>    *  Consequently, VFI is a time interval during which all performance
>>>>>       parameters are at or better than their respective pre-defined
>>>>>       optimal levels.
>>>>>
>>>>> Perhaps:
>>>>>    VI: A time interval during which at least one of the performance
>>>>>       parameters degraded below its configurable optimal level
>>>>>       threshold.
>>>>>
>>>>>    SVI: A time interval during which at least one of the
>>>>>       performance parameters degraded below its configurable critical
>>>>>       threshold.
>>>>>
>>>>>    VFI: A time interval during which all performance
>>>>>       parameters are at or better than their respective pre-defined
>>>>>       optimal levels.
>>>>>
>>>>> GIM>> I slightly prefer the current format, but I can live with the update.
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 12) <!-- [rfced] Should "the following section" here read "this
>>>>> section"? This sentence appears in Section 3.3; the following
>>>>> section is Section 4, which does not mention a state model.
>>>>>
>>>>> Original:
>>>>>    While the definition of a service state model is outside the scope of
>>>>>    this document, the following section provides some considerations for
>>>>>    how such a state model and accompanying configuration settings could
>>>>>    be defined.
>>>>>
>>>>> Perhaps:
>>>>>    While the definition of a service state model is outside the scope of
>>>>>    this document, this section provides some considerations for
>>>>>    how such a state model and accompanying configuration settings could
>>>>>    be defined.
>>>>>
>>>>> GIM>> Thank you for your thoughtful consideration of the text. I agree with the proposed update.
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 13) <!-- [rfced] Would it be helpful to update "YANG/NETCONF/RESTCONF framework"
>>>>> as follows? Or do you prefer the current?
>>>>>
>>>>> Original:
>>>>>    *  A YANG data model will allow PAM to be incorporated into
>>>>>       monitoring applications based on the YANG/NETCONF/RESTCONF
>>>>>       framework.
>>>>>
>>>>> Perhaps:
>>>>>    *  A YANG data model will allow PAM to be incorporated into
>>>>>       monitoring applications based on the YANG, NETCONF,
>>>>>       and RESTCONF frameworks.
>>>>>
>>>>> GIM>> I agree with the proposed update.
>>>>>
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 14) <!-- [rfced] FYI - We rephrased this as follows to form a
>>>>> complete sentence. The other items in the list are complete
>>>>> sentences. Please review.
>>>>>
>>>>> Original:
>>>>>    *  The definition of the metrics that represent histograms for
>>>>>       service level parameters with buckets corresponding to individual
>>>>>       service level objectives,
>>>>>
>>>>> Updated:
>>>>>    *  Metrics can be defined to represent histograms for
>>>>>       service-level parameters with buckets corresponding to individual
>>>>>       SLOs..
>>>>>
>>>>> GIM>> I agree with the proposed update.
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 15) <!-- [rfced] Please review "that should be maintained". Should
>>>>> this read "and should be maintained", or is the current okay? Also,
>>>>> please confirm that "violated time units" is correct here. We do not
>>>>> see this mentioned elsewhere in the document.
>>>>>
>>>>> Original:
>>>>>    The same service levels that
>>>>>    constitute SLO violations for one flow that should be maintained as
>>>>>    part of the "violated time units" and related metrics, may be
>>>>>    compliant for another flow.
>>>>>
>>>>> Perhaps:
>>>>>    The same service levels that
>>>>>    constitute SLO violations for one flow and should be maintained as
>>>>>    part of the "violated time units" and related metrics may be
>>>>>    compliant for another flow.
>>>>>
>>>>> GIM>> I agree with the updated version.
>>>>>
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 16) <!-- [rfced] FYI - We updated this fragment as follows to create
>>>>> a complete sentence.
>>>>>
>>>>> Original:
>>>>>    By the same token, where the definition of what constitutes a
>>>>>    "severe" or a "significant" violation depends on configuration
>>>>>    settings or context.
>>>>>
>>>>> Perhaps:
>>>>>    By the same token, the definition of what constitutes a
>>>>>    "severe" or a "significant" violation depends on configuration
>>>>>    settings or context.
>>>>>
>>>>> GIM>> I agree with the proposed update.
>>>>>
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 17) <!-- [rfced] Abbreviations
>>>>>
>>>>> a) We see both of the following as the expansion for PAM.
>>>>>
>>>>>   Precision Availability Metric (1 instance)
>>>>>   Precision Availability Metrics (8 instances)
>>>>>
>>>>> We updated to use the latter form (i.e., the form with "Metrics").
>>>>> Please let us know any objections.
>>>>>
>>>>> GIM>> Thank you for the question. I think that the use of singular, i.e., "Metric", in Acronyms is valid. Consequently, all acronyms in the document, in my opinion, should be changed to "PAMs".
>>>>>
>>>>>
>>>>>
>>>>> b) We see two instances of "PAMs" in the document (see below). Since "Metrics"
>>>>> in the expansion is already plural, is the "s" needed in "PAMs"?
>>>>> Please review.
>>>>>
>>>>> Original:
>>>>>    To indicate a historic degree of precision availability, additional
>>>>>    derived PAMs can be defined as follows:
>>>>>    ...
>>>>>    It might be useful for a service provider to determine the current
>>>>>    condition of the service for which PAMs are maintained.
>>>>>
>>>>> GIM>> If we agree that the acronym is expanded as "Precision Availability Metric", then "PAMs" is the right form.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> c) OAM appears in the list of acronyms in Section 2.2 but is not
>>>>> mentioned elsewhere in the document. May we delete this term from the list?
>>>>>
>>>>> GIM>> Yes, please remove it.
>>>>>
>>>>>
>>>>>
>>>>> d) FYI - We have added an expansion for the following abbreviation
>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>>>>> expansion in the document carefully to ensure correctness.
>>>>>
>>>>>   IP Flow Information Export (IPFIX)
>>>>>
>>>>> GIM>> It seems that IPFIX is used only one time in the document. Do you think that the expanded form without the acronym is sufficient? I'm okay with any form.
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 18) <!-- [rfced] Please review the "Inclusive Language" portion of
>>>>> the online Style Guide
>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>>> 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.
>>>>>
>>>>> GIM>> I agree, don't find anything that requires rewording.
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> 19) <!-- [rfced] We see a number of author-inserted comments in the
>>>>> .xml file for this document. We are unsure if these have been
>>>>> resolved. Please review and let us know if these can be deleted or if they need to be addressed.
>>>>>
>>>>> GIM>> :-) My apologies for not cleaning our workspace properly. Thank you.
>>>>>
>>>>> -->
>>>>>
>>>>>
>>>>> Thank you.
>>>>>
>>>>> RFC Editor/rv
>>>>>
>>>>>
>>>>>
>>>>> On Feb 15, 2024, at 5:34 PM, [e-mail] wrote:
>>>>>
>>>>> *****IMPORTANT*****
>>>>>
>>>>> Updated 2024/02/15
>>>>>
>>>>> 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://www.rfc-editor.org/faq/).
>>>>>
>>>>> 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://trustee.ietf.org/license-info/).
>>>>>
>>>>> *  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://authors.ietf.org/rfcxml-vocabulary>.
>>>>>
>>>>> *  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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2US
>>>>> xIAe6P8O4Zc
>>>>>
>>>>>     *  The archive itself:
>>>>>        https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>
>>>>>     *  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://www.rfc-editor.org/authors/rfc9544.xml
>>>>>   https://www.rfc-editor.org/authors/rfc9544.html
>>>>>   https://www.rfc-editor.org/authors/rfc9544.pdf
>>>>>   https://www.rfc-editor.org/authors/rfc9544.txt
>>>>>
>>>>> Diff file of the text:
>>>>>   https://www.rfc-editor.org/authors/rfc9544-diff.html
>>>>>   https://www.rfc-editor.org/authors/rfc9544-rfcdiff.html (side by
>>>>> side)
>>>>>
>>>>> Alt-diff of the text (allows you to more easily view changes where
>>>>> text has been deleted or moved):
>>>>>   https://www.rfc-editor.org/authors/rfc9544-alt-diff.html
>>>>>
>>>>> Diff of the XML:
>>>>>   https://www.rfc-editor.org/authors/rfc9544-xmldiff1.html
>>>>>
>>>>>
>>>>> Tracking progress
>>>>> -----------------
>>>>>
>>>>> The details of the AUTH48 status of your document are here:
>>>>>   https://www.rfc-editor.org/auth48/rfc9544
>>>>>
>>>>> Please let us know if you have any questions.
>>>>>
>>>>> Thank you for your cooperation,
>>>>>
>>>>> RFC Editor
>>>>>
>>>>> --------------------------------------
>>>>> RFC9544 (draft-ietf-ippm-pam-09)
>>>>>
>>>>> Title            : Precision Availability Metrics for Services Governed by Service Level Objectives (SLOs)
>>>>> Author(s)        : G. Mirsky, J. Halpern, X. Min, A. Clemm, J. Strassner, J. François
>>>>> WG Chair(s)      : Marcus Ihlar, Tommy Pauly
>>>>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> regards,
>>>>> John
>>>>
>>>>
>>>>
>>>> --
>>>> regards,
>>>> John
>>>
>>
>>
>