Subject: Re: [Supa] Information models and Data models - WG adopion?

From: Nevil Brownlee <[email-masked]>
Date: Wed, 2 Mar 2016 11:56:21 +1300

Hi Tianran:

In my experiences, having a well-defined information model is a good
starting point.  It allows different implementations, each of which
can develop it's own data model - in other words, the information
model is a good unifying influence - which is why publishing such
a document is the second of our chart items.  I hope that getting
a good data model will help us with the first chart item ("scope
of the policy-based management framework").

draft-strassner-supa-generic-policy-info-model is the only SUPA
information model that's had any work done on it since IETF 95,
therefore I've proposed it for WG adoption.

As for the third charter item - "set of YANG data models", there
are two of these on the SUPA documents page.  It would help at
this stage if their authors could comment on this list about the
status of these drafts.  In particular, jave they been working on
a new version?

Overall, we really need more discussion on the list of what's
happening with the SUPA work!

Cheers, Nevil

On 1/03/16 6:13 pm, Zhoutianran wrote:
> If this is a poll for WG adoption, I would say not support.
>
> If we want to finally generate YANG data models here, why do we spend time working on this information model?
>
> Why not focus on the ECA YANG data model directly as standard track?
>
>
> Tianran
>
>> -----Original Message-----
>> From: Supa [mailto:[email-masked]] On Behalf Of IETF Secretariat
>> Sent: Monday, February 29, 2016 6:35 AM
>> To: [email-masked];
>> [email-masked]; [email-masked]
>> Subject: [Supa] The SUPA WG has placed
>> draft-strassner-supa-generic-policy-info-model in state "Call For
>> Adoption By WG Issued"
>>
>>
>> The SUPA WG has placed draft-strassner-supa-generic-policy-info-model in
>> state Call For Adoption By WG Issued (entered by Nevil Brownlee)
>>
>> The document is available at
>> https://datatracker.ietf.org/doc/draft-strassner-supa-generic-policy-i
>> nfo-model/
>>
>>
>> Comment:
>> This is the first of our charter documents, the other charter items build
>> on this
>>
>> _______________________________________________
>> Supa mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/supa

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Andy Bierman <[email-masked]>
Date: Tue, 1 Mar 2016 18:44:12 -0800

Hi,

I am not objecting to an info model, but this is a non-trivial document that
will take a lot of WG resources. We should know in advance how it
relates to (a) implementations and (b) all other SUPA documents.

It is not clear if this document will have any normative impact on the
solution
or not.  Is an solution required to provide all the functionality of this
info model?
Is the solution allowed to support more than this info model covers?

It is not clear whether the solution consists of policy-specific YANG
modules
or whether there is a generic YANG module that is "programmed" with
policy-specific
data.  This is a critical design decision.

Example:  It appears from sec. 5.6.1.2 the encoding syntax is an extremely
limited subset of
the data types supported by YANG.  Even the typedefs in ietf-inet-types.yang
are much more powerful and better-defined.  Does this imply that a solution
that
uses YANG cannot use the full set of YANG functionality (e.g., union,
leafref, ip-address)?

YANG is not even listed as a constraint language (e.g. 5.7.2.1).
I am curious how I write SUPA policy in YANG.  I am curious how
existing YANG modules such as ietf-interfaces or ietf-routing are used in
SUPA.
If the WG has no clue about the answers to these fundamental questions, that
is cause for concern.

5.6.1.2 <https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-04#section-5.6.1.2>.
The Attribute "supaEncodedClauseEncoding"

   This is a mandatory integer attribute, and defines how to
   interpret the value of this encoded clause. It works with another
   class attribute, called supaEncodedClauseContent, which defines
   the content of the encoded clause. These two attributes form a
   tuple, and together enable a machine to understand the syntax and
   value of the encoded clause for the object instance of this class.
   Values include:

      0:  undefined
      1:  String
      2:  GUID
      3:  UUID
      4:  URI
      5:  FQDN

5.7.2.1 <https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-04#section-5.7.2.1>.
The Attribute "supaPolCompConstraintEncoding"

   This is a mandatory non-negative enumerated integer that defines
   how to interpret each string in the supaPolCompConstraint class
   attribute. Values include:

     0:  undefined
     1:  OCL 2.4
     2:  OCL 2.x
     3:  OCL 1.x
     4:  QVT 1.2 - Relations Language
     5:  QVT 1.2 - Operational language
     6:  Alloy

   Enumerations 1-3 are dedicated to OCL (with OCL 2.4 being the
   latest version as of this writing). QVT defines a set of languages
   (the two most powerful and useful are defined by enumerations 4
   and 5). Alloy is a language for describing constraints, and uses a
   SAT solver to guarantee correctness.

Andy

---

From: Zhoutianran <[email-masked]>
Date: Wed, 2 Mar 2016 03:29:12 +0000

Hi Nevil,

I am not arguing information model is useless, but it can be worked out in other organizations if necessary, e.g. TMF.
If in SUPA we can worked on YANG data models directly, why we firstly work on an information model and then translate it to YANG data model?
It just not makes sense to me.

Tianran

> From: Supa [mailto:[email-masked]] On Behalf Of Nevil Brownlee
> Sent: Wednesday, March 02, 2016 6:56 AM
> To: Zhoutianran
> Cc: SUPA list
> Subject: Re: [Supa] Information models and Data models - WG adopion?
> 
> 
> Hi Tianran:
> 
> In my experiences, having a well-defined information model is a good starting
> point.  It allows different implementations, each of which can develop it's
> own data model - in other words, the information model is a good unifying
> influence - which is why publishing such a document is the second of our
> chart items.  I hope that getting a good data model will help us with the
> first chart item ("scope of the policy-based management framework").
> 
> information model that's had any work done on it since IETF 95, therefore
> I've proposed it for WG adoption.
> 
> As for the third charter item - "set of YANG data models", there are two
> of these on the SUPA documents page.  It would help at this stage if their
> authors could comment on this list about the status of these drafts.  In
> particular, jave they been working on a new version?
> 
> Overall, we really need more discussion on the list of what's happening
> with the SUPA work!
> 
> Cheers, Nevil
> 
> 
> >> The SUPA WG has placed draft-strassner-supa-generic-policy-info-model
> >> in state Call For Adoption By WG Issued (entered by Nevil Brownlee)
> >>
> >> This is the first of our charter documents, the other charter items
> >> build on this
> >>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 2 Mar 2016 00:09:58 -0500

First, the entire information model will be rendered intoa YANG data model.
The advantage of discussing the information model is that we can make 
sure the information and relationships are right before doing the work 
of getting the YANG syntax right.

The encoded clause mechanism can not allow the encoding to be 
represented in YANG.  That is not what it is for.  Rather, to represent 
the policies explicit in YANG, using the Event, Condition, Action 
paradigm the working group has indicated it prefers (based on the 
charter), one subclasses the event, condition, and action decorators.

The encoded clause mechanism allows one to specify an encoded clause in 
a language (either declarative or imperitive.  If one wanted to use YANG 
as the lanague, one would need the YANG data model, at which point the 
mechanism above will allow everything you want.  The purpose of this 
alternative is to allow policy expressions which do not fit neatly into 
the model.

Similarly, in many places we allow expression of constraints. 
Constraint languages are something that modeling folks have found to be 
useful.  An implementation is not required to support any or all of the 
languages, but the model can represent the range of constraint languages 
that have been found to be useful.  Thus, these constraints are 
expressed as strings, with a language indication as to which constraint 
language is suitable.
Note that the languages for the encoded clause are not the same as the 
languages for the constraints.  Those are different aspects of the model.

Yours,
Joel

On 3/1/16 9:44 PM, Andy Bierman wrote:
> or not.  Is an solution required to provide all the functionality of
> this info model?
> Example:  It appears from sec. 5.6.1.2 the encoding syntax is an
> extremely limited subset of
> are much more powerful and better-defined.  Does this imply that a
> solution that
> existing YANG modules such as ietf-interfaces or ietf-routing are used
> in SUPA.
>           5.6.1.2
>           <https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-04#section-5.6.1.2>.
>           5.7.2.1
>           <https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-04#section-5.7.2.1>.
> On Tue, Mar 1, 2016 at 2:56 PM, Nevil Brownlee
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Hi Tianran:
>
>         If we want to finally generate YANG data models here, why do we
>         spend time working on this information model?
>
>             From: Supa [mailto:[email-masked]
>             <mailto:[email-masked]>] On Behalf Of IETF Secretariat
>             To: [email-masked]
>             <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>
>             The SUPA WG has placed
>             draft-strassner-supa-generic-policy-info-model in
>             [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Mar 2016 07:45:05 +0100

> of getting the YANG syntax right.

My experience is that you usually only know whether the information
model is reasonably complete and clear if you have done the whole
round-trip at least once, that is you have done:

info model -> data model -> implementation -> data model updates -> information model updates

A pure top-down approach will leave you with an info model which only
partially describes what happens in a data model. Now, this might be
fine, depending on _why_ you define an info model. If you do the info
model because you expect interoperability based on the info model,
then I believe a full round-trip is necessary to get the info model
reasonably precise. If you do the info model because you have no clue
or agreement how to write a data model, then it is fine to be prepared
to diverge from the info model up to the point that it is not
important anymore for interoperability.

So the key question for me is which function the info model is
supposed to fulfill.

/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: "Joel M. Halpern" <[email-masked]>
Date: Wed, 2 Mar 2016 09:15:08 -0500

Juergen, I would love to see us do a full round trip.
We are calling for WG adoption of the information model, not WG last 
call.  You make a good point that we should get further down the path 
with the data model before we do go for the last call.

Yours,
Joel

---

From: John Strassner <[email-masked]>
Date: Thu, 3 Mar 2016 03:21:59 +0000

We should work on an information model for several reasons, even if
there is only target data model (i.e., YANG):

  1) An information model can define how data are related to each
     other independent of implementation. This is much harder to do
     in YANG. Hence, the information model may make these inherent
     relationships easier to visualize and define.
  2) An information model separates the logical design from the
     physical design of the system, enabling a deeper understanding
     of both independent of implementation. This can be used to
     produce more powerful implementations.
  3) If an information model is worked on in another organization,
     there is no guarantee that its output will be useful to the
     IETF. I am active in the TM Forum, which you cited; they are
     in general not worried about implementing YANG models, much
     less producing optimal YANG models.
  4) This enables other SDOs and fora, which do not use YANG, to
     more easily understand our output.

