Re: [auth48] AUTH48: RFC-to-be 9417 <draft-ietf-opsawg-service-assurance-architecture-13> for your review

[Benoit Claise <[e-mail]>]

Hi,

On 5/26/2023 7:13 PM, Alanna Paloma wrote:
> Hi Benoit,
>
> Thank you for your replies. We have updated the files accordingly.
>
> Regarding the use of “YANG module” and “YANG data model", we ask that 
> you review *all *occurrences of “YANG model” in this document and let 
> us know where updates are necessary. For example, in the following, 
> “YANG modules” doesn’t seem right as RFC 7950 is titled “The YANG 1.1 
> Data Modeling Language”.
I followed your advice:

    c) We have received guidance from the YANG Doctors
    that "YANG module" and "YANG data model" are preferred.
    Some occurrences may need an update, for example:

>
> Original:
>   This
>    problem is compounded by a large, disparate set of data sources (MIB
>    modules, YANG models [RFC7950], IPFIX information elements [RFC7011],
>    syslog plain text [RFC5424], TACACS+ [RFC8907], RADIUS [RFC2865],
>    etc.).
NEW:
   This
    problem is compounded by a large, disparate set of data sources (MIB
    modules, YANG data models [RFC7950], IPFIX information elements 
[RFC7011],
    syslog plain text [RFC5424], TACACS+ [RFC8907], RADIUS [RFC2865],
    etc.).
>
> In another example, we see the following. However, Section 6 is titled 
> “Subservice Augmentation: ietf-service-assurance-interface YANG Module”.
This is fine.
>
> Original:
>    This can be partially achieved by correctly setting permissions of
>    each node in the YANG model as described in Section 6 of
>    [RFC9418].

New:
    This can be partially achieved by correctly setting permissions of
    each node in the YANG data model as described in Section 6 of
    [RFC9418].
>
> Note that it is not always clear to us whether “model” vs. “module” is 
> correct and/or if all instances of “YANG model” should be updated to 
> “YANG data model”. Please review each instance and let us know if 
> updates are needed.
OLD:

In order to avoid this data
    model mapping, the industry converged on model-driven telemetry to
    stream the service operational data, reusing the YANG models used for

NEW:
In order to avoid this data
    model mapping, the industry converged on model-driven telemetry to
    stream the service operational data, reusing the YANG data models used for

OLD:
    In order to make agents, orchestrators, and collectors from different
    vendors interoperable, their interface is defined as a YANG model in
    a companion document [RFC9418].  In Figure 1, the communications that
    are normalized by this YANG model are tagged with a "Y".  The use of
    this YANGmodel  *module*  is further explained in Section 3.5.

NEW:
    In order to make agents, orchestrators, and collectors from different
    vendors interoperable, their interface is defined as a YANG moddule in
    a companion document [RFC9418].  In Figure 1, the communications that
    are normalized by this YANG module are tagged with a "Y".  The use of
    this YANGmodel  *module*  is further explained in Section 3.5.

OLD:
  The set of dependency types presented here is not exhaustive.  More
    specific dependency types can be defined by extending the YANG model.

NEW:
  The set of dependency types presented here is not exhaustive.  More
    specific dependency types can be defined by extending the YANG module.

OLD:
This also implies that, while waiting for all the
    metrics to be available via standard YANG modules, SAIN agents might
    have to retrieve metric values via nonstandard YANG models,

NEW:
This also implies that, while waiting for all the
    metrics to be available via standard YANG modules, SAIN agents might
    have to retrieve metric values via nonstandard YANG data models,

>
> The files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9417.xml
> https://www.rfc-editor.org/authors/rfc9417.txt
> https://www.rfc-editor.org/authors/rfc9417.html
> https://www.rfc-editor.org/authors/rfc9417.pdf
>
> The relevant diff files have been posted here:
> https://www.rfc-editor.org/authors/rfc9417-diff.html (comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9417-auth48diff.html (AUTH48 
> changes)
>
> Please review the document carefully and contact us with any further 
> updates you may have.  Note that we do not make changes once a 
> document is published as an RFC.
>
> We will await approvals from each party listed on the AUTH48 status 
> page below prior to moving this document forward in the publication 
> process.
Everything is fine.

