Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

From: "[email-masked]" <[email-masked]>
Date: Tue, 2 Jun 2020 17:04:09 +0800

Hi, folks,
As a co-author, I believe this document is ready for publication. Thanks!

Chongfeng
 
From: OPSAWG [mailto:[email-masked]] On Behalf Of Tianran Zhou
Sent: Monday, June 1, 2020 10:25 AM
To: [email-masked]
Cc: OpsAWG-Chairs <[email-masked]>
Subject: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03
 
Hi WG,
 
The authors requested the WG last call. And we think this draft is mature and stable. We start a two week last call for this draft.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/
 
Please send your comments stating whether you believe the document is ready for publication. 
If not, please explain why not and provide comments to improve this document.
 
Thanks,
Tianran and Joe

---

From: <[email-masked]>
Date: Tue, 2 Jun 2020 09:07:13 +0000

Hi,

As one of the contributors, I too believe this draft is ready for publication.

Cheers,

Christian.

De : OPSAWG [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 2 juin 2020 11:04
À : opsawg
Cc : opsawg-chairs
Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi, folks,

Chongfeng

From: OPSAWG [mailto:[email-masked]] On Behalf Of Tianran Zhou
Sent: Monday, June 1, 2020 10:25 AM
To: [email-masked]<mailto:[email-masked]>
Cc: OpsAWG-Chairs <[email-masked]<mailto:[email-masked]>>
Subject: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi WG,

Thanks,

Tianran and Joe

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 5 Jun 2020 10:59:47 +1200

Hi,

I've read through the draft and it seems almost ready to progress as an Informational document. I just found one tricky issue in the Security Considerations:

>    The lowest RESTCONF layer
>    is HTTPS, and the mandatory-to-implement secure transport is TLS
>    [RFC8446].

Do you intend to specify TLS 1.3 as mandatory to implement? RFC8040 specifies TLS 1.2, and this Informational document can't change that.

Editorial:

There seem to be a lot of very long, complicated sentences that are difficult to understand. For example, in the Abstract:

>    Data models for service and network management provides a
>    programmatic approach for representing services or networks and
>    deriving (1) configuration information that will be communicated to
>    network and service components that are used to build and deliver the
>    service and (2) state information that will be monitored and tracked.
and in the Introduction:

>    SDN techniques [RFC7149] are meant to automate the
>    overall service delivery procedures and typically rely upon
>    (standard) data models that are used to not only reflect service
>    providers'savoir-faire but also to dynamically instantiate and
>    enforce a set of (service-inferred) policies that best accommodate
>    what has been (contractually) defined (and possibly negotiated) with
>    the customer.

I suggest reviewing all the sentence above ~40 words to consider splitting them into several shorter sentences.

Also, in the second example, the () () are more confusing than helpful. Throughout the document, I see uses of () that do not help the reader. For example:

> 4.1.2.  Service Creation/Modification
> 
>    A customer is (usually) unaware of the technology...

It is just easier to read like this:

   A customer is usually unaware of the technology...

Regards
   Brian Carpenter

---

From: <[email-masked]>
Date: Fri, 5 Jun 2020 05:07:56 +0000

Hi Brian, 

Thank you for the comments.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:[email-masked]] De la part de Brian E
> Carpenter
> Envoyé : vendredi 5 juin 2020 01:00
> À : [email-masked]
> Cc : OpsAWG-Chairs
> I've read through the draft and it seems almost ready to progress as
> an Informational document. I just found one tricky issue in the
> Security Considerations:
> 
> Do you intend to specify TLS 1.3 as mandatory to implement?

[Med] Yeah. We are echoing the guidelines in RFC8407#section-3.7.1.

 RFC8040
> specifies TLS 1.2, and this Informational document can't change that.
> 
> Editorial:
> 
> There seem to be a lot of very long, complicated sentences that are
> difficult to understand. For example, in the Abstract:
> 
> I suggest reviewing all the sentence above ~40 words to consider
> splitting them into several shorter sentences.

[Med] Sure. Will check and fix those. Thanks. 

> 
> Also, in the second example, the () () are more confusing than
> helpful. Throughout the document, I see uses of () that do not help
> the reader. For example:
> 