John

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Zhoutianran
Sent: Tuesday, March 01, 2016 7:29 PM
To: Nevil Brownlee
Cc: SUPA list
Subject: Re: [Supa] Information models and Data models - WG adopion?

Hi Nevil,

Tianran

---

From: Zhoutianran <[email-masked]>
Date: Thu, 3 Mar 2016 04:00:41 +0000

Hi Juergen,

Emmm, the round trip you mentioned much like the spiral model in software engineering. That's of course a good way to do system design and implementation. 

However, in this process, the information model is like an intermediary state, but not the final output (RFC) we need.
I mean, even if we do not have a IM RFC, we can always have a scratch or UML drawing shared during the DM design. And those make life simpler for express intent and idea, and for interoperation.

A document with more than 100 pages just make all the things complex. That's my humble opinion.

Tianran

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Wednesday, March 02, 2016 2:45 PM
> To: Joel M. Halpern
> Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list
> My experience is that you usually only know whether the information model
> is reasonably complete and clear if you have done the whole round-trip at
> least once, that is you have done:
> 
> partially describes what happens in a data model. Now, this might be fine,
> depending on _why_ you define an info model. If you do the info model because
> you expect interoperability based on the info model, then I believe a full
> round-trip is necessary to get the info model reasonably precise. If you
> do the info model because you have no clue or agreement how to write a data
> model, then it is fine to be prepared to diverge from the info model up
> to the point that it is not important anymore for interoperability.
> 
> So the key question for me is which function the info model is supposed
> to fulfill.
> 
> /js
> 
> --

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Mar 2016 21:06:43 -0800

On Wed, Mar 2, 2016 at 7:21 PM, John Strassner <[email-masked]

>      more easily understand our output.

It seems to me that your draft has many details related to the abstraction
of policy logic, but also many aspects that look like implementation
details.
Perhaps it can be simplified if the implementation details were removed.

I am more interested in the SUPA Architecture document first.
I don't see how we can agree on an info-model in the absence
of a system architecture.

Does SUPA run anywhere? What does it even mean to implement SUPA?
Will people be able to build interoperable SUPA engines from the RFCs?
Is there a difference between a SUPA engine running at the device level
or the controller level?  What data is available for policy enforcement
analysis?
Is this configurable through YANG modules implemented by a SUPA engine?
How are policies defined and managed within the SUPA implementation?
How is device config altered to implement policy?
How are device operational state and statistics used to verify policy
implementation?

A precise description of policy logic might be a good thing to have.
I am not objecting to an info model doc.  A system architecture and a
workable solution
will require a lot more than that.

Andy

> I am not arguing information model is useless, but it can be worked out in
> other organizations if necessary, e.g. TMF.
> If in SUPA we can worked on YANG data models directly, why we firstly work
> on an information model and then translate it to YANG data model?
> starting

---

From: Zhoutianran <[email-masked]>
Date: Thu, 3 Mar 2016 06:18:44 +0000

I agree with Andy on the SUPA architecture. And I think Andy has posted many useful ideas on questions that we need to solve in the arch doc.
This document should firstly be delivered, while information model is just one aspect that may help the data model design.

Moreover, I do not think text document is the best tool for information modeling. Most organizations use UML for it.

If SUPA has plan to deliver such an architecture doc, I would very like to contribute.

Best,
Tianran

From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, March 03, 2016 1:07 PM
To: John Strassner
Cc: Zhoutianran; Nevil Brownlee; SUPA list
Subject: Re: [Supa] Information models and Data models - WG adopion?

On Wed, Mar 2, 2016 at 7:21 PM, John Strassner <[email-masked]<mailto:[email-masked]>> wrote:
We should work on an information model for several reasons, even if
there is only target data model (i.e., YANG):

It seems to me that your draft has many details related to the abstraction
of policy logic, but also many aspects that look like implementation details.
Perhaps it can be simplified if the implementation details were removed.

Does SUPA run anywhere? What does it even mean to implement SUPA?
Will people be able to build interoperable SUPA engines from the RFCs?
Is there a difference between a SUPA engine running at the device level
or the controller level?  What data is available for policy enforcement analysis?
Is this configurable through YANG modules implemented by a SUPA engine?
How are policies defined and managed within the SUPA implementation?
How is device config altered to implement policy?
How are device operational state and statistics used to verify policy implementation?

A precise description of policy logic might be a good thing to have.
I am not objecting to an info model doc.  A system architecture and a workable solution
will require a lot more than that.

John

Andy

-----Original Message-----
From: Supa [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Zhoutianran
Sent: Tuesday, March 01, 2016 7:29 PM
To: Nevil Brownlee
Cc: SUPA list
Subject: Re: [Supa] Information models and Data models - WG adopion?

Hi Nevil,

Tianran

> From: Supa [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nevil Brownlee
> >> From: Supa [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of IETF
> >> Secretariat
> >> To: [email-masked]<mailto:[email-masked]>;
> >> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> >> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Supa mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/supa

_______________________________________________
Supa mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/supa

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 3 Mar 2016 16:27:18 +0100

Very good and practical question raised by Andy!

Bert

On 03/03/16 06:06, Andy Bierman wrote:
>
>
> On Wed, Mar 2, 2016 at 7:21 PM, John Strassner <[email-masked] <mailto:[email-masked]>> wrote:
>
>     From: Supa [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Zhoutianran
>     > From: Supa [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Nevil Brownlee
>     > >> From: Supa [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of IETF
>     > >> Secretariat
>     > >> To: [email-masked] <mailto:[email-masked]>;
>     > >> [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Mar 2016 10:48:01 -0500

Two separate but related quesitons.

1) Can you help use find the places where the model / text is too 
implementation specific?  There are a few places where in describing 
enumerations the model calls for integers.  In the mapping to YANG, I 
have already started replacing those with Enumerations.  Are there other 
kinds of over-specificity?

2) The charter allows for a range of implementations of the SUPA system. 
  Folks may recall I asked in the room at the last meeting whether our 
chartered allowd both communication between a control system and a 
device, and communication between a policy repository and a policy 
engine.  I was told by the AD that the chartered allowed both.  This 
does make it rather interesting to define the "architecture".
2') I do think that there are a few places in the model, particularly 
with regard to policy execution status, where the model makes some 
assumptions about the structure of policy delivery.  For the most part, 
those should be removed.  Assistance in finding them is appreciated.  I 
suspect that some of them are necessary, and those should be explicitly 
described.   (And we should make sure the working group agrees with the 
assumptions.)

3) (minor) The charter permits the information model.  I presume we 
could amend the charter to permit an architecture document.

Yours,
Joel

On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote:
>> On Wed, Mar 2, 2016 at 7:21 PM, John Strassner
>> <[email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>> <mailto:[email-masked]>] On Behalf Of Zhoutianran
>>     I am not arguing information model is useless, but it can be
>> worked out in other organizations if necessary, e.g. TMF.
>>     If in SUPA we can worked on YANG data models directly, why we
>> firstly work on an information model and then translate it to
>>     YANG data model?
>> <mailto:[email-masked]>] On Behalf Of Nevil Brownlee
>> are two
>>     > > If we want to finally generate YANG data models here, why do
>> we spend
>>     > time working on this information model?
>>     > >
>> draft-strassner-supa-generic-policy-info-model

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 3 Mar 2016 17:12:51 +0100

Inline

On 03/03/16 16:48, Joel M. Halpern wrote:
> 1) Can you help use find the places where the model / text is too implementation specific?  There are a few places where in 
> describing enumerations the model calls for integers.  In the mapping to YANG, I have already started replacing those with 
> Enumerations.  Are there other kinds of over-specificity?
>
> 2) The charter allows for a range of implementations of the SUPA system.  Folks may recall I asked in the room at the last meeting 
> whether our chartered allowd both communication between a control system and a device, and communication between a policy 
> repository and a policy engine.  I was told by the AD that the chartered allowed both.  This does make it rather interesting to 
> define the "architecture".
Mmmm... both concurrently, or did he mean that we as a WG can make a choice what we prefer
and standardize that?
If we do both concurrently or a longside each other, can we then still guarantee interoperability
(which I think is one of our main objctives, no)?
> 2') I do think that there are a few places in the model, particularly with regard to policy execution status, where the model 
> makes some assumptions about the structure of policy delivery.  For the most part, those should be removed.  Assistance in finding 
> them is appreciated.  I suspect that some of them are necessary, and those should be explicitly described.   (And we should make 
> sure the working group agrees with the assumptions.)
>
> 3) (minor) The charter permits the information model.  I presume we could amend the charter to permit an architecture document.
>
I would say an "Architecture" or "System Overview" document would be a good thing.

Bert

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Mar 2016 11:28:05 -0500

In terms of applied spaces, my own view is that the same model should be 
useable in both contexts.  One of the issues with a policy 
representation system is that no system will be able to support the full 
range of all possible policies that can be represented in the model.

But if the structure is right, and if we have build a good set of 
starting points for realizable policies, interoperability should be 
definable and achievable in terms of the expectation that a device 
trying to set policies (and query them) using this model can expect 
reasonable response from the other end.  (Yes, I am a bit of an optimist.)

Yours,
Joel

> On 03/03/16 16:48, Joel M. Halpern wrote:
...
>> 2) The charter allows for a range of implementations of the SUPA
>> system.  Folks may recall I asked in the room at the last meeting
>> whether our chartered allowd both communication between a control
>> system and a device, and communication between a policy repository and
>> a policy engine.  I was told by the AD that the chartered allowed
>> both.  This does make it rather interesting to define the "architecture".
...

---

From: "King, Daniel" <[email-masked]>
Date: Thu, 3 Mar 2016 16:41:22 +0000

Hi  All. 

We have a placeholder in the SUPA Charter for:

1) An explanation of the scope of the policy-based management framework and how it relates to existing work of the IETF.

A proposal for this document has not been forthcoming thus far. It would seem that a "Policy-based Management Framework" discussing architecture, applicability and relationships ("system overview") would be reasonable content for a framework document mentioned in the Charter?  

Furthermore, Andy, Tianran and Bert all seem willing to support development (via direct contributions) for the framework/architecture document?

BR, Dan. 

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Bert Wijnen (IETF)
Sent: 03 March 2016 16:13
To: Joel M. Halpern <[email-masked]>; Andy Bierman <[email-masked]>; John Strassner <[email-masked]>
Cc: Zhoutianran <[email-masked]>; Nevil Brownlee <[email-masked]>; SUPA list <[email-masked]>
Subject: Re: [Supa] Information models and Data models - WG adopion?

Inline

On 03/03/16 16:48, Joel M. Halpern wrote:
> enumerations the model calls for integers.  In the mapping to YANG, I have already started replacing those with Enumerations.  Are there other kinds of over-specificity?
>
> system and a device, and communication between a policy repository and a policy engine.  I was told by the AD that the chartered allowed both.  This does make it rather interesting to define the "architecture".
Mmmm... both concurrently, or did he mean that we as a WG can make a choice what we prefer and standardize that?
If we do both concurrently or a longside each other, can we then still guarantee interoperability (which I think is one of our main objctives, no)?
> with regard to policy execution status, where the model makes some assumptions about the structure of policy delivery.  For the most part, those should be removed.  Assistance in finding

Bert
>>> It seems to me that your draft has many details related to the 
>>> abstraction of policy logic, but also many aspects that look like 
>>> implementation details.
>>> I don't see how we can agree on an info-model in the absence of a 
>>> system architecture.
>>>
>>> Is there a difference between a SUPA engine running at the device 
>>> level or the controller level?  What data is available for policy 
>>> enforcement analysis?
>>> I am not objecting to an info model doc.  A system architecture and 
>>> a workable solution will require a lot more than that.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>     John
>>>
>>>
>>>
>>> Andy
>>>
>>>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Mar 2016 09:38:34 -0800

On Thu, Mar 3, 2016 at 8:41 AM, King, Daniel <[email-masked]> wrote:

> 1) An explanation of the scope of the policy-based management framework
> and how it relates to existing work of the IETF.
>
> A proposal for this document has not been forthcoming thus far. It would
> seem that a "Policy-based Management Framework" discussing architecture,
> applicability and relationships ("system overview") would be reasonable
> content for a framework document mentioned in the Charter?
>
> Furthermore, Andy, Tianran and Bert all seem willing to support
> development (via direct contributions) for the framework/architecture
> document?
>
>
I don't know how much time I can spend on SUPA.
If there is nothing implementable in SUPA then I don't really see
what standards value it has to operators.

Andy

