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

["Adrian Farrel" <[e-mail]>]

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:[e-mail]]
> Sent: 09 August 2017 10:39
> To: [e-mail]; 'Tianran Zhou'; [e-mail]
> Cc: [e-mail]
> 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): [phone]
> Mobile: [phone]
> [e-mail]
> 
> 
> -----Mensaje original-----
> De: OPSAWG [mailto:[e-mail]] En nombre de Adrian Farrel
> Enviado el: viernes, 16 de junio de 2017 16:19
> Para: 'Tianran Zhou' <[e-mail]>; [e-mail]
> CC: [e-mail]
> 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:[e-mail]] On Behalf Of Tianran
> > Zhou
> > Sent: 05 June 2017 02:55
> > To: [e-mail]
> > Cc: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> 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