[Med] Noted. Will be fixed. 

> Regards
>    Brian Carpenter
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Jun 2020 16:36:36 +0100

Hi,

I've reviewed this document in working group last call and support its

publication. I found the Appendix particularly helpful.

I have some minor thoughts that the authors may want to consider as the

document moves forward.

Thanks,

Adrian

==

idits says that draft-ietf-dots-data-channel has been published as

RFC 8783

---

The Abstract is a little longer than the recommended maximum length of

20 lines. Maybe reduce the first paragraph to:

   Data models provide a programmatic approach to represent services and

   networks.  They can be used to derive configuration information for 

   network and service components, and state information that will be

   monitored and tracked.  Data models can be used during the service

   and network management life cycle, such as service instantiation,

   provisioning, optimization, monitoring, diagnostic, and assurance. 

   Data models are also instrumental in the automation of network

   management, and they can provide closed-loop control for adaptive and

   deterministic service creation, delivery, and maintenance.

---

Section 1

s/requirements and order/requirements and orders,/

s/operating in a silo/operate in a silo/

s/providers'savoir-faire/providers' savoir-faire,/

s/first tentative/first tentative attempt/

   YANG [RFC7950] module developers have taken both top-down and bottom-

   up approaches to develop modules [RFC8199] and to establish a mapping

   between a network technology and customer requirements on the top or

   abstracting common construct from various network technologies on the

   bottom.

s/construct/constructs/

s/on the/at the/  (twice)

---

Section 1

   other Standards Developing

   Organizations (SDOs) (e.g., MEF)

It's not clear to me why you cite MEF as an example of another SDO. I 

don't think you mean to be judgemental (i.e., saying that you would have

expected MEF to have done this) so it is probably best to leave that out

---

Section 2

I don't object to your definitions of Network Model and Device Model, 

but I wondered why you chose not to use or reference Network 

Configuration Model and Device Configuration Model from RFC 8309.

---

Section 3.1

   Figure 1 depicts the example of a VoIP service provider that relies

   upon connectivity services offered by a Network Operator.

But Figure 1 actually uses the terms "Provider" and "SP". It might be

helpful to clarify in the text (the paragraph before the figure) whether

the two "SP sites" and the "Provider" are all under the control of the 

"Network Operator" while the "Internet" is of broader scope.

---

Section 3.3

   To operate a service, Device Models derived from Service Models and/

   or Network Models can be used to provision each involved network

   function/device with the proper configuration information, and

   operate the network based on service requirements as described in the

   Service Model(s) and local operational guidelines.

It seems to me that you are describing a top-down approach to the 

construction of data models. But, in practice, isn't it the case that

Device Models are derived from the nature of the devices being managed

in a bottom-up approach. Thus there is a challenge of "meeting in the

middle" as the top-down service models meet the bottom-up device models.

Perhaps this issue is resolved by...

   To operate a service, the settings of the parameters in the Device

   Models are derived from Service Models and/or Network Models and are

   used to provision each involved network function/device...

---

Section 4

s/led to the/lead to the/

---

Can I be so bold as to suggest some changes to Figure 4?

Changes include:

- Minor updates to spacing to make arrows clearer

- Arrow end where path joins E2E Service Assurance to E2E Service

  Diagnostics

- Remove path cross-over in paths from Specific Service Assurance

- Arrow end where path joins Specific Service Assurance to Specific

  Service Optimization

- Dotted lines to separate the different levels and moved the names of

  the levels inside the boundaries.

                    +------------------+

  ................. |                  |

     Service level  |                  |

                    V                  |

      E2E          E2E                E2E              E2E

    Service --> Service --------->  Service   -----> Service -----+

    Exposure    Creation     ^    Optimization   ^  Diagnosis     |

               /Modification |                   |                |

                    |        |Diff               |                V

     Multi-layer    |        |         E2E       |               E2E

     Multi-domain   |        |       Service     |            Service

     Service Mapping|        +------ Assurance --+         Decommission

                    |                     ^

   ................ |<-----------------+  |

     Network level  |                  |  +-------+

                    V                  |          |

                Specific           Specific       |

                Service  -------->  Service <--+  |

                Creation     ^    Optimization |  |

               /Modification |                 |  |

                    |        |Diff             |  |

                    |        |      Specific --+  |

           Service  |        |      Service       |

        Decomposing |        +----- Assurance ----+

                    |                  ^

   ................ |                  |    Aggregation

     Device level   |                  +------------+

                    V                               |

   Service       Intent                             |

   Fullfillment  Config  -----> Config  -----> Performance ---> Fault

                 Provision      Validate       Monitoring     Diagnostic