> To: Joel M. Halpern <[email-masked]>; Andy Bierman <
> [email-masked]>; John Strassner <[email-masked]>
> Cc: Zhoutianran <[email-masked]>; Nevil Brownlee <
> [email-masked]>; SUPA list <[email-masked]>
> > system and a device, and communication between a policy repository and a
> policy engine.  I was told by the AD that the chartered allowed both.  This
> Mmmm... both concurrently, or did he mean that we as a WG can make a
> choice what we prefer and standardize that?
> If we do both concurrently or a longside each other, can we then still
> guarantee interoperability (which I think is one of our main objctives, no)?
> those should be removed.  Assistance in finding
> > them is appreciated.  I suspect that some of them are necessary, and
> those should be explicitly described.   (And we should make

---

From: John Strassner <[email-masked]>
Date: Thu, 3 Mar 2016 17:40:24 +0000

I agree with Joel. The objective here is to get the round trip started by calling for WG adoption. One of the reasons that there are multiple options in the info model is to simplify this round-trip.

regards,
John

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, March 02, 2016 6:15 AM
To: Joel M. Halpern; Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list
Subject: Re: [Supa] Information models and Data models - WG adopion?

Yours,
Joel

---

From: John Strassner <[email-masked]>
Date: Thu, 3 Mar 2016 17:45:31 +0000

It is actually more like the V-model than a spiral model - the spiral model is risk-driven.

The point of model-driven software is to use the info model as the source that ties everything together, including requirements, documentation, test, and implementation. You seem to be advocating bottom-up data models, which produces separate silos of software.

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Zhoutianran
Sent: Wednesday, March 02, 2016 8:01 PM
To: Juergen Schoenwaelder; Joel M. Halpern
Cc: Nevil Brownlee; Andy Bierman; SUPA list
Subject: Re: [Supa] Information models and Data models - WG adopion?

Hi Juergen,

Tianran

---

From: Zhoutianran <[email-masked]>
Date: Fri, 4 Mar 2016 02:52:37 +0000

I would like to contribute on this framework document. 
I can try to address questions like Andy raised in the mailing list based on my experience.

Tianran

> From: King, Daniel [mailto:[email-masked]]
> Sent: Friday, March 04, 2016 12:41 AM
> To: Bert Wijnen (IETF); Joel M. Halpern; Andy Bierman; John Strassner;
> Zhoutianran
> Cc: Nevil Brownlee; SUPA list
> Subject: RE: [Supa] Information models and Data models - WG adopion?
> 
> Hi  All.
> 
> Furthermore, Andy, Tianran and Bert all seem willing to support development
> (via direct contributions) for the framework/architecture document?
> 
> BR, Dan.
> 
> To: Joel M. Halpern <[email-masked]>; Andy Bierman
> <[email-masked]>; John Strassner <[email-masked]>
> Cc: Zhoutianran <[email-masked]>; Nevil Brownlee
> <[email-masked]>; SUPA list <[email-masked]>
> > enumerations the model calls for integers.  In the mapping to YANG, I have
> already started replacing those with Enumerations.  Are there other kinds
> of over-specificity?
> >
> a policy engine.  I was told by the AD that the chartered allowed both.  This
> assumptions about the structure of policy delivery.  For the most part, those
> should be removed.  Assistance in finding
> > them is appreciated.  I suspect that some of them are necessary, and those
> should be explicitly described.   (And we should make
> > 3) (minor) The charter permits the information model.  I presume we could
> amend the charter to permit an architecture document.
> >

---

From: Zhoutianran <[email-masked]>
Date: Fri, 4 Mar 2016 03:23:08 +0000

I think you miss my point.

I am not against IM. But as an intermediary state, I think IM no need to be delivered as an RFC.

And I do not think text document is the best tool for the IM, while in many other organizations, they use UML.

You have a 100+ pages draft, but large content just repeat the basic UML and OO concept, like the inherit, aggregation, subclass... 

Tianran

> From: John Strassner
> Sent: Friday, March 04, 2016 1:46 AM
> To: Zhoutianran; Juergen Schoenwaelder; Joel M. Halpern
> Cc: Nevil Brownlee; Andy Bierman; SUPA list; [email-masked]
> The point of model-driven software is to use the info model as the source
> that ties everything together, including requirements, documentation, test,
> and implementation. You seem to be advocating bottom-up data models, which
> produces separate silos of software.
> 
> 
> Emmm, the round trip you mentioned much like the spiral model in software
> engineering. That's of course a good way to do system design and
> implementation.
> 
> However, in this process, the information model is like an intermediary
> state, but not the final output (RFC) we need.
> I mean, even if we do not have a IM RFC, we can always have a scratch or
> UML drawing shared during the DM design. And those make life simpler for
> express intent and idea, and for interoperation.
> 
> > From: Juergen Schoenwaelder
> > [mailto:[email-masked]]
> > > The advantage of discussing the information model is that we can
> > > make sure the information and relationships are right before doing
> > > the work of getting the YANG syntax right.
> >
> > to diverge from the info model up to the point that it is not important
> anymore for interoperability.
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Mar 2016 22:29:31 -0500

I have real trouble understanding this email.
If we are going to use the IM, the working group needs to adopt it, so 
that the document reflects working group agreements rather than just 
John and my opinions.

Documents that a working group is using need to be Internet Drafts. 
While it is possible to produce IDs in PDF, they need to parallel the 
text documents.  So it is rather difficult to build one that focuses on 
a full UML diagram.  (And many people do not want to read the PDF.)

Side note: The RFC Editor and the community are working on revisions to 
the process and rules for RFCs.  The IESG is watch carefully, and as I 
understand it hopes to extend the same improvements to the I-D series. 
But we are not there yet.

Finally, yes, there is a lot of explanation about basic UML modeling in 
the document.  This is included because we have found that many people 
in the working group are not familiar with the ways things are done in 
UML.  And we want everyone interested to be able to review and comment 
on the document.

We are working on producing a YANG data model.  The charter is quite 
clear that such is what we need to produce.

Given that you say you are not opposed to the IM, I am left quite 
confused as to what you want.

Yours,
Joel

---

From: John Strassner <[email-masked]>
Date: Thu, 3 Mar 2016 21:00:12 -0800

Hi Andy,

thank you for your thoughtful reply. Replies inline below (just copying
your reply,

details.
> Perhaps it can be simplified if the implementation details were removed.

That's probably true. The implementation details come from past
experience with similar models, and we thought that it may help the reader
better understand how this a SUPA-derived data model could be used in
a policy-based management model. If it is confusing then it should be
taken out.

> of a system architecture.

Well, we don't have an architecture document currently in our charter
(though I would support amending the charter to include this). In the
(now expired) proposition draft (which we are now working on to reissue),
there was an exemplary architecture.

However, I am missing your point here. The information model is by
definition generic in nature. It SHOULD be able to support many
different architectures. You are probably referring to something specific,
but I don't understand what.

> Does SUPA run anywhere?

SUPA - no, though there are at least 3 implementations that are currently
being built (hopefully one of these will be ready for IETF95). Subsets of
SUPA - absolutely.

> What does it even mean to implement SUPA?

Implementing SUPA means creating a data model derived from the
SUPA information model.

> Will people be able to build interoperable SUPA engines from the RFCs?

They'll have a better chance than without having RFCs :-)

> or the controller level?

It likely depends on your definition of "policy". For me, they are
different,
because both the actor using the policy and the nature of the policy are
different at these two levels. I would hope that SUPA could help
standardize this to make the translation from controller to device easier.

> What data is available for policy enforcement analysis?

That is, of course, a function of implementation. There are some hooks
in the SUPA info model for supporting this. I've also graduated 3 Ph.D.
students that have worked on policy detection and enforcement.
However, this clearly needs a supporting architecture document, as
well as clear definitions of what enforcement is.

> Is this configurable through YANG modules implemented by a SUPA engine?

The SUPA IM will be translated to a set of YANG modules. However,
looking at the charter, policy enforcement is currently out of scope imho.

implementation?

All of these questions are dependent on implementation and architecture.
Note, however, that some of these can be helped by the implementation
details that are in the SUPA draft (e.g., supaPolAdminStatus,
supaPolDeployStatus,
supaPolExecStatus, and supaPolClauseExecStatus). So yes, I agree that these
are implementation-oriented; however, all of these attributes are generic
in nature, and
should be able to help answer your questions.

workable solution
> will require a lot more than that.

I absolutely agree. The info model authors are focused on that, and are
helping with
a new version of a YANG data model. I'm sure all of us would be interested
in
helping create a workable solution.

regards,
John

On Wed, Mar 2, 2016 at 9:06 PM, Andy Bierman <[email-masked]> wrote:

>
>
> On Wed, Mar 2, 2016 at 7:21 PM, John Strassner <
> [email-masked]> wrote:
>
>> I am not arguing information model is useless, but it can be worked out
>> in other organizations if necessary, e.g. TMF.
>> If in SUPA we can worked on YANG data models directly, why we firstly
>> work on an information model and then translate it to YANG data model?

-- 
regards,
John

---

From: Zhoutianran <[email-masked]>
Date: Fri, 4 Mar 2016 05:01:36 +0000

In short to be clear.
I am not opposed to do information modeling for DM generation and other benefits.
However, I do not think the IM is necessary to be published as RFC in text document.

To Chairs, may I have a question? It's my preliminary idea.
Is it possible that we create IMs using UML, and archive them in github or some other repositories? 
So no need to text publish them in IETF.
We can still use this mailing list for discussion. Maybe like many open source communities, we can also use jira, gerrit, but may not.
We document the final data models with YANG in text.

Regards,
Tianran

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Friday, March 04, 2016 11:30 AM
> To: Zhoutianran; John Strassner; Juergen Schoenwaelder
> If we are going to use the IM, the working group needs to adopt it, so that
> the document reflects working group agreements rather than just John and
> my opinions.
> 
> While it is possible to produce IDs in PDF, they need to parallel the text
> documents.  So it is rather difficult to build one that focuses on a full
> UML diagram.  (And many people do not want to read the PDF.)
> 
> the document.  This is included because we have found that many people in
> the working group are not familiar with the ways things are done in UML.
> And we want everyone interested to be able to review and comment on the
> document.
> 
> We are working on producing a YANG data model.  The charter is quite clear
> that such is what we need to produce.
> 
> Given that you say you are not opposed to the IM, I am left quite confused
> as to what you want.
> 
> Yours,
> Joel
> 
> > You have a 100+ pages draft, but large content just repeat the basic UML
> and OO concept, like the inherit, aggregation, subclass...
> >
> >
> > Tianran
> >
> >> The point of model-driven software is to use the info model as the
> >> source that ties everything together, including requirements,
> >> documentation, test, and implementation. You seem to be advocating
> >> bottom-up data models, which produces separate silos of software.
> >>
> >>
> >> Emmm, the round trip you mentioned much like the spiral model in
> >> software engineering. That's of course a good way to do system design
> >> and implementation.
> >>
> >> However, in this process, the information model is like an
> >> intermediary state, but not the final output (RFC) we need.
> >> I mean, even if we do not have a IM RFC, we can always have a scratch
> >> or UML drawing shared during the DM design. And those make life
> >> simpler for express intent and idea, and for interoperation.
> >>
> >>>> First, the entire information model will be rendered intoa YANG
> >>>> data
> >> model.
> >>> A pure top-down approach will leave you with an info model which
> >>> only partially describes what happens in a data model. Now, this
> >>> might be fine, depending on _why_ you define an info model. If you
> >>> do the info model because you expect interoperability based on the
> >>> info model, then I believe a full round-trip is necessary to get the
> >>> info model reasonably precise. If you do the info model because you
> >>> have no clue or agreement how to write a data model, then it is fine
> >>> to be prepared to diverge from the info model up to the point that
> >>> it is not important

---

From: John Strassner <[email-masked]>
Date: Thu, 3 Mar 2016 21:01:50 -0800

There have been numerous "text documents" of info models and data models.
If you have a technical point, such as improvement in the symbology used in
the draft, please let us know.

On Wed, Mar 2, 2016 at 10:18 PM, Zhoutianran <[email-masked]> wrote:

> I agree with Andy on the SUPA architecture. And I think Andy has posted
> many useful ideas on questions that we need to solve in the arch doc.
>
> This document should firstly be delivered, while information model is just
> one aspect that may help the data model design.
>
>
>
> Moreover, I do not think text document is the best tool for information
> modeling. Most organizations use UML for it.
>
>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Thursday, March 03, 2016 1:07 PM
> *To:* John Strassner
> *Cc:* Zhoutianran; Nevil Brownlee; SUPA list
> *Subject:* Re: [Supa] Information models and Data models - WG adopion?
>
>
>
>
>
>
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 3 Mar 2016 21:06:53 -0800

>>      whether our chartered allowd both communication between a
>>      control system and a device, and communication between a
>>      policy repository and a policy engine.  I was told by the AD that
>>      the chartered allowed both.  This does make it rather interesting
>>      to define the "architecture".
> Mmmm... both concurrently, or did he mean that we as a WG can
> make a choice what we prefer and standardize that?

Why would doing both concurrently impede interoperability?

regards,
John

On Thu, Mar 3, 2016 at 8:12 AM, Bert Wijnen (IETF) <[email-masked]>
wrote:

>> chartered allowd both communication between a control system and a device,
>> and communication between a policy repository and a policy engine.  I was
>> told by the AD that the chartered allowed both.  This does make it rather
>> interesting to define the "architecture".
>>
> guarantee interoperability
>>>> abstraction

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 3 Mar 2016 21:11:44 -0800

> So the key question for me is which function the info model is supposed

At least for me (and I think for my co-authors as well), the answer is to
support interoperability. As Joel expressed earlier, I do hope that we are
able to do the round-trip at least once to improve all SUPA documents.

regards,
John

On Thu, Mar 3, 2016 at 9:45 AM, John Strassner <[email-masked]

> fine,

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 3 Mar 2016 21:18:05 -0800

I agree with Joel. I'm completely lost as to your motivation.

If you understand UML, terrific! Then you can skip the associated
pages in the draft. If you don't understand UML, then if all we had
was **just** a UML diagram (even if it was a free tool), then what
are people supposed to do?

The original PCIM and PCIMe info models, as well as several
others (e.g., IPsec work) were all RFCs and were all text.

In addition, there are plenty of data models built from UML. There
is even a UML-to-YANG converter in process.

If you have a technical contribution, please make it.

On Thu, Mar 3, 2016 at 9:01 PM, Zhoutianran <[email-masked]> wrote:

> We can still use this mailing list for discussion. Maybe like many open
> source communities, we can also use jira, gerrit, but may not.
> text

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 3 Mar 2016 21:20:51 -0800

Actually, you are missing my point. It's about model-driven software.
This is not the OMG, it is the IETF. Text is our friend. We need a
text document to establish WG traceability for the data model.

In addition, see my last response.

On Thu, Mar 3, 2016 at 7:23 PM, Zhoutianran <[email-masked]> wrote:

> > It is actually more like the V-model than a spiral model - the spiral
> model
> > is risk-driven.
> >
> > A document with more than 100 pages just make all the things complex.
> That's
> > my humble opinion.
> >
> > Tianran
> >

-- 
regards,
John

---

From: Zhoutianran <[email-masked]>
Date: Fri, 4 Mar 2016 06:53:22 +0000

Seen your this and last email.

Your logic is: this is IETF, so text is omnipotent, so you use text to describe IM with 100+ pages document for interoperation, and then generate UMLs, and finally use UML->YANG tool to generate data model.

My suggestion is: Text used in IETF is not good at describe IM, so we use UML for interoperation(but UML output not qualifies RFC), and then generate DM.

Am I miss your point? Which one is easier to implement?

Tianran

From: John Strassner [mailto:[email-masked]]
Sent: Friday, March 04, 2016 1:21 PM
To: Zhoutianran; John Strassner
Cc: John Strassner; Juergen Schoenwaelder; Joel M. Halpern; Nevil Brownlee; Andy Bierman; SUPA list
Subject: Re: [Supa] Information models and Data models - WG adopion?

On Thu, Mar 3, 2016 at 7:23 PM, Zhoutianran <[email-masked]<mailto:[email-masked]>> wrote:
I think you miss my point.

Tianran

> Cc: Nevil Brownlee; Andy Bierman; SUPA list; [email-masked]<mailto:[email-masked]>
> > [mailto:[email-masked]<mailto:[email-masked]>]

--
regards,
John

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 4 Mar 2016 10:28:54 +0100

Inline:

> Why would doing both concurrently impede interoperability?
Having two architectural solutions makes thinsgs more complex. And from experience
I know that complexity hinderts interoperability. You must have that same experience.
For one thing, if there are two approaches, then the software on each end will need to
add negotiations in order to figure out what the other side supports.

Bert
> regards,
> John
>
> On Thu, Mar 3, 2016 at 8:12 AM, Bert Wijnen (IETF) <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Inline
>
>         1) Can you help use find the places where the model / text is too implementation specific?  There are a few places where
>         in describing enumerations the model calls for integers.  In the mapping to YANG, I have already started replacing those
>         with Enumerations.  Are there other kinds of over-specificity?
>
>         2) The charter allows for a range of implementations of the SUPA system.  Folks may recall I asked in the room at the last
>         meeting whether our chartered allowd both communication between a control system and a device, and communication between a
>         policy repository and a policy engine.  I was told by the AD that the chartered allowed both.  This does make it rather
>         2') I do think that there are a few places in the model, particularly with regard to policy execution status, where the
>         model makes some assumptions about the structure of policy delivery.  For the most part, those should be removed. 
>         Assistance in finding them is appreciated.  I suspect that some of them are necessary, and those should be explicitly
>         described.   (And we should make sure the working group agrees with the assumptions.)
>
>                 <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>>
>                 wrote:
>
>                     From: Supa [mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>] On Behalf Of Zhoutianran
>                     > From: Supa [mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>] On Behalf Of Nevil Brownlee
>                     > >> From: Supa [mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>] On Behalf Of IETF
>                     > >> Secretariat
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>;
>                     > >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>;
>                 [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>                     > >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>                     >   Phone: +64 9 373 7599 x88941 <tel:%2B64%209%20373%207599%20x88941>             The University of
>                 Auckland
>                     >   FAX: +64 9 373 7453 <tel:%2B64%209%20373%207453>   Private Bag 92019, Auckland 1142, New
>                 Zealand
>                     >
>                     > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>                 [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>                 [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 4 Mar 2016 11:10:40 +0100

> Furthermore, Andy, Tianran and Bert all seem willing to support development (via direct contributions) for the framework/architecture document?
Dan, I am willing to take initiative on this.

I saw in one of Johns postings:

John, do you have the piece of text in an XML file (I-D source file) and if so,
can you send that to me. I assume you are OK with us using that as a starting point?

Dan/Nevil, if we submit an in initial I-D timely, do you think we can spend some time
on it in our IETF95 session?

Thanks,
Bert

---

From: "King, Daniel" <[email-masked]>
Date: Fri, 4 Mar 2016 13:34:30 +0000

Hi Bert, 

Thank for taking the initiative. We can make sure there is time on the agenda for the I-D. 

BR, Dan. 

-----Original Message-----
From: Bert Wijnen (IETF) [mailto:[email-masked]] 
Sent: 04 March 2016 10:11
To: King, Daniel <[email-masked]>; Joel M. Halpern <[email-masked]>; Andy Bierman <[email-masked]>; John Strassner <[email-masked]>; Zhoutianran <[email-masked]>
Cc: Nevil Brownlee <[email-masked]>; SUPA list <[email-masked]>
Subject: Re: [Supa] Information models and Data models - WG adopion?

John, do you have the piece of text in an XML file (I-D source file) and if so, can you send that to me. I assume you are OK with us using that as a starting point?

Dan/Nevil, if we submit an in initial I-D timely, do you think we can spend some time on it in our IETF95 session?

Thanks,
Bert

>>>>      > > If we want to finally generate YANG data models here, why 
>>>> do we spend
>>>>      > >> To: 
>>>> [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 4 Mar 2016 09:25:53 -0500

The obverse is that by dealing with both use cases at once, we make sure 
the model is strong enough to address the range of policies and problems 
that need to be covered.

If we as a working group insist on only discussing and addressing one of 
the two, we get two problems:
1) I think we differ as to which is more important
2) It is really hard to extend a narrow model to do a good job on a 
broader problem.

Yours,
Joel

On 3/4/16 4:28 AM, Bert Wijnen (IETF) wrote:
>>         1) Can you help use find the places where the model / text is
>> too implementation specific?  There are a few places where
>>         in describing enumerations the model calls for integers.  In
>> the mapping to YANG, I have already started replacing those
>>         2) The charter allows for a range of implementations of the
>> SUPA system.  Folks may recall I asked in the room at the last
>>         meeting whether our chartered allowd both communication
>> between a control system and a device, and communication between a
>>         policy repository and a policy engine.  I was told by the AD
>> that the chartered allowed both.  This does make it rather
>>         2') I do think that there are a few places in the model,
>> particularly with regard to policy execution status, where the
>>         model makes some assumptions about the structure of policy
>> delivery.  For the most part, those should be removed.
>> Assistance in finding them is appreciated.  I suspect that some of
>> them are necessary, and those should be explicitly
>>         3) (minor) The charter permits the information model.  I
>> presume we could amend the charter to permit an architecture
>>         document.
>>
>>                 <[email-masked]
>> <mailto:[email-masked]>
>> <mailto:[email-masked]
>>                 or the controller level?  What data is available for
>> policy
>>                 enforcement analysis?
>> <mailto:[email-masked]>
>>                 <mailto:[email-masked]
>> <mailto:[email-masked]>>] On Behalf Of Zhoutianran
>> <mailto:[email-masked]>
>>                 <mailto:[email-masked]
>> <mailto:[email-masked]>>] On Behalf Of Nevil Brownlee
>>                     > Subject: Re: [Supa] Information models and Data
>> models - WG
>>                 adopion?
>>                     >
>>                     >
>>                     > Hi Tianran:
>>                     >
>>                     > In my experiences, having a well-defined
>> information model is a
>>                 good starting
>>                     > point.  It allows different implementations,
>> each of which can
>>                 develop it's
>>                     > own data model - in other words, the information
>> model is a good
>>                 unifying
>>                     > influence - which is why publishing such a
>> document is the
>>                 second of our
>>                     > chart items.  I hope that getting a good data
>> model will help us
>>                 with the
>>                     > first chart item ("scope of the policy-based
>> management
>>                 framework").
>>                     >
>> is the only SUPA
>>                     > of these on the SUPA documents page.  It would
>> help at this
>>                 stage if their
>>                     > authors could comment on this list about the
>> status of these
>>                 drafts.  In
>>                     > > Why not focus on the ECA YANG data model
>> directly as standard
>>                 track?
>>                     > >
>>                     > >
>>                     > > Tianran
>>                     > >
>> <mailto:[email-masked]>
>>                 <mailto:[email-masked]
>> <mailto:[email-masked]>>] On Behalf Of IETF
>>                     > >> Secretariat
>>                     > >> [email-masked]
>> <mailto:[email-masked]> <mailto:[email-masked]
>> <mailto:[email-masked] <mailto:[email-masked]>>
>>                     > >> in state Call For Adoption By WG Issued
>> (entered by Nevil
>>                 Brownlee)
>>                     > >>
>>                     > >> This is the first of our charter documents,
>> the other charter
>>                 items
>>                     > >> build on this
>>                     > >>
>> <mailto:[email-masked] <mailto:[email-masked]>>
>>                     >   Phone: +64 9 373 7599 x88941
>> <tel:%2B64%209%20373%207599%20x88941>             The University of
>>                 Auckland
>>                     >   FAX: +64 9 373 7453
>> <tel:%2B64%209%20373%207453>   Private Bag 92019, Auckland 1142, New
>>                 Zealand
>>                     >
>> <mailto:[email-masked] <mailto:[email-masked]>>
>> <mailto:[email-masked] <mailto:[email-masked]>>
>> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: John Strassner <[email-masked]>
Date: Fri, 4 Mar 2016 08:12:16 -0800

I agree with Joel. These two cases SHOULD both be supported
by the model. They stress different aspects of the model and
implementations, but are complementary in past
implementations that I have done.

regards,
John

On Fri, Mar 4, 2016 at 6:25 AM, Joel M. Halpern <[email-masked]> wrote:

>>> models - WG adopion?

-- 
regards,
John

---

From: Andy Bierman <[email-masked]>
Date: Fri, 4 Mar 2016 10:01:39 -0800

On Fri, Mar 4, 2016 at 9:29 AM, Jason Coleman (colemaj) <[email-masked]>
wrote:

> Sending again w/ the correct email address this time:
>
>
>
>
>
> >I would like to be part of working on an architecture document as well.
>

I would like to participate as well, since Bert is willing to take the lead.

It is quite possible I do not understand the development plan implied by
the charter.

I was hoping we would end up with the following standards:

  1) one standard way to express a SUPA policy
  2) one standard "SUPA engine" definition that is capable of understanding
and enforcing specific policies
      2a) device-level SUPA can only access policy and enforce policy on
itself
      2b) controller-level SUPA can be configured to communicate with
multiple network elements
   3) one or more standard protocols should be selected (e.g., NETCONF,
RESTCONF) for
       communication between (2b) and network elements, to support policy
enforcement

IMO, SDOs, vendors or even operators should be able to write SUPA policies.

