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

[John Strassner <[e-mail]>]

Thank you Rebecca for your hard work. I also approve this document.

best regards,
John

On Wed, Feb 21, 2024 at 9:04 PM Rebecca VanRheenen <[e-mail]>
wrote:

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

-- 
regards,
John