Re: [OPSAWG] WG LC for Service Models Explained

[<[e-mail]>]

Thanks Adrian, all good. 

BR, Dan. 

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: 02 August 2017 13:29
To: [e-mail]; [e-mail]
Subject: RE: [OPSAWG] WG LC for Service Models Explained

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