Re: [OPSAWG] WG LC for Service Models Explained

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

Dan, thanks!

> Comment #1 - The current abstract could be simmered down to:
> 
> The IETF has produced a number of data modules in the  YANG modelling
> language.  The majority of these modules are used to construct data models
> to model devices or monolithic functions.
> 
> A small number of YANG modules have been defined to model services (for
> example, the Layer Three Virtual Private Network Service Model produced by
> the L3SM working group and documented in RFC 8049).
> 
> This document describes the role of an IETF service model, and where a
> service model might fit into a Software Defined Networking architecture.
> Note that service models do not make any assumption of how a service is
> engineered and delivered to the customer; 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.

OK. Appreciate reducing the Abstract. Most changes good. Some "not far enough".
But I would like to keep the mention of config and operational status.

So...

   The IETF has produced a number of data modules in the YANG modelling
   language.  The majority of these are used to construct data models to
   model devices or monolithic functions and they allow access for 
   configuration and to read operational status.

   A small number of YANG modules have been defined to model services
   (for example, the Layer Three Virtual Private Network Service Model
   documented in RFC 8049).

   This document describes the role of an IETF service model, and shows
   where a service model fits into a Software Defined Networking architecture.
   Note that service models do not make any assumption of how a service is
   engineered and delivered for a customer; 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.

> Comment #2 - A mix of "modelling" and "modeling" usage in the document.
> British or American is fine, but maybe not both.

Oh, yes. Fixing.

> Comment #3 - Section 1. Introduction, second paragraph, last sentence:
> ""There may also be a hierarchy of such components with super-controllers,
> domain controllers, and device controllers all exchanging information and
> instructions using YANG models"
> 
> The only reference to "super-controller" I found (using a popular search
> engine) was an accessory for the Nintendo Entertainment System video game
> console. Maybe the authors might want to use the term "super controller".

Isn't the Super Controller a character in Guardians of the Galaxy?

> Comment #4 - Section 1. Introduction, third paragraph, last sentence:
> "Ultimately they could be used in online, software-driven dynamic systems."
> 
> Why not use the term "software defined networks" or "SDN systems", instead
> of "online, software-driven dynamic systems". You use the term "software
> defined networks" in the abstract and earlier in the introductory text, and
> again in section 4.

Yes. Actually we should say both since "online, software-driven dynamic systems"
is only a step on the path to SDN. Hence...

   Such models may be used in manual and even paper-driven
   service request processes with a gradual transition to IT-based
   mechanisms.  Ultimately they could be used in online, software-driven
   dynamic systems, and eventually as part of an SDN system.

> Comment #5 - Section 3. Using Service Models, third paragraph, last
> sentence:
> 
> "However, co-located software components might use an API, while systems
> with more direct human interactions might use web pages or even paper
> forms."
> 
> Indeed RFC6241 and RFC8040 are data-model/schema-driven APIs. Should the
> sentence read ("internal API" or "private API"), as in:
> 
> "However, co-located software components might use an internal API, while
> systems with more direct human interactions might use web pages or even
> paper forms."

O tempera, o mores.

Once upon a time there were APIs and remote APIs (which weren't really APIs at
all but rather a communications library accessed via an API and delivering
remotely via another API). But language is a living medium :-)

I don't object to "internal API".

> Comment #6 - The document uses capitalised and non-capitalised instances of
> "Control Plane".

Ack

> Comment #9 - Section 9. Manageability Considerations
> 
> You use the term "Service Orchestration" in this section but I found no
> reference, or previous definition, in the document.

Figure 3 introduces the "Service Orchestrator". Do you think we should add more
text to explain its function?

> Overall, really minor NITs. Good job with the document.

Thanks.
All nits are good nits.

Adrian