Subject: Re: [OPSAWG] WG LC for Service Models Explained

From: <[email-masked]>
Date: Sun, 30 Jul 2017 22:14:39 +0300

Hi Authors, 

Overall a really useful document, and I enjoyed reading and commenting on
the various iterations. I support publication. 

Please find below are some final minor Comment(s) #n:

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.

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

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".

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. 

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."

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

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.

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

BR, Dan.

> -----Massage d'orange-----
> De : OPSAWG [mailto:[email-masked]] De la part de Tianran Zhou
> Envoyé : vendredi 28 juillet 2017 05:06
> À : mailto:[email-masked]
> Cc : mailto:[email-masked]
> Objet : [OPSAWG] WG LC for Service Models Explained
> 
> Dear OPSAWG,
> 
> This is a notice to start a three-week OPSAWG WG last call for the
> document:
> 
> Service Models Explained
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-
> explained/
> 
> Please read the above draft and send any issues, comments, or corrections
> to this mailing list.
> Please indicate your support or concerns by Friday August 18, 2017.
> 
> Authors:
> Although this is an informational document, please indicate with an email
> on the mailing list explicitly whether you are aware or you are not aware
> of any IPRs related to the drafts.
> 
> 
> Thanks,
> Tianran, as co-chair
> 
> _______________________________________________
> OPSAWG mailing list
> mailto:[email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg