Subject: Re: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-explained-06

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 9 Aug 2017 09:38:54 +0000

Hi Adrian, all,

I have been able to work on the review after holidays. Apologies for the delay in providing it. Please, find here below my comments and suggestions. If something is not clear ta all, please, let me know.

*Specific comments*

- There are several sentences along the document trying to define the scope of service model in the context of IETF. These are: (1) in Terms and Concepts, for Service, "... A service in the context of this document (sometimes called a Network Service) is some form of connectivity between customer sites and the Internet, or between customer sites across the network operator's network and across the Internet"; (2) section 5, first bullet, "The services we are discussing are services provided by network operators to customers ... network operators may offer value-added services as well as network connection services to their customers.";  (3) section 6.4, "The IETF's work on service models is typically smaller offering a simple, self-contained service YANG module".
Since in the abstract it is stated that "This document briefly sets out the scope of and purpose of an IETF service model", probably the best would be to include at the very beginning a clear sentence with such definition, in order to focus the reader.

- In abstract: "... details of how network protocols and devices are engineered to deliver a service are captured in other models that are not exposed through the Customer-Provider Interface" <-- Thinking on recursiveness, the Customer-Provide Interface can require low-level details or models. In other words, when a Network Operator is Customer of another Network Operator, what kind of interface would you consider for that relationship?

- Figure 2: in contrast with Figure 3, where would be positioned here the Service Delivery models? Should it be assumed a collapse of functionality in the Orchestrator of Fig. 2 including both Service and Network Orchestrator? Would be those models internal? Maybe it could be convenient to reflect also in Fig. 2 both Service Delivery and Network Configuration models, for consistency.

- In section 4, below Fig. 2: "This means that the service request must be mapped to the orchestrator's view, and this mapping may include a choice of which networks and technologies to use depending on which service features have been requested." < -- Such mapping is performed by the Orchestrator itself, right? So maybe the sentence can be rephrased (e.g., ... the service request must be mapped by the orchestrator ...).

- Figure 3. The Customer Service model in segment (a) would be probably something else than a connectivity/transport service, even though parts of such service request are out of scope of IETF. I mean, e.g. a Network Service Descriptor in NFV. So the Service Orchestrator purpose can be broader than what is the scope of IETF. This can be maybe clarified.

- Figure 3. As part of the figure or in the text description, it would be nice to have hints about how recursiveness or east/west relationships (for multiple administrative domains) are mapped to model categories here.

- Section 5, bullets about Commercial terms and SLAs. Maybe it can be convenient to explicitly say that they are out of the scope. It is mentioned that is hard to standardize this, but no assertive indication if both are out of the scope.

- Section 6: "... interface between the Service Orchestrator or OSS/BSS ...". Does it apply as well to Fig. 3? If so, maybe it would be nice also to include in Fig. 3 for consistency.

- Figure 4. I think that the figure it is not clear at all. There is a mix of functional elements (e.g. Service Orchestrator, OSS/BSS) with models. Probably a more homogeneous figure could be better.

- Section 6.2: it would be nice to make clear what of the sample models can be categorized as Service Delivery model, and what of them can be categorized as network Element (or device) models.

- MEF work is mentioned in section 6.4. I think it would be necessary to cover/describe some other initiatives like the one of ETSI NFV with respect to Network Service Descriptors.

- Section 6.4: "This does not invalidate either approach, but only observes that they are different." More than different, MEF as described here is broader in scope. Maybe the sentence can be rephrased in this sense.

- Section 7.2: it is not clear if policies are considered or not as part of the scope of the customer service models. Difficulties on identifying common policies for the operators are mentioned. But similar situation is also mentioned in section 7.3 with the result of identifying common parametrization after working on it. So maybe it can be mentioned that such kind of work is required, instead of not covering policies at all.

- Section 8: the interface between Service Orchestrator and Network Orchestrator can be also external, and then security measures should be applied.

- Section 9, last paragraph: Reporting is essential for SLAs (monitoring) and accounting / billing (resource usage). But it seems (as mentioned before in the document) that commercial terms and SLAs are not part of the customer service models. Then, if reporting is included as part of the customer service model, as suggested by this paragraph, it is apparently inconsistent with the fact of not having the ways of requesting SLAs and billing, but having the necessary information for that being reported (in other words, how can I express what information is of interest for me if I cannot express SLAs or commercial terms?).

*Editorial comments*

- In abstract: RFC 8049 should be included between brackets.

