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. > -----Original Message----- > From: LUIS MIGUEL CONTRERAS MURILLO > [mailto:luismiguel.contrerasmuri...@telefonica.com] > Sent: 09 August 2017 10:39 > To: adr...@olddog.co.uk; 'Tianran Zhou'; firstname.lastname@example.org > Cc: opsawg-cha...@ietf.org > 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?). > > *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>; email@example.com > 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: firstname.lastname@example.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