Thanks, B.
>
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9417
>
> Thank you,
> RFC Editor/ap
>
>> On May 24, 2023, at 3:18 AM, Benoit Claise 
>> <benoit.claise=[e-mail]> wrote:
>>
>> Dear RFC editors,
>>
>> On 5/24/2023 11:09 AM, [e-mail] wrote:
>>> Authors,
>>>
>>> While reviewing this document during AUTH48, please resolve (as 
>>> necessary)
>>> the following questions, which are also in the XML file.
>>>
>>> Also, please note that this diff file will allow you to more easily 
>>> view changes in the Introduction and Terminology sections. 
>>>  Apologies, as we forgot to include this in the initial AUTH48 message:
>>> https://www.rfc-editor.org/authors/rfc9417-alt-diff.html
>> All is fine thanks.
>>>
>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear 
>>> in the
>>> title) for use on https://www.rfc-editor.org/search. -->
>> NA
>>>
>>>
>>> 2) <!-- [rfced] May we update this document to say "an architecture that
>>> assures" rather than "aims to assure"?  Otherwise, perhaps "an 
>>> architecture
>>> that provides some assurance that service instances are..."?
>>>
>>> Original:
>>>    This document describes an architecture that aims at assuring that
>>>    service instances are running as expected.
>>> -->
>>
>> an architecture
>> that provides some assurance that service instances are..."
>>
>> The above works better, thanks.
>>>
>>> 3) <!--[rfced] FYI, we have moved the Terminology section to appear 
>>> after
>>> the Introduction.
>>> -->
>> Ok.
>>>
>>>
>>> 4) <!-- [rfced] "feed" reads a bit awkwardly.  Would "fuel" work here
>>> instead?
>>>
>>> Original:
>>>    To feed that task, the industry has been standardizing
>>>    on telemetry to push network element performance information (e.g.,
>>>    [I-D.ietf-opsawg-yang-vpn-service-pm]).
>>> -->
>> Fuel is better.
>>>
>>>
>>> 5) <!-- [rfced] As this document is being published as an RFC, should
>>> "propose" be removed?  That is, should it read "this document defines an
>>> architecture implementing ..."?
>> Yes.
>>>
>>> Original:
>>>    In this document, we propose an architecture implementing Service
>>>    Assurance for Intent-Based Networking (SAIN).
>>> -->
>>>
>>>
>>> 6) <!--[rfced] Should the terms listed in the Terminology section be
>>> listed in alphabetical order?
>>> -->
>> IIRC, there is some logic behind the order, for the reader
>> Ex: health status after subservice.
>>>
>>> 7) <!-- [rfced] We have updated the expansion for L2VPN to be "layer 2
>>> virtual private network" (i.e., s/level/layer).  Please let us know 
>>> if any
>>> updates are needed.
>>>
>>> Original:
>>>    As an example of a service, let us consider a point-to-point level 2
>>>    virtual private network (L2VPN).
>>> -->
>> OK
>>>
>>> 8) <!-- [rfced] What is being forwarded to the orchestrator?  Is it the
>>> information that a switchover has occurred?  Also, is it the 
>>> orchestrator
>>> that reconfigures the agents?  Please consider whether the suggested 
>>> text
>>> correctly conveys the intended meaning.
>>>
>>> Original:
>>>    The
>>>    collector also detects changes in the assurance graph structures, for
>>>    instance when a switchover from primary to backup path occurs, and
>>>    forwards to the orchestrator, which reconfigures the agents.
>>>
>>> Perhaps:
>>>    The
>>>    collector also detects changes in the assurance graph structures 
>>> (e.g., an
>>>    occurrence of a switchover from primary to backup path) and
>>>    forwards the information to the orchestrator, which reconfigures 
>>> the agents.
>>> -->
>> Good proposal
>>>
>>>
>>> 9) <!--[rfced] We note that RFC 8641 does not include mention of
>>> "telemetry".  Please review and let us know if/how the text/citation
>>> should be updated.
>>>
>>> Original:
>>>    *  Stream (via telemetry [RFC8641]) operational and config metric
>>>       values when possible, else continuously poll.
>>> -->
>>
>>   *  Stream (via telemetry such as YANG-PUSH [RFC8641]) operational 
>> and config metric
>>      values when possible, else continuously poll.
>>
>>>
>>>
>>> 10) <!--[rfced] For clarity, may we change "as" to "since" here? This
>>> would make it clear the intended meaning is a result rather than "at the
>>> same time".
>>>
>>> Original:
>>>   However, the dependencies between the link and the
>>>   interfaces are lost as they were causing the circular dependency.
>>>
>>> Perhaps:
>>>   However, the dependencies between the link and the
>>>   interfaces are lost since they were causing the circular dependency.
>>> -->
>> Fine.
>>>
>>>
>>> 11) <!-- [rfced]  We find the use of "configuration" and
>>> "configuring"/"configure" in the same sentence a bit confusing.  Please
>>> consider whether updates are needed?  Will the suggested text change the
>>> intended meaning?
>>>
>>> Original:
>>>    The SAIN orchestrator must be able to analyze configuration pushed to
>>>    various devices for configuring a service instance and produce the
>>>    assurance graph for that service instance.
>>>
>>>    To schematize what a SAIN orchestrator does, assume that the
>>>    configuration for a service instance touches two devices and
>>>    configure on each device a virtual tunnel interface. ...
>>>
>>> Perhaps:
>>>    The SAIN orchestrator must be able to analyze the configuration 
>>> pushed to
>>>    various devices of a service instance and produce the
>>>    assurance graph for that service instance.
>>>
>>>    To schematize what a SAIN orchestrator does, assume that
>>>    a service instance touches two devices and
>>>    configures a virtual tunnel interface on each device.
>>> -->
>> Yes, this is better
>>>
>>> 12) <!-- [rfced] Is it possible to detect a non-functional tunnel?
>> Yes, it's configured but no traffic is forwarded.
>>> Does
>>> detection that a tunnel exists imply that it is functional?
>> No, see above.
>>>
>>> Original:
>>>    *  Capturing the intent would start by detecting that the service
>>>       instance is actually a tunnel between the two devices, and stating
>>>       that this tunnel must be functional.
>>>
>>> Perhaps:
>>>    *  Capturing the intent would entail detecting that the service
>>>       instance is actually a tunnel between the two devices and 
>>> indicating
>>>       that the tunnel must remain functional.
>>> -->
>> Proposal
>>
>>   *  Capturing the intent would start by detecting that the service
>>      instance is actually a tunnel between the two devices, and stating
>>      that this tunnel must be operational.
>>
>>>
>>>
>>> 13) <!-- [rfced] This text reads awkwardly in that it first says the
>>> organization is out of scope but then lists goals.  Please consider
>>> whether the suggested text is correct.
>>>
>>> Original:
>>>    The organization of such a process is out-of-scope for this
>>>    document and should aim to:
>>>
>>>    *  Ensure that existing subservices are reused as much as possible.
>>>
>>>    *  Avoid circular dependencies.
>>>
>>> Perhaps:
>>>    The organization of such a process is out of scope for this
>>>    document.  Future documentation should aim to:
>>>
>>>    *  Ensure that existing subservices are reused as much as possible.
>>>
>>>    *  Avoid circular dependencies.
>>> -->
>> Proposal:
>>
>>   The organization of such a process (Ensure that existing 
>> subservices are reused as much as possible
>>   and avoid circular dependencies) is out-of-scope for this
>>   document.
>>
>> Does it work better?
>>
>>>
>>>
>>> 14) <!--[rfced] In the sentence below, does "identify the object" 
>>> describe
>>> "the parameters" or "a minimal set"?
>>>
>>> Original:
>>>    Then, the parameters
>>>    must be chosen as a minimal set that completely identify the object
>>>    (see examples from the previous paragraph).
>>>
>>> Perhaps (describes "a minimal set"):
>>>    Then, the parameters
>>>    must be chosen as a minimal set that completely identifies the object
>>>    (see examples from the previous paragraph).
>>> -->
>> Your proposal is better.
>>>
>>>
>>> 15) <!-- [rfced] We are having some difficulty understanding "expressed
>>> differently" in the sentence below. Please review and let us know 
>>> how this
>>> sentence should be updated.
>> expressed differently = in other words
>>> Original:
>>>    In order to keep subservices independent of metric collection method,
>>>    or, expressed differently, to support multiple combinations of
>>>    platforms, OSes, and even vendors, the architecture introduces the
>>>    concept of "metric engine".
>>>
>>> Perhaps A:
>>>    In order to keep subservices independent of metric collection method,
>>>    and support multiple combinations of
>>>    platforms, OSes, and even vendors, the architecture introduces the
>>>    concept of "metric engine".
>>>
>>> Perhaps B:
>>>    In order to keep subservices independent of metric collection method
>>>    (or, expressed differently, to support multiple combinations of
>>>    platforms, OSes, and even vendors), the architecture introduces the
>>>    concept of "metric engine".
>>> -->
>> Proposal B is better
>>>
>>>
>>> 16) <!--[rfced] Ordering the IANA section before the Security 
>>> Considerations
>>> section is strongly recommended in the RFC Style Guide (see RFC 7322,
>>> Section 4). Given this, we updated the document accordingly.  Please 
>>> let us know any objections.
>>> -->
>> Then we will strongly follow the recommendations :-)
>>>
>>>
>>> 17) <!--[rfced] Terminology questions
>>>
>>> a) FYI, we have capitalized instances of "engineer A" and "engineer B"
>>> to be "Engineer A" and "Engineer B" to be consistent. Please let us know
>>> of any objections.
>> No objection.
>>>
>>> b) We note that "health score" and "health-score" are both used in this
>>> document. Should these instances be made consistent?
>> Fine to change "health-score" to health score. There is only one 
>> occurence.
>>>
>>> c) We have received guidance from the YANG Doctors
>>> that "YANG module" and "YANG data model" are preferred.
>>> Some occurrences may need an update, for example:
>>>
>>> Original:
>>>    The use of this YANG model is further
>>>    explained in Section 3.5.
>>>
>>> Where Section 3.5 is "Open Interfaces with YANG Modules.”
>>>
>>> Please review and specify any needed updates.
>>> -->
>> This is fine.
>>>
>>> 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.
>>
>> Thank you very much for the improvements.
>>
>> Regards, Benoit
>>> -->
>>>
>>>
>>> Thank you.
>>>
>>> RFC Editor
>>>
>>>
>>>
>>>
>>> On May 23, 2023, at 7:58 PM, [e-mail] wrote:
>>>
>>> *****IMPORTANT*****
>>>
>>> Updated 2023/05/23
>>>
>>> RFC Author(s):
>>> --------------
>>>
>>> Instructions for Completing AUTH48
>>>
>>> Your document has now entered AUTH48.  Once it has been reviewed and
>>> approved by you and all coauthors, it will be published as an RFC.
>>> If an author is no longer available, there are several remedies
>>> available as listed in the FAQ (https://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/rfc9417.xml
>>> https://www.rfc-editor.org/authors/rfc9417.html
>>> https://www.rfc-editor.org/authors/rfc9417.pdf
>>> https://www.rfc-editor.org/authors/rfc9417.txt
>>>
>>> Diff file of the text:
>>> https://www.rfc-editor.org/authors/rfc9417-diff.html
>>> https://www.rfc-editor.org/authors/rfc9417-rfcdiff.html (side by side)
>>>
>>> Diff of the XML:
>>> https://www.rfc-editor.org/authors/rfc9417-xmldiff1.html
>>>
>>> The following files are provided to facilitate creation of your own
>>> diff files of the XML.
>>>
>>> Initial XMLv3 created using XMLv2 as input:
>>> https://www.rfc-editor.org/authors/rfc9417.original.v2v3.xml
>>>
>>> XMLv3 file that is a best effort to capture v3-related format updates
>>> only:
>>> https://www.rfc-editor.org/authors/rfc9417.form.xml
>>>
>>>
>>> Tracking progress
>>> -----------------
>>>
>>> The details of the AUTH48 status of your document are here:
>>> https://www.rfc-editor.org/auth48/rfc9417
>>>
>>> Please let us know if you have any questions.
>>>
>>> Thank you for your cooperation,
>>>
>>> RFC Editor
>>>
>>> --------------------------------------
>>> RFC9417 (draft-ietf-opsawg-service-assurance-architecture-13)
>>>
>>> Title            : Service Assurance for Intent-based Networking 
>>> Architecture
>>> Author(s)        : B. Claise, J. Quilbeuf, D. Lopez, D. Voyer, T. 
>>> Arumugam
>>> WG Chair(s)      : Henk Birkholz, Joe Clarke, Tianran Zhou
>>> Area Director(s) : Warren Kumari, Robert Wilton
>