- In section 2, Terms and concepts: for Network Operator -> it is mentioned that "The term is also used to refer to an individual who performs operations and management on those networks." <-- Since it is not used with this meaning in the text, I would remove that clarification to avoid ambiguity.

- In section 2, Terms and concepts: for Data Model -> the following sentence seems to be editorial, maybe it can be removed: "so it may be helpful to quote some text to give context within this document."

- Section 6.2 < -- Probably it would be better to separate Service Delivery from Network Element models in different sections, with sample models referred

- Same section. Network Element model is introduced here for 1st time. In figure 3 it is referred as device configuration model. It would be better to have an homogeneous naming.

- Section 9, first sentence: "... related to network management." -> "... related to network management and control."

Best regards

Luis

__________________________________
Luis M. Contreras

Technology and Planning
Transport, IP and Interconnection Networks
Telefónica I+D / Global CTO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Skype (Lync): +34 91 312 9084
Mobile: +34 680 947 650
[email-masked]

-----Mensaje original-----
De: OPSAWG [mailto:[email-masked]] En nombre de Adrian Farrel
Enviado el: viernes, 16 de junio de 2017 16:19
Para: 'Tianran Zhou' <[email-masked]>; [email-masked]
CC: [email-masked]
Asunto: Re: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-explained-06

Of course, I support the WG working on this :-)

The offer of a review from Luis is gratefully accepted. That will make for a nice first revision inside the WG.

Joe. Yes, I'd be interested to hear what other's think about your point, and to add text to clarify the issue.

Cheers,
Adrian

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Tianran
> Zhou
> Sent: 05 June 2017 02:55
> To: [email-masked]
> Cc: [email-masked]
> Subject: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-
> explained-06
>
> Dear OPSAWG,
>
> In Seoul, we got enough interest and positive response on this service
> models explained draft.
> By the authors' request, this email starts a formal poll. The chairs
> would
like to
> know if the WG participants agree that the following document should
> be adopted as a WG document in OPSAWG.
>
> Service Models Explained
> https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explain
> ed/
>
> The adoption poll will take two weeks. Please let us know your opinion
> by June 19. It would also be good to hear who is willing to review this document.
>
> Since we already found that the majority of the f2f participants at
> our IETF97 session like this idea, please do speak up now if you do
> not agree or have
serious
> objections (with explanation of course).
>
> Regards,
> Tianran,  OPSAWG 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

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 9 Aug 2017 13:33:43 +0100

Luis thanks very much indeed for such a thorough and thoughtful review.

We'll come back to you with detailed responses SOON.

Cheers,
Adrian
--
Support an author and your imagination
Tales from the Wood - Eighteen new fairy tales
More Tales from the Wood - Eighteen MORE new fairy tales
Coming soon - Tales from Beyond the Wood
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.

