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 

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

-----Mensaje original-----
De: OPSAWG [mailto:opsawg-boun...@ietf.org] En nombre de Adrian Farrel
Enviado el: viernes, 16 de junio de 2017 16:19
Para: 'Tianran Zhou' <zhoutian...@huawei.com>; opsawg@ietf.org
CC: opsawg-cha...@ietf.org
Asunto: Re: [OPSAWG] WG adoption poll for 

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.


> -----Original Message-----
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran
> Zhou
> Sent: 05 June 2017 02:55
> To: opsawg@ietf.org
> Cc: opsawg-cha...@ietf.org
> 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
> objections (with explanation of course).
> Regards,
> Tianran,  OPSAWG Co-Chair
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

OPSAWG mailing list


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

OPSAWG mailing list

Reply via email to