Andy

> >
> >As for the information model versus data model discussion, I think that
> an information model is required to allow for different data models to
> follow a common structure.
> >It is possible to create a data model first, but that data model may not
> fit in well with other data models.  This is why the information model
> exists to allow for things that may extend that data model or are in place
> for other data models.
> >
> >At this time the focus is on Event, Condition, Action, but there will be
> further management structures to define.
> >The information model supports a general structure and then provides
> details on ECA.  That general structure is important for future data models
> as well.
> >Those may be YANG or other people may chose to use the information model
> to create a data model in a different way.
> >
> >The architecture document would define the role of the information model
> clearly, which I think that part of the ID that John, Joel, and I worked on
> attempts to do as well, and then can show how the data models will be
> supported by the information model and what else the WG Charter has defined
> and possibly where we go next.
> >
> >Jason
> >
> >
> >
> >On 3/4/16, 7:34 AM, "Supa on behalf of King, Daniel" <
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >>Hi Bert,
> >>
> >>To: King, Daniel <[email-masked]>; Joel M. Halpern <
> [email-masked]>; Andy Bierman <[email-masked]>; John Strassner <
> [email-masked]>; Zhoutianran <[email-masked]>
> >>Cc: Nevil Brownlee <[email-masked]>; SUPA list <[email-masked]
> >
> >>> 1) An explanation of the scope of the policy-based management
> framework and how it relates to existing work of the IETF.
> >>>
> >>> A proposal for this document has not been forthcoming thus far. It
> would seem that a "Policy-based Management Framework" discussing
> architecture, applicability and relationships ("system overview") would be
> reasonable content for a framework document mentioned in the Charter?
> >>>
> >>John, do you have the piece of text in an XML file (I-D source file) and
> if so, can you send that to me. I assume you are OK with us using that as a
> starting point?
> >>
> >>Dan/Nevil, if we submit an in initial I-D timely, do you think we can
> spend some time on it in our IETF95 session?
> >>
> >>Thanks,
> >>Bert
> >>
> >>
> >>
> >>> BR, Dan.
> >>>
> >>>> system and a device, and communication between a policy repository
> and a policy engine.  I was told by the AD that the chartered allowed
> >>>>>> <mailto:[email-masked]>>
> >>>>>> wrote:
> >>>>>>