---

Section 4.1.2

   Upon receiving a service request, the service orchestrator/management

   system should first verify whether the service requirements in the

   service request can be met (i.e., whether there is sufficient

   resources that can be allocated with the requested guarantees).

It may sound "obvious" but I think there is an authentication and 

authorisation step first. Is the user who they say they are? Are they

allowed to request the service they are asking for?

It would be worth mentioning this in Section 6 as well.

---

Section 4.1.3

s/feed/fed/

---

Section 4.3

   in Traffic Engineering Architecture and Signaling

   (TEAS) VN model [I-D.ietf-teas-actn-vn-yang]

I think you should use the name of the model as given in the referenced

document. 

---

Section 5.1

You use L3NM without expansion or a reference

I think it might be helpful to know where the model in [I-D.ogondio-

opsawg-uni-topology] fits in the context of Figure 5.

---

Figure 5

OLD

            |              +-----V- -------+                  |

NEW

            |              +-----V---------+                  |

OLD

            +-------------++----------  ++--------------------+

NEW

            +-------------++------------++--------------------+

OLD

            +--+--+      +++---+      --+---+           +--+--+

NEW

            +--+--+      +-+---+      +-+---+           +--+--+

OLD

            | CE1 -------| PE1 |      | PE2 |  ---------+ CE2 |

NEW

            | CE1 +------+ PE1 |      | PE2 +-----------+ CE2 |

---

Figure 6

OLD

              +-------------++----------  ++--------------------+

NEW

              +-------------++------------++--------------------+

OLD

              +--+--+      +++---+      --+---+           +--+--+

NEW

              +--+--+      +-+---+      +-+---+           +--+--+

OLD

              | CE1 |------| PE1 |      | PE2 |  ---------+ CE2 |

NEW

              | CE1 +------+ PE1 |      | PE2 +-----------+ CE2 |

---

Figure 7

OLD

            +----------------------V--------------------+----+

NEW

            +----------------------V--------------------+-----+

OLD

            | CE1 |------| PE1 |        | PE2 |---------+ CE2 |

NEW

            | CE1 +------+ PE1 |        | PE2 +---------+ CE2 |

---

Appendix A

   It is not the intent of this appendix to provide an inventory of

   tools and mechanisms used in specific network and service management

   domains; such inventory can be found in documents such as [RFC7276].

It is OK to say what this appendix is not, but it might be useful to 

also say what it is. Also to note that the appendix is non-normative.

From: OPSAWG <[email-masked]> On Behalf Of Tianran Zhou
Sent: 01 June 2020 03:25
To: [email-masked]
Cc: OpsAWG-Chairs <[email-masked]>
Subject: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi WG,

The authors requested the WG last call. And we think this draft is mature
and stable. We start a two week last call for this draft.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framewor
k/

Please send your comments stating whether you believe the document is ready
for publication. 

If not, please explain why not and provide comments to improve this
document.

Thanks,

Tianran and Joe

---

From: <[email-masked]>
Date: Fri, 12 Jun 2020 08:15:28 +0000

Hi Adrian,

Thank you for the review.

I integrated almost all your suggestions. FWIW, an updated version is available at: https://github.com/boucadair/draft-ietf-opsawg-model-automation-framework.

Please see inline for more details.

Cheers,
Med

De : OPSAWG [mailto:[email-masked]] De la part de Adrian Farrel
Envoyé : jeudi 11 juin 2020 17:37
À : [email-masked]
Cc : 'OpsAWG-Chairs'
Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi,

Thanks,
Adrian

==

[Med] Fixed.
---

[Med] Deal. Thanks.
---

Section 1

[Med] Fixed.

[Med] Fixed.
---

Section 1

[Med] The intent was to give an example. Deleted it to avoid misinterpretations.
---

Section 2

[Med] There is no "formal" definition in 8309, if you will. Updated the text to say that these terms refer to Network Configuration Model and Device Configuration Model discussed in RFC 8309.
---

Section 3.1

[Med] Updated the text as follows:

NEW:
   Figure 1 depicts the example of a VoIP service that relies upon
   connectivity services offered by a Network Operator.  In this
   example, the VoIP service is offered to the Network Operator's
   customers by Service Provider (SP1).  In order to provide global VoIP
   reachability, SP1 service site interconnects with other Service
   Providers service sites typically by interconnecting Session Border
   Elements (SBEs) and Data Border Elements (DBEs) [RFC5486][RFC6406].
   For other VoIP destinations, sessions are forwarded over Internet.
   These connectivity services can be captured in a YANG Service Module
   that reflects the service attributes that are shown in Figure 2.

---

Section 3.3

[Med] That is the intent. Thanks.
---

Section 4

[Med] Fixed. Thanks.
---

                    +------------------+
  .................. |                  |
     Service level  |                  |
                    V                  |
      E2E          E2E                E2E              E2E

[Med] I like the changes. Much appreciated!
---

Section 4.1.2

[Med] Updated as follows:

NEW:

   Upon receiving a service request, and assuming that appropriate

   authentication and authorization checks have been made, the service

[Med] We do have some text about access control. We can add more text if you think this is not covered.

---

Section 4.1.3

s/feed/fed/

[Med] OK
---

Section 4.3

[Med] OK.
---

Section 5.1

You use L3NM without expansion or a reference
[Med] This one was already fixed as per a comment from Oscar. We also added NEW text for L2xM.

[Med] Will be added.

---

Figure 5

OLD
            |              +-----V- -------+                  |
NEW
            |              +-----V---------+                  |

OLD

OLD

OLD

[Med] Fixed.
---

Figure 6

OLD

OLD

OLD

[Med] Fixed.
---

Figure 7

OLD

OLD

[Med] Fixed.
---

Appendix A

[Med] Here is a first tentative (will work this further):

NEW:

   This appendix lists a set of data models that can be used for the

   delivery of connectivity services.  These models can be classified as

   Service, Network, or Device Models.

Thank you, again.

Hi WG,

Thanks,

Tianran and Joe

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 15 Jun 2020 01:37:56 +0000

Hi WG,

Thanks very much for your comments on

We see sufficient supports on the publication and the IPR is clear.

Authors, please publish a new version of the draft to incorporate the feedbacks.
We will progress the document.

Cheers,
Tianran

Hi WG,

Thanks,

Tianran and Joe

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 15 Jun 2020 01:40:27 +0000

Hi WG,

We would also like to seek a shepherd for this document.
It's really appreciate if you can volunteer.
Please send an email to the chairs.

Thanks,
Tianran

From: Tianran Zhou
Sent: Monday, June 15, 2020 9:38 AM
To: Tianran Zhou <[email-masked]>; [email-masked]
Cc: OpsAWG-Chairs <[email-masked]>
Subject: RE: WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi WG,

Cheers,
Tianran

Hi WG,

Thanks,

Tianran and Joe

---

From: <[email-masked]>
Date: Mon, 15 Jun 2020 06:09:41 +0000

Hi Tianran,

The updated version is available at:

URL:            https://www.ietf.org/internet-drafts/draft-ietf-opsawg-model-automation-framework-04.txt

Status:         https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/

Htmlized:       https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-04

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-framework

Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-04

It addresses the comments from Joe, Oscar, Brian, and Adrian in particular.

Cheers,
Med

De : OPSAWG [mailto:[email-masked]] De la part de Tianran Zhou
Envoyé : lundi 15 juin 2020 03:38
À : Tianran Zhou; [email-masked]
Cc : OpsAWG-Chairs
Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi WG,

Cheers,
Tianran

Hi WG,

Thanks,

Tianran and Joe

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Jun 2020 12:21:46 +0100

I looked at the diffs, and I think Med has correctly captured my comments.
Thanks!

Adrian

From: OPSAWG <[email-masked]> On Behalf Of
[email-masked]
Sent: 15 June 2020 07:10
To: Tianran Zhou <[email-masked]>; [email-masked]
Cc: OpsAWG-Chairs <[email-masked]>
Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi Tianran, 

