Hello, I have been selected as the Routing Directorate reviewer for draft: ​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 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.