Subject: Re: [OPSAWG] WG LC for Service Models Explained

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 Aug 2017 15:15:14 +0100

Med, thanks!

All of this looks tractable. I think nearly 100% is just stuff we can take.
There are one or two items for clarification where we'll respond at the time of
the edits.

Cheers,
Adrian

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 28 July 2017 09:23
> To: Tianran Zhou; [email-masked]
> Cc: [email-masked]
> Subject: Re: [OPSAWG] WG LC for Service Models Explained
> 
> Hi all,
> 
> I support advancing this document.
> 
> Below some comments that can be easily fixed by the authors.
> 
> - Remove RFC7426 and RFC8049 from the normative references. Those are cited
> as examples.
> 
> - Simplify the text in the abstract as follows:
> 
> OLD :
> 
> The IETF has produced a considerable number of data modules in the
>    YANG modelling language.  The majority of these modules are used to
>    construct data models to model devices or monolithic functions and
>                   ^^^^^^^^^^^^^^
>    they allow access for configuration and to read operational status.^
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^^^
> 
> NEW:
>    The IETF has produced a considerable number of data modules in the
>    YANG modelling language.  The majority of these modules are used to
>    construct data models for devices or monolithic functions.
> 
> - Introduction:
> 
> * Please cite RFC7149 in addition to [RFC7426] to have both IETF and IRTF
> perspectives.
> * Please update this text as follows:
> 
> OLD:
>    Within the context of Software Defined Networking (SDN) [RFC7426]
>    YANG data models may be used on Southbound Interfaces (SBIs) between
>                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    a controller and network devices, and between network orchestrators
>    and controllers.
> 
> NEW:
>    Within the context of Software Defined Networking (SDN) [RFC7426]
>    YANG data models may be used on the interface between
>    a controller and network devices, and between network orchestrators
>    and controllers.
> 
> SBI is introduced, but not used in the text.
> I'm not sure introducing geo-coordinate interfaces adds clarity to the text.
> 
> * Update this text as follows:
> 
> OLD:
>    Recently there has been interest in using YANG to define and document
>    ^^^^^^^^
>    data models that describe services in a portable way that is
>    independent of which network operator uses the model.
> 
> NEW:
>    There has been interest in using YANG to define and document
>    data models that describe services in a portable way that is
>    independent of which network operator uses the model.
> 
> Or change s/Recently/Recently (as per 2017)
> 
> * s/ Customer- Provider Interface/Customer-Provider Interface
> 
> - Section 2:
> s/i.e., routers or switches/e.g., routers or switches
> 
> - Section 3:
> 
> * Fix the following:
> 
> OLD:
> This is shown simply in Figure 1
> 
> NEW:
> This is shown simply in Figure 1.
> 
> * Fix the following:
> 
> OLD:
> The IETF uses the YANG data modeling language defined in [RFC6020]
> 
> NEW:
> The IETF uses the YANG data modeling language defined in [RFC6020].
> 
> - Section 4: Update this text as follows (the introduction text is about "many
> figures")
> 
> OLD:
> [RFC7491] describes an interface between...
> 
> NEW:
> Figure 1 of [RFC7491] shows an interface between...
> 
> - Section 5: I don't understand what is meant by "standard feature" in this
text:
> 
> "but these are not
>       standard features of the service as described in the customer
>       service model"
> 
> Do you mean: those are not mandatory features to be included in a service
> model?
> 
> - Section 6: I would shorten this text because L3WG is already introduced and
> stated many times in the document:
> 
>    Several initiatives within the IETF are developing customer service
>    models.  The most advanced presents the Layer Three Virtual Private
>    Network (L3VPN) service as described by a network operator to a
>    customer.  This L3VPN service model (L3SM) is documented in [RFC8049]
>    where its usage is described as in Figure 5 which is reproduced from
>    that document.  As can be seen, the L3SM is a customer service model
>    as described in this document.
> 
> Many thanks to the authors for writing this draft.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : OPSAWG [mailto:[email-masked]] De la part de Tianran Zhou
> > Envoyé : vendredi 28 juillet 2017 05:06
> > À : [email-masked]
> > Cc : [email-masked]
> > Objet : [OPSAWG] WG LC for Service Models Explained
> >
> > Dear OPSAWG,
> >
> > This is a notice to start a three-week OPSAWG WG last call for the
> > document:
> >
> > Service Models Explained
> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-
> > explained/
> >
> > Please read the above draft and send any issues, comments, or corrections
> > to this mailing list.
> > Please indicate your support or concerns by Friday August 18, 2017.
> >
> > Authors:
> > Although this is an informational document, please indicate with an email
> > on the mailing list explicitly whether you are aware or you are not aware
> > of any IPRs related to the drafts.
> >
> >
> > Thanks,
> > Tianran, as co-chair
> >
> > _______________________________________________
> > OPSAWG mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 18 Aug 2017 01:06:02 +0000

Hi Authors,

We got pretty good suggestions and comments during the LC.
Could you please improve the document and send to the community?

Cheers,
Tianran

> From: OPSAWG [mailto:[email-masked]] On Behalf Of Tianran Zhou
> Sent: Friday, July 28, 2017 11:06 AM
> To: [email-masked]
> Subject: [OPSAWG] WG LC for Service Models Explained
> 
> Dear OPSAWG,
> 
> This is a notice to start a three-week OPSAWG WG last call for the document:
> 
> Service Models Explained
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-expla
> ined/
>

---

From: Qin Wu <[email-masked]>
Date: Fri, 18 Aug 2017 01:14:44 +0000

-----邮件原件-----
发件人: OPSAWG [mailto:[email-masked]] 代表 Tianran Zhou
发送时间: 2017年7月28日 11:06
收件人: [email-masked]
抄送: [email-masked]
主题: [OPSAWG] WG LC for Service Models Explained

Dear OPSAWG,

Service Models Explained
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/

Please read the above draft and send any issues, comments, or corrections to this mailing list.
Please indicate your support or concerns by Friday August 18, 2017.

Authors: 
Although this is an informational document, please indicate with an email on the mailing list explicitly whether you are aware or you are not aware of any IPRs related to the drafts.

[Qin]: Receive kindly reminder from chairs recently, thanks. here I confirm that we have no IPR and also we are not aware of any IPRs related to this draft.

Thanks,
Tianran, as co-chair

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Aug 2017 09:32:32 +0100

> Authors:
> Although this is an informational document, please indicate with an email on
the
> mailing list explicitly whether you are aware or you are not aware of any IPRs
> related to the drafts.
> 
> [Qin]: Receive kindly reminder from chairs recently, thanks. here I confirm
that
> we have no IPR and also we are not aware of any IPRs related to this draft.

Not sure whether I responded. Anyway...

No, I am not aware of any IPR related to this draft.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Aug 2017 20:27:30 +0100

Hi Med,

Thanks again for your review. I'm just in the process of updating the draft and
wanted to let you know what changes I'm making.

> - Remove RFC7426 and RFC8049 from the normative references. Those are cited

Yes. No problem with that.

>    construct data models to model devices or monolithic functions and

OK

> * Please cite RFC7149 in addition to [RFC7426] to have both IETF and IRTF

OK

>    YANG data models may be used on Southbound Interfaces (SBIs) between

OK

> Or change s/Recently/Recently (as per 2017)

Yeah, you're right. Don't need temporal commentary.

> * s/ Customer- Provider Interface/Customer-Provider Interface

Wow! That's careful reading!
(That was an XML2RFC bug)

> s/i.e., routers or switches/e.g., routers or switches

I think we really meant "i.e."

> This is shown simply in Figure 1.

Ack

> The IETF uses the YANG data modeling language defined in [RFC6020].

Ack

> Figure 1 of [RFC7491] shows an interface between...

OK

> Do you mean: those are not mandatory features to be included in a service

Well, I think the point is that these features are not part of this service
model, and for the reason that they are not the sort of thing that service
provides will agree about.

>    as described in this document.

Yes. I have made some edits through the text for this.

Thanks again for your careful reading.

I hope this addresses your points.

Adrian