Last Call Review of draft-ietf-opsawg-service-model-explained-03
review-ietf-opsawg-service-model-explained-03-rtgdir-lc-sinicrope-2017-10-05-00

Hello,
I have been selected as the Routing Directorate reviewer for draft:
​https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained<https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/>.
The Routing Directorate seeks to review all routing or routing-related drafts
as they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>
Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-opsawg-service-model-explained-03.txt
Reviewer: David Sinicrope
Review Date: 4 Oct 2017
IETF LC End Date: 27 Sep 2017
Intended Status: Informational
Summary:
This document is basically ready for publication, but has nits and some minor
issues that should be considered prior to publication.

Comments:
I found the document helpful and a good aid to those trying to get a grip on
the variety of modeling activities in the IETF.  The nits and minor comments
below are offered in an attempt to improve clarity and quality of the document.
 None of these comments are of high enough priority to block publication of the
document should they remain unresolved.

Minor Issues and Nits:

  *   Abstract: "... used within the IETF...". Wouldn't the document serve
  better to describe how the models could/are used by the industry including
  within SDN? Several of these models are used by other SDOs for their work in
  e.g., providing network architecture, equipment requirements, orchestration,
  OAM and management to support and provide the service. I would think that the
  matter of how these are used by the IETF would be much to narrow a view. *  
  Intro para 3, last sentences - This text dates itself. It would suffice to
  note that the models may be used in these environments regardless of the time
  frame. (e.g., drop “eventually) *   Intro para 5 last sentence - customer -
  Provider Interface needs a forward reference or brief definition. *   Intro
  para 6. - "described to" or "subscribed to"? *   Intro para 6 - does it
  describe the service or the attributes of the service. I'm not sure a service
  model describes the service operation.  Add the words "attributes of the" *  
  Sec 1, para 4 - “... within the IETF...” but the document also discusses the
  MEF. Need to make statement more general.

  *   Definition of Network Operator - change to read "... other network
  services." Not sure other non-network services are intended. *   Definition
  of Customer: suggest change “purchases” to “subscribes” *   Definition of
  Customer: Excludes residential customer... why? *   Definition of Service: -
  Would help to give titles of RFCs, but may not be aligned with conventions.

  *   Definition of Data Model: Refers to information model and relationships
  between managed objects.  Should it be just objects? *   Definition of
  Service model - in IETF it's a data model. In other groups? E.g., ITU? It
  could be an information model. *   Definition of Customer Service Model: Not
  sure example of order fulfillment system illustrates a human.  Is there a
  better example of a human consumer? *   Definition of Service model - "... a
  portable way". Portable way? or do you mean more agnostic to deployment
  architecture and equipment? *   Last para just before section 3. - while a
  service model as a whole may not be intended to be sent to network devices,
  parts of it may be sent to network equipment. This could be clarified. *  
  Sec 3, 2nd para - “... choice for whoever specifies the model.” And the next
  sentence notes the IETF. Is the choice that of the organization where the
  model is specified, the individuals specifying the model or some combination
  of both? *   Sec 3, para 1&2 - these two paragraphs don’t add to the
  discussion and distract from para 3 where the 
actual discussion starts. *  
  Sec 3, para 3, last sentence - “... direct human interaction...”. This
  crosses from implementation to business process and should be noted. Add a
  sentence to the effect of “Where direct human interaction comes into play,
  interface interactions may become realized via business practices and must
  account for some margin of error, thus raising the priority for automated,
  deterministic interfaces.” *   Figure 1 -move figure to the definition of
  customer service model *   Sec 3, para 8, last sentence - distinction of
  modules and models. Good description of modules, but needs to be contrasted
  vs models. *   Sec 3, para 7 –“ The practicality…”  these last two paragraphs
  highlight a debate and the different points of view. This is different from
  the “big picture” usage description in the paragraphs above. Subsections
  (e.g., “The Big Picture” and “Practically Speaking”) would help call out the
  transition in thinking & flow. *   Sec 4, heading or para 1, 1st sentence -
  “SDN” has been spelled out previously in the introduction but given the
  elementary level of explanation here, e.g., “controller”, it may be worth
  spelling it out again. *   Sec 4, para 2, 1st sentence - remove the “But” or
  clarify what the statement is contradicting or juxtaposing. *   Sec 4, para
  2, 2nd sentence “ That is,…” - This statement should be clarified. Inherently
  the technology available to deliver a service will influence the functions
  that a customer can request. E.g., an Ethernet connectivity service will be
  defined in terms of MAC addresses,etc. I think the point trying to be made
  here is that the underlying technology specific details should not, or to the
  lowest extent possible, be reflected in customer service requests. E.g., one
  should not have to specify switch or router ids, IP addresses or MAC
  addresses for a TV service. 
See section 7 of the document *   Sec 4, para 2
  & 3 - wouldn’t this point about a Service/Network split be true outside of
  the SDN context as well? Why would this be limited to SDN? *   Sec 4, Figure
  3 - could the figure show an orchestrator interacting directly to a network
  element? *   Sec 5, bullet 1 - In the terminology section, “Service” is
  defined as a connectivity service. For purposes of this document then it
  should not be confused with higher layer services. The “customer” for this
  definition *is* aware of technology specific parameters and constraints of
  the connectivity service they are subscribing to. The cause of the confusion,
  and this is an age old problem, is that “service” is a recursive term. That
  is, a consumer/client of one level of service (e.g., Ethernet connectivity)
  is the provider/server of another (e.g., Internet access) for higher layer
  use (e.g., TV service) 
Modeling methods (G.805) have been established to
  describe the client/server relationship. *   Sec 5, bullet 2 - “completely”
  -> might want to tone this down a bit, to accommodate exceptions noted
  elsewhere in the document. While kept to a minimum, network operation is not
  *completely* out of scope when discussing service between a customer and
  network operator. E.g., Part of a service could be routing of the connect to
  avoid geopolitical borders. (Noted on the very next page) another example is,
  Fault notification and protection mechanisms may be discussed. 
The statement
  here seems to contradict the definition of Customer Service Model in the
  terminology section where it states that “Except where specific technology
  details (such as encapsulations, or mechanisms applied on access links) are
  directly pertinent to the customer, customer service models are technology
  agnostic so that the customer does not have influence over or knowledge of
  how the network operator engineers the service.” 
Perhaps use “normally” vs
  “completely” *   Sec 5, bullet 2 - providing detail about how the service is
  offered could actually be considered a security 
vulnerability. *   Sec 5,
  bullet 4 - give some examples of “commercial terms”. *   Sec 5, bullet 5 -
  give an example of the “fine grained details” *   Sec 6.2 list of drafts -
  will these works in progress be stable or final before publication? *   Sec
  6.4, para 2,3rd sentence - the statement on it being impractical to fit IETF
  models into MEF models seems a bit broad. Has anyone looked into this?

Relevant Directorate Review Guidance
Minor Issues and Nits:

  *   Minor issues are concerns about clarity or technical accuracy that should
  be discussed and resolved before publication, but which would normally be
  resolved between the authors and the reviewers. *   Please include all of the
  minor issues you have found. Give as much context information as possible
  (e.g., section numbers, paragraph counts). *   If you find no minor issues,
  please write: "No minor issues found."

  *   Nits are editorial or layout items. They are things that would ideally be
  resolved before publication to make the document more readable, and may be
  raised now to save the RFC Editor work.