---

From: John Strassner <[email-masked]>
Date: Fri, 4 Mar 2016 19:23:19 +0000

> Your logic is: this is IETF, so text is omnipotent,

Not omnipotent, but applicable and relevant.

> so you use text to describe IM with 100+ pages document for
> interoperation, and then generate UMLs, and finally use
> UML->YANG tool to generate data model.

I fail to understand your point. Hopefully you do not think that UML is
just building pretty pictures; the underlying **language** of UML is
MOF, and MOF is text. More particularly, the graphical format in UML
is not normative; the textual part is.

> My suggestion is: Text used in IETF is not good at describe IM,
> so we use UML for interoperation(but UML output not qualifies
> RFC), and then generate DM.
>

ALL UML tools can generate data models and code. Whether they are
graphical and/or textual is irrelevant.

I said that there is an open source effort to produce YANG from UML. I
did not say that I was using that mechanism.

Finally, how can the WG discuss the info model if it is not in text?

From: Zhoutianran
Sent: Thursday, March 03, 2016 10:53 PM
To: John Strassner
Cc: John Strassner; Juergen Schoenwaelder; Joel M. Halpern; Nevil Brownlee; Andy Bierman; SUPA list
Subject: RE: [Supa] Information models and Data models - WG adopion?

Tianran

Tianran

--
regards,
John

---

From: colemaj <[email-masked]>
Date: Fri, 04 Mar 2016 11:28:29 -0600

As for the information model versus data model discussion, I think that an information model is required to allow for different data models to follow a common structure.  
It is possible to create a data model first, but that data model may not fit in well with other data models.  This is why the information model exists to allow for things that may extend that data model or are in place for other data models.

At this time the focus is on Event, Condition, Action, but there will be further management structures to define.
The information model supports a general structure and then provides details on ECA.  That general structure is important for future data models as well.
Those may be YANG or other people may chose to use the information model to create a data model in a different way.

The architecture document would define the role of the information model clearly, which I think that part of the ID that John, Joel, and I worked on attempts to do as well, and then can show how the data models will be supported by the information model and what else the WG Charter has defined and possibly where we go next.

Jason

---

From: "Jason Coleman (colemaj)" <[email-masked]>
Date: Fri, 4 Mar 2016 17:29:47 +0000

---

From: "Jason Coleman (colemaj)" <[email-masked]>
Date: Fri, 4 Mar 2016 19:39:29 +0000

“Text used in IETF is not good at describe IM”

While this may be true for you, do you believe that this is true for everyone that is going to work on a data model?
I think that you are in agreement that the IM needs to be documented.
The process for documenting things in IETF is in text.

You continue to mention the length of the draft.  If you have a specific issue with the length, then please reference your issue with the length of the draft.

However it appears that your issue is that you wish to create a UML and use that as a reference although UML can not be part of IETF at this time.  Therefore, what is the point of using UML?

