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 luismiguel.contrerasmuri...@telefonica.com -----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 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: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 serious > 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 OPSAWG@ietf.org 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 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