> From: LUIS MIGUEL CONTRERAS MURILLO
> [mailto:[email-masked]]
> Sent: 09 August 2017 10:39
> To: [email-masked]; 'Tianran Zhou'; [email-masked]
> Subject: RE: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-
> explained-06
> 
> Hi Adrian, all,
> 
> I have been able to work on the review after holidays. Apologies for the delay
in
> providing it. Please, find here below my comments and suggestions. If
something
> is not clear ta all, please, let me know.
> 
> *Specific comments*
> 
> - There are several sentences along the document trying to define the scope of
> service model in the context of IETF. These are: (1) in Terms and Concepts,
for
> Service, "... A service in the context of this document (sometimes called a
> Network Service) is some form of connectivity between customer sites and the
> Internet, or between customer sites across the network operator's network and
> across the Internet"; (2) section 5, first bullet, "The services we are
discussing are
> services provided by network operators to customers ... network operators may
> offer value-added services as well as network connection services to their
> customers.";  (3) section 6.4, "The IETF's work on service models is typically
> smaller offering a simple, self-contained service YANG module".
> Since in the abstract it is stated that "This document briefly sets out the
scope of
> and purpose of an IETF service model", probably the best would be to include
at
> the very beginning a clear sentence with such definition, in order to focus
the
> reader.
> 
> - In abstract: "... details of how network protocols and devices are
engineered to
> deliver a service are captured in other models that are not exposed through
the
> Customer-Provider Interface" <-- Thinking on recursiveness, the Customer-
> Provide Interface can require low-level details or models. In other words,
when a
> Network Operator is Customer of another Network Operator, what kind of
> interface would you consider for that relationship?
> 
> - Figure 2: in contrast with Figure 3, where would be positioned here the
Service
> Delivery models? Should it be assumed a collapse of functionality in the
> Orchestrator of Fig. 2 including both Service and Network Orchestrator? Would
> be those models internal? Maybe it could be convenient to reflect also in Fig.
2
> both Service Delivery and Network Configuration models, for consistency.
> 
> - In section 4, below Fig. 2: "This means that the service request must be
mapped
> to the orchestrator's view, and this mapping may include a choice of which
> networks and technologies to use depending on which service features have
> been requested." < -- Such mapping is performed by the Orchestrator itself,
> right? So maybe the sentence can be rephrased (e.g., ... the service request
must
> be mapped by the orchestrator ...).
> 
> - Figure 3. The Customer Service model in segment (a) would be probably
> something else than a connectivity/transport service, even though parts of
such
> service request are out of scope of IETF. I mean, e.g. a Network Service
> Descriptor in NFV. So the Service Orchestrator purpose can be broader than
what
> is the scope of IETF. This can be maybe clarified.
> 
> - Figure 3. As part of the figure or in the text description, it would be nice
to have
> hints about how recursiveness or east/west relationships (for multiple
> administrative domains) are mapped to model categories here.
> 
> - Section 5, bullets about Commercial terms and SLAs. Maybe it can be
> convenient to explicitly say that they are out of the scope. It is mentioned
that is
> hard to standardize this, but no assertive indication if both are out of the
scope.
> 
> - Section 6: "... interface between the Service Orchestrator or OSS/BSS ...".
Does
> it apply as well to Fig. 3? If so, maybe it would be nice also to include in
Fig. 3 for
> consistency.
> 
> - Figure 4. I think that the figure it is not clear at all. There is a mix of
functional
> elements (e.g. Service Orchestrator, OSS/BSS) with models. Probably a more
> homogeneous figure could be better.
> 
> - Section 6.2: it would be nice to make clear what of the sample models can be
> categorized as Service Delivery model, and what of them can be categorized as
> network Element (or device) models.
> 
> - MEF work is mentioned in section 6.4. I think it would be necessary to
> cover/describe some other initiatives like the one of ETSI NFV with respect to
> Network Service Descriptors.
> 
> - Section 6.4: "This does not invalidate either approach, but only observes
that
> they are different." More than different, MEF as described here is broader in
> scope. Maybe the sentence can be rephrased in this sense.
> 
> - Section 7.2: it is not clear if policies are considered or not as part of
the scope of
> the customer service models. Difficulties on identifying common policies for
the
> operators are mentioned. But similar situation is also mentioned in section
7.3
> with the result of identifying common parametrization after working on it. So
> maybe it can be mentioned that such kind of work is required, instead of not
> covering policies at all.
> 
> - Section 8: the interface between Service Orchestrator and Network
> Orchestrator can be also external, and then security measures should be
applied.
> 
> - Section 9, last paragraph: Reporting is essential for SLAs (monitoring) and
> accounting / billing (resource usage). But it seems (as mentioned before in
the
> document) that commercial terms and SLAs are not part of the customer service
> models. Then, if reporting is included as part of the customer service model,
as
> suggested by this paragraph, it is apparently inconsistent with the fact of
not
> having the ways of requesting SLAs and billing, but having the necessary
> information for that being reported (in other words, how can I express what
> information is of interest for me if I cannot express SLAs or commercial
terms?).
> - In section 2, Terms and concepts: for Network Operator -> it is mentioned
that
> "The term is also used to refer to an individual who performs operations and
> management on those networks." <-- Since it is not used with this meaning in
the
> text, I would remove that clarification to avoid ambiguity.
> 
> - In section 2, Terms and concepts: for Data Model -> the following sentence
> seems to be editorial, maybe it can be removed: "so it may be helpful to quote
> some text to give context within this document."
> 
> - Section 6.2 < -- Probably it would be better to separate Service Delivery
from
> Network Element models in different sections, with sample models referred
> 
> - Same section. Network Element model is introduced here for 1st time. In
figure
> 3 it is referred as device configuration model. It would be better to have an
> homogeneous naming.
> 
> - Section 9, first sentence: "... related to network management." -> "...
related to
> network management and control."
> 
> 
> Best regards
> 
> Luis
> 
> The offer of a review from Luis is gratefully accepted. That will make for a
nice
> first revision inside the WG.
> 
> Joe. Yes, I'd be interested to hear what other's think about your point, and
to add
> text to clarify the issue.
> 
> Cheers,
> Adrian
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede
> contener información privilegiada o confidencial y es para uso exclusivo de la
> persona o entidad de destino. Si no es usted. el destinatario indicado, queda
> notificado de que la lectura, utilización, divulgación y/o copia sin
autorización
> puede estar prohibida en virtud de la legislación vigente. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por esta
> misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is privileged and confidential
> information intended only for the use of the individual or entity named above.
If
> the reader of this message is not the intended recipient, you are hereby
notified
> that any dissemination, distribution or copying of this communication is
strictly
> prohibited. If you have received this transmission in error, do not read it.
Please
> immediately reply to the sender that you have received this communication in
> error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo da
> pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
indicado,
> fica notificado de que a leitura, utilização, divulgação e/ou cópia sem
autorização
> pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem
> por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via
> e proceda a sua destruição

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 23 Aug 2017 16:28:21 +0100