URL:
https://www.ietf.org/internet-drafts/draft-ietf-opsawg-model-automation-fram
ework-04.txt

Status:

Htmlized:
https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-04

Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-fra
mework

Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framewo
rk-04

Cheers,

Med

Hi WG,

Authors, please publish a new version of the draft to incorporate the
feedbacks. 

Cheers,

Tianran

Hi WG,

Thanks,

Tianran and Joe

____________________________________________________________________________
_____________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
 
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Jun 2020 10:41:00 +0100

Hi Tianran,

Since I did a detailed review during last call, and considering that I
haven't been involved in the production of this document, I guess I can
volunteer.

OK?

Best,

Adrian

Sent: 15 June 2020 02:40

Hi WG,

Thanks,

Tianran

From: Tianran Zhou 
Sent: Monday, June 15, 2020 9:38 AM
To: Tianran Zhou <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> 
Cc: OpsAWG-Chairs <[email-masked] <mailto:[email-masked]> >
Subject: RE: WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi WG,

Cheers,

Tianran

From: OPSAWG [mailto:[email-masked]] On Behalf Of Tianran Zhou
Sent: Monday, June 1, 2020 10:25 AM
To: [email-masked] <mailto:[email-masked]> 
Cc: OpsAWG-Chairs <[email-masked] <mailto:[email-masked]> >
Subject: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi WG,

Thanks,

Tianran and Joe

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 16 Jun 2020 09:51:06 +0000

Hi Adrian,

Wonderful! Thank you very much.

Cheers,
Tianran

From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, June 16, 2020 5:41 PM
To: Tianran Zhou <[email-masked]>; [email-masked]
Cc: 'OpsAWG-Chairs' <[email-masked]>
Subject: RE: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi Tianran,

Since I did a detailed review during last call, and considering that I haven't been involved in the production of this document, I guess I can volunteer.

OK?

Best,
Adrian

From: OPSAWG <[email-masked]<mailto:[email-masked]>> On Behalf Of Tianran Zhou
Sent: 15 June 2020 02:40
To: [email-masked]<mailto:[email-masked]>
Cc: OpsAWG-Chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi WG,

Thanks,
Tianran

From: Tianran Zhou
Sent: Monday, June 15, 2020 9:38 AM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: OpsAWG-Chairs <[email-masked]<mailto:[email-masked]>>
Subject: RE: WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi WG,

Cheers,
Tianran

Hi WG,

Thanks,

Tianran and Joe

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Jun 2020 12:10:23 +0100

Draft write-up now posted in the datatracker.

Happy to receive comments, otherwise it's back to the chairs.

Adrian

From: Tianran Zhou <[email-masked]> 
Sent: 16 June 2020 10:51
To: [email-masked]; [email-masked]
Cc: 'OpsAWG-Chairs' <[email-masked]>
Subject: RE: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi Adrian,

Cheers,

Tianran

Hi Tianran,

OK?

Best,

Adrian

From: OPSAWG <[email-masked] <mailto:[email-masked]> > On
Behalf Of Tianran Zhou
Sent: 15 June 2020 02:40
To: [email-masked] <mailto:[email-masked]> 
Cc: OpsAWG-Chairs <[email-masked] <mailto:[email-masked]> >
Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi WG,

Thanks,

Tianran

From: Tianran Zhou 

Hi WG,

Cheers,

Tianran

Hi WG,

Thanks,

Tianran and Joe

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 17 Jun 2020 00:22:44 +0000

Amazing! Thanks for your good work.
Let's have a look, and move it forward.

Tianran

Sent: Tuesday, June 16, 2020 7:10 PM

Adrian

From: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Sent: 16 June 2020 10:51
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: 'OpsAWG-Chairs' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

Hi Adrian,

Cheers,
Tianran

Cc: 'OpsAWG-Chairs' <[email-masked]<mailto:[email-masked]>>

Hi Tianran,

OK?

Best,
Adrian

Hi WG,

Thanks,
Tianran

From: Tianran Zhou

Hi WG,

Cheers,
Tianran

Hi WG,

Thanks,

Tianran and Joe