[OPSAWG] Soliciting thoughts on draft-ietf-netmod-yang-model-classification

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 31 October 2016 12:04 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E051295BB; Mon, 31 Oct 2016 05:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level:
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jvFmbQu6W1I; Mon, 31 Oct 2016 05:04:02 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7AA81294A5; Mon, 31 Oct 2016 05:03:58 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9VC3uoE026126; Mon, 31 Oct 2016 12:03:56 GMT
Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9VC3sLf026099 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 31 Oct 2016 12:03:55 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'opsawg@ietf.org'" <OpsAWG@ietf.org>
Date: Mon, 31 Oct 2016 12:03:50 -0000
Message-ID: <00f701d2336e$d892e390$89b8aab0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdIzbq9EP4RJAzxtQQ667SmsQfy/Ow==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22670.006
X-TM-AS-Result: No--8.359-10.0-31-10
X-imss-scan-details: No--8.359-10.0-31-10
X-TMASE-MatchedRID: 5d5UyYH8moER9y8WJPyXEPp1plqEbuqxCQ3xS+zL6e1/T6JSxYggpS1l xAVVUrr25RlEVaicFdu5NNaj2lpbTo7VvZCLNnEn04Rmz/agfdwHg23OuPl1dLNcuCb8CAxuFll 1gqCkr0N0cjCLkcGjWQ+tU2/Wp19VJXb8mGWA8s/tP6Pv+A+w81AsQ+5PgsP5/1vUyJ9kJXL0K7 ZB8xwtHK44KKsu90SxmSvMlyme0UDsSfhHYXfCBH9NanCUA4VemoKXVHfiMM+D1OfYfymjIwC0e KsJmESJ5q7gfVab4Kl13TkHObNXgRgHZ8655DOPOX/V8P8ail1bCjvvWZW+Sabj/c4OO+6RKrau Xd3MZDWwW8fa2IttjLSrQFM9ByoGsTh04AzaWbwgwS4UHP3CVByNwXiFz51IwL6SxPpr1/I=
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/IxrvguCmDJdtkcvzuQ2Rkzt_M-k>
Cc: draft-wu-opsawg-service-model-explained@ietf.org
Subject: [OPSAWG] Soliciting thoughts on draft-ietf-netmod-yang-model-classification
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2016 12:04:04 -0000

Hi,

We previously discussed draft-wu-opsawg-service-model-explained a bit on this
list and also at a face-to-face meeting.

Since then the I-D has moved on to a -03 revision picking up and addressing
comments from the list, private emails, and the authors' gradual understanding
of the field.

We do not think that this I-D is conflicted by, with, or from
draft-ietf-netmod-yang-model-classification (which we understand may be
approaching WG last call in NETMOD).

We believe there are some issues that would benefit from focused discussion in
the OPSAWG.

Is there agreement on our separation of models into customer service models,
service delivery models, and network/device configuration models? We think that
we have the right split of function, but not necessarily the right names for the
terms.

Can we refine the definition of "service"? There was some discussion of this at
the last meeting, and it led us to refine the language a bit, but it would be
helpful to have more feedback.

Is this stuff "obvious" or is there value in publishing an RFC? Our experience
working in L3SM has been that there is a tension with the protocol working
groups (particularly BESS) that arises from the equipment vendors being closer
to how services are delivered within a network (i.e., by configuring a set of
devices in the network) than they are to an understanding of how an operator
presents a service for consumption by their customer. Our intention is to make
that distinction clearer.

Have we got the correlation with the MEF's LSO right? We have heard a
conflicting view to what we have written, but we have also heard supporting
views. Should we drop all discussion of the MEF's model as it is out of scope
for the IETF?

Thanks for any opinions.

Adrian