Hey Luis,

As we are updating the draft for last call comment, here are responses to your
comments.

for
discussing are
scope of
at
the
> reader.

OK. That is easy to add.

      In summary, a service model is a formal representation of the data
elements
      that describe a network service as that service is described to or
requested 
      by a customer of a network operator.  Details included in the service
model
      include a description of the service as experienced by the customer, but
not
      features of how that service is delivered or realized by the service
provider.

engineered to
the
when a
> interface would you consider for that relationship?

For me, recursion does not add detail. So, a network operator that engages with
another network operator as a customer could do so exactly using the service
model.

If the relationship is internal to a commercial organisation then it is possible
that the interface will be more transparent.

It is also true that if the recursion happens lower down (e.g., at the service
delivery interface) then more details are exposed.

I don't believe that any of this has direct bearing on this document, but I can
see that there may be space for more architectural debate about how SDN systems
are constructed. MEF, ETSI, and TMF seem to be having this sort of discussion.

Service
2
> both Service Delivery and Network Configuration models, for consistency.

I think that is exactly the point. The "traditional" SDN approach shown in
Figure 2 makes it hard to place these different models in context, so we
introduce an extended view in Figure 3.

mapped
must
> be mapped by the orchestrator ...).

Yeah. OK.

such
what
> is the scope of IETF. This can be maybe clarified.

It is true that there is a broader architectural picture sitting behind this.
One that includes the NFV features and might be modeled after the ETSI NFV work.
As you note, those features are out of scope of the IETF. And this document is
quite clear that its scope is to discuss the IETF's use of service models.

As I said above, I can see that there may be space for a document discussing a
wider architecture. That would probably not be an IETF document, but it could go
to the NFVRG.

to have
> administrative domains) are mapped to model categories here.

The L3SM work talks a little about multi-operator service delivery, but this is
handled in a relatively simplistic way because the interface between operators
is a complex commercial relationship and the involvement of customers in that
relationship is beyond complex.

I think we can talk about a multi-network solution where those networks are all
under the control of one service provider. And I think this document does that
OK (although I'd be happy to hear specific suggestions for improvement) by the
text you suggested to be modified, above.

   The orchestrator must map the service 
   request to its view, and this mapping may include a choice of which
   networks and technologies to use depending on which service features
   have been requested.

This, of course, does not speak to an east/west relationship, but to a
coordinated north/south relationship.

that is
scope.

Yes. Good idea.
Added text to both bullets.

Does
Fig. 3 for
> consistency.

This is already shown in Figure 3. Perhaps something is not clear in that figure
do we will add a second label (b) on the communication between OSS/BSS and
Network Orchestrator.

functional
> homogeneous figure could be better.

Figure 4 comes from RFC 8199 (with only minor modifications) and is not in scope
for us to change.
Probably gets clearer with several readings of RFC 8199 which is a normative
reference.

> network Element (or device) models.

:-)

No, I don't plan to walk into that minefield!

Well, not in this document that is not actually about either of those categories
of model. In fact, the reason why we grouped all of these models into one
section was because we didn't see rapid convergence (even among the authors of
those documents) and didn't want to get distracted from the purpose of this
document.

> Network Service Descriptors.

In earlier revisions of this draft we had a lot more text about the MEF
architecture and made attempts to compare and draw some parallels. But over time
we discovered that that wasn't so easy so we collapsed the section into
something quite simple that gives the reference and states that the approaches
fill a similar space but are different.

We could easily include a similar section on ETSI NFV, but:

- Someone else would have to write it as I'm not familiar with that work
- I am very cautious about attempting to reach completeness with regard to all
other approaches. Fundamentally, we are writing about IETF service models.

that
> scope. Maybe the sentence can be rephrased in this sense.

You can't be "more than different". The text already summarises the breadth of
scope of the MEF work and says that "the IETF's work on service models is
typically smaller offering a simple, self-contained service YANG module".

I think that this cover the point you wanted made and that we don't want to get
into any further comparison.

the scope of
the
7.3
> covering policies at all.

Right. Like the bullets in Section 5 that you mentioned, this will be clarified.

applied.

Agreed.

the
as
not
terms?).

You're right. Monitoring information is on a similar level to SLA description
(although personally I've never quite trusted the service provider's reports of
performance as evidence that they are meeting the SLA :-).

This text needs to be treated the same way as the bullet you pointed to in
section 5, and we'll do that.

> - In abstract: RFC 8049 should be included between brackets.

Well, actually, no. There should be no citations in an Abstract because that
piece of text must be able to stand alone.

that
the
> text, I would remove that clarification to avoid ambiguity.

Could catch. And we previously fixed the ambiguity by saying "human operator"
when we needed to.

> some text to give context within this document."

Yup.

from
> Network Element models in different sections, with sample models referred

As above. The authors really don't want to go there.

figure
> 3 it is referred as device configuration model. It would be better to have an

Well, "Network Element model" shows in 6.1 and comes from RFC 8199.
"Device models" comes from draft-ietf-l2sm-l2vpn-service-model.

So we're stuck with both terms, but I've added text to help with the terminology
mapping.

related to
> network management and control."

OK

Many thanks for your really helpful review.

Adrian

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 28 Aug 2017 14:50:39 +0000

Hi Adrian,

Sorry for my late response. Thanks for the clarifications. They are fine to me.

Best regards

Luis

-----Mensaje original-----
De: Adrian Farrel [mailto:[email-masked]]
Enviado el: miércoles, 23 de agosto de 2017 17:28
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; 'Tianran Zhou' <[email-masked]>; [email-masked]
CC: [email-masked]
Asunto: RE: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-explained-06

Hey Luis,

As we are updating the draft for last call comment, here are responses to your comments.

> *Specific comments*
>
> - There are several sentences along the document trying to define the
> scope of service model in the context of IETF. These are: (1) in Terms
> and Concepts,
for
> Service, "... A service in the context of this document (sometimes
> called a Network Service) is some form of connectivity between
> customer sites and the Internet, or between customer sites across the
> network operator's network and across the Internet"; (2) section 5,
> first bullet, "The services we are
discussing are
> services provided by network operators to customers ... network
> operators may offer value-added services as well as network connection
> services to their customers.";  (3) section 6.4, "The IETF's work on
> service models is typically smaller offering a simple, self-contained service YANG module".
scope of
at
the

OK. That is easy to add.

      In summary, a service model is a formal representation of the data elements
      that describe a network service as that service is described to or requested
      by a customer of a network operator.  Details included in the service model
      include a description of the service as experienced by the customer, but not
      features of how that service is delivered or realized by the service provider.

engineered to
the
> Customer-Provider Interface" <-- Thinking on recursiveness, the
> Customer- Provide Interface can require low-level details or models.
> In other words,
when a
> interface would you consider for that relationship?

For me, recursion does not add detail. So, a network operator that engages with another network operator as a customer could do so exactly using the service model.

If the relationship is internal to a commercial organisation then it is possible that the interface will be more transparent.

It is also true that if the recursion happens lower down (e.g., at the service delivery interface) then more details are exposed.

I don't believe that any of this has direct bearing on this document, but I can see that there may be space for more architectural debate about how SDN systems are constructed. MEF, ETSI, and TMF seem to be having this sort of discussion.

Service
> Delivery models? Should it be assumed a collapse of functionality in
> the Orchestrator of Fig. 2 including both Service and Network
> Orchestrator? Would be those models internal? Maybe it could be convenient to reflect also in Fig.
2
> both Service Delivery and Network Configuration models, for consistency.

I think that is exactly the point. The "traditional" SDN approach shown in Figure 2 makes it hard to place these different models in context, so we introduce an extended view in Figure 3.