UML does a great job of showing relationships, but none of the reasons why a relationship exists between elements in the UML.  The text provides this information.

Jason

From: Supa <[email-masked]<mailto:[email-masked]>> on behalf of Zhoutianran <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 4, 2016 at 12:53 AM
To: John Strassner <[email-masked]<mailto:[email-masked]>>
Cc: John Strassner <[email-masked]<mailto:[email-masked]>>, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>, Andy Bierman <[email-masked]<mailto:[email-masked]>>, Nevil Brownlee <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>, SUPA list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Supa] Information models and Data models - WG adopion?

Tianran

Tianran

--
regards,
John

---

From: Nevil Brownlee <[email-masked]>
Date: Mon, 7 Mar 2016 10:42:00 +1300

Hi Tianran et al:

If what you'd like to see published is a UML diagram, we will - real
soon now - be able to publish a UML diagram as an SVG image in an RFC.
However, right now we can only publish text in Internet Drafts.

Remember that Internet Drafts are exactly that; working documents.
If you have suggestions as to how their text can be improved, do please
send those suggestions to the list - that's the only effective way
to improve the drafts.

A suggestion on this list a few days back was to revive the SUPA 
Management Framework draft (draft-klyus-supa-proposition-02).  I'm
delighted to see efforts under way to make that happen, not least
because it should provide a good introduction to what SUPA is all
about!

Dan and I will soon be starting to put together the Agenda for the SUPA
WG meeting in Buenos Aires.  Please send us details of items you'd like
to see presented and discussed there, the email address is
   [email-masked] <[email-masked]>

Cheers, Nevil

---

From: Zhoutianran <[email-masked]>
Date: Mon, 7 Mar 2016 03:48:50 +0000

Hi Jason,

>The architecture document would define the role of the information model clearly

I would very like to see this been discussed and addressed in the architecture document.
Especially, 
1. How the information model can help data model generation if we know we will deliver YANG DMs? I mean on one hand we can improve the information model, then generate a YANG DM; on the other hand, we can just work on a YANG DMs and improve it. What's the difference? 
2. What should be defined in IM, what in DM. Best with some examples. After all, IM cannot be used in a system implementation, we need DMs. 
3. We can define a YANG DM with "augment", "grouping-use", or design items with "type-value" pair. So that there will be generic DM and specific DM. Then how can IM be more for DM.

If those could be address, I think that will be much help.

Best,
Tianran

> From: Jason Coleman (colemaj) [mailto:[email-masked]] On Behalf Of
> colemaj
> Sent: Saturday, March 05, 2016 1:28 AM
> To: King, Daniel; Bert Wijnen (IETF); Joel M. Halpern; Andy Bierman; John
> Strassner; Zhoutianran
> an information model is required to allow for different data models to follow
> a common structure.
> fit in well with other data models.  This is why the information model exists
> to allow for things that may extend that data model or are in place for
> other data models.
> 
> The information model supports a general structure and then provides details
> on ECA.  That general structure is important for future data models as well.
> clearly, which I think that part of the ID that John, Joel, and I worked
> on attempts to do as well, and then can show how the data models will be
> On 3/4/16, 7:34 AM, "Supa on behalf of King, Daniel" <[email-masked]
> on behalf of [email-masked]> wrote:
> 
> >Hi Bert,
> >
> >To: King, Daniel <[email-masked]>; Joel M. Halpern
> ><[email-masked]>; Andy Bierman <[email-masked]>; John
> >Strassner <[email-masked]>; Zhoutianran
> ><[email-masked]>
> if so, can you send that to me. I assume you are OK with us using that as
> a starting point?
> >
> >>> particularly with regard to policy execution status, where the model
> makes some assumptions about the structure of policy delivery.  For the most
> part, those should be removed.  Assistance in finding
> >>>>> I am not objecting to an info model doc.  A system architecture
> >>>>> and a workable solution will require a lot more than that.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>      John
> >>>>>
> >>>>>
> >>>>>
> >>>>> Andy
> >>>>>
> >>>>>
> >>>>>      > >> in state Call For Adoption By WG Issued (entered by
> >>>>> Nevil
> >>>>> Brownlee)
> >>>>>      > >>

---

From: Zhoutianran <[email-masked]>
Date: Tue, 8 Mar 2016 16:04:02 +0000

My brief thoughts on SUPA arch is as follows: 

1. Position of the policy engine
Network can be modeled with multiple layers. Policies can be applied to all the layers to achieve requirements from various type of actors.
a) device-level: policy can only be accessed and enforced on one device. The policy controls the dynamic behaviours, e.g. QoS, decapsulation, encapsulation, and forwarding. 
b) network-level: policy can be configured to communicate with multiple network elements. The policy controls the adjustment of technique related network solutions, e.g. L3VPN, L2VPN.
c) service-level: policies are abstracted to be technique independent, and provided for the higher level users. The customer facing policy is provided to reduce the operation on service level agreement, generic VPN service, unified tunnel services.

2. policy engine framework
This is a brief policy engine framework.

higher level event
  ^          + policy operations
  |          |
  |          |
+-+----------v-------+
|                    <------+
|    Policy Engine   |  concrete policy DM
|                    |
+-^------------------+
  |
  |
  + lower level event

The policy engine is configured with concrete policy DMs, so that it can deal with assigned policies. The concrete policy DM can generate data-store and northbound interface for the policy engine.
One or more standard protocols should be selected (e.g., NETCONF, RESTCONF) for policy operations to communicate with the Policy Engine. 
The policy engine runs with monitoring the lower level events from the southbound.
Higher level events may be generated by the policy engine, so that policy engine or applications sitting on a higher level can consume.

3. policy data model
The policy data model describes in detail about the protocol operations and data-store content. It serves as an "API contract" honored by the policy engine, and is essential to the model driven policy API. The well defined policy model structure facilities both flexibility and extensibility.
a) generic policy model: defines a generic policy header and the policy body structure. The generic policy header contains information on, e.g. name, identifier, life cycle, which can be shared by all the specific policy models. The generic policy body could be a ordered list of policy rules. But the details on how the policy rule like is extended by the specific policy model, e.g. ECA policy model.
b) specific policy model: inherits from the generic policy model with specific extensions on the policy rule. For example the ECA policy model extends the policy rule with Event-Condition-Action definition.
c) concrete policy model: is rendered based on the specific model by SDOs, vendors or operators. It represents concrete technique and vendor implementation. For example, a concrete Event, like time event, packet-in.

4. information modeling
How the information model can help data model generation? What should be defined in IM, what in DM?
a) The DM document should be more on how to represent informaitons in YANG, while the IM document can have more words introducing what an item is and why we need an item.
b) The IM helps other DM creation rather than YANG both in and outside IETF.

Best,
Tianran

--------------------------------------------------------------------------------------------------
发件人: Andy Bierman [[email-masked]]
发送时间: 2016年3月5日 2:01
收件人: Jason Coleman (colemaj)
抄送: King, Daniel; Bert Wijnen (IETF); Joel M. Halpern; John Strassner; Zhoutianran; Nevil Brownlee; SUPA list
主题: Re: [Supa] Information models and Data models - WG adopion?

On Fri, Mar 4, 2016 at 9:29 AM, Jason Coleman (colemaj) <[email-masked]> wrote:

It is quite possible I do not understand the development plan implied by the charter.

  1) one standard way to express a SUPA policy
  2) one standard "SUPA engine" definition that is capable of understanding and enforcing specific policies
      2a) device-level SUPA can only access policy and enforce policy on itself
      2b) controller-level SUPA can be configured to communicate with multiple network elements
   3) one or more standard protocols should be selected (e.g., NETCONF, RESTCONF) for
       communication between (2b) and network elements, to support policy enforcement

Andy