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

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

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
Or buy from me direct.

> -----Original Message-----
> []
> Sent: 09 August 2017 10:39
> To:; 'Tianran Zhou';
> Cc:
> 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
> providing it. Please, find here below my comments and suggestions. If
> 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,
> 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
> the very beginning a clear sentence with such definition, in order to focus
> 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
> 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
> 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.
> both Service Delivery and Network Configuration models, for consistency.
> - In section 4, below Fig. 2: "This means that the service request must be
> 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
> 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
> 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
> 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
> - Section 6: "... interface between the Service Orchestrator or OSS/BSS ...".
> 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
> 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
> 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
> operators are mentioned. But similar situation is also mentioned in section
> 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
> - Section 9, last paragraph: Reporting is essential for SLAs (monitoring) and
> accounting / billing (resource usage). But it seems (as mentioned before in
> 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,
> suggested by this paragraph, it is apparently inconsistent with the fact of
> 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
> "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
> 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
> Network Element models in different sections, with sample models referred
> - Same section. Network Element model is introduced here for 1st time. In
> 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
> -----Mensaje original-----
> De: OPSAWG [] En nombre de Adrian Farrel
> Enviado el: viernes, 16 de junio de 2017 16:19
> Para: 'Tianran Zhou' <>;
> CC:
> 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
> 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 [] On Behalf Of Tianran
> > Zhou
> > Sent: 05 June 2017 02:55
> > To:
> > Cc:
> > 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
> >
> > 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
> >
> >
> _______________________________________________
> 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
> 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.
> the reader of this message is not the intended recipient, you are hereby
> that any dissemination, distribution or copying of this communication is
> prohibited. If you have received this transmission in error, do not read it.
> 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
> fica notificado de que a leitura, utilização, divulgação e/ou cópia sem
> 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