Subject: [netmod] New Version Notification for draft-bogdanovic-netmod-yang-model-classification-01.txt

From: Benoit Claise <[email-masked]>
Date: Thu, 12 Mar 2015 15:48:02 +0100

Dear all,

We would appreciate your review on this new draft version.

Regards, Benoit

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-bogdanovic-netmod-yang-model-classification-01.txt
Date: 	Mon, 9 Mar 2015 15:46:05 -0700
From: 	[email-masked]
To: 	Dean Bogdanovic <[email-masked]>, Dean Bogdanovic 
<[email-masked]>, Benoit Claise <[email-masked]>, Carl Moberg 
<[email-masked]>, Carl Moberg <[email-masked]>, Benoit Claise 
<[email-masked]>

A new version of I-D, draft-bogdanovic-netmod-yang-model-classification-01.txt
has been successfully submitted by Dean Bogdanovic and posted to the
IETF repository.

Name:		draft-bogdanovic-netmod-yang-model-classification
Revision:	01
Title:		YANG model classification
Document date:	2015-03-09
Group:		Individual Submission
Pages:		12
URL:            http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-yang-model-classification-01.txt
Status:         https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-yang-model-classification/
Htmlized:       http://tools.ietf.org/html/draft-bogdanovic-netmod-yang-model-classification-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-bogdanovic-netmod-yang-model-classification-01

Abstract:
    YANG became de facto standard language for data modeling in the
    industry.  More and more groups uses YANG to create protocol and
    service models, both for configuration and operational models.
    Currently there is a lack of consistent terminology to categorize
    those models.  A consistent terminology would help models
    categorization, assist in the analysis the YANG data modeling effort
    in the IETF and in the industry, and facilitate the YANG-related
    discussions between different groups.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Mar 2015 08:34:24 +0100

> We would appreciate your review on this new draft version.

Speaking as technical contributor...

- I am confused by section 3.2 which talks about differences between
  vendor models and standard models. It says: "Key difference between
  those two is what is implemented. Vendor device model will always
  describe what is implemented, which can ber more or even less then
  in standard model." This kind of implies that standard models do not
  describe what is implemented. If this is true, we should perhaps
  stop wasting our time. And I think the discussion of vendor model
  vs. standard model does not really belong into this section or does
  this only apply to NE (Network Element) YANG models?

- It would perhaps be a good idea if the document would clearly define
  terms (and maybe acronyms) that can be reused such as

  Network Element Model (NEM): ...

  Network Service Model (NSM): ...

  [...]

- The second dimension is a bit confusing for me because it seems to
  make multiple distinctions and perhaps this is really multiple
  dimensions merged into one. On the distinction standard
  vs. proprietary: It sounds like binary while I believe in reality it
  is a continuum. There is surely the dimension "who has change
  control and what are the procedures to make updates" but there is
  also the dimension "what became a pratically largely deployed
  model". (I find it interesting that ITU is mentioned, I would expect
  or hope that IEEE is going to produce YANG data models way earlier.)

- I find the classification in section 4 a bit confusing:

      Standard YANG Model
      Standard Extension YANG Model
      Proprietary Extension to Standard YANG Model
      Vendor Configuration Model
      Proprietary YANG Model

   What is the distinction between Vendor Configuration Model and
   Proprietary YANG Model - are they not the same? See also next item
   below...

   I am not sure whether it would be useful to classify the first two
   into three categories. We tend to have some:

   - Standard Core YANG Models (SCM) (e.g., interfaces),
   - Standard Technology Base YANG Models (STBM) that are technology
     specific extensions of core models (e.g., interface type specific
     models), and
   - Standard Technology Extension YANG Models (STEM) that are
     extensions of the basic technology specific models (that are
     usually added over time).

   Perhaps it is not worth distinguishing these but clearly building
   the core models is a rather complicated exercise since errors or
   limitations in the core models impact potentially many other
   models.

- The text in section 4.4 seems to be more about implementation
  aspects, e.g., how can a vendor support both proprietary and
  standard models or migrate from proprietary models to standard
  models or how to map standard and prorietary models to the
  underlying internal configuration model. I think this is a topic
  worthwhile to discuss somewhere but I do not think this belongs into
  the classification. The vendor internal model is an implementation
  concern, not a classification concern.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 18 Mar 2015 17:18:12 +0100

Hi Jürgen,
>    this only apply to NE (Network Element) YANG models?
You're right. Will be corrected.
>    Network Service Model (NSM): ...
I thought we introduced those definitions before submitting. Now 
corrected in our temp version.
>    or hope that IEEE is going to produce YANG data models way earlier.)
Or the fact that vendors have to use proprietary models while waiting 
for SDO to develop the standard ones.
>     Proprietary YANG Model - are they not the same? See also next item
Not really. Most vendors still use CLI.

   Vendor Configuration Model: It describes all configurable
       capabilities of the device and what device vendor exposes for
       configuration.  The vendor configuration model can be CLI or YANG-
       based.

>       usually added over time).
We tried to clarify.
>     limitations in the core models impact potentially many other
Agreed.  Now, what we consider a non-core model now can become a core 
model for someone else in the future.
So the boundary is not clear.

Thanks for your review. We're actively working on the next version.

Regards, Benoit