mapped
> to the orchestrator's view, and this mapping may include a choice of
> which networks and technologies to use depending on which service
> features have been requested." < -- Such mapping is performed by the
> Orchestrator itself, right? So maybe the sentence can be rephrased
> (e.g., ... the service request
must

Yeah. OK.

> - Figure 3. The Customer Service model in segment (a) would be
> probably something else than a connectivity/transport service, even
> though parts of
such
> service request are out of scope of IETF. I mean, e.g. a Network
> Service Descriptor in NFV. So the Service Orchestrator purpose can be
> broader than
what

It is true that there is a broader architectural picture sitting behind this.
One that includes the NFV features and might be modeled after the ETSI NFV work.
As you note, those features are out of scope of the IETF. And this document is quite clear that its scope is to discuss the IETF's use of service models.

As I said above, I can see that there may be space for a document discussing a wider architecture. That would probably not be an IETF document, but it could go to the NFVRG.

to have
> administrative domains) are mapped to model categories here.

The L3SM work talks a little about multi-operator service delivery, but this is handled in a relatively simplistic way because the interface between operators is a complex commercial relationship and the involvement of customers in that relationship is beyond complex.

I think we can talk about a multi-network solution where those networks are all under the control of one service provider. And I think this document does that OK (although I'd be happy to hear specific suggestions for improvement) by the text you suggested to be modified, above.

This, of course, does not speak to an east/west relationship, but to a coordinated north/south relationship.

that is
scope.

Yes. Good idea.

Does
Fig. 3 for
> consistency.

This is already shown in Figure 3. Perhaps something is not clear in that figure do we will add a second label (b) on the communication between OSS/BSS and Network Orchestrator.

functional
> elements (e.g. Service Orchestrator, OSS/BSS) with models. Probably a
> more homogeneous figure could be better.

Figure 4 comes from RFC 8199 (with only minor modifications) and is not in scope for us to change.
Probably gets clearer with several readings of RFC 8199 which is a normative reference.

> - Section 6.2: it would be nice to make clear what of the sample
> models can be categorized as Service Delivery model, and what of them
> can be categorized as network Element (or device) models.

:-)

Well, not in this document that is not actually about either of those categories of model. In fact, the reason why we grouped all of these models into one section was because we didn't see rapid convergence (even among the authors of those documents) and didn't want to get distracted from the purpose of this document.

> - MEF work is mentioned in section 6.4. I think it would be necessary
> to cover/describe some other initiatives like the one of ETSI NFV with
> respect to Network Service Descriptors.

In earlier revisions of this draft we had a lot more text about the MEF architecture and made attempts to compare and draw some parallels. But over time we discovered that that wasn't so easy so we collapsed the section into something quite simple that gives the reference and states that the approaches fill a similar space but are different.

- Someone else would have to write it as I'm not familiar with that work
- I am very cautious about attempting to reach completeness with regard to all other approaches. Fundamentally, we are writing about IETF service models.

that
> they are different." More than different, MEF as described here is
> broader in scope. Maybe the sentence can be rephrased in this sense.

You can't be "more than different". The text already summarises the breadth of scope of the MEF work and says that "the IETF's work on service models is typically smaller offering a simple, self-contained service YANG module".

I think that this cover the point you wanted made and that we don't want to get into any further comparison.

the scope of
the
7.3
> with the result of identifying common parametrization after working on
> it. So maybe it can be mentioned that such kind of work is required,
> instead of not covering policies at all.

applied.

Agreed.

> - Section 9, last paragraph: Reporting is essential for SLAs
> (monitoring) and accounting / billing (resource usage). But it seems
> (as mentioned before in
the
> document) that commercial terms and SLAs are not part of the customer
> service models. Then, if reporting is included as part of the customer
> service model,
as
not
> having the ways of requesting SLAs and billing, but having the
> necessary information for that being reported (in other words, how can
> I express what information is of interest for me if I cannot express
> SLAs or commercial
terms?).

You're right. Monitoring information is on a similar level to SLA description (although personally I've never quite trusted the service provider's reports of performance as evidence that they are meeting the SLA :-).

This text needs to be treated the same way as the bullet you pointed to in section 5, and we'll do that.

> - In abstract: RFC 8049 should be included between brackets.

Well, actually, no. There should be no citations in an Abstract because that piece of text must be able to stand alone.

that
> "The term is also used to refer to an individual who performs
> operations and management on those networks." <-- Since it is not used
> with this meaning in
the

> - In section 2, Terms and concepts: for Data Model -> the following
> sentence seems to be editorial, maybe it can be removed: "so it may be
> helpful to quote some text to give context within this document."

Yup.

from

figure
> 3 it is referred as device configuration model. It would be better to
> have an homogeneous naming.

So we're stuck with both terms, but I've added text to help with the terminology mapping.

related to

OK

Adrian