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

[Greg Mirsky <[e-mail]>]

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-4Q9l2USxIAe6P8O4Zc
>>> >
>>> >     *  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
>>> synonyms. I slightly prefer the first option (above), but I 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-4Q9l2USxIAe6P8O4Zc
>>> >
>>> >     *  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
>