Re: [netmod] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained

Tianran, OPSAWG,

 Now that RFC8199 is published, I have two (somewhat associated) points of
 high-level feedback on draft-ietf-opsawg-service-model-explained:

  - The term “Network Service Model” in RFC 8199 is intended to cover both
    "Customer Service Model” as well as “Service Delivery Model” as defined
    in draft-ietf-opsawg-service-model-explained. At the time of the first
    revision of what was draft-bogdanovic-netmod-yang-model-classification
    we discussed further splitting "Network Service Model” into smaller
    components, but decided against it since we did not see a consensus on
    what that split would look like. I believe the authors here is
    suggesting such a further split.

    There is one specific passage in this draft that I would suggest could
    use rephrasing if the authors agree to the above:

"""
   As previously noted, [I-D.ietf-netmod-yang-model-classification]
   provides a classification of YANG data models.  It introduces the
   term "Network Service YANG Module" to identify the type of model used
   to "describe the configuration, state data, operations and
   notifications of abstract representations of services implemented on
   one or multiple network elements."  These are service delivery models
   as described in this document, that is, they are the models used on
   the interface between the Service Orchestrator or OSS/BSS and the
   Network Orchestrator as shown in Figure 3.
"""

 - And this gets to my second point of feedback. Figure 4. in the draft seems
   to suggest that the "Service Orchestrator" is an entity separate from the
   "Operations and Business Support Systems (OSS/BSS)". And also that
   Customers (as defined) in Section 2 interface directly with that entity.
   This is a very unusual construct, in the sense that:
    o The common taxonomomy from e.g. TMForum would classify a service
      orchestrator as a part of the OSS/BSS stack, since...
    o The successful activation of a service includes many parts of the
      OSS/BSS-stack including operational readiness (are there physical ports
      available), billing management (is the customer allowed to perform e.g.
      this resource expansion), and assurance (changed services require new
      assurance parameters). This makes it hard to separate out a Customer
      interface to service orchestration only, separate from the OSS/BSS
      stack.

 This an informational draft and as such is for general information, and not
 necessarily intended to represent community consensus or recommendation, just
 like 8119. But I would suggest the document could be improved by elaborating
 the point of the separation of the orchestrator and the BSS/OSS and the
 resulting difference in module types.

--
Carl Moberg
camoberg@cisco.com

> On Aug 1, 2017, at 10:45 AM, Tianran Zhou <zhoutianran@huawei.com> wrote:
> 
> Hi NETMOD WG,
> 
> This is a cross post for the ongoing WGLC in OPSAWG. 
> 
> Service Models Explained
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/
> 
> Please send your comments by August 18, 2017. If you do not feel this  document should advance, please state your reasons why.
> 
> Regards,
> Tianran, OPSAWG co-chair
> 
> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran Zhou
> Sent: Friday, July 28, 2017 11:06 AM
> To: opsawg@ietf.org
> Cc: opsawg-chairs@ietf.org
> Subject: [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
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod