From nobody Tue Mar 1 14:56:29 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DF01B42F0 for ; Tue, 1 Mar 2016 14:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.307 X-Spam-Level: X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 GgPTHYO06eDy for ; Tue, 1 Mar 2016 14:56:25 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE2D1B42ED for ; Tue, 1 Mar 2016 14:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1456872985; x=1488408985; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=nuRkz6z3kf8Q4XKaQj3BgZ98E+6ezzM7kDcWAaVVXFA=; b=bTMibwawNtNkzWH8pM9xkDJXATRCnascif+tqZxhzyvbfVQAHsSbxxrT fy2of0LTdVhTm9JATWkTF+5EYgpz0ilg9jiTagGCTrylVpS7LdoKal3n0 hJIlWK3AiChKx9dpV61WaKCDIkFfHXtOLqe3mHtKLi1tod6EPDif9+3qA VwzpoI512L/aAkYYLblY7NA5aVmAPh5tLUYZsB3JJEgSesb+DnT9Pdr8j eWRrgqVjUWXmeKZVFMPwfKYE1ACULSiN7FJ3iCNXI7JGkNZN1gjqKUEAc D1yw5fvmSJA6GTCE2aB7EK9o+Khf2aLx6G843hiFcGDBZu2V79g1+L+ks g==; X-IronPort-AV: E=Sophos;i="5.22,524,1449486000"; d="scan'208";a="71351255" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.7 - Outgoing - Outgoing-SSL Received: from sc-cs-316051.uoa.auckland.ac.nz (HELO [130.216.38.7]) ([130.216.38.7]) by mx4-int.auckland.ac.nz with ESMTP; 02 Mar 2016 11:56:22 +1300 To: Zhoutianran References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> From: Nevil Brownlee Message-ID: <56D61E15.1070302@auckland.ac.nz> Date: Wed, 2 Mar 2016 11:56:21 +1300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:56:28 -0000 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:supa-bounces@ietf.org] On Behalf Of IETF Secretariat >> Sent: Monday, February 29, 2016 6:35 AM >> To: draft-strassner-supa-generic-policy-info-model@ietf.org; >> supa-chairs@ietf.org; supa@ietf.org >> 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 >> Supa@ietf.org >> 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 nobody Tue Mar 1 18:44:19 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058601B4564 for ; Tue, 1 Mar 2016 18:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 GSxPE3o9Rlcl for ; Tue, 1 Mar 2016 18:44:15 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9EC1B4559 for ; Tue, 1 Mar 2016 18:44:14 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id l83so78856242lfd.3 for ; Tue, 01 Mar 2016 18:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=z6IoFypDbk4muqsDfDZ/QqGqBL9bb+xabofjG+LBaiY=; b=Zbw9thhhkS9w1do4kuQfQ5A+0XSWM/J9bmnSG3KZ2eLnFoMgZ8YsDeCD1YTy8Rzblu DQ1GvIu0Iq02ow67Qm/uDLh7rwHuEZaemKKoX3G44GhcGWkiWd462Iq2QLm9wY/69B4n hPJEPHoKPfgcx21qXgjQSn/b6sex/6kSoXCZGoEHSdDu5C8bSeM993gWlXh4wlIZqjbz 5LNJQhwWJsrZtzBBbsSZYYWdTznqu46woxzeITA1hB9w6DfhO79/wMiVt9hyXO3hKpIt VZ1UOQ90No/zuRoyKGYlNx8VWzZoN2624zE2xEt2hLlVXY2H0cYr5oYwDPHIRRbD8jHH +1Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=z6IoFypDbk4muqsDfDZ/QqGqBL9bb+xabofjG+LBaiY=; b=ZTk0OfHaz2AgNSkzWwJg0nHeGoG0KejJpUz+kVnqFApfGcb40gCCwAA1UjTua6QkEV BKssHQDQET9QKXOJilY7ytZbeXwS00d9AX7E3y3FRXtu6oeSGJaKqhjNHewWgkGgB9vj 6DDyJN0xLrOzw2jrcRCXu8Jl57XMZgenZf8gqcbliSxXRqOsB0jbYbIdsK0y8znNeOE3 rTev3A7SOqZyrqz10iRTE+w+nuIOg7pmUlkE0PKkewn+mH/KIoSPb68skvjTqGUuFVEC GAfGnbk+cSU3pzXXHda2yBLxCoHN9wQfo1wNv8G+FwF8tEWaK0W4QDWKVgwqGN2Rk5Kb Y20Q== X-Gm-Message-State: AD7BkJJg0hvMUPU4bANbrWhpNGB1Jf/5oV0pDe+4Kh15LLZKPgyHAUDktw4zGOPhc2kDfxS7X+MhNxaJ6jQK/A== MIME-Version: 1.0 X-Received: by 10.25.158.72 with SMTP id h69mr9720369lfe.8.1456886653001; Tue, 01 Mar 2016 18:44:13 -0800 (PST) Received: by 10.112.110.68 with HTTP; Tue, 1 Mar 2016 18:44:12 -0800 (PST) In-Reply-To: <56D61E15.1070302@auckland.ac.nz> References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> Date: Tue, 1 Mar 2016 18:44:12 -0800 Message-ID: From: Andy Bierman To: Nevil Brownlee Content-Type: multipart/alternative; boundary=001a11401b3c6e3de7052d07db52 Archived-At: Cc: Zhoutianran , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 02:44:18 -0000 --001a11401b3c6e3de7052d07db52 Content-Type: text/plain; charset=UTF-8 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 . 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 . 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 On Tue, Mar 1, 2016 at 2:56 PM, Nevil Brownlee wrote: > > 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:supa-bounces@ietf.org] On Behalf Of IETF Secretariat >>> Sent: Monday, February 29, 2016 6:35 AM >>> To: draft-strassner-supa-generic-policy-info-model@ietf.org; >>> supa-chairs@ietf.org; supa@ietf.org >>> 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 >>> Supa@ietf.org >>> 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 > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > --001a11401b3c6e3de7052d07db52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

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

It is n= ot clear if this document will have any normative impact on the solution
or not.=C2=A0 Is an solution required to provide all the functional= ity of this info model?
Is the solution allowed to support more t= han this info model covers?

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

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

YANG is not eve= n listed as a constraint language (e.g. 5.7.2.1).
I am curious ho= w I write SUPA policy in YANG.=C2=A0 I am curious how
existing YA= NG modules such as ietf-interfaces or ietf-routing are used in SUPA.
<= div>If the WG has no clue about the answers to these fundamental questions,= that
is cause for concern.



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:  undefin=
ed
      1:  String
      2:  GUID
      3:  UUID
      4:  URI
      5:  FQDN

5.7.2.1.  The Attribute "sup=
aPolCompConstraintEncoding"


   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


On Tue, = Mar 1, 2016 at 2:56 PM, Nevil Brownlee <n.brownlee@auckland.ac.nz<= /a>> wrote:

Hi Tianran:

In my experiences, having a well-defined information model is a good
starting point.=C2=A0 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.=C2=A0 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<= br> are two of these on the SUPA documents page.=C2=A0 It would help at
this stage if their authors could comment on this list about the
status of these drafts.=C2=A0 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:supa-bounces@ietf.org] On Behalf Of IETF Secretariat
Sent: Monday, February 29, 2016 6:35 AM
To: draft-strassner-supa-generic-policy-info-model@ietf.o= rg;
supa-chairs@ietf.= org; supa@ietf.org
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/d= oc/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
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa


--
---------------------------------------------------------------------
=C2=A0Nevil Brownlee=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Computer Science Department
=C2=A0Phone: +64 9 373 7599 x88941=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0The University of Auckland
=C2=A0FAX: +64 9 373 7453=C2=A0 =C2=A0Private Bag 92019, Auckland 1142, New= Zealand

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

--001a11401b3c6e3de7052d07db52-- From nobody Tue Mar 1 19:29:31 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39741B466C for ; Tue, 1 Mar 2016 19:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 4IQKRc8AHm8y for ; Tue, 1 Mar 2016 19:29:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1591B466E for ; Tue, 1 Mar 2016 19:29:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJK22670; Wed, 02 Mar 2016 03:29:20 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Mar 2016 03:29:19 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Wed, 2 Mar 2016 11:29:13 +0800 From: Zhoutianran To: Nevil Brownlee Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2mOZC2OcBCLECSqIAKm8tvNJ9FdHGA Date: Wed, 2 Mar 2016 03:29:12 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> In-Reply-To: <56D61E15.1070302@auckland.ac.nz> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56D65E11.0151, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 97528be5817d802e4f99a7371c95f527 Archived-At: Cc: SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 03:29:29 -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 > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] 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? >=20 >=20 > Hi Tianran: >=20 > In my experiences, having a well-defined information model is a good star= ting > 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"). >=20 > 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. >=20 > 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 thei= r > authors could comment on this list about the status of these drafts. In > particular, jave they been working on a new version? >=20 > Overall, we really need more discussion on the list of what's happening > with the SUPA work! >=20 > Cheers, Nevil >=20 >=20 > 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:supa-bounces@ietf.org] On Behalf Of IETF > >> Secretariat > >> Sent: Monday, February 29, 2016 6:35 AM > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org; > >> supa-chairs@ietf.org; supa@ietf.org > >> 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 > >> Supa@ietf.org > >> https://www.ietf.org/mailman/listinfo/supa >=20 >=20 > -- > --------------------------------------------------------------------- > 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 >=20 > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa From nobody Tue Mar 1 21:10:05 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6652A1B48BF for ; Tue, 1 Mar 2016 21:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 MZndNUeWsbpQ for ; Tue, 1 Mar 2016 21:10:00 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCA21B48BC for ; Tue, 1 Mar 2016 21:10:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B1CF31C052D; Tue, 1 Mar 2016 21:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1456895400; bh=gqVcw9fmY2wQFPW7xTQm3dfCEzeWsEHSy70CH9rqQyA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=pgFyt7wYkeHGClG2OLLT5SDbK8JfrhZe5XWfmn5IaXFnoCNVAq/DM3K6NP1w9cw/F HZkmgjgkY9dZVWhu4/UfAoxs7JwVskcWoL3tU0hW82CqifjfzjPw8uzmoC7JwXTyln +zUfTNMnodjm5vzP6LOeDuXR63kuoZUasEG/fKAU= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from joels-mbp.home (pool-98-114-54-183.phlapa.fios.verizon.net [98.114.54.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E2A4D1C04D4; Tue, 1 Mar 2016 21:09:59 -0800 (PST) To: Andy Bierman , Nevil Brownlee References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> From: "Joel M. Halpern" Message-ID: <56D675A6.5010409@joelhalpern.com> Date: Wed, 2 Mar 2016 00:09:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Zhoutianran , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 05:10:03 -0000 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: > 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 > . > 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 > . > 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 > > > On Tue, Mar 1, 2016 at 2:56 PM, Nevil Brownlee > > wrote: > > > 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:supa-bounces@ietf.org > ] On Behalf Of IETF Secretariat > Sent: Monday, February 29, 2016 6:35 AM > To: draft-strassner-supa-generic-policy-info-model@ietf.org > ; > supa-chairs@ietf.org ; > supa@ietf.org > 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 > Supa@ietf.org > 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 > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Tue Mar 1 22:45:14 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B771A1AA3 for ; Tue, 1 Mar 2016 22:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 T2Z-3cPlUuuS for ; Tue, 1 Mar 2016 22:45:10 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B73D1A1A9E for ; Tue, 1 Mar 2016 22:45:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 68A081BA0; Wed, 2 Mar 2016 07:45:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id V_t1MjnOiAC1; Wed, 2 Mar 2016 07:44:57 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 2 Mar 2016 07:45:07 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AEFDE20038; Wed, 2 Mar 2016 07:45:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HsFDHWTorZlz; Wed, 2 Mar 2016 07:45:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89C9020036; Wed, 2 Mar 2016 07:45:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 368A13A03165; Wed, 2 Mar 2016 07:45:05 +0100 (CET) Date: Wed, 2 Mar 2016 07:45:05 +0100 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20160302064505.GA30528@elstar.local> Mail-Followup-To: "Joel M. Halpern" , Andy Bierman , Nevil Brownlee , Zhoutianran , SUPA list References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D675A6.5010409@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Zhoutianran , Nevil Brownlee , Andy Bierman , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 06:45:12 -0000 On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote: > 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. 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 From nobody Wed Mar 2 06:15:12 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94DB1B2B27 for ; Wed, 2 Mar 2016 06:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 LiXm7tJamqwa for ; Wed, 2 Mar 2016 06:15:09 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9E81B2B23 for ; Wed, 2 Mar 2016 06:15:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4625B1C04D4; Wed, 2 Mar 2016 06:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1456928109; bh=xrfQomd3cPovgs2nG/WEaQi6b0mzExjwWt/Wx9M+SA4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=UCJoZI8vW+UYvNvH4FzL+KXHKxQ42sRKSQ6cZki1/2LyUYPoJAQlCOHq9IH/bdjhC YolD+9pBoC8rD1A+jijJ34cg3gcx60NgMQo1tgy9rRJcJdyLGbCFMbNbEMBnX30tqO nAfJdrIpuNSKnu1m2xmuH0ZX/Rk1tI7IoETDFm+M= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-98-114-54-183.phlapa.fios.verizon.net [98.114.54.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 84AB51C0073; Wed, 2 Mar 2016 06:15:08 -0800 (PST) To: "Joel M. Halpern" , Andy Bierman , Nevil Brownlee , Zhoutianran , SUPA list References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> From: "Joel M. Halpern" Message-ID: <56D6F56C.1040708@joelhalpern.com> Date: Wed, 2 Mar 2016 09:15:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160302064505.GA30528@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 14:15:11 -0000 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 On 3/2/16 1:45 AM, Juergen Schoenwaelder wrote: > On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote: > >> 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. > > 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 > From nobody Wed Mar 2 19:22:19 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A114F1A8716 for ; Wed, 2 Mar 2016 19:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 BSPagvZ09fpK for ; Wed, 2 Mar 2016 19:22:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D2B1A86F0 for ; Wed, 2 Mar 2016 19:22:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJL63615; Thu, 03 Mar 2016 03:22:11 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Mar 2016 03:22:09 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.143]) by SJCEML702-CHM.china.huawei.com ([169.254.4.108]) with mapi id 14.03.0235.001; Wed, 2 Mar 2016 19:22:00 -0800 From: John Strassner To: Zhoutianran , Nevil Brownlee , John Strassner Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2rx5wdWV9zckyTIiHCBdvZs59GBWEAgAD+DLA= Date: Thu, 3 Mar 2016 03:21:59 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.56D7ADE4.0059, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.143, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 97528be5817d802e4f99a7371c95f527 Archived-At: Cc: SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 03:22:18 -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:supa-bounces@ietf.org] 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, 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 > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] 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? >=20 >=20 > Hi Tianran: >=20 > In my experiences, having a well-defined information model is a good star= ting > 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"). >=20 > 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. >=20 > 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 thei= r > authors could comment on this list about the status of these drafts. In > particular, jave they been working on a new version? >=20 > Overall, we really need more discussion on the list of what's happening > with the SUPA work! >=20 > Cheers, Nevil >=20 >=20 > 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:supa-bounces@ietf.org] On Behalf Of IETF > >> Secretariat > >> Sent: Monday, February 29, 2016 6:35 AM > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org; > >> supa-chairs@ietf.org; supa@ietf.org > >> 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 > >> Supa@ietf.org > >> https://www.ietf.org/mailman/listinfo/supa >=20 >=20 > -- > --------------------------------------------------------------------- > 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 >=20 > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Wed Mar 2 20:01:00 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151751B3B4C for ; Wed, 2 Mar 2016 20:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 8zg0sZcgkN2i for ; Wed, 2 Mar 2016 20:00:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D044F1B3AEB for ; Wed, 2 Mar 2016 20:00:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFG32794; Thu, 03 Mar 2016 04:00:51 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Mar 2016 04:00:49 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 3 Mar 2016 12:00:42 +0800 From: Zhoutianran To: Juergen Schoenwaelder , "Joel M. Halpern" Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2mOZC2OcBCLECSqIAKm8tvNJ9E7JYAgAAougCAABqTgIAB5T0A Date: Thu, 3 Mar 2016 04:00:41 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> In-Reply-To: <20160302064505.GA30528@elstar.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56D7B6F4.007B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 071bb84bb764e94a94ef44b694de3e28 Archived-At: Cc: Nevil Brownlee , Andy Bierman , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 04:00:59 -0000 Hi Juergen, Emmm, the round trip you mentioned much like the spiral model in software e= ngineering. That's of course a good way to do system design and implementat= ion.=20 However, in this process, the information model is like an intermediary sta= te, 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 UM= L drawing shared during the DM design. And those make life simpler for expr= ess 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 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, March 02, 2016 2:45 PM > To: Joel M. Halpern > Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list > Subject: Re: [Supa] Information models and Data models - WG adopion? >=20 > On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote: >=20 > > First, the entire information model will be rendered intoa YANG data mo= del. > > 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. >=20 > 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: >=20 > info model -> data model -> implementation -> data model updates -> > information model updates >=20 > 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 bec= ause > you expect interoperability based on the info model, then I believe a ful= l > 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 da= ta > 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. >=20 > So the key question for me is which function the info model is supposed > to fulfill. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Wed Mar 2 21:06:53 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386671B3D04 for ; Wed, 2 Mar 2016 21:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 acZwUVrpSlcc for ; Wed, 2 Mar 2016 21:06:47 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1B51B3D08 for ; Wed, 2 Mar 2016 21:06:45 -0800 (PST) Received: by mail-lb0-x232.google.com with SMTP id bc4so9869899lbc.2 for ; Wed, 02 Mar 2016 21:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=EOVLX2iq8fPirz40iQ+TJFUAki0DcGsohiwA5abgR0U=; b=Oahomc4n1VM+WQHPknsbKXRtvAqIx5g8og24VtkHWhonuzvE3r2YQsYrrrzrl7fpRY GSKmWHdXHBkposiv4weCP3CD+ZMG3Juw9cHfDljcri7ki42wBrg28oCdEBMVTb3vW90u owje0qTZ3QgLDr4960QCR6sifFC34v6t/p+OZW83gfvgWAzDkPMknHWjarDUrc/9ZkpC QwM2tP6jZNWH4BC+R4U2ePvsgx1VgimgwQHbgZuE6ToYjik4Unt+Le6BBAQ49+Yhsn6W o35gTvOHRSokHFrqjFNv6x9dJAl4ebkB86hNAZw6iWqeersQjv4qgTR4/3+yOK+S5rZx /KWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=EOVLX2iq8fPirz40iQ+TJFUAki0DcGsohiwA5abgR0U=; b=QQ26+cxMzl0Cp/stnVyKTbKIMd8uKL3YTikOeuNLiF5bFFkngJNcos8d4y+KpCTRUO uEtoebm82tAaI+kP08ljb72w7uiP21UQJ1MSJoxfnZhbqoBZQU17xYLKHPe6U3rlZ9Ak RB3Nu8qZWa+KkTzto2U+5QTtL/Dng5NozP0nDq0HkWiqgk6YUqF5X9hZotrWIzcwc9Ot y7gQiM1U53LlcHJ018jqslz8iyn8Po6brRmvUvIxyk6LjAdQQQpd+Qn/Bu6WuCDPl4u0 2vkOMLAp0fYuxON3fUKHU9wqZPxEcPh4uLKDFuDFBsma6v5nhf/LQnb+FtWsK5XSvpk/ AFFg== X-Gm-Message-State: AD7BkJKsyETbquSfbJzJ7sLHZ4LunOzGurYzi13wox5dekp/y2UjRCly0HkNHwP26JtvqnrlcPM9WzqyYYHLtQ== MIME-Version: 1.0 X-Received: by 10.25.85.145 with SMTP id j139mr213983lfb.131.1456981603452; Wed, 02 Mar 2016 21:06:43 -0800 (PST) Received: by 10.112.110.68 with HTTP; Wed, 2 Mar 2016 21:06:43 -0800 (PST) In-Reply-To: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> Date: Wed, 2 Mar 2016 21:06:43 -0800 Message-ID: From: Andy Bierman To: John Strassner Content-Type: multipart/alternative; boundary=001a11405936eb20df052d1df664 Archived-At: Cc: Zhoutianran , Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 05:06:50 -0000 --001a11405936eb20df052d1df664 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 2, 2016 at 7:21 PM, John Strassner wrote: > 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. > > 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. > John > > Andy > > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] 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, > > 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 > > > -----Original Message----- > > From: Supa [mailto:supa-bounces@ietf.org] 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"). > > > > 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:supa-bounces@ietf.org] On Behalf Of IETF > > >> Secretariat > > >> Sent: Monday, February 29, 2016 6:35 AM > > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org; > > >> supa-chairs@ietf.org; supa@ietf.org > > >> 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 > > >> Supa@ietf.org > > >> 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 > > > > _______________________________________________ > > Supa mailing list > > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > --001a11405936eb20df052d1df664 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 2, 2016 at 7:21 PM, John Strassner <John.sc.Str= assner@huawei.com> wrote:
We should work = on an information model for several reasons, even if
there is only target data model (i.e., YANG):

=C2=A0 1) An information model can define how data are related to each
=C2=A0 =C2=A0 =C2=A0other independent of implementation. This is much harde= r to do
=C2=A0 =C2=A0 =C2=A0in YANG. Hence, the information model may make these in= herent
=C2=A0 =C2=A0 =C2=A0relationships easier to visualize and define.
=C2=A0 2) An information model separates the logical design from the
=C2=A0 =C2=A0 =C2=A0physical design of the system, enabling a deeper unders= tanding
=C2=A0 =C2=A0 =C2=A0of both independent of implementation. This can be used= to
=C2=A0 =C2=A0 =C2=A0produce more powerful implementations.
=C2=A0 3) If an information model is worked on in another organization,
=C2=A0 =C2=A0 =C2=A0there is no guarantee that its output will be useful to= the
=C2=A0 =C2=A0 =C2=A0IETF. I am active in the TM Forum, which you cited; the= y are
=C2=A0 =C2=A0 =C2=A0in general not worried about implementing YANG models, = much
=C2=A0 =C2=A0 =C2=A0less producing optimal YANG models.
=C2=A0 4) This enables other SDOs and fora, which do not use YANG, to
=C2=A0 =C2=A0 =C2=A0more easily understand our output.



It seems to me that you= r draft has many details related to the abstraction
of policy log= ic, 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 docume= nt first.
I don't see how we can agree on an info-model in th= e absence
of a system architecture.=C2=A0

Does SUPA run anywhere? What does it even mean to implement SUPA?
Will people be able to build interoperable SUPA engines from the RFC= s?
Is there a difference between a SUPA engine running at the dev= ice level
or the controller level?=C2=A0 What data is available f= or policy enforcement analysis?
Is this configurable through YANG= modules implemented by a SUPA engine?
How are policies defined a= nd managed within the SUPA implementation?
How is device config a= ltered 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.=C2=A0 A system architecture and= a workable solution
will require a lot more than that.






=C2=A0
John



Andy
=C2=A0

-----Original Message-----
From: Supa [mailto:supa-bounces@ie= tf.org] 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,

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

> -----Original Message-----
> From: Supa [mailto:supa-bounc= es@ietf.org] 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 s= tarting
> point.=C2=A0 It allows different implementations, each of which can de= velop it's
> own data model - in other words, the information model is a good unify= ing
> influence - which is why publishing such a document is the second of o= ur
> chart items.=C2=A0 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, th= erefore
> I've proposed it for WG adoption.
>
> As for the third charter item - "set of YANG data models", t= here are two
> of these on the SUPA documents page.=C2=A0 It would help at this stage= if their
> authors could comment on this list about the status of these drafts.= =C2=A0 In
> particular, jave they been working on a new version?
>
> Overall, we really need more discussion on the list of what's happ= ening
> 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 s= pend
> time working on this information model?
> >
> > Why not focus on the ECA YANG data model directly as standard tra= ck?
> >
> >
> > Tianran
> >
> >> -----Original Message-----
> >> From: Supa [mailto:s= upa-bounces@ietf.org] On Behalf Of IETF
> >> Secretariat
> >> Sent: Monday, February 29, 2016 6:35 AM
> >> To: draft-strassner-supa-generic-policy-info-model@ietf.org;
> >> supa-chairs@ietf.org<= /a>; supa@ietf.org
> >> 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-in= fo-model
> >> in state Call For Adoption By WG Issued (entered by Nevil Bro= wnlee)
> >>
> >> The document is available at
> >>
> https://datatracker.ietf.o= rg/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
> >> Supa@ietf.org
> >> https://www.ietf.org/mailman/listinfo/supa
>
>
> --
> ---------------------------------------------------------------------<= br> >=C2=A0 =C2=A0Nevil Brownlee=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Computer Science Departmen= t
>=C2=A0 =C2=A0Phone: +64 9 373 7599 x88941=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0The University of Auckland
>=C2=A0 =C2=A0FAX: +64 9 373 7453=C2=A0 =C2=A0Private Bag 92019, Aucklan= d 1142, New Zealand
>
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

--001a11405936eb20df052d1df664-- From nobody Wed Mar 2 22:19:05 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69D81B3E6F for ; Wed, 2 Mar 2016 22:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 X1XkewKyhw3q for ; Wed, 2 Mar 2016 22:18:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0CD1B3E6E for ; Wed, 2 Mar 2016 22:18:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFG42021; Thu, 03 Mar 2016 06:18:55 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Mar 2016 06:18:53 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0235.001; Thu, 3 Mar 2016 14:18:45 +0800 From: Zhoutianran To: Andy Bierman , John Strassner Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2mOZC2OcBCLECSqIAKm8tvNJ9FdHGAgAEVCICAAB1DgIAAltLg Date: Thu, 3 Mar 2016 06:18:44 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2183B84D72NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56D7D750.00D0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 071bb84bb764e94a94ef44b694de3e28 Archived-At: Cc: Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 06:19:04 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2183B84D72NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEFuZHkgb24gdGhlIFNVUEEgYXJjaGl0ZWN0dXJlLiBBbmQgSSB0aGluayBB bmR5IGhhcyBwb3N0ZWQgbWFueSB1c2VmdWwgaWRlYXMgb24gcXVlc3Rpb25zIHRoYXQgd2UgbmVl ZCB0byBzb2x2ZSBpbiB0aGUgYXJjaCBkb2MuDQpUaGlzIGRvY3VtZW50IHNob3VsZCBmaXJzdGx5 IGJlIGRlbGl2ZXJlZCwgd2hpbGUgaW5mb3JtYXRpb24gbW9kZWwgaXMganVzdCBvbmUgYXNwZWN0 IHRoYXQgbWF5IGhlbHAgdGhlIGRhdGEgbW9kZWwgZGVzaWduLg0KDQpNb3Jlb3ZlciwgSSBkbyBu b3QgdGhpbmsgdGV4dCBkb2N1bWVudCBpcyB0aGUgYmVzdCB0b29sIGZvciBpbmZvcm1hdGlvbiBt b2RlbGluZy4gTW9zdCBvcmdhbml6YXRpb25zIHVzZSBVTUwgZm9yIGl0Lg0KDQpJZiBTVVBBIGhh cyBwbGFuIHRvIGRlbGl2ZXIgc3VjaCBhbiBhcmNoaXRlY3R1cmUgZG9jLCBJIHdvdWxkIHZlcnkg bGlrZSB0byBjb250cmlidXRlLg0KDQpCZXN0LA0KVGlhbnJhbg0KDQpGcm9tOiBBbmR5IEJpZXJt YW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMDMs IDIwMTYgMTowNyBQTQ0KVG86IEpvaG4gU3RyYXNzbmVyDQpDYzogWmhvdXRpYW5yYW47IE5ldmls IEJyb3dubGVlOyBTVVBBIGxpc3QNClN1YmplY3Q6IFJlOiBbU3VwYV0gSW5mb3JtYXRpb24gbW9k ZWxzIGFuZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/DQoNCg0KDQpPbiBXZWQsIE1hciAyLCAy MDE2IGF0IDc6MjEgUE0sIEpvaG4gU3RyYXNzbmVyIDxKb2huLnNjLlN0cmFzc25lckBodWF3ZWku Y29tPG1haWx0bzpKb2huLnNjLlN0cmFzc25lckBodWF3ZWkuY29tPj4gd3JvdGU6DQpXZSBzaG91 bGQgd29yayBvbiBhbiBpbmZvcm1hdGlvbiBtb2RlbCBmb3Igc2V2ZXJhbCByZWFzb25zLCBldmVu IGlmDQp0aGVyZSBpcyBvbmx5IHRhcmdldCBkYXRhIG1vZGVsIChpLmUuLCBZQU5HKToNCg0KICAx KSBBbiBpbmZvcm1hdGlvbiBtb2RlbCBjYW4gZGVmaW5lIGhvdyBkYXRhIGFyZSByZWxhdGVkIHRv IGVhY2gNCiAgICAgb3RoZXIgaW5kZXBlbmRlbnQgb2YgaW1wbGVtZW50YXRpb24uIFRoaXMgaXMg bXVjaCBoYXJkZXIgdG8gZG8NCiAgICAgaW4gWUFORy4gSGVuY2UsIHRoZSBpbmZvcm1hdGlvbiBt b2RlbCBtYXkgbWFrZSB0aGVzZSBpbmhlcmVudA0KICAgICByZWxhdGlvbnNoaXBzIGVhc2llciB0 byB2aXN1YWxpemUgYW5kIGRlZmluZS4NCiAgMikgQW4gaW5mb3JtYXRpb24gbW9kZWwgc2VwYXJh dGVzIHRoZSBsb2dpY2FsIGRlc2lnbiBmcm9tIHRoZQ0KICAgICBwaHlzaWNhbCBkZXNpZ24gb2Yg dGhlIHN5c3RlbSwgZW5hYmxpbmcgYSBkZWVwZXIgdW5kZXJzdGFuZGluZw0KICAgICBvZiBib3Ro IGluZGVwZW5kZW50IG9mIGltcGxlbWVudGF0aW9uLiBUaGlzIGNhbiBiZSB1c2VkIHRvDQogICAg IHByb2R1Y2UgbW9yZSBwb3dlcmZ1bCBpbXBsZW1lbnRhdGlvbnMuDQogIDMpIElmIGFuIGluZm9y bWF0aW9uIG1vZGVsIGlzIHdvcmtlZCBvbiBpbiBhbm90aGVyIG9yZ2FuaXphdGlvbiwNCiAgICAg dGhlcmUgaXMgbm8gZ3VhcmFudGVlIHRoYXQgaXRzIG91dHB1dCB3aWxsIGJlIHVzZWZ1bCB0byB0 aGUNCiAgICAgSUVURi4gSSBhbSBhY3RpdmUgaW4gdGhlIFRNIEZvcnVtLCB3aGljaCB5b3UgY2l0 ZWQ7IHRoZXkgYXJlDQogICAgIGluIGdlbmVyYWwgbm90IHdvcnJpZWQgYWJvdXQgaW1wbGVtZW50 aW5nIFlBTkcgbW9kZWxzLCBtdWNoDQogICAgIGxlc3MgcHJvZHVjaW5nIG9wdGltYWwgWUFORyBt b2RlbHMuDQogIDQpIFRoaXMgZW5hYmxlcyBvdGhlciBTRE9zIGFuZCBmb3JhLCB3aGljaCBkbyBu b3QgdXNlIFlBTkcsIHRvDQogICAgIG1vcmUgZWFzaWx5IHVuZGVyc3RhbmQgb3VyIG91dHB1dC4N Cg0KDQpJdCBzZWVtcyB0byBtZSB0aGF0IHlvdXIgZHJhZnQgaGFzIG1hbnkgZGV0YWlscyByZWxh dGVkIHRvIHRoZSBhYnN0cmFjdGlvbg0Kb2YgcG9saWN5IGxvZ2ljLCBidXQgYWxzbyBtYW55IGFz cGVjdHMgdGhhdCBsb29rIGxpa2UgaW1wbGVtZW50YXRpb24gZGV0YWlscy4NClBlcmhhcHMgaXQg Y2FuIGJlIHNpbXBsaWZpZWQgaWYgdGhlIGltcGxlbWVudGF0aW9uIGRldGFpbHMgd2VyZSByZW1v dmVkLg0KDQpJIGFtIG1vcmUgaW50ZXJlc3RlZCBpbiB0aGUgU1VQQSBBcmNoaXRlY3R1cmUgZG9j dW1lbnQgZmlyc3QuDQpJIGRvbid0IHNlZSBob3cgd2UgY2FuIGFncmVlIG9uIGFuIGluZm8tbW9k ZWwgaW4gdGhlIGFic2VuY2UNCm9mIGEgc3lzdGVtIGFyY2hpdGVjdHVyZS4NCg0KRG9lcyBTVVBB IHJ1biBhbnl3aGVyZT8gV2hhdCBkb2VzIGl0IGV2ZW4gbWVhbiB0byBpbXBsZW1lbnQgU1VQQT8N CldpbGwgcGVvcGxlIGJlIGFibGUgdG8gYnVpbGQgaW50ZXJvcGVyYWJsZSBTVVBBIGVuZ2luZXMg ZnJvbSB0aGUgUkZDcz8NCklzIHRoZXJlIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgU1VQQSBlbmdp bmUgcnVubmluZyBhdCB0aGUgZGV2aWNlIGxldmVsDQpvciB0aGUgY29udHJvbGxlciBsZXZlbD8g IFdoYXQgZGF0YSBpcyBhdmFpbGFibGUgZm9yIHBvbGljeSBlbmZvcmNlbWVudCBhbmFseXNpcz8N CklzIHRoaXMgY29uZmlndXJhYmxlIHRocm91Z2ggWUFORyBtb2R1bGVzIGltcGxlbWVudGVkIGJ5 IGEgU1VQQSBlbmdpbmU/DQpIb3cgYXJlIHBvbGljaWVzIGRlZmluZWQgYW5kIG1hbmFnZWQgd2l0 aGluIHRoZSBTVVBBIGltcGxlbWVudGF0aW9uPw0KSG93IGlzIGRldmljZSBjb25maWcgYWx0ZXJl ZCB0byBpbXBsZW1lbnQgcG9saWN5Pw0KSG93IGFyZSBkZXZpY2Ugb3BlcmF0aW9uYWwgc3RhdGUg YW5kIHN0YXRpc3RpY3MgdXNlZCB0byB2ZXJpZnkgcG9saWN5IGltcGxlbWVudGF0aW9uPw0KDQpB IHByZWNpc2UgZGVzY3JpcHRpb24gb2YgcG9saWN5IGxvZ2ljIG1pZ2h0IGJlIGEgZ29vZCB0aGlu ZyB0byBoYXZlLg0KSSBhbSBub3Qgb2JqZWN0aW5nIHRvIGFuIGluZm8gbW9kZWwgZG9jLiAgQSBz eXN0ZW0gYXJjaGl0ZWN0dXJlIGFuZCBhIHdvcmthYmxlIHNvbHV0aW9uDQp3aWxsIHJlcXVpcmUg YSBsb3QgbW9yZSB0aGFuIHRoYXQuDQoNCg0KDQoNCg0KDQoNCkpvaG4NCg0KDQpBbmR5DQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN1cGEgW21haWx0bzpzdXBhLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBa aG91dGlhbnJhbg0KU2VudDogVHVlc2RheSwgTWFyY2ggMDEsIDIwMTYgNzoyOSBQTQ0KVG86IE5l dmlsIEJyb3dubGVlDQpDYzogU1VQQSBsaXN0DQpTdWJqZWN0OiBSZTogW1N1cGFdIEluZm9ybWF0 aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBXRyBhZG9waW9uPw0KDQpIaSBOZXZpbCwNCg0K SSBhbSBub3QgYXJndWluZyBpbmZvcm1hdGlvbiBtb2RlbCBpcyB1c2VsZXNzLCBidXQgaXQgY2Fu IGJlIHdvcmtlZCBvdXQgaW4gb3RoZXIgb3JnYW5pemF0aW9ucyBpZiBuZWNlc3NhcnksIGUuZy4g VE1GLg0KSWYgaW4gU1VQQSB3ZSBjYW4gd29ya2VkIG9uIFlBTkcgZGF0YSBtb2RlbHMgZGlyZWN0 bHksIHdoeSB3ZSBmaXJzdGx5IHdvcmsgb24gYW4gaW5mb3JtYXRpb24gbW9kZWwgYW5kIHRoZW4g dHJhbnNsYXRlIGl0IHRvIFlBTkcgZGF0YSBtb2RlbD8NCkl0IGp1c3Qgbm90IG1ha2VzIHNlbnNl IHRvIG1lLg0KDQpUaWFucmFuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3VwYS1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIE5ldmlsIEJyb3dubGVlDQo+IFNlbnQ6IFdlZG5lc2Rh eSwgTWFyY2ggMDIsIDIwMTYgNjo1NiBBTQ0KPiBUbzogWmhvdXRpYW5yYW4NCj4gQ2M6IFNVUEEg bGlzdA0KPiBTdWJqZWN0OiBSZTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBt b2RlbHMgLSBXRyBhZG9waW9uPw0KPg0KPg0KPiBIaSBUaWFucmFuOg0KPg0KPiBJbiBteSBleHBl cmllbmNlcywgaGF2aW5nIGEgd2VsbC1kZWZpbmVkIGluZm9ybWF0aW9uIG1vZGVsIGlzIGEgZ29v ZCBzdGFydGluZw0KPiBwb2ludC4gIEl0IGFsbG93cyBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25z LCBlYWNoIG9mIHdoaWNoIGNhbiBkZXZlbG9wIGl0J3MNCj4gb3duIGRhdGEgbW9kZWwgLSBpbiBv dGhlciB3b3JkcywgdGhlIGluZm9ybWF0aW9uIG1vZGVsIGlzIGEgZ29vZCB1bmlmeWluZw0KPiBp bmZsdWVuY2UgLSB3aGljaCBpcyB3aHkgcHVibGlzaGluZyBzdWNoIGEgZG9jdW1lbnQgaXMgdGhl IHNlY29uZCBvZiBvdXINCj4gY2hhcnQgaXRlbXMuICBJIGhvcGUgdGhhdCBnZXR0aW5nIGEgZ29v ZCBkYXRhIG1vZGVsIHdpbGwgaGVscCB1cyB3aXRoIHRoZQ0KPiBmaXJzdCBjaGFydCBpdGVtICgi c2NvcGUgb2YgdGhlIHBvbGljeS1iYXNlZCBtYW5hZ2VtZW50IGZyYW1ld29yayIpLg0KPg0KPiBk cmFmdC1zdHJhc3NuZXItc3VwYS1nZW5lcmljLXBvbGljeS1pbmZvLW1vZGVsIGlzIHRoZSBvbmx5 IFNVUEENCj4gaW5mb3JtYXRpb24gbW9kZWwgdGhhdCdzIGhhZCBhbnkgd29yayBkb25lIG9uIGl0 IHNpbmNlIElFVEYgOTUsIHRoZXJlZm9yZQ0KPiBJJ3ZlIHByb3Bvc2VkIGl0IGZvciBXRyBhZG9w dGlvbi4NCj4NCj4gQXMgZm9yIHRoZSB0aGlyZCBjaGFydGVyIGl0ZW0gLSAic2V0IG9mIFlBTkcg ZGF0YSBtb2RlbHMiLCB0aGVyZSBhcmUgdHdvDQo+IG9mIHRoZXNlIG9uIHRoZSBTVVBBIGRvY3Vt ZW50cyBwYWdlLiAgSXQgd291bGQgaGVscCBhdCB0aGlzIHN0YWdlIGlmIHRoZWlyDQo+IGF1dGhv cnMgY291bGQgY29tbWVudCBvbiB0aGlzIGxpc3QgYWJvdXQgdGhlIHN0YXR1cyBvZiB0aGVzZSBk cmFmdHMuICBJbg0KPiBwYXJ0aWN1bGFyLCBqYXZlIHRoZXkgYmVlbiB3b3JraW5nIG9uIGEgbmV3 IHZlcnNpb24/DQo+DQo+IE92ZXJhbGwsIHdlIHJlYWxseSBuZWVkIG1vcmUgZGlzY3Vzc2lvbiBv biB0aGUgbGlzdCBvZiB3aGF0J3MgaGFwcGVuaW5nDQo+IHdpdGggdGhlIFNVUEEgd29yayENCj4N Cj4gQ2hlZXJzLCBOZXZpbA0KPg0KPg0KPiBPbiAxLzAzLzE2IDY6MTMgcG0sIFpob3V0aWFucmFu IHdyb3RlOg0KPiA+IElmIHRoaXMgaXMgYSBwb2xsIGZvciBXRyBhZG9wdGlvbiwgSSB3b3VsZCBz YXkgbm90IHN1cHBvcnQuDQo+ID4NCj4gPiBJZiB3ZSB3YW50IHRvIGZpbmFsbHkgZ2VuZXJhdGUg WUFORyBkYXRhIG1vZGVscyBoZXJlLCB3aHkgZG8gd2Ugc3BlbmQNCj4gdGltZSB3b3JraW5nIG9u IHRoaXMgaW5mb3JtYXRpb24gbW9kZWw/DQo+ID4NCj4gPiBXaHkgbm90IGZvY3VzIG9uIHRoZSBF Q0EgWUFORyBkYXRhIG1vZGVsIGRpcmVjdGx5IGFzIHN0YW5kYXJkIHRyYWNrPw0KPiA+DQo+ID4N Cj4gPiBUaWFucmFuDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g RnJvbTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3VwYS1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIElFVEYNCj4gPj4gU2VjcmV0YXJpYXQNCj4gPj4g U2VudDogTW9uZGF5LCBGZWJydWFyeSAyOSwgMjAxNiA2OjM1IEFNDQo+ID4+IFRvOiBkcmFmdC1z dHJhc3NuZXItc3VwYS1nZW5lcmljLXBvbGljeS1pbmZvLW1vZGVsQGlldGYub3JnPG1haWx0bzpk cmFmdC1zdHJhc3NuZXItc3VwYS1nZW5lcmljLXBvbGljeS1pbmZvLW1vZGVsQGlldGYub3JnPjsN Cj4gPj4gc3VwYS1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnN1cGEtY2hhaXJzQGlldGYub3JnPjsg c3VwYUBpZXRmLm9yZzxtYWlsdG86c3VwYUBpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogW1N1cGFd IFRoZSBTVVBBIFdHIGhhcyBwbGFjZWQNCj4gPj4gZHJhZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJp Yy1wb2xpY3ktaW5mby1tb2RlbCBpbiBzdGF0ZSAiQ2FsbCBGb3INCj4gPj4gQWRvcHRpb24gQnkg V0cgSXNzdWVkIg0KPiA+Pg0KPiA+Pg0KPiA+PiBUaGUgU1VQQSBXRyBoYXMgcGxhY2VkIGRyYWZ0 LXN0cmFzc25lci1zdXBhLWdlbmVyaWMtcG9saWN5LWluZm8tbW9kZWwNCj4gPj4gaW4gc3RhdGUg Q2FsbCBGb3IgQWRvcHRpb24gQnkgV0cgSXNzdWVkIChlbnRlcmVkIGJ5IE5ldmlsIEJyb3dubGVl KQ0KPiA+Pg0KPiA+PiBUaGUgZG9jdW1lbnQgaXMgYXZhaWxhYmxlIGF0DQo+ID4+DQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXN0cmFzc25lci1zdXBhLWdlbmVyaWMt cG9saWN5LQ0KPiA+PiBpDQo+ID4+IG5mby1tb2RlbC8NCj4gPj4NCj4gPj4NCj4gPj4gQ29tbWVu dDoNCj4gPj4gVGhpcyBpcyB0aGUgZmlyc3Qgb2Ygb3VyIGNoYXJ0ZXIgZG9jdW1lbnRzLCB0aGUg b3RoZXIgY2hhcnRlciBpdGVtcw0KPiA+PiBidWlsZCBvbiB0aGlzDQo+ID4+DQo+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IFN1cGEgbWFp bGluZyBsaXN0DQo+ID4+IFN1cGFAaWV0Zi5vcmc8bWFpbHRvOlN1cGFAaWV0Zi5vcmc+DQo+ID4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KPg0KPg0KPiAtLQ0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gICBOZXZpbCBCcm93bmxlZSAgICAgICAgICAgICAgICAgICAgICAg ICAgQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50DQo+ICAgUGhvbmU6ICs2NCA5IDM3MyA3NTk5 IHg4ODk0MSAgICAgICAgICAgICBUaGUgVW5pdmVyc2l0eSBvZiBBdWNrbGFuZA0KPiAgIEZBWDog KzY0IDkgMzczIDc0NTMgICBQcml2YXRlIEJhZyA5MjAxOSwgQXVja2xhbmQgMTE0MiwgTmV3IFpl YWxhbmQNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gU3VwYSBtYWlsaW5nIGxpc3QNCj4gU3VwYUBpZXRmLm9yZzxtYWlsdG86U3VwYUBpZXRm Lm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTdXBhIG1haWxp bmcgbGlzdA0KU3VwYUBpZXRmLm9yZzxtYWlsdG86U3VwYUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KU3VwYSBtYWlsaW5nIGxpc3QNClN1cGFAaWV0Zi5v cmc8bWFpbHRvOlN1cGFAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3N1cGENCg0K --_000_BBA82579FD347748BEADC4C445EA0F2183B84D72NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65paw5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2 IDkgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDmlrDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDkgMyAxIDEgMSAx IDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueaz qOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHls ZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIEFuZHkgb24gdGhlIFNVUEEg YXJjaGl0ZWN0dXJlLiBBbmQgSSB0aGluayBBbmR5IGhhcyBwb3N0ZWQgbWFueSB1c2VmdWwgaWRl YXMgb24gcXVlc3Rpb25zIHRoYXQgd2UgbmVlZCB0byBzb2x2ZSBpbiB0aGUgYXJjaCBkb2MuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgZG9jdW1lbnQgc2hvdWxkIGZpcnN0bHkgYmUgZGVs aXZlcmVkLCB3aGlsZSBpbmZvcm1hdGlvbiBtb2RlbCBpcyBqdXN0IG9uZSBhc3BlY3QgdGhhdCBt YXkgaGVscCB0aGUgZGF0YSBtb2RlbCBkZXNpZ24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1vcmVvdmVyLCBJIGRvIG5vdCB0aGluayB0 ZXh0IGRvY3VtZW50IGlzIHRoZSBiZXN0IHRvb2wgZm9yIGluZm9ybWF0aW9uIG1vZGVsaW5nLiBN b3N0IG9yZ2FuaXphdGlvbnMgdXNlIFVNTCBmb3IgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBTVVBBIGhhcyBwbGFuIHRvIGRlbGl2 ZXIgc3VjaCBhbiBhcmNoaXRlY3R1cmUgZG9jLCBJIHdvdWxkIHZlcnkgbGlrZSB0byBjb250cmli dXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGlhbnJhbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFuZHkgQmll cm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgTWFyY2ggMDMsIDIwMTYgMTowNyBQTTxicj4NCjxiPlRvOjwvYj4gSm9obiBTdHJhc3Nu ZXI8YnI+DQo8Yj5DYzo8L2I+IFpob3V0aWFucmFuOyBOZXZpbCBCcm93bmxlZTsgU1VQQSBsaXN0 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU3VwYV0gSW5mb3JtYXRpb24gbW9kZWxzIGFuZCBE YXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQs IE1hciAyLCAyMDE2IGF0IDc6MjEgUE0sIEpvaG4gU3RyYXNzbmVyICZsdDs8YSBocmVmPSJtYWls dG86Sm9obi5zYy5TdHJhc3NuZXJAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkpvaG4uc2Mu U3RyYXNzbmVyQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5XZSBzaG91bGQgd29yayBvbiBhbiBpbmZvcm1hdGlvbiBtb2RlbCBmb3Ig c2V2ZXJhbCByZWFzb25zLCBldmVuIGlmPGJyPg0KdGhlcmUgaXMgb25seSB0YXJnZXQgZGF0YSBt b2RlbCAoaS5lLiwgWUFORyk6PGJyPg0KPGJyPg0KJm5ic3A7IDEpIEFuIGluZm9ybWF0aW9uIG1v ZGVsIGNhbiBkZWZpbmUgaG93IGRhdGEgYXJlIHJlbGF0ZWQgdG8gZWFjaDxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7b3RoZXIgaW5kZXBlbmRlbnQgb2YgaW1wbGVtZW50YXRpb24uIFRoaXMgaXMg bXVjaCBoYXJkZXIgdG8gZG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2luIFlBTkcuIEhlbmNl LCB0aGUgaW5mb3JtYXRpb24gbW9kZWwgbWF5IG1ha2UgdGhlc2UgaW5oZXJlbnQ8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwO3JlbGF0aW9uc2hpcHMgZWFzaWVyIHRvIHZpc3VhbGl6ZSBhbmQgZGVm aW5lLjxicj4NCiZuYnNwOyAyKSBBbiBpbmZvcm1hdGlvbiBtb2RlbCBzZXBhcmF0ZXMgdGhlIGxv Z2ljYWwgZGVzaWduIGZyb20gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtwaHlzaWNhbCBk ZXNpZ24gb2YgdGhlIHN5c3RlbSwgZW5hYmxpbmcgYSBkZWVwZXIgdW5kZXJzdGFuZGluZzxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7b2YgYm90aCBpbmRlcGVuZGVudCBvZiBpbXBsZW1lbnRhdGlv bi4gVGhpcyBjYW4gYmUgdXNlZCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7cHJvZHVjZSBt b3JlIHBvd2VyZnVsIGltcGxlbWVudGF0aW9ucy48YnI+DQombmJzcDsgMykgSWYgYW4gaW5mb3Jt YXRpb24gbW9kZWwgaXMgd29ya2VkIG9uIGluIGFub3RoZXIgb3JnYW5pemF0aW9uLDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7dGhlcmUgaXMgbm8gZ3VhcmFudGVlIHRoYXQgaXRzIG91dHB1dCB3 aWxsIGJlIHVzZWZ1bCB0byB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO0lFVEYuIEkgYW0g YWN0aXZlIGluIHRoZSBUTSBGb3J1bSwgd2hpY2ggeW91IGNpdGVkOyB0aGV5IGFyZTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7aW4gZ2VuZXJhbCBub3Qgd29ycmllZCBhYm91dCBpbXBsZW1lbnRp bmcgWUFORyBtb2RlbHMsIG11Y2g8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2xlc3MgcHJvZHVj aW5nIG9wdGltYWwgWUFORyBtb2RlbHMuPGJyPg0KJm5ic3A7IDQpIFRoaXMgZW5hYmxlcyBvdGhl ciBTRE9zIGFuZCBmb3JhLCB3aGljaCBkbyBub3QgdXNlIFlBTkcsIHRvPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDttb3JlIGVhc2lseSB1bmRlcnN0YW5kIG91ciBvdXRwdXQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pkl0IHNlZW1zIHRvIG1lIHRoYXQgeW91ciBkcmFmdCBoYXMgbWFueSBkZXRhaWxzIHJlbGF0ZWQg dG8gdGhlIGFic3RyYWN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPm9mIHBvbGljeSBsb2dpYywg YnV0IGFsc28gbWFueSBhc3BlY3RzIHRoYXQgbG9vayBsaWtlIGltcGxlbWVudGF0aW9uIGRldGFp bHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBlcmhhcHMgaXQgY2FuIGJlIHNpbXBsaWZpZWQgaWYg dGhlIGltcGxlbWVudGF0aW9uIGRldGFpbHMgd2VyZSByZW1vdmVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBhbSBtb3JlIGludGVyZXN0ZWQgaW4g dGhlIFNVUEEgQXJjaGl0ZWN0dXJlIGRvY3VtZW50IGZpcnN0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JIGRvbid0IHNlZSBob3cgd2UgY2FuIGFncmVlIG9uIGFuIGluZm8tbW9kZWwgaW4gdGhlIGFi c2VuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+b2YgYSBzeXN0ZW0gYXJjaGl0ZWN0dXJlLiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RG9lcyBT VVBBIHJ1biBhbnl3aGVyZT8gV2hhdCBkb2VzIGl0IGV2ZW4gbWVhbiB0byBpbXBsZW1lbnQgU1VQ QT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2lsbCBwZW9wbGUgYmUgYWJsZSB0byBidWlsZCBpbnRl cm9wZXJhYmxlIFNVUEEgZW5naW5lcyBmcm9tIHRoZSBSRkNzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JcyB0aGVyZSBhIGRpZmZlcmVuY2UgYmV0d2VlbiBhIFNVUEEgZW5naW5lIHJ1bm5pbmcgYXQg dGhlIGRldmljZSBsZXZlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5vciB0aGUgY29udHJvbGxlciBs ZXZlbD8mbmJzcDsgV2hhdCBkYXRhIGlzIGF2YWlsYWJsZSBmb3IgcG9saWN5IGVuZm9yY2VtZW50 IGFuYWx5c2lzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JcyB0aGlzIGNvbmZpZ3VyYWJsZSB0aHJv dWdoIFlBTkcgbW9kdWxlcyBpbXBsZW1lbnRlZCBieSBhIFNVUEEgZW5naW5lPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5Ib3cgYXJlIHBvbGljaWVzIGRlZmluZWQgYW5kIG1hbmFnZWQgd2l0aGluIHRo ZSBTVVBBIGltcGxlbWVudGF0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3cgaXMgZGV2aWNl IGNvbmZpZyBhbHRlcmVkIHRvIGltcGxlbWVudCBwb2xpY3k/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PkhvdyBhcmUgZGV2aWNlIG9wZXJhdGlvbmFsIHN0YXRlIGFuZCBzdGF0aXN0aWNzIHVzZWQgdG8g dmVyaWZ5IHBvbGljeSBpbXBsZW1lbnRhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkEgcHJlY2lzZSBkZXNjcmlwdGlvbiBvZiBwb2xpY3kgbG9n aWMgbWlnaHQgYmUgYSBnb29kIHRoaW5nIHRvIGhhdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkg YW0gbm90IG9iamVjdGluZyB0byBhbiBpbmZvIG1vZGVsIGRvYy4mbmJzcDsgQSBzeXN0ZW0gYXJj aGl0ZWN0dXJlIGFuZCBhIHdvcmthYmxlIHNvbHV0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPndp bGwgcmVxdWlyZSBhIGxvdCBtb3JlIHRoYW4gdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbmR5PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCkZyb206IFN1cGEgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c3VwYS1i b3VuY2VzQGlldGYub3JnIj5zdXBhLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Yg WmhvdXRpYW5yYW48YnI+DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAwMSwgMjAxNiA3OjI5IFBNPGJy Pg0KVG86IE5ldmlsIEJyb3dubGVlPGJyPg0KQ2M6IFNVUEEgbGlzdDxicj4NClN1YmplY3Q6IFJl OiBbU3VwYV0gSW5mb3JtYXRpb24gbW9kZWxzIGFuZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/ PGJyPg0KPGJyPg0KSGkgTmV2aWwsPGJyPg0KPGJyPg0KSSBhbSBub3QgYXJndWluZyBpbmZvcm1h dGlvbiBtb2RlbCBpcyB1c2VsZXNzLCBidXQgaXQgY2FuIGJlIHdvcmtlZCBvdXQgaW4gb3RoZXIg b3JnYW5pemF0aW9ucyBpZiBuZWNlc3NhcnksIGUuZy4gVE1GLjxicj4NCklmIGluIFNVUEEgd2Ug Y2FuIHdvcmtlZCBvbiBZQU5HIGRhdGEgbW9kZWxzIGRpcmVjdGx5LCB3aHkgd2UgZmlyc3RseSB3 b3JrIG9uIGFuIGluZm9ybWF0aW9uIG1vZGVsIGFuZCB0aGVuIHRyYW5zbGF0ZSBpdCB0byBZQU5H IGRhdGEgbW9kZWw/PGJyPg0KSXQganVzdCBub3QgbWFrZXMgc2Vuc2UgdG8gbWUuPGJyPg0KPGJy Pg0KVGlhbnJhbjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQomZ3Q7IEZyb206IFN1cGEgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c3VwYS1ib3VuY2VzQGll dGYub3JnIj5zdXBhLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTmV2aWwgQnJv d25sZWU8YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDIsIDIwMTYgNjo1NiBBTTxi cj4NCiZndDsgVG86IFpob3V0aWFucmFuPGJyPg0KJmd0OyBDYzogU1VQQSBsaXN0PGJyPg0KJmd0 OyBTdWJqZWN0OiBSZTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMg LSBXRyBhZG9waW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBUaWFucmFuOjxi cj4NCiZndDs8YnI+DQomZ3Q7IEluIG15IGV4cGVyaWVuY2VzLCBoYXZpbmcgYSB3ZWxsLWRlZmlu ZWQgaW5mb3JtYXRpb24gbW9kZWwgaXMgYSBnb29kIHN0YXJ0aW5nPGJyPg0KJmd0OyBwb2ludC4m bmJzcDsgSXQgYWxsb3dzIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMsIGVhY2ggb2Ygd2hpY2gg Y2FuIGRldmVsb3AgaXQnczxicj4NCiZndDsgb3duIGRhdGEgbW9kZWwgLSBpbiBvdGhlciB3b3Jk cywgdGhlIGluZm9ybWF0aW9uIG1vZGVsIGlzIGEgZ29vZCB1bmlmeWluZzxicj4NCiZndDsgaW5m bHVlbmNlIC0gd2hpY2ggaXMgd2h5IHB1Ymxpc2hpbmcgc3VjaCBhIGRvY3VtZW50IGlzIHRoZSBz ZWNvbmQgb2Ygb3VyPGJyPg0KJmd0OyBjaGFydCBpdGVtcy4mbmJzcDsgSSBob3BlIHRoYXQgZ2V0 dGluZyBhIGdvb2QgZGF0YSBtb2RlbCB3aWxsIGhlbHAgdXMgd2l0aCB0aGU8YnI+DQomZ3Q7IGZp cnN0IGNoYXJ0IGl0ZW0gKCZxdW90O3Njb3BlIG9mIHRoZSBwb2xpY3ktYmFzZWQgbWFuYWdlbWVu dCBmcmFtZXdvcmsmcXVvdDspLjxicj4NCiZndDs8YnI+DQomZ3Q7IGRyYWZ0LXN0cmFzc25lci1z dXBhLWdlbmVyaWMtcG9saWN5LWluZm8tbW9kZWwgaXMgdGhlIG9ubHkgU1VQQTxicj4NCiZndDsg aW5mb3JtYXRpb24gbW9kZWwgdGhhdCdzIGhhZCBhbnkgd29yayBkb25lIG9uIGl0IHNpbmNlIElF VEYgOTUsIHRoZXJlZm9yZTxicj4NCiZndDsgSSd2ZSBwcm9wb3NlZCBpdCBmb3IgV0cgYWRvcHRp b24uPGJyPg0KJmd0Ozxicj4NCiZndDsgQXMgZm9yIHRoZSB0aGlyZCBjaGFydGVyIGl0ZW0gLSAm cXVvdDtzZXQgb2YgWUFORyBkYXRhIG1vZGVscyZxdW90OywgdGhlcmUgYXJlIHR3bzxicj4NCiZn dDsgb2YgdGhlc2Ugb24gdGhlIFNVUEEgZG9jdW1lbnRzIHBhZ2UuJm5ic3A7IEl0IHdvdWxkIGhl bHAgYXQgdGhpcyBzdGFnZSBpZiB0aGVpcjxicj4NCiZndDsgYXV0aG9ycyBjb3VsZCBjb21tZW50 IG9uIHRoaXMgbGlzdCBhYm91dCB0aGUgc3RhdHVzIG9mIHRoZXNlIGRyYWZ0cy4mbmJzcDsgSW48 YnI+DQomZ3Q7IHBhcnRpY3VsYXIsIGphdmUgdGhleSBiZWVuIHdvcmtpbmcgb24gYSBuZXcgdmVy c2lvbj88YnI+DQomZ3Q7PGJyPg0KJmd0OyBPdmVyYWxsLCB3ZSByZWFsbHkgbmVlZCBtb3JlIGRp c2N1c3Npb24gb24gdGhlIGxpc3Qgb2Ygd2hhdCdzIGhhcHBlbmluZzxicj4NCiZndDsgd2l0aCB0 aGUgU1VQQSB3b3JrITxicj4NCiZndDs8YnI+DQomZ3Q7IENoZWVycywgTmV2aWw8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMS8wMy8xNiA2OjEzIHBtLCBaaG91dGlhbnJhbiB3cm90 ZTo8YnI+DQomZ3Q7ICZndDsgSWYgdGhpcyBpcyBhIHBvbGwgZm9yIFdHIGFkb3B0aW9uLCBJIHdv dWxkIHNheSBub3Qgc3VwcG9ydC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYgd2Ug d2FudCB0byBmaW5hbGx5IGdlbmVyYXRlIFlBTkcgZGF0YSBtb2RlbHMgaGVyZSwgd2h5IGRvIHdl IHNwZW5kPGJyPg0KJmd0OyB0aW1lIHdvcmtpbmcgb24gdGhpcyBpbmZvcm1hdGlvbiBtb2RlbD88 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgV2h5IG5vdCBmb2N1cyBvbiB0aGUgRUNBIFlB TkcgZGF0YSBtb2RlbCBkaXJlY3RseSBhcyBzdGFuZGFyZCB0cmFjaz88YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGlhbnJhbjxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsm Z3Q7IEZyb206IFN1cGEgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c3VwYS1ib3VuY2VzQGlldGYu b3JnIj5zdXBhLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSUVURjxicj4NCiZn dDsgJmd0OyZndDsgU2VjcmV0YXJpYXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwg RmVicnVhcnkgMjksIDIwMTYgNjozNSBBTTxicj4NCiZndDsgJmd0OyZndDsgVG86IDxhIGhyZWY9 Im1haWx0bzpkcmFmdC1zdHJhc3NuZXItc3VwYS1nZW5lcmljLXBvbGljeS1pbmZvLW1vZGVsQGll dGYub3JnIj4NCmRyYWZ0LXN0cmFzc25lci1zdXBhLWdlbmVyaWMtcG9saWN5LWluZm8tbW9kZWxA aWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnN1cGEtY2hh aXJzQGlldGYub3JnIj5zdXBhLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpz dXBhQGlldGYub3JnIj4NCnN1cGFAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTdWJq ZWN0OiBbU3VwYV0gVGhlIFNVUEEgV0cgaGFzIHBsYWNlZDxicj4NCiZndDsgJmd0OyZndDsgZHJh ZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5mby1tb2RlbCBpbiBzdGF0ZSAmcXVv dDtDYWxsIEZvcjxicj4NCiZndDsgJmd0OyZndDsgQWRvcHRpb24gQnkgV0cgSXNzdWVkJnF1b3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 IFRoZSBTVVBBIFdHIGhhcyBwbGFjZWQgZHJhZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy1wb2xp Y3ktaW5mby1tb2RlbDxicj4NCiZndDsgJmd0OyZndDsgaW4gc3RhdGUgQ2FsbCBGb3IgQWRvcHRp b24gQnkgV0cgSXNzdWVkIChlbnRlcmVkIGJ5IE5ldmlsIEJyb3dubGVlKTxicj4NCiZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRoZSBkb2N1bWVudCBpcyBhdmFpbGFibGUgYXQ8YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1zdHJhc3NuZXItc3VwYS1nZW5lcmljLXBvbGljeS0iIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXN0cmFzc25l ci1zdXBhLWdlbmVyaWMtcG9saWN5LTwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IGk8YnI+DQomZ3Q7 ICZndDsmZ3Q7IG5mby1tb2RlbC88YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsgQ29tbWVudDo8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRoaXMgaXMg dGhlIGZpcnN0IG9mIG91ciBjaGFydGVyIGRvY3VtZW50cywgdGhlIG90aGVyIGNoYXJ0ZXIgaXRl bXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IGJ1aWxkIG9uIHRoaXM8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsgJmd0OyZndDsgU3VwYSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZn dDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpTdXBhQGlldGYub3JnIj5TdXBhQGlldGYub3JnPC9hPjxi cj4NCiZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zdXBhIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zdXBhPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4N CiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtOZXZpbCBCcm93bmxlZSZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDb21wdXRlciBTY2llbmNlIERlcGFydG1l bnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1Bob25lOiAmIzQzOzY0IDkgMzczIDc1OTkgeDg4OTQx Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIFVuaXZl cnNpdHkgb2YgQXVja2xhbmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO0ZBWDogJiM0Mzs2NCA5IDM3 MyA3NDUzJm5ic3A7ICZuYnNwO1ByaXZhdGUgQmFnIDkyMDE5LCBBdWNrbGFuZCAxMTQyLCBOZXcg WmVhbGFuZDxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBTdXBhIG1haWxpbmcgbGlzdDxicj4NCiZndDsg PGEgaHJlZj0ibWFpbHRvOlN1cGFAaWV0Zi5vcmciPlN1cGFAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGEiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGE8 L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpTdXBhIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpTdXBhQGll dGYub3JnIj5TdXBhQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3VwYSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClN1cGEgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlN1cGFAaWV0Zi5vcmciPlN1cGFAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBh PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BBA82579FD347748BEADC4C445EA0F2183B84D72NKGEML515MBXchi_-- From nobody Thu Mar 3 07:27:26 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22E11A009E for ; Thu, 3 Mar 2016 07:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 OLY6DAynzH6L for ; Thu, 3 Mar 2016 07:27:23 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBEBA1A009C for ; Thu, 3 Mar 2016 07:27:22 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id RTTJ1s0163vXPcr01TTKvu; Thu, 03 Mar 2016 16:27:20 +0100 To: Andy Bierman , John Strassner References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> From: "Bert Wijnen (IETF)" Message-ID: <56D857D6.1010804@bwijnen.net> Date: Thu, 3 Mar 2016 16:27:18 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Zhoutianran , Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 15:27:25 -0000 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 > wrote: > > 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. > > > > 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. > > > > > > > > John > > > > Andy > > > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org ] 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, > > 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 > > > -----Original Message----- > > From: Supa [mailto:supa-bounces@ietf.org ] 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"). > > > > 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:supa-bounces@ietf.org ] On Behalf Of IETF > > >> Secretariat > > >> Sent: Monday, February 29, 2016 6:35 AM > > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org ; > > >> supa-chairs@ietf.org ; supa@ietf.org > > >> 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 > > >> Supa@ietf.org > > >> 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 > > > > _______________________________________________ > > Supa mailing list > > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa From nobody Thu Mar 3 07:48:07 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89D71A1A52 for ; Thu, 3 Mar 2016 07:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Ir13pzGy_t4L for ; Thu, 3 Mar 2016 07:48:04 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307041A0419 for ; Thu, 3 Mar 2016 07:48:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CEF74246502; Thu, 3 Mar 2016 07:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1457020082; bh=8BwHW0bwHF58rM0r1GaeTk0V50iU3AVXBa5rqLSkCnU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=R9uEMN4YdMytMh3NI4BQfVayeknxbKSEDKBDmAOHI1AiLiyS7Uj6KOZfanfjMzfdC LjeBewuq77Ag3o69vXZwyyAq1nn8ZLb0AUBE2bdNC0VharjnZCvDjPX1c2AP9jiBeb /MD7VZpXJSN62IOYPHn+qdVibCCqtkJQTZN6g3oI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from joels-mbp.home (pool-98-114-54-183.phlapa.fios.verizon.net [98.114.54.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1030224126D; Thu, 3 Mar 2016 07:48:01 -0800 (PST) To: "Bert Wijnen (IETF)" , Andy Bierman , John Strassner References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> From: "Joel M. Halpern" Message-ID: <56D85CB1.2070703@joelhalpern.com> Date: Thu, 3 Mar 2016 10:48:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D857D6.1010804@bwijnen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Zhoutianran , Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 15:48:07 -0000 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: > 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 >> > >> wrote: >> >> 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. >> >> >> >> 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. >> >> >> >> >> >> >> >> John >> >> >> >> Andy >> >> >> -----Original Message----- >> From: Supa [mailto:supa-bounces@ietf.org >> ] 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, >> >> 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 >> >> > -----Original Message----- >> > From: Supa [mailto:supa-bounces@ietf.org >> ] 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"). >> > >> > 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:supa-bounces@ietf.org >> ] On Behalf Of IETF >> > >> Secretariat >> > >> Sent: Monday, February 29, 2016 6:35 AM >> > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org >> ; >> > >> supa-chairs@ietf.org ; >> supa@ietf.org >> > >> 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 >> > >> Supa@ietf.org >> > >> 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 >> > >> > _______________________________________________ >> > Supa mailing list >> > Supa@ietf.org >> > https://www.ietf.org/mailman/listinfo/supa >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> >> >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Thu Mar 3 08:13:00 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DC41A21AE for ; Thu, 3 Mar 2016 08:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 fWd_Z5g1bPEP for ; Thu, 3 Mar 2016 08:12:56 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF64B1A1EFA for ; Thu, 3 Mar 2016 08:12:55 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id RUCr1s01H3vXPcr01UCt8c; Thu, 03 Mar 2016 17:12:54 +0100 To: "Joel M. Halpern" , Andy Bierman , John Strassner References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> From: "Bert Wijnen (IETF)" Message-ID: <56D86283.2050403@bwijnen.net> Date: Thu, 3 Mar 2016 17:12:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D85CB1.2070703@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Zhoutianran , Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 16:12:59 -0000 Inline On 03/03/16 16:48, Joel M. Halpern wrote: > 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". 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 > Yours, > Joel > > On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: >> 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 >>> > >>> wrote: >>> >>> 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. >>> >>> >>> >>> 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. >>> >>> >>> >>> >>> >>> >>> >>> John >>> >>> >>> >>> Andy >>> >>> >>> -----Original Message----- >>> From: Supa [mailto:supa-bounces@ietf.org >>> ] 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, >>> >>> 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 >>> >>> > -----Original Message----- >>> > From: Supa [mailto:supa-bounces@ietf.org >>> ] 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"). >>> > >>> > 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:supa-bounces@ietf.org >>> ] On Behalf Of IETF >>> > >> Secretariat >>> > >> Sent: Monday, February 29, 2016 6:35 AM >>> > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org >>> ; >>> > >> supa-chairs@ietf.org ; >>> supa@ietf.org >>> > >> 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 >>> > >> Supa@ietf.org >>> > >> 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 >>> > >>> > _______________________________________________ >>> > Supa mailing list >>> > Supa@ietf.org >>> > https://www.ietf.org/mailman/listinfo/supa >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >>> >>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Thu Mar 3 08:28:09 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26451A7026 for ; Thu, 3 Mar 2016 08:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 iU0__o414dwQ for ; Thu, 3 Mar 2016 08:28:07 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279711A7030 for ; Thu, 3 Mar 2016 08:28:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1439D24DD89; Thu, 3 Mar 2016 08:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1457022487; bh=eJHu6LkIxQAMk4H/z52kCBHr4VHNANjY9ONTD/o9J/4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=aFog1jKKkScYEpJ9mcXdPoXZ+IBDZloTeQSDT9Iq8+RIYYkpBvpCoG32RtdY7fQpo L7azJE+6F97GXNFbYwWgyBfMOHlpNpVgTYe9lCFz4V7Fv03Of1xgTQZpqBf7N8EBgU +B256Pz8s/EWvZ+llc/vVlcvaNrnKePXtF8Mmm4o= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from joels-mbp.home (pool-98-114-54-183.phlapa.fios.verizon.net [98.114.54.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4B0F2240258; Thu, 3 Mar 2016 08:28:06 -0800 (PST) To: "Bert Wijnen (IETF)" , "Joel M. Halpern" , Andy Bierman , John Strassner References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> From: "Joel M. Halpern" Message-ID: <56D86615.8020406@joelhalpern.com> Date: Thu, 3 Mar 2016 11:28:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D86283.2050403@bwijnen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Zhoutianran , Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 16:28:08 -0000 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 3/3/16 11:12 AM, Bert Wijnen (IETF) wrote: > Inline > > 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". > Mmmm... both concurrently, or did he mean that we as a WG can make a > choice what we prefer > and standardize that? ... From nobody Thu Mar 3 08:41:44 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A391A8741 for ; Thu, 3 Mar 2016 08:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=ham 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 Df2L3QM1sr6L for ; Thu, 3 Mar 2016 08:41:38 -0800 (PST) Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 59F7B1A86F2 for ; Thu, 3 Mar 2016 08:41:38 -0800 (PST) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by sideburn.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1abWJY-0008Dc-1K; Thu, 03 Mar 2016 16:41:24 +0000 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0266.001; Thu, 3 Mar 2016 16:41:23 +0000 From: "King, Daniel" To: "Bert Wijnen (IETF)" , "Joel M. Halpern" , Andy Bierman , John Strassner , Zhoutianran Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2aGXTF8TS3OES1mXu6TQc0IZ9Ff0UAgAGQUICAAB1EgIAArWMAgAAFyoCAAAbwgIAAA5kQ Date: Thu, 3 Mar 2016 16:41:22 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> In-Reply-To: <56D86283.2050403@bwijnen.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.205.251.70] x-iss-local-domain: 1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 16:41:42 -0000 Hi All.=20 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 se= em that a "Policy-based Management Framework" discussing architecture, appl= icability and relationships ("system overview") would be reasonable content= for a framework document mentioned in the Charter? =20 Furthermore, Andy, Tianran and Bert all seem willing to support development= (via direct contributions) for the framework/architecture document? BR, Dan.=20 -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) Sent: 03 March 2016 16:13 To: Joel M. Halpern ; Andy Bierman ; John Strassner Cc: Zhoutianran ; Nevil Brownlee ; SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? Inline On 03/03/16 16:48, Joel M. Halpern wrote: > Two separate but related quesitons. > > 1) Can you help use find the places where the model / text is too=20 > implementation specific? There are a few places where in describing=20 > enumerations the model calls for integers. In the mapping to YANG, I hav= e 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=20 > system. Folks may recall I asked in the room at the last meeting=20 > whether our chartered allowd both communication between a control=20 > 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 guar= antee 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=20 > with regard to policy execution status, where the model makes some assump= tions about the structure of policy delivery. For the most part, those sho= uld be removed. Assistance in finding > them is appreciated. I suspect that some of them are necessary, and thos= e should be explicitly described. (And we should make=20 > 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 > Yours, > Joel > > On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: >> 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=20 >>> > >>> wrote: >>> >>> 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. >>> >>> >>> >>> It seems to me that your draft has many details related to the=20 >>> abstraction of policy logic, but also many aspects that look like=20 >>> 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=20 >>> 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=20 >>> level or the controller level? What data is available for policy=20 >>> 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=20 >>> 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=20 >>> a workable solution will require a lot more than that. >>> >>> >>> >>> >>> >>> >>> >>> John >>> >>> >>> >>> Andy >>> >>> >>> -----Original Message----- >>> From: Supa [mailto:supa-bounces@ietf.org=20 >>> ] 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, >>> >>> I am not arguing information model is useless, but it can be=20 >>> worked out in other organizations if necessary, e.g. TMF. >>> If in SUPA we can worked on YANG data models directly, why we=20 >>> firstly work on an information model and then translate it to >>> YANG data model? >>> It just not makes sense to me. >>> >>> Tianran >>> >>> > -----Original Message----- >>> > From: Supa [mailto:supa-bounces@ietf.org=20 >>> ] 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=20 >>> adopion? >>> > >>> > >>> > Hi Tianran: >>> > >>> > In my experiences, having a well-defined information model is=20 >>> a good starting >>> > point. It allows different implementations, each of which can=20 >>> develop it's >>> > own data model - in other words, the information model is a=20 >>> good unifying >>> > influence - which is why publishing such a document is the=20 >>> second of our >>> > chart items. I hope that getting a good data model will help=20 >>> us with the >>> > first chart item ("scope of the policy-based management=20 >>> framework"). >>> > >>> > draft-strassner-supa-generic-policy-info-model is the only SUPA >>> > information model that's had any work done on it since IETF=20 >>> 95, therefore >>> > I've proposed it for WG adoption. >>> > >>> > As for the third charter item - "set of YANG data models",=20 >>> there are two >>> > of these on the SUPA documents page. It would help at this=20 >>> stage if their >>> > authors could comment on this list about the status of these=20 >>> drafts. In >>> > particular, jave they been working on a new version? >>> > >>> > Overall, we really need more discussion on the list of what's=20 >>> 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=20 >>> we spend >>> > time working on this information model? >>> > > >>> > > Why not focus on the ECA YANG data model directly as=20 >>> standard track? >>> > > >>> > > >>> > > Tianran >>> > > >>> > >> -----Original Message----- >>> > >> From: Supa [mailto:supa-bounces@ietf.org=20 >>> ] On Behalf Of IETF >>> > >> Secretariat >>> > >> Sent: Monday, February 29, 2016 6:35 AM >>> > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org >>> ; >>> > >> supa-chairs@ietf.org ;=20 >>> supa@ietf.org >>> > >> Subject: [Supa] The SUPA WG has placed >>> > >> draft-strassner-supa-generic-policy-info-model in state=20 >>> "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=20 >>> charter items >>> > >> build on this >>> > >> >>> > >> _______________________________________________ >>> > >> Supa mailing list >>> > >> Supa@ietf.org >>> > >> 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 >>> > >>> > _______________________________________________ >>> > Supa mailing list >>> > Supa@ietf.org >>> > https://www.ietf.org/mailman/listinfo/supa >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >>> >>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Thu Mar 3 09:38:47 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201AE1B2A5E for ; Thu, 3 Mar 2016 09:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Cu3OAOjomV9p for ; Thu, 3 Mar 2016 09:38:37 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2E81B2A4D for ; Thu, 3 Mar 2016 09:38:36 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id x1so32312076lbj.3 for ; Thu, 03 Mar 2016 09:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=hCS0QrizJi1uzkO+rU91ZRQXcEL+HHflZfjYVaR9SQA=; b=x/+jpzw7w/7fclmxfxVP662SSWLDrOYncwZbsH8/LHduQDSOF8y/o0yPaZ84Uax5Rc tZFTpMOjEvMJmKGKudW1xREqpW4SBzlXLE6G2dNdVAi4VBen/dF0pKOFWlbH1P4APUFg 9ovV7LybZRMyfCFUr2//a35FDQjN60q4Fq2ppma89ktMITsCp7TH+GlI+vDsPUAr/phK nwBekIycPGiOV50/TbWyHOyqShkLcZj5SkEQPU22VewbOgXdgjSr8KmO6ocoyneUVvPQ 99OXKiusQK7GadXFS9q4kEnIsSCYRtp1kq2nku1NPGOqJjI9kwe25SC8eWs/ERLYo02d MBcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=hCS0QrizJi1uzkO+rU91ZRQXcEL+HHflZfjYVaR9SQA=; b=Y9q8UceE5slVn6ilsAg28danuBnK2tebUyi47AonX5RnNrBOXcjAcKzDFJlsh+rabL NXiePd4gm2yIcU6ueJdNN7QG1wlO/my9Oa46dmFzM7YXTKXdrfwYobxqkWONhXnufF6J 6zX85wcdneWhoPnfahCn+MUoWDW12xI5ElvbbZ4cJ15vB139yyZR/yW+kCEjPTgJN768 DsHYH1yfe0vZn/lI3xgakr/mgwzkWYuspAmQyP6d/d0olRNOcmQQ3Vmsb6dLT5mjfjrB nnk2yX5oe2T6epON5Z30PzuPp2K0pgdcsLJyZ19NXLRX+g6uwDJ7RbZ5BNgb+PiVV2Vk cKzw== X-Gm-Message-State: AD7BkJJNTP0kic0F5W58yd08mvaTgpBdoGIxyG/8vRpvgB4Zc/+JTs49r+rMD5wTIGYxROV4/VRDZ9zU//+67w== MIME-Version: 1.0 X-Received: by 10.112.171.163 with SMTP id av3mr1488261lbc.145.1457026714308; Thu, 03 Mar 2016 09:38:34 -0800 (PST) Received: by 10.112.110.68 with HTTP; Thu, 3 Mar 2016 09:38:34 -0800 (PST) In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> Date: Thu, 3 Mar 2016 09:38:34 -0800 Message-ID: From: Andy Bierman To: "King, Daniel" Content-Type: multipart/alternative; boundary=001a11c36b36bc80cb052d2877ef Archived-At: Cc: John Strassner , Zhoutianran , "Bert Wijnen \(IETF\)" , Nevil Brownlee , "Joel M. Halpern" , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 17:38:41 -0000 --001a11c36b36bc80cb052d2877ef Content-Type: text/plain; charset=UTF-8 On Thu, Mar 3, 2016 at 8:41 AM, King, Daniel wrote: > 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? > > 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. > BR, Dan. > Andy > > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: 03 March 2016 16:13 > To: Joel M. Halpern ; Andy Bierman < > andy@yumaworks.com>; John Strassner > Cc: Zhoutianran ; Nevil Brownlee < > n.brownlee@auckland.ac.nz>; SUPA list > Subject: Re: [Supa] Information models and Data models - WG adopion? > > Inline > > On 03/03/16 16:48, Joel M. Halpern wrote: > > 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". > 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 > > Yours, > > Joel > > > > On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: > >> 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 > >>> > > >>> wrote: > >>> > >>> 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. > >>> > >>> > >>> > >>> 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. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> John > >>> > >>> > >>> > >>> Andy > >>> > >>> > >>> -----Original Message----- > >>> From: Supa [mailto:supa-bounces@ietf.org > >>> ] 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, > >>> > >>> 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 > >>> > >>> > -----Original Message----- > >>> > From: Supa [mailto:supa-bounces@ietf.org > >>> ] 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"). > >>> > > >>> > 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:supa-bounces@ietf.org > >>> ] On Behalf Of IETF > >>> > >> Secretariat > >>> > >> Sent: Monday, February 29, 2016 6:35 AM > >>> > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org > >>> ; > >>> > >> supa-chairs@ietf.org ; > >>> supa@ietf.org > >>> > >> 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 > >>> > >> Supa@ietf.org > >>> > >> 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 > >>> > > >>> > _______________________________________________ > >>> > Supa mailing list > >>> > Supa@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/supa > >>> > >>> _______________________________________________ > >>> Supa mailing list > >>> Supa@ietf.org > >>> https://www.ietf.org/mailman/listinfo/supa > >>> > >>> _______________________________________________ > >>> Supa mailing list > >>> Supa@ietf.org > >>> https://www.ietf.org/mailman/listinfo/supa > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Supa mailing list > >>> Supa@ietf.org > >>> https://www.ietf.org/mailman/listinfo/supa > >> > >> _______________________________________________ > >> Supa mailing list > >> Supa@ietf.org > >> https://www.ietf.org/mailman/listinfo/supa > >> > > > > _______________________________________________ > > Supa mailing list > > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > --001a11c36b36bc80cb052d2877ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 3, 2016 at 8:41 AM, King, Daniel <d.king@lancaster.ac= .uk> wrote:
Hi=C2=A0 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 se= em that a "Policy-based Management Framework" discussing architec= ture, applicability and relationships ("system overview") would b= e 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 s= pend on SUPA.
If there is nothing implementable in SUPA then I do= n't really see
what standards value it has to operators.

=C2=A0
BR, Dan.

Andy

= =C2=A0

-----Original Message-----
From: Supa [mailto:supa-bounces@ie= tf.org] On Behalf Of Bert Wijnen (IETF)
Sent: 03 March 2016 16:13
To: Joel M. Halpern <jmh@joelhalp= ern.com>; Andy Bierman <and= y@yumaworks.com>; John Strassner <John.sc.Strassner@huawei.com>
Cc: Zhoutianran <zhoutianran@h= uawei.com>; Nevil Brownlee <n.brownlee@auckland.ac.nz>; SUPA list <supa@ietf.org>
Subject: Re: [Supa] Information models and Data models - WG adopion?

Inline

On 03/03/16 16:48, Joel M. Halpern wrote:
> Two separate but related quesitons.
>
> 1) Can you help use find the places where the model / text is too
> implementation specific?=C2=A0 There are a few places where in describ= ing
> enumerations the model calls for integers.=C2=A0 In the mapping to YAN= G, I have already started replacing those with Enumerations.=C2=A0 Are ther= e other kinds of over-specificity?
>
> 2) The charter allows for a range of implementations of the SUPA
> system.=C2=A0 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.=C2=A0 I was told by the AD that the chartered allowed bot= h.=C2=A0 This does make it rather interesting to define the "architect= ure".
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 guar= antee interoperability (which I think is one of our main objctives, no)? > 2') I do think that there are a few places in the model, particula= rly
> with regard to policy execution status, where the model makes some ass= umptions about the structure of policy delivery.=C2=A0 For the most part, t= hose should be removed.=C2=A0 Assistance in finding
> them is appreciated.=C2=A0 I suspect that some of them are necessary, = and those should be explicitly described.=C2=A0 =C2=A0(And we should make > sure the working group agrees with the assumptions.)
>
> 3) (minor) The charter permits the information model.=C2=A0 I presume = we could amend the charter to permit an architecture document.
>
I would say an "Architecture" or "System Overview" docu= ment would be a good thing.

Bert
> Yours,
> Joel
>
> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote:
>> 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
>>> <John.sc.St= rassner@huawei.com <mailto:John.sc.Strassner@huawei.com>>
>>> wrote:
>>>
>>>=C2=A0 =C2=A0 =C2=A0We should work on an information model for = several reasons, even if
>>>=C2=A0 =C2=A0 =C2=A0there is only target data model (i.e., YANG= ):
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A01) An information model can define h= ow data are related to each
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 other independent of impleme= ntation. This is much harder to do
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in YANG. Hence, the informat= ion model may make these inherent
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relationships easier to visu= alize and define.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A02) An information model separates th= e logical design from the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 physical design of the syste= m, enabling a deeper understanding
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of both independent of imple= mentation. This can be used to
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 produce more powerful implem= entations.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A03) If an information model is worked= on in another organization,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there is no guarantee that i= ts output will be useful to the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF. I am active in the TM = Forum, which you cited; they are
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in general not worried about= implementing YANG models, much
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 less producing optimal YANG = models.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A04) This enables other SDOs and fora,= which do not use YANG, to
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 more easily understand our o= utput.
>>>
>>>
>>>
>>> It seems to me that your draft has many details related to the=
>>> abstraction of policy logic, but also many aspects that look l= ike
>>> implementation details.
>>> Perhaps it can be simplified if the implementation details wer= e removed.
>>>
>>> I am more interested in the SUPA Architecture document first.<= br> >>> I don't see how we can agree on an info-model in the absen= ce of a
>>> system architecture.
>>>
>>> Does SUPA run anywhere? What does it even mean to implement SU= PA?
>>> Will people be able to build interoperable SUPA engines from t= he RFCs?
>>> Is there a difference between a SUPA engine running at the dev= ice
>>> level or the controller level?=C2=A0 What data is available fo= r policy
>>> enforcement analysis?
>>> Is this configurable through YANG modules implemented by a SUP= A engine?
>>> How are policies defined and managed within the SUPA implement= ation?
>>> 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.=C2=A0 A system archit= ecture and
>>> a workable solution will require a lot more than that.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0John
>>>
>>>
>>>
>>> Andy
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0-----Original Message-----
>>>=C2=A0 =C2=A0 =C2=A0From: Supa [mailto:supa-bounces@ietf.org
>>> <mailto:supa-bounc= es@ietf.org>] On Behalf Of Zhoutianran
>>>=C2=A0 =C2=A0 =C2=A0Sent: Tuesday, March 01, 2016 7:29 PM
>>>=C2=A0 =C2=A0 =C2=A0To: Nevil Brownlee
>>>=C2=A0 =C2=A0 =C2=A0Cc: SUPA list
>>>=C2=A0 =C2=A0 =C2=A0Subject: Re: [Supa] Information models and = Data models - WG adopion?
>>>
>>>=C2=A0 =C2=A0 =C2=A0Hi Nevil,
>>>
>>>=C2=A0 =C2=A0 =C2=A0I am not arguing information model is usele= ss, but it can be
>>> worked out in other organizations if necessary, e.g. TMF.
>>>=C2=A0 =C2=A0 =C2=A0If in SUPA we can worked on YANG data model= s directly, why we
>>> firstly work on an information model and then translate it to<= br> >>>=C2=A0 =C2=A0 =C2=A0YANG data model?
>>>=C2=A0 =C2=A0 =C2=A0It just not makes sense to me.
>>>
>>>=C2=A0 =C2=A0 =C2=A0Tianran
>>>
>>>=C2=A0 =C2=A0 =C2=A0> -----Original Message-----
>>>=C2=A0 =C2=A0 =C2=A0> From: Supa [mailto:supa-bounces@ietf.org
>>> <mailto:supa-bounc= es@ietf.org>] On Behalf Of Nevil Brownlee
>>>=C2=A0 =C2=A0 =C2=A0> Sent: Wednesday, March 02, 2016 6:56 A= M
>>>=C2=A0 =C2=A0 =C2=A0> To: Zhoutianran
>>>=C2=A0 =C2=A0 =C2=A0> Cc: SUPA list
>>>=C2=A0 =C2=A0 =C2=A0> Subject: Re: [Supa] Information models= and Data models - WG
>>> adopion?
>>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0> Hi Tianran:
>>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0> In my experiences, having a well-defin= ed information model is
>>> a good starting
>>>=C2=A0 =C2=A0 =C2=A0> point.=C2=A0 It allows different imple= mentations, each of which can
>>> develop it's
>>>=C2=A0 =C2=A0 =C2=A0> own data model - in other words, the i= nformation model is a
>>> good unifying
>>>=C2=A0 =C2=A0 =C2=A0> influence - which is why publishing su= ch a document is the
>>> second of our
>>>=C2=A0 =C2=A0 =C2=A0> chart items.=C2=A0 I hope that getting= a good data model will help
>>> us with the
>>>=C2=A0 =C2=A0 =C2=A0> first chart item ("scope of the p= olicy-based management
>>> framework").
>>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0> draft-strassner-supa-generic-policy-in= fo-model is the only SUPA
>>>=C2=A0 =C2=A0 =C2=A0> information model that's had any w= ork done on it since IETF
>>> 95, therefore
>>>=C2=A0 =C2=A0 =C2=A0> I've proposed it for WG adoption.<= br> >>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0> As for the third charter item - "= set of YANG data models",
>>> there are two
>>>=C2=A0 =C2=A0 =C2=A0> of these on the SUPA documents page.= =C2=A0 It would help at this
>>> stage if their
>>>=C2=A0 =C2=A0 =C2=A0> authors could comment on this list abo= ut the status of these
>>> drafts.=C2=A0 In
>>>=C2=A0 =C2=A0 =C2=A0> particular, jave they been working on = a new version?
>>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0> Overall, we really need more discussio= n on the list of what's
>>> happening
>>>=C2=A0 =C2=A0 =C2=A0> with the SUPA work!
>>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0> Cheers, Nevil
>>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0> On 1/03/16 6:13 pm, Zhoutianran wrote:=
>>>=C2=A0 =C2=A0 =C2=A0> > If this is a poll for WG adoption= , I would say not support.
>>>=C2=A0 =C2=A0 =C2=A0> >
>>>=C2=A0 =C2=A0 =C2=A0> > If we want to finally generate YA= NG data models here, why do
>>> we spend
>>>=C2=A0 =C2=A0 =C2=A0> time working on this information model= ?
>>>=C2=A0 =C2=A0 =C2=A0> >
>>>=C2=A0 =C2=A0 =C2=A0> > Why not focus on the ECA YANG dat= a model directly as
>>> standard track?
>>>=C2=A0 =C2=A0 =C2=A0> >
>>>=C2=A0 =C2=A0 =C2=A0> >
>>>=C2=A0 =C2=A0 =C2=A0> > Tianran
>>>=C2=A0 =C2=A0 =C2=A0> >
>>>=C2=A0 =C2=A0 =C2=A0> >> -----Original Message----- >>>=C2=A0 =C2=A0 =C2=A0> >> From: Supa [mailto:supa-bounces@ietf.org
>>> <mailto:supa-bounc= es@ietf.org>] On Behalf Of IETF
>>>=C2=A0 =C2=A0 =C2=A0> >> Secretariat
>>>=C2=A0 =C2=A0 =C2=A0> >> Sent: Monday, February 29, 20= 16 6:35 AM
>>>=C2=A0 =C2=A0 =C2=A0> >> To: draft-strassner-supa-gene= ric-policy-info-model@ietf.org
>>> <mailto:draft-strassner-supa-generic-policy-info-model@ietf= .org>;
>>>=C2=A0 =C2=A0 =C2=A0> >> supa-chairs@ietf.org <mailto:supa-chairs@ietf.org>;
>>> supa@ietf.org <mailto:= supa@ietf.org>
>>>=C2=A0 =C2=A0 =C2=A0> >> Subject: [Supa] The SUPA WG h= as placed
>>>=C2=A0 =C2=A0 =C2=A0> >> draft-strassner-supa-generic-= policy-info-model in state
>>> "Call For
>>>=C2=A0 =C2=A0 =C2=A0> >> Adoption By WG Issued" >>>=C2=A0 =C2=A0 =C2=A0> >>
>>>=C2=A0 =C2=A0 =C2=A0> >>
>>>=C2=A0 =C2=A0 =C2=A0> >> The SUPA WG has placed
>>> draft-strassner-supa-generic-policy-info-model
>>>=C2=A0 =C2=A0 =C2=A0> >> in state Call For Adoption By= WG Issued (entered by Nevil
>>> Brownlee)
>>>=C2=A0 =C2=A0 =C2=A0> >>
>>>=C2=A0 =C2=A0 =C2=A0> >> The document is available at<= br> >>>=C2=A0 =C2=A0 =C2=A0> >>
>>>=C2=A0 =C2=A0 =C2=A0>
>>> https://datatracke= r.ietf.org/doc/draft-strassner-supa-generic-policy-
>>>=C2=A0 =C2=A0 =C2=A0> >> i
>>>=C2=A0 =C2=A0 =C2=A0> >> nfo-model/
>>>=C2=A0 =C2=A0 =C2=A0> >>
>>>=C2=A0 =C2=A0 =C2=A0> >>
>>>=C2=A0 =C2=A0 =C2=A0> >> Comment:
>>>=C2=A0 =C2=A0 =C2=A0> >> This is the first of our char= ter documents, the other
>>> charter items
>>>=C2=A0 =C2=A0 =C2=A0> >> build on this
>>>=C2=A0 =C2=A0 =C2=A0> >>
>>>=C2=A0 =C2=A0 =C2=A0> >> _____________________________= __________________
>>>=C2=A0 =C2=A0 =C2=A0> >> Supa mailing list
>>>=C2=A0 =C2=A0 =C2=A0> >> Supa@ietf.org <mailto:Supa@ietf= .org>
>>>=C2=A0 =C2=A0 =C2=A0> >> https://www.= ietf.org/mailman/listinfo/supa
>>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0> --
>>>=C2=A0 =C2=A0 =C2=A0>
>>> --------------------------------------------------------------= -------
>>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0Nevil Brownlee=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Computer Science
>>> Department
>>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0Phone: +64 9 373 7599 x889= 41=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The University of
>>> Auckland
>>>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0FAX: +64 9 373 7453=C2=A0 = =C2=A0Private Bag 92019, Auckland 1142, New
>>> Zealand
>>>=C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0> ______________________________________= _________
>>>=C2=A0 =C2=A0 =C2=A0> Supa mailing list
>>>=C2=A0 =C2=A0 =C2=A0> Supa@= ietf.org <mailto:Supa@ietf.org&= gt;
>>>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/= mailman/listinfo/supa
>>>
>>>=C2=A0 =C2=A0 =C2=A0___________________________________________= ____
>>>=C2=A0 =C2=A0 =C2=A0Supa mailing list
>>>=C2=A0 =C2=A0 =C2=A0Supa@ietf.= org <mailto:Supa@ietf.org> >>>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailm= an/listinfo/supa
>>>
>>>=C2=A0 =C2=A0 =C2=A0___________________________________________= ____
>>>=C2=A0 =C2=A0 =C2=A0Supa mailing list
>>>=C2=A0 =C2=A0 =C2=A0Supa@ietf.= org <mailto:Supa@ietf.org> >>>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailm= an/listinfo/supa
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Supa mailing list
>>> Supa@ietf.org
>>> https://www.ietf.org/mailman/listinfo/supa
>>
>> _______________________________________________
>> Supa mailing list
>> Supa@ietf.org
>> https://www.ietf.org/mailman/listinfo/supa >>
>
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa
>

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

--001a11c36b36bc80cb052d2877ef-- From nobody Thu Mar 3 09:40:45 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4CA1B2A69 for ; Thu, 3 Mar 2016 09:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 RSmuXMAwm9_5 for ; Thu, 3 Mar 2016 09:40:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F671B2A6C for ; Thu, 3 Mar 2016 09:40:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJM64712; Thu, 03 Mar 2016 17:40:34 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Mar 2016 17:40:33 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.143]) by SJCEML702-CHM.china.huawei.com ([169.254.4.108]) with mapi id 14.03.0235.001; Thu, 3 Mar 2016 09:40:25 -0800 From: John Strassner To: "Joel M. Halpern" , Andy Bierman , Nevil Brownlee , Zhoutianran , SUPA list , "strazpdj@gmail.com" Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2rx5wdWV9zckyTIiHCBdvZs59F+M4AgAAougCAABqUgIAAfb4AgAFFCCA= Date: Thu, 3 Mar 2016 17:40:24 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> <56D6F56C.1040708@joelhalpern.com> In-Reply-To: <56D6F56C.1040708@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.56D87713.002B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.143, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 97528be5817d802e4f99a7371c95f527 Archived-At: Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 17:40:43 -0000 I agree with Joel. The objective here is to get the round trip started by c= alling 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:supa-bounces@ietf.org] 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? 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=20 call. You make a good point that we should get further down the path=20 with the data model before we do go for the last call. Yours, Joel On 3/2/16 1:45 AM, Juergen Schoenwaelder wrote: > On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote: > >> First, the entire information model will be rendered intoa YANG data mod= el. >> 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. > > 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 -> infor= mation 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 > _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Thu Mar 3 09:45:56 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DA71AD248 for ; Thu, 3 Mar 2016 09:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 qagMRYndo43Y for ; Thu, 3 Mar 2016 09:45:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD47D1B29EF for ; Thu, 3 Mar 2016 09:45:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFH57683; Thu, 03 Mar 2016 17:45:46 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Mar 2016 17:45:44 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.143]) by SJCEML702-CHM.china.huawei.com ([169.254.4.108]) with mapi id 14.03.0235.001; Thu, 3 Mar 2016 09:45:32 -0800 From: John Strassner To: Zhoutianran , Juergen Schoenwaelder , "Joel M. Halpern" Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2rx5wdWV9zckyTIiHCBdvZs59F+M4AgAAougCAABqUgIABZGaAgABfE5A= Date: Thu, 3 Mar 2016 17:45:31 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56D8784B.02FB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.143, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 071bb84bb764e94a94ef44b694de3e28 Archived-At: Cc: Nevil Brownlee , Andy Bierman , SUPA list , "strazpdj@gmail.com" Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 17:45:54 -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 t= hat 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:supa-bounces@ietf.org] 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, Emmm, the round trip you mentioned much like the spiral model in software e= ngineering. That's of course a good way to do system design and implementat= ion.=20 However, in this process, the information model is like an intermediary sta= te, 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 UM= L drawing shared during the DM design. And those make life simpler for expr= ess 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 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, March 02, 2016 2:45 PM > To: Joel M. Halpern > Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list > Subject: Re: [Supa] Information models and Data models - WG adopion? >=20 > On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote: >=20 > > First, the entire information model will be rendered intoa YANG data mo= del. > > 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. >=20 > 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: >=20 > info model -> data model -> implementation -> data model updates -> > information model updates >=20 > 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 bec= ause > you expect interoperability based on the info model, then I believe a ful= l > 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 da= ta > 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. >=20 > So the key question for me is which function the info model is supposed > to fulfill. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Thu Mar 3 18:53:01 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164CA1B29D7 for ; Thu, 3 Mar 2016 18:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 zizx9p1cbjNP for ; Thu, 3 Mar 2016 18:52:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A3B1B29A7 for ; Thu, 3 Mar 2016 18:52:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFH84897; Fri, 04 Mar 2016 02:52:47 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Mar 2016 02:52:46 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0235.001; Fri, 4 Mar 2016 10:52:38 +0800 From: Zhoutianran To: "King, Daniel" , "Bert Wijnen (IETF)" , "Joel M. Halpern" , Andy Bierman , John Strassner Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2mOZC2OcBCLECSqIAKm8tvNJ9FdHGAgAEVCICAAB1DgIAArWQAgAAFyoCAAAbwgIAAB/cAgAEvlUA= Date: Fri, 4 Mar 2016 02:52:37 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56D8F881.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 071bb84bb764e94a94ef44b694de3e28 Archived-At: Cc: Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 02:53:00 -0000 I would like to contribute on this framework document.=20 I can try to address questions like Andy raised in the mailing list based o= n my experience. Tianran > -----Original Message----- > From: King, Daniel [mailto:d.king@lancaster.ac.uk] > 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? >=20 > Hi All. >=20 > We have a placeholder in the SUPA Charter for: >=20 > 1) An explanation of the scope of the policy-based management framework > and how it relates to existing work of the IETF. >=20 > 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? >=20 > Furthermore, Andy, Tianran and Bert all seem willing to support developme= nt > (via direct contributions) for the framework/architecture document? >=20 > BR, Dan. >=20 > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: 03 March 2016 16:13 > To: Joel M. Halpern ; Andy Bierman > ; John Strassner > Cc: Zhoutianran ; Nevil Brownlee > ; SUPA list > Subject: Re: [Supa] Information models and Data models - WG adopion? >=20 > Inline >=20 > On 03/03/16 16:48, Joel M. Halpern wrote: > > 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 h= ave > 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 choi= ce > 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, t= hose > should be removed. Assistance in finding > > them is appreciated. I suspect that some of them are necessary, and th= ose > 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 cou= ld > amend the charter to permit an architecture document. > > > I would say an "Architecture" or "System Overview" document would be a go= od > thing. >=20 > Bert > > Yours, > > Joel > > > > On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: > >> 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 > >>> > > >>> wrote: > >>> > >>> 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 inheren= t > >>> relationships easier to visualize and define. > >>> 2) An information model separates the logical design from the > >>> physical design of the system, enabling a deeper understandi= ng > >>> 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. > >>> > >>> > >>> > >>> 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 remov= ed. > >>> > >>> 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 engin= e? > >>> 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:supa-bounces@ietf.org > >>> ] 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 adopi= on? > >>> > >>> 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 > >>> > >>> > -----Original Message----- > >>> > From: Supa [mailto:supa-bounces@ietf.org > >>> ] 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"). > >>> > > >>> > 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:supa-bounces@ietf.org > >>> ] On Behalf Of IETF > >>> > >> Secretariat > >>> > >> Sent: Monday, February 29, 2016 6:35 AM > >>> > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org > >>> ; > >>> > >> supa-chairs@ietf.org ; > >>> supa@ietf.org > >>> > >> 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 > >>> > >> Supa@ietf.org > >>> > >> 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 > >>> > > >>> > _______________________________________________ > >>> > Supa mailing list > >>> > Supa@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/supa > >>> > >>> _______________________________________________ > >>> Supa mailing list > >>> Supa@ietf.org > >>> https://www.ietf.org/mailman/listinfo/supa > >>> > >>> _______________________________________________ > >>> Supa mailing list > >>> Supa@ietf.org > >>> https://www.ietf.org/mailman/listinfo/supa > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Supa mailing list > >>> Supa@ietf.org > >>> https://www.ietf.org/mailman/listinfo/supa > >> > >> _______________________________________________ > >> Supa mailing list > >> Supa@ietf.org > >> https://www.ietf.org/mailman/listinfo/supa > >> > > > > _______________________________________________ > > Supa mailing list > > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > > >=20 > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa From nobody Thu Mar 3 19:23:36 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C81B3232 for ; Thu, 3 Mar 2016 19:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 s8cm6OPxsIo6 for ; Thu, 3 Mar 2016 19:23:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B99B1B3230 for ; Thu, 3 Mar 2016 19:23:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJN01058; Fri, 04 Mar 2016 03:23:24 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Mar 2016 03:23:22 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 4 Mar 2016 11:23:09 +0800 From: Zhoutianran To: John Strassner , Juergen Schoenwaelder , "Joel M. Halpern" Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2mOZC2OcBCLECSqIAKm8tvNJ9E7JYAgAAougCAABqTgIAB5T0AgABlnoCAASNagA== Date: Fri, 4 Mar 2016 03:23:08 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56D8FFAD.009E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 97528be5817d802e4f99a7371c95f527 Archived-At: Cc: Nevil Brownlee , Andy Bierman , SUPA list , "strazpdj@gmail.com" Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 03:23:35 -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 an= d OO concept, like the inherit, aggregation, subclass...=20 Tianran > -----Original Message----- > 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; strazpdj@gmail.com > Subject: RE: [Supa] Information models and Data models - WG adopion? >=20 > It is actually more like the V-model than a spiral model - the spiral mod= el > is risk-driven. >=20 > The point of model-driven software is to use the info model as the source > that ties everything together, including requirements, documentation, tes= t, > and implementation. You seem to be advocating bottom-up data models, whic= h > produces separate silos of software. >=20 >=20 > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] 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? >=20 >=20 > Hi Juergen, >=20 > 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. >=20 > 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. >=20 > A document with more than 100 pages just make all the things complex. Tha= t's > my humble opinion. >=20 > Tianran >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, March 02, 2016 2:45 PM > > To: Joel M. Halpern > > Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list > > Subject: Re: [Supa] Information models and Data models - WG adopion? > > > > On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote: > > > > > 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. > > > > 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 >=20 > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa From nobody Thu Mar 3 19:29:37 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD7B1B3238 for ; Thu, 3 Mar 2016 19:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YPbBurOXv0pS for ; Thu, 3 Mar 2016 19:29:33 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E221F1B3237 for ; Thu, 3 Mar 2016 19:29:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id BE1D9246502; Thu, 3 Mar 2016 19:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1457062173; bh=1jx+y70YVrGmKm/Q5llLCPTLO69mjGAFiHgjL391pvA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=NvOvYFg8FGdT97x9IHglVVidh74GRxb9tNw2/ntFd+TRJuQxnweFoUzslPHn4vC+t JRpHM7cVbLKJCu357i4cXe9MB8jbmXvxakepjaONnXz7qIZPaL/t6cWSKVopHN0GNU OMCCseiZJaKeLaAZqXPVvEhi2Xr4aZp2irZQ3Yw0= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BD60824126D; Thu, 3 Mar 2016 19:29:32 -0800 (PST) To: Zhoutianran , John Strassner , Juergen Schoenwaelder References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> From: "Joel M. Halpern" Message-ID: <56D9011B.50803@joelhalpern.com> Date: Thu, 3 Mar 2016 22:29:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Nevil Brownlee , Andy Bierman , SUPA list , "strazpdj@gmail.com" Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 03:29:36 -0000 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 On 3/3/16 10:23 PM, Zhoutianran wrote: > 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 > >> -----Original Message----- >> 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; strazpdj@gmail.com >> Subject: RE: [Supa] Information models and Data models - WG adopion? >> >> 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:supa-bounces@ietf.org] 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, >> >> 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 >> >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Wednesday, March 02, 2016 2:45 PM >>> To: Joel M. Halpern >>> Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list >>> Subject: Re: [Supa] Information models and Data models - WG adopion? >>> >>> On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote: >>> >>>> 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. >>> >>> 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 >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa > From nobody Thu Mar 3 21:00:26 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA801B3359 for ; Thu, 3 Mar 2016 21:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 gRTmmABXw18O for ; Thu, 3 Mar 2016 21:00:15 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95CCE1B334B for ; Thu, 3 Mar 2016 21:00:14 -0800 (PST) Received: by mail-lb0-x229.google.com with SMTP id bc4so48145430lbc.2 for ; Thu, 03 Mar 2016 21:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=oq9Dm2iEMsNcGzwriAdMUZMuqb/Hqq1McdLZRtBk410=; b=daT9Z7hfRuFguOv1MDHKtfjFq+pMg85dJjNiNMcu4cymJGh6VpVtKpYyzCRF8542IH rY9t3zlRgYeAAXic+kam7QyWXHMmjCzmTqOBQ8AAD2ywoPR6HU9kwv0+1U9/6vCDJQkr E8y1TQid9fY2PicgB7Skvk2pmwsdhqgeJ1QpSthgXq4BNaDINnyD0f+KNZC8sz+Iqigo qv5ECN9XLgHpigdtKX3b/TIqzJPWd3y3aKcJuTtLiE6HMsAQMrCi8XfGGDwaI6YdcLxn xdo9X6g9FIAEaZkST8zsUaLWIvyitsVksZvdHO3IcEJ/mf9FfN/MGuOD9UeoUFY+gGQ5 WrYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=oq9Dm2iEMsNcGzwriAdMUZMuqb/Hqq1McdLZRtBk410=; b=Sf9yZfsIFIgNbDS2pnCeOm4e4JwCppUEejkku3CDUX4EZZ3MCZsCKzlaw/FAd/3wdQ aVaVwxyI5IqllK8vipC4UvaNbrYGeGsETAVAxk+nX8qH/UIlmlbc32xDDn7DGCL5pzZE 1CfNnHM4mqoPAM0c6bDCJMLmMX0K1o++/C3DgYFCEs6EAANzsWe8KhN+4fgYewRHxawS Ai3i8ZtgylCOjJBVMOTL7mScyGtFgjyKOyKhCQ2LEbya3NyXDdDxNE+22wHb/SmiV3wx OXoxV+fwnBEjHVR/emG9gXPluZEYLBjaf9JyK8TCn4ZgPtrFNjmKwV2934GJf6eHDWXq 7zpg== X-Gm-Message-State: AD7BkJK3oVT5msM96eVaqjLktDOmMvA08a5p1CE0botuEIee1l4yK3G9m9afMnUIQUaodPo/If6eUnJKtMFyiA== MIME-Version: 1.0 X-Received: by 10.112.139.164 with SMTP id qz4mr2304673lbb.41.1457067612760; Thu, 03 Mar 2016 21:00:12 -0800 (PST) Received: by 10.25.156.76 with HTTP; Thu, 3 Mar 2016 21:00:12 -0800 (PST) In-Reply-To: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> Date: Thu, 3 Mar 2016 21:00:12 -0800 Message-ID: From: John Strassner To: Andy Bierman , John Strassner Content-Type: multipart/alternative; boundary=001a11c3476e78f5d5052d31fdc0 Archived-At: Cc: John Strassner , Zhoutianran , Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 05:00:20 -0000 --001a11c3476e78f5d5052d31fdc0 Content-Type: text/plain; charset=UTF-8 Hi Andy, thank you for your thoughtful reply. Replies inline below (just copying your reply, not my original message: > 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. 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. > 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. 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 :-) > Is there a difference between a SUPA engine running at the device level > 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. > 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? 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. > 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. 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 wrote: > > > On Wed, Mar 2, 2016 at 7:21 PM, John Strassner < > John.sc.Strassner@huawei.com> wrote: > >> 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. >> >> > > 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. > > > > > > > > >> John >> >> > > Andy > > >> >> -----Original Message----- >> From: Supa [mailto:supa-bounces@ietf.org] 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, >> >> 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 >> >> > -----Original Message----- >> > From: Supa [mailto:supa-bounces@ietf.org] 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"). >> > >> > 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:supa-bounces@ietf.org] On Behalf Of IETF >> > >> Secretariat >> > >> Sent: Monday, February 29, 2016 6:35 AM >> > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org; >> > >> supa-chairs@ietf.org; supa@ietf.org >> > >> 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 >> > >> Supa@ietf.org >> > >> 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 >> > >> > _______________________________________________ >> > Supa mailing list >> > Supa@ietf.org >> > https://www.ietf.org/mailman/listinfo/supa >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > -- regards, John --001a11c3476e78f5d5052d31fdc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andy,

thank you for your = thoughtful reply. Replies inline below (just copying your reply,
= not my original message:


> = It seems to me that your draft has many details related to the abstraction<= /div>
> of policy logic, but also many aspects that look like implem= entation details.
> Perhaps it can be simplified if the implem= entation 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
<= div>taken out.


> I am more inter= ested in the SUPA Architecture document first.
> I don't s= ee how we can agree on an info-model in the absence
> of a sys= tem architecture.=C2=A0

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

However, I am mi= ssing your point here. The information model is by
definition gen= eric in nature. It SHOULD be able to support many
different archi= tectures. You are probably referring to something specific,
but I= don't understand what.


> Do= es SUPA run anywhere?

SUPA - no, though there are = at least 3 implementations that are currently
being built (hopefu= lly one of these will be ready for IETF95). Subsets of
SUPA - abs= olutely.


> What does it even mea= n to implement SUPA?

Implementing SUPA means creat= ing a data model derived from the
SUPA information model.


> Will people be able to build interope= rable SUPA engines from the RFCs?

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


=
> Is there a difference between a SUPA engine running at the = device level
> 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 n= ature of the policy are
different at these two levels. I would ho= pe that SUPA could help
standardize this to make the translation = from controller to device easier.


&= gt; What data is available for policy enforcement analysis?

<= /div>
That is, of course, a function of implementation. There are some = hooks
in the SUPA info model for supporting this. I've also g= raduated 3 Ph.D.
students that have worked on policy detection an= d enforcement.
However, this clearly needs a supporting architect= ure document, as
well as clear definitions of what enforcement is= .


>=C2=A0Is this configurable th= rough YANG modules implemented by a SUPA engine?

T= he SUPA IM will be translated to a set of YANG modules. However,
= looking at the charter, policy enforcement is currently out of scope imho.<= /div>


> How are policies defined and m= anaged within the SUPA implementation?
> How is device config = altered to implement policy?
> How are device operational stat= e and statistics used to verify policy implementation?

=
All of these questions are dependent on implementation and architectur= e.
Note, however, that some of these can be helped by the impleme= ntation
details that are in the SUPA draft (e.g., supaPolAdminSta= tus, supaPolDeployStatus,
supaPolExecStatus, and supaPolClauseExe= cStatus). So yes, I agree that these
are implementation-oriented;= however, all of these attributes are generic in nature, and
shou= ld be able to help answer your questions.


> A precise description of policy logic might be a good thing to = have.
> I am not objecting to an info model doc.=C2=A0 A syste= m architecture and a workable solution
> will require a lot mo= re than that.

I absolutely agree. The info model a= uthors 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

<= div class=3D"gmail_quote">On Wed, Mar 2, 2016 at 9:06 PM, Andy Bierman <a= ndy@yumaworks.com> wrote:
<= div dir=3D"ltr">

On Wed, Mar 2, 2016 at 7:21 PM, John Strassner <John.sc.Stra= ssner@huawei.com> wrote:
We should work o= n an information model for several reasons, even if
there is only target data model (i.e., YANG):

=C2=A0 1) An information model can define how data are related to each
=C2=A0 =C2=A0 =C2=A0other independent of implementation. This is much harde= r to do
=C2=A0 =C2=A0 =C2=A0in YANG. Hence, the information model may make these in= herent
=C2=A0 =C2=A0 =C2=A0relationships easier to visualize and define.
=C2=A0 2) An information model separates the logical design from the
=C2=A0 =C2=A0 =C2=A0physical design of the system, enabling a deeper unders= tanding
=C2=A0 =C2=A0 =C2=A0of both independent of implementation. This can be used= to
=C2=A0 =C2=A0 =C2=A0produce more powerful implementations.
=C2=A0 3) If an information model is worked on in another organization,
=C2=A0 =C2=A0 =C2=A0there is no guarantee that its output will be useful to= the
=C2=A0 =C2=A0 =C2=A0IETF. I am active in the TM Forum, which you cited; the= y are
=C2=A0 =C2=A0 =C2=A0in general not worried about implementing YANG models, = much
=C2=A0 =C2=A0 =C2=A0less producing optimal YANG models.
=C2=A0 4) This enables other SDOs and fora, which do not use YANG, to
=C2=A0 =C2=A0 =C2=A0more easily understand our output.



It seems to me that you= r draft has many details related to the abstraction
of policy log= ic, 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 docume= nt first.
I don't see how we can agree on an info-model in th= e absence
of a system architecture.=C2=A0

Does SUPA run anywhere? What does it even mean to implement SUPA?
Will people be able to build interoperable SUPA engines from the RFC= s?
Is there a difference between a SUPA engine running at the dev= ice level
or the controller level?=C2=A0 What data is available f= or policy enforcement analysis?
Is this configurable through YANG= modules implemented by a SUPA engine?
How are policies defined a= nd managed within the SUPA implementation?
How is device config a= ltered 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.=C2=A0 A system architecture and= a workable solution
will require a lot more than that.






=C2=A0
John



Andy
=C2=A0

-----Original Message-----
From: Supa [mailto:supa-bounces@ietf.org] 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,

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

> -----Original Message-----
> From: Supa [mailto:supa-bounces@ietf.org] 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 s= tarting
> point.=C2=A0 It allows different implementations, each of which can de= velop it's
> own data model - in other words, the information model is a good unify= ing
> influence - which is why publishing such a document is the second of o= ur
> chart items.=C2=A0 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, th= erefore
> I've proposed it for WG adoption.
>
> As for the third charter item - "set of YANG data models", t= here are two
> of these on the SUPA documents page.=C2=A0 It would help at this stage= if their
> authors could comment on this list about the status of these drafts.= =C2=A0 In
> particular, jave they been working on a new version?
>
> Overall, we really need more discussion on the list of what's happ= ening
> 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 s= pend
> time working on this information model?
> >
> > Why not focus on the ECA YANG data model directly as standard tra= ck?
> >
> >
> > Tianran
> >
> >> -----Original Message-----
> >> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of IETF
> >> Secretariat
> >> Sent: Monday, February 29, 2016 6:35 AM
> >> To: draft-strassner-supa-generic-policy-inf= o-model@ietf.org;
> >> sup= a-chairs@ietf.org; s= upa@ietf.org
> >> 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-in= fo-model
> >> in state Call For Adoption By WG Issued (entered by Nevil Bro= wnlee)
> >>
> >> The document is available at
> >>
> https://datatracker.ietf.o= rg/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
> >> Supa@ietf.= org
> >> https://www.ietf.org/mailman/listinfo/supa
>
>
> --
> ---------------------------------------------------------------------<= br> >=C2=A0 =C2=A0Nevil Brownlee=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Computer Science Departmen= t
>=C2=A0 =C2=A0Phone: +64 9 373 7599 x88941=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The University of Auckland
>=C2=A0 =C2=A0FAX: +64 9 373 7453=C2=A0 =C2=A0Private Bag 92019,= Auckland 1142, New Zealand
>
> _______________________________________________
> Supa mailing list
> Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa


_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa




--
regards,
John
--001a11c3476e78f5d5052d31fdc0-- From nobody Thu Mar 3 21:01:57 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F711A7020 for ; Thu, 3 Mar 2016 21:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 7pAkmgS6_hDc for ; Thu, 3 Mar 2016 21:01:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84B81B3353 for ; Thu, 3 Mar 2016 21:01:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFH92553; Fri, 04 Mar 2016 05:01:48 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Mar 2016 05:01:47 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.102]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 4 Mar 2016 13:01:36 +0800 From: Zhoutianran To: "Joel M. Halpern" , John Strassner , Juergen Schoenwaelder Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2mOZC2OcBCLECSqIAKm8tvNJ9E7JYAgAAougCAABqTgIAB5T0AgABlnoCAASNagP//f9GAgACZMIA= Date: Fri, 4 Mar 2016 05:01:36 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> <56D9011B.50803@joelhalpern.com> In-Reply-To: <56D9011B.50803@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56D916BD.0081, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 071bb84bb764e94a94ef44b694de3e28 Archived-At: Cc: Nevil Brownlee , Andy Bierman , SUPA list , "strazpdj@gmail.com" Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 05:01:56 -0000 In short to be clear. I am not opposed to do information modeling for DM generation and other ben= efits. 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?=20 So no need to text publish them in IETF. We can still use this mailing list for discussion. Maybe like many open sou= rce communities, we can also use jira, gerrit, but may not. We document the final data models with YANG in text. Regards, Tianran > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Friday, March 04, 2016 11:30 AM > To: Zhoutianran; John Strassner; Juergen Schoenwaelder > Cc: Nevil Brownlee; Andy Bierman; SUPA list; strazpdj@gmail.com > Subject: Re: [Supa] Information models and Data models - WG adopion? >=20 > I have real trouble understanding this email. > If we are going to use the IM, the working group needs to adopt it, so th= at > the document reflects working group agreements rather than just John and > my opinions. >=20 > 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 tex= t > 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.) >=20 > 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. >=20 > 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. >=20 > We are working on producing a YANG data model. The charter is quite clea= r > that such is what we need to produce. >=20 > Given that you say you are not opposed to the IM, I am left quite confuse= d > as to what you want. >=20 > Yours, > Joel >=20 > On 3/3/16 10:23 PM, Zhoutianran wrote: > > 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 UM= L > and OO concept, like the inherit, aggregation, subclass... > > > > > > Tianran > > > >> -----Original Message----- > >> 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; strazpdj@gmail.com > >> Subject: RE: [Supa] Information models and Data models - WG adopion? > >> > >> 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:supa-bounces@ietf.org] 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, > >> > >> 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 > >> > >>> -----Original Message----- > >>> From: Juergen Schoenwaelder > >>> [mailto:j.schoenwaelder@jacobs-university.de] > >>> Sent: Wednesday, March 02, 2016 2:45 PM > >>> To: Joel M. Halpern > >>> Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list > >>> Subject: Re: [Supa] Information models and Data models - WG adopion? > >>> > >>> On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote: > >>> > >>>> 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. > >>> > >>> 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 | German= y > >>> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> Supa mailing list > >> Supa@ietf.org > >> https://www.ietf.org/mailman/listinfo/supa > > From nobody Thu Mar 3 21:02:14 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEC91B335F for ; Thu, 3 Mar 2016 21:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 674PMF3qIxwi for ; Thu, 3 Mar 2016 21:01:55 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6B61B3359 for ; Thu, 3 Mar 2016 21:01:52 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id cf7so31953608lbb.1 for ; Thu, 03 Mar 2016 21:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=s/KNxLsA62CZJGNlL2ugrgccYAKKg3AQN5t3bYgyeJ4=; b=MMaX7wywKhii6bdP6RX1NoJb7WUceBe88t0yVm1eTMypJIgt6cHdByhLdWEbHJ1kZN VfxXZ7wgXa1koReA6wexWACufFO2hqM6m8gVIRuz/61fwh7C+9ACgigWYsLhCM+/NUjx 12u7JErYJC5V7y1hWqnZX1Mx0g0+/rR8wKpVe8VW6IClk1+Q2zQyt+GEklZ+8MF+aHCk GKqHCNRG41Yf2bDZ/jRbXOEiukkQyta1pDQHWWsGq4ZgFYUTDWSrl9o/YTjxwq572+CU nkxyUYuUfKftJ3CvmsvVGA2GqJW3rBMrOCWPVGyby0p9qRQH5gtW+SOSoIrxrFXdm+YU iMfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=s/KNxLsA62CZJGNlL2ugrgccYAKKg3AQN5t3bYgyeJ4=; b=I6GG27RBmzagbip3bS5baIb/VGllqyPcgBerfi6gxhvOhl/3tATMRmeamkfaxTBSwo PlbkC7IDgD1Y7C+mPNX5c/5+KG15fNAwY88BUtaivAkDCCnen4uMOJis7Uj2pfgVbXmK S2FDnCtTRAKBCyN5jFckDu38gGCgM5whdCBvPobcOIc1LmvTX45msvLhcxyMuLP/t8dh VJvcj8o9IYBIjfxxQWChmTLYrd/BT58JJC7DT2oOxApP2yXCpKVlbtLJviO36O//YX7F leUUFCRvfGq7hcuwqPbjNMztp+fYzrykUFzx5YPFfQkS9teLLlZ3OI5bOU135rb0Bgso zyOw== X-Gm-Message-State: AD7BkJJG382X4n/aeG5DUNHG6w6ml58trwSr6+df11pK0QQVia+/yYE0V+OKp+oZn5v58tyOzmYLP8Pqx0URog== MIME-Version: 1.0 X-Received: by 10.25.144.80 with SMTP id s77mr2313423lfd.6.1457067710774; Thu, 03 Mar 2016 21:01:50 -0800 (PST) Received: by 10.25.156.76 with HTTP; Thu, 3 Mar 2016 21:01:50 -0800 (PST) In-Reply-To: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> Date: Thu, 3 Mar 2016 21:01:50 -0800 Message-ID: From: John Strassner To: Zhoutianran , John Strassner Content-Type: multipart/alternative; boundary=001a114020d85084ae052d3203fa Archived-At: Cc: John Strassner , Nevil Brownlee , Andy Bierman , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 05:01:59 -0000 --001a114020d85084ae052d3203fa Content-Type: text/plain; charset=UTF-8 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 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. > > > > If SUPA has plan to deliver such an architecture doc, I would very like to > contribute. > > > > Best, > > Tianran > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *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 < > John.sc.Strassner@huawei.com> wrote: > > 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. > > > > > > 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. > > > > > > > > > > > > > > > > John > > > > > > Andy > > > > > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] 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, > > 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 > > > -----Original Message----- > > From: Supa [mailto:supa-bounces@ietf.org] 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"). > > > > 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:supa-bounces@ietf.org] On Behalf Of IETF > > >> Secretariat > > >> Sent: Monday, February 29, 2016 6:35 AM > > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org; > > >> supa-chairs@ietf.org; supa@ietf.org > > >> 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 > > >> Supa@ietf.org > > >> 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 > > > > _______________________________________________ > > Supa mailing list > > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > -- regards, John --001a114020d85084ae052d3203fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There have been numerous "text documents" o= f info models and data models.
If you have a technical point, suc= h as improvement in the symbology used in
the draft, please let u= s know.

On Wed, Mar 2, 2016 at 10:18 PM, Zhoutianran <zhoutianran@huawei.co= m> wrote:

I agree with Andy on t= he SUPA architecture. And I think Andy has posted many useful ideas on ques= tions that we need to solve in the arch doc.

This document should f= irstly be delivered, while information model is just one aspect that may he= lp the data model design.

=C2=A0

Moreover, I do not thi= nk text document is the best tool for information modeling. Most organizati= ons use UML for it.

=C2=A0

If SUPA has plan to de= liver such an architecture doc, I would very like to contribute.<= /u>

=C2=A0

Best,

Tianran<= /span>

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
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?=

=C2=A0

=C2=A0

=C2=A0

On Wed, Mar 2, 2016 at 7:21 PM,= John Strassner <John.sc.Strassner@huawei.com> wrote:

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

=C2=A0 1) An information model can define how data are related to each
=C2=A0 =C2=A0 =C2=A0other independent of implementation. This is much harde= r to do
=C2=A0 =C2=A0 =C2=A0in YANG. Hence, the information model may make these in= herent
=C2=A0 =C2=A0 =C2=A0relationships easier to visualize and define.
=C2=A0 2) An information model separates the logical design from the
=C2=A0 =C2=A0 =C2=A0physical design of the system, enabling a deeper unders= tanding
=C2=A0 =C2=A0 =C2=A0of both independent of implementation. This can be used= to
=C2=A0 =C2=A0 =C2=A0produce more powerful implementations.
=C2=A0 3) If an information model is worked on in another organization,
=C2=A0 =C2=A0 =C2=A0there is no guarantee that its output will be useful to= the
=C2=A0 =C2=A0 =C2=A0IETF. I am active in the TM Forum, which you cited; the= y are
=C2=A0 =C2=A0 =C2=A0in general not worried about implementing YANG models, = much
=C2=A0 =C2=A0 =C2=A0less producing optimal YANG models.
=C2=A0 4) This enables other SDOs and fora, which do not use YANG, to
=C2=A0 =C2=A0 =C2=A0more easily understand our output.=

=C2=A0

=C2=A0

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.

=C2=A0

I am more interested in the SUP= A Architecture document first.

I don't see how we can agre= e on an info-model in the absence

of a system architecture.=C2=A0=

=C2=A0

Does SUPA run anywhere? What do= es it even mean to implement SUPA?

Will people be able to build in= teroperable SUPA engines from the RFCs?

Is there a difference between a= SUPA engine running at the device level

or the controller level?=C2=A0 = What data is available for policy enforcement analysis?

Is this configurable through YA= NG modules implemented by a SUPA engine?

How are policies defined and ma= naged within the SUPA implementation?

How is device config altered to= implement policy?

How are device operational stat= e and statistics used to verify policy implementation?=

=C2=A0

A precise description of policy= logic might be a good thing to have.

I am not objecting to an info m= odel doc.=C2=A0 A system architecture and a workable solution=

will require a lot more than th= at.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Jo= hn

=C2=A0

=C2=A0

Andy

=C2=A0


-----Original Message-----
From: Supa [mailto:supa-bounces@ietf.org] 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,

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

> -----Original Message-----
> From: Supa [mailto:supa-bounces@ietf.org] 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 s= tarting
> point.=C2=A0 It allows different implementations, each of which can de= velop it's
> own data model - in other words, the information model is a good unify= ing
> influence - which is why publishing such a document is the second of o= ur
> chart items.=C2=A0 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, th= erefore
> I've proposed it for WG adoption.
>
> As for the third charter item - "set of YANG data models", t= here are two
> of these on the SUPA documents page.=C2=A0 It would help at this stage= if their
> authors could comment on this list about the status of these drafts.= =C2=A0 In
> particular, jave they been working on a new version?
>
> Overall, we really need more discussion on the list of what's happ= ening
> 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 s= pend
> time working on this information model?
> >
> > Why not focus on the ECA YANG data model directly as standard tra= ck?
> >
> >
> > Tianran
> >
> >> -----Original Message-----
> >> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of IETF
> >> Secretariat
> >> Sent: Monday, February 29, 2016 6:35 AM
> >> To: draft-strassner-supa-generic-policy-info-model@ietf.org;
> >> sup= a-chairs@ietf.org; supa@ietf.org
> >> 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-in= fo-model
> >> in state Call For Adoption By WG Issued (entered by Nevil Bro= wnlee)
> >>
> >> 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
> >> Supa@ietf.= org
> >> https://www.ietf.org/mailman/listinfo/supa
>
>
> --
> ---------------------------------------------------------------------<= br> >=C2=A0 =C2=A0Nevil Brownlee=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Computer Science Departmen= t
>=C2=A0 =C2=A0Phone: +64 9 373 7599 x88941=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The University of Auckland
>=C2=A0 =C2=A0FAX: +64 9 373 7453=C2=A0 =C2=A0Private Bag 92019,= Auckland 1142, New Zealand
>
> _______________________________________________
> Supa mailing list
> Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa

_______________________________________________
Supa mailing list
Supa@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/supa

_______________________________________________
Supa mailing list
Supa@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/supa

=C2=A0


_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa




--
regards,
John
--001a114020d85084ae052d3203fa-- From nobody Thu Mar 3 21:07:01 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3F11ACEE5 for ; Thu, 3 Mar 2016 21:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 9bW7C1_9qYce for ; Thu, 3 Mar 2016 21:06:56 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835761A87CC for ; Thu, 3 Mar 2016 21:06:55 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id bc4so48268026lbc.2 for ; Thu, 03 Mar 2016 21:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=E7QWPlrN+qiGPTc3JOs7H5xPVYBQZmCelN5fQ4gBtDw=; b=dB1kNonux9V/ktHCFUsR3KkLQfrxngxX6W+8aaeXswmDT5+id7Y3REG+O3P+WUWzab VQrEwJje8ug5kUE3GckQE56/bj/HXG9cOqcsmd7r91N8Q7HQ0CVQDSh3OTdXwsmZEK6T H3QOIt1rW3qqdxqWWDpBXc1k+BBbPdlMgEStT5P+MxyIT6wKHq5SHtPTPSV+8hvS+Zax eknf5xOZHY5t4q1LnJqnyN756F0TnE3R3cf+eI+EarrktYdCbUU2xmXQaA/G5zlAz4zb WhY4EYHemJlime8B0zxvNFQDqFFHmWRF6tgEIoL7ejdVVCBtJ13Sy4wxDtQkDSFCV52n 0sZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=E7QWPlrN+qiGPTc3JOs7H5xPVYBQZmCelN5fQ4gBtDw=; b=In+TJX5gYaz/DYnPDs4jWcJihUxd062MvVlnFCffk6n9e19lcZ8Wz8LQ3S5oTD1tyd Xqc4b8U6m9jZnliOo6MTxtlCy/MD7uab3AvzCT1dbTR2s3T9dpXRuxEJ+kLW6nmPp8wS CFaJFcsGuDD+7aMSdm0NjskHc4Nx5vm+cl0L+tVp44emAucvRR3Th2VSwgJ0u+jdl5ZK qkOEERJF4Aj5imPVcpwrEiBlGIFfvQEUWuTUUfpmRKH23l+122jBpYsHPtf6pqy8CORS vgjp+1dsJ0IT9uIGHl1bZsKQP0DlU1B9mOfYpxsIYQSKn0ghLFuhi3anXvgqMzmX04Dx BCtw== X-Gm-Message-State: AD7BkJLlENUZiBZsgZVMcievftSPGt/xGoxAdVLrx+M0E3gzrxcIfoIb06LtUdIepgfxQwi9ld6+xl2SPpmsKA== MIME-Version: 1.0 X-Received: by 10.25.18.158 with SMTP id 30mr2432624lfs.16.1457068013560; Thu, 03 Mar 2016 21:06:53 -0800 (PST) Received: by 10.25.156.76 with HTTP; Thu, 3 Mar 2016 21:06:53 -0800 (PST) In-Reply-To: <56D86283.2050403@bwijnen.net> References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> Date: Thu, 3 Mar 2016 21:06:53 -0800 Message-ID: From: John Strassner To: "Bert Wijnen (IETF)" , John Strassner Content-Type: multipart/alternative; boundary=001a113f1fe05caaee052d321547 Archived-At: Cc: John Strassner , "Joel M. Halpern" , Andy Bierman , Nevil Brownlee , Zhoutianran , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 05:07:01 -0000 --001a113f1fe05caaee052d321547 Content-Type: text/plain; charset=UTF-8 >> 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)? Why would doing both concurrently impede interoperability? regards, John On Thu, Mar 3, 2016 at 8:12 AM, Bert Wijnen (IETF) wrote: > Inline > > On 03/03/16 16:48, Joel M. Halpern wrote: > >> 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". >> > 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 > >> Yours, >> Joel >> >> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: >> >>> 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 >>>> > >>>> wrote: >>>> >>>> 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. >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> John >>>> >>>> >>>> >>>> Andy >>>> >>>> >>>> -----Original Message----- >>>> From: Supa [mailto:supa-bounces@ietf.org >>>> ] 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, >>>> >>>> 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 >>>> >>>> > -----Original Message----- >>>> > From: Supa [mailto:supa-bounces@ietf.org >>>> ] 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"). >>>> > >>>> > 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:supa-bounces@ietf.org >>>> ] On Behalf Of IETF >>>> > >> Secretariat >>>> > >> Sent: Monday, February 29, 2016 6:35 AM >>>> > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org >>>> ; >>>> > >> supa-chairs@ietf.org ; >>>> supa@ietf.org >>>> > >> 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 >>>> > >> Supa@ietf.org >>>> > >> 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 >>>> > >>>> > _______________________________________________ >>>> > Supa mailing list >>>> > Supa@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/supa >>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >>> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > -- regards, John --001a113f1fe05caaee052d321547 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>> 2) The charter allows for a range of impleme= ntations of the SUPA
>>=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0syste= m.=C2=A0 Folks may recall I asked in the room at the last meeting
>>=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0whether our chartered allowd both c= ommunication between a
>>=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0con= trol system and a device, and communication between a
>>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 policy repository and a policy engine.=C2=A0 I = was told by the AD that
>>=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0th= e chartered allowed both.=C2=A0 This does make it rather interesting
<= div>>>=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0to define the "architecture= ".
> Mmmm... both concurrently, or did he mean that we as a WG c= an
>=C2=A0make a choice what we prefer and standardize that? > If we do both concurrently or a longside each other, can we then st= ill
>=C2=A0guarantee interoperability (which I think is one of= our main objctives, no)?

Why would doing both con= currently impede interoperability?


= regards,
John

On Thu, Mar 3, 2016 at 8:12 AM, Bert Wijnen (IETF) <bwi= etf@bwijnen.net> wrote:
Inl= ine

On 03/03/16 16:48, Joel M. Halpern wrote:
Two separate but related quesitons.

1) Can you help use find the places where the model / text is too implement= ation specific?=C2=A0 There are a few places where in describing enumeratio= ns the model calls for integers.=C2=A0 In the mapping to YANG, I have alrea= dy started replacing those with Enumerations.=C2=A0 Are there other kinds o= f over-specificity?

2) The charter allows for a range of implementations of the SUPA system.=C2= =A0 Folks may recall I asked in the room at the last meeting whether our ch= artered allowd both communication between a control system and a device, an= d communication between a policy repository and a policy engine.=C2=A0 I wa= s told by the AD that the chartered allowed both.=C2=A0 This does make it r= ather 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 guar= antee 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 w= ith regard to policy execution status, where the model makes some assumptio= ns about the structure of policy delivery.=C2=A0 For the most part, those s= hould be removed.=C2=A0 Assistance in finding them is appreciated.=C2=A0 I = suspect that some of them are necessary, and those should be explicitly des= cribed.=C2=A0 =C2=A0(And we should make sure the working group agrees with = the assumptions.)

3) (minor) The charter permits the information model.=C2=A0 I presume we co= uld amend the charter to permit an architecture document.

I would say an "Architecture" or "System Overview" docu= ment would be a good thing.

Bert
Yours,
Joel

On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote:
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
<John.= sc.Strassner@huawei.com <mailto:John.sc.Strassner@huawei.com>>
wrote:

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

=C2=A0 =C2=A0 =C2=A0 1) An information model can define how data are relate= d to each
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other independent of implementation. This= is much harder to do
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in YANG. Hence, the information model may= make these inherent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0relationships easier to visualize and def= ine.
=C2=A0 =C2=A0 =C2=A0 2) An information model separates the logical design f= rom the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0physical design of the system, enabling a= deeper understanding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of both independent of implementation. Th= is can be used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0produce more powerful implementations. =C2=A0 =C2=A0 =C2=A0 3) If an information model is worked on in another org= anization,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0there is no guarantee that its output wil= l be useful to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF. I am active in the TM Forum, which = you cited; they are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in general not worried about implementing= YANG models, much
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0less producing optimal YANG models.
=C2=A0 =C2=A0 =C2=A0 4) This enables other SDOs and fora, which do not use = YANG, to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more 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?=C2=A0 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.=C2=A0 A system architecture and a<= br> workable solution
will require a lot more than that.







=C2=A0 =C2=A0 John



Andy


=C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 From: Supa [mailto:supa-bounces@ietf.org
<mailto:supa-= bounces@ietf.org>] On Behalf Of Zhoutianran
=C2=A0 =C2=A0 Sent: Tuesday, March 01, 2016 7:29 PM
=C2=A0 =C2=A0 To: Nevil Brownlee
=C2=A0 =C2=A0 Cc: SUPA list
=C2=A0 =C2=A0 Subject: Re: [Supa] Information models and Data models - WG a= dopion?

=C2=A0 =C2=A0 Hi Nevil,

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

=C2=A0 =C2=A0 Tianran

=C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 > From: Supa [mailto:supa-bounces@ietf.org
<mailto:supa-= bounces@ietf.org>] On Behalf Of Nevil Brownlee
=C2=A0 =C2=A0 > Sent: Wednesday, March 02, 2016 6:56 AM
=C2=A0 =C2=A0 > To: Zhoutianran
=C2=A0 =C2=A0 > Cc: SUPA list
=C2=A0 =C2=A0 > Subject: Re: [Supa] Information models and Data models -= WG
adopion?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Hi Tianran:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > In my experiences, having a well-defined information mod= el is a
good starting
=C2=A0 =C2=A0 > point.=C2=A0 It allows different implementations, each o= f which can
develop it's
=C2=A0 =C2=A0 > own data model - in other words, the information model i= s a good
unifying
=C2=A0 =C2=A0 > influence - which is why publishing such a document is t= he
second of our
=C2=A0 =C2=A0 > chart items.=C2=A0 I hope that getting a good data model= will help us
with the
=C2=A0 =C2=A0 > first chart item ("scope of the policy-based manage= ment
framework").
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > draft-strassner-supa-generic-policy-info-model is the on= ly SUPA
=C2=A0 =C2=A0 > information model that's had any work done on it sin= ce IETF 95,
therefore
=C2=A0 =C2=A0 > I've proposed it for WG adoption.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > As for the third charter item - "set of YANG data m= odels", there
are two
=C2=A0 =C2=A0 > of these on the SUPA documents page.=C2=A0 It would help= at this
stage if their
=C2=A0 =C2=A0 > authors could comment on this list about the status of t= hese
drafts.=C2=A0 In
=C2=A0 =C2=A0 > particular, jave they been working on a new version?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Overall, we really need more discussion on the list of w= hat's
happening
=C2=A0 =C2=A0 > with the SUPA work!
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Cheers, Nevil
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On 1/03/16 6:13 pm, Zhoutianran wrote:
=C2=A0 =C2=A0 > > If this is a poll for WG adoption, I would say not = support.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > If we want to finally generate YANG data models her= e, why do
we spend
=C2=A0 =C2=A0 > time working on this information model?
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Why not focus on the ECA YANG data model directly a= s standard
track?
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Tianran
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >> -----Original Message-----
=C2=A0 =C2=A0 > >> From: Supa [mailto:supa-bounces@ietf.org
<mailto:supa-= bounces@ietf.org>] On Behalf Of IETF
=C2=A0 =C2=A0 > >> Secretariat
=C2=A0 =C2=A0 > >> Sent: Monday, February 29, 2016 6:35 AM
=C2=A0 =C2=A0 > >> To: draft-strassner-supa-gene= ric-policy-info-model@ietf.org
<mailto:draft-strassner-supa-generic-policy-info-model= @ietf.org>;
=C2=A0 =C2=A0 > >> supa-chairs@ietf.org <mailto:supa-chairs@ietf.org>;
supa@ietf.org <ma= ilto:supa@ietf.org&g= t;
=C2=A0 =C2=A0 > >> Subject: [Supa] The SUPA WG has placed
=C2=A0 =C2=A0 > >> draft-strassner-supa-generic-policy-info-model = in state "Call
For
=C2=A0 =C2=A0 > >> Adoption By WG Issued"
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> The SUPA WG has placed
draft-strassner-supa-generic-policy-info-model
=C2=A0 =C2=A0 > >> in state Call For Adoption By WG Issued (entere= d by Nevil
Brownlee)
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> The document is available at
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 >
https://datatracker.ietf.org/do= c/draft-strassner-supa-generic-policy-
=C2=A0 =C2=A0 > >> i
=C2=A0 =C2=A0 > >> nfo-model/
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> Comment:
=C2=A0 =C2=A0 > >> This is the first of our charter documents, the= other charter
items
=C2=A0 =C2=A0 > >> build on this
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> _______________________________________________=
=C2=A0 =C2=A0 > >> Supa mailing list
=C2=A0 =C2=A0 > >> Supa@ietf.org <mailto:Supa@ietf.org>
=C2=A0 =C2=A0 > >> https://www.ietf.org/mailman/l= istinfo/supa
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > --
=C2=A0 =C2=A0 >
---------------------------------------------------------------------
=C2=A0 =C2=A0 >=C2=A0 =C2=A0Nevil Brownlee=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Computer Sci= ence
Department
=C2=A0 =C2=A0 >=C2=A0 =C2=A0Phone: +64 9 373 7599 x88941=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The University of
Auckland
=C2=A0 =C2=A0 >=C2=A0 =C2=A0FAX: +64 9 373 7453=C2=A0 =C2=A0Priv= ate Bag 92019, Auckland 1142, New
Zealand
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Supa mailing list
=C2=A0 =C2=A0 > Supa@= ietf.org <mailto:= Supa@ietf.org>
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/s= upa

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Supa mailing list
=C2=A0 =C2=A0 Supa@ietf.= org <mailto:Supa@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/supa

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Supa mailing list
=C2=A0 =C2=A0 Supa@ietf.= org <mailto:Supa@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/supa




_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa


_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa


_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa



--
regards,
John
--001a113f1fe05caaee052d321547-- From nobody Thu Mar 3 21:11:50 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBB11B336B for ; Thu, 3 Mar 2016 21:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 NkSUcSTzI7YU for ; Thu, 3 Mar 2016 21:11:46 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C1D1B336A for ; Thu, 3 Mar 2016 21:11:45 -0800 (PST) Received: by mail-lb0-x229.google.com with SMTP id x1so48377103lbj.3 for ; Thu, 03 Mar 2016 21:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=MLFTQX154zknNkIiF57ZncScrhxhe9oCySjg33mfeC4=; b=vaz7Dtt9msHDB1EXRQseQnpzh0ufUV6sh1qef5wgai1CZPzUFArIikCJQBUsUH+1Nr VQ/ofFeaEMJJLalDw45ia0hQqif/EOKJLUWtMapLFRwZpuzV2cGRkiBJMZCvKDph+D7f uPLbras8Eih8Lrq4hRlvhuc6MdD+mj9KH3mV8isP2ZkUJxwsZ8pEUdyjDUae8QGxG36O emiXt9brOD6iZcBj1CGaSxohLij+JMYTmNolZFksmNxzVG0VCzcvS23VReZ3g8i1l/Od eAv+Zf7WDUiX/IkIMeRiszeiLcD9TnrRPPEdcviJt18rhTXTF30j8uHD/ubA4iWCvoyD 3s0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MLFTQX154zknNkIiF57ZncScrhxhe9oCySjg33mfeC4=; b=ZB/+vB4epv7j98luA04fhUcKDQ4CIkybMe94MKu0MS5d7CUtxEqhAdsuuJTH3tnqd2 prwoO+o2CmW2xhkXDxvcAExekl75wDSHIUpOIkCnWbN/mzDReJarRQyWVKFL+yvXoYoE XFRZOoYnhmTMNjj55KHTW+xVH+Cbe0U3r18bGpzK/cLSpq46NyXzbgRGYP22MZ/qU6lI MNsot32kjw4U8r06J5lGxZ8sdY6NOu+pxsdP8QWFrUVPMOw9FY/W5sePW7dNYUsmru5o Q1gfQc035IXaxgGWSZqjl75ImZm0VGUg9kM6TqddlJIQHDLrBMyjPpnu+zFyOv+uJNvs UARw== X-Gm-Message-State: AD7BkJLh59EJGaoXqCILzzukKCbTwSAG6JscsDBOTT1bLq3IK70Fl7tfiNcJ6rh3S7zykKRCk31ZOcJrov8vZw== MIME-Version: 1.0 X-Received: by 10.112.159.200 with SMTP id xe8mr2397104lbb.75.1457068304221; Thu, 03 Mar 2016 21:11:44 -0800 (PST) Received: by 10.25.156.76 with HTTP; Thu, 3 Mar 2016 21:11:44 -0800 (PST) In-Reply-To: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> Date: Thu, 3 Mar 2016 21:11:44 -0800 Message-ID: From: John Strassner To: Juergen Schoenwaelder , John Strassner Content-Type: multipart/alternative; boundary=001a11c3c092afcd2c052d3226f7 Archived-At: Cc: John Strassner , "Joel M. Halpern" , Andy Bierman , Nevil Brownlee , Zhoutianran , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 05:11:49 -0000 --001a11c3c092afcd2c052d3226f7 Content-Type: text/plain; charset=UTF-8 > 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. 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 wrote: > 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:supa-bounces@ietf.org] 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, > > 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 > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de > ] > > Sent: Wednesday, March 02, 2016 2:45 PM > > To: Joel M. Halpern > > Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list > > Subject: Re: [Supa] Information models and Data models - WG adopion? > > > > On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote: > > > > > 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. > > > > 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 > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > -- regards, John --001a11c3c092afcd2c052d3226f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> My experience is that you usually only know whet= her the information model
> is reasonably complete and clear if you h= ave done the whole round-trip at
> least once, that is you have done:=
>
> info model -> data model -> implementation -> da= ta 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 m= odel because
> you expect interoperability based on the info model, t= hen 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 cl= ue or agreement how to write a data
> model, then it is fine to be pr= epared to diverge from the info model up
> to the point that it is no= t important anymore for interoperability.
>
> So the key quest= ion for me is which function the info model is supposed
> to fulfill.=

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

regards,<= /div>
John

On Thu, Mar 3, 2016 at 9:45 AM, John Strassner &= lt;John.s= c.Strassner@huawei.com> wrote:
It is actually more like the V-model than a spiral model - the spiral m= odel is risk-driven.

The point of model-driven software is to use the info model as the source t= hat 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:supa-bounces@ie= tf.org] 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,

Emmm, the round trip you mentioned much like the spiral model in software e= ngineering. That's of course a good way to do system design and impleme= ntation.

However, in this process, the information model is like an intermediary sta= te, 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 UM= L drawing shared during the DM design. And those make life simpler for expr= ess intent and idea, and for interoperation.

A document with more than 100 pages just make all the things complex. That&= #39;s my humble opinion.

Tianran

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Wednesday, March 02, 2016 2:45 PM
> To: Joel M. Halpern
> Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list
> Subject: Re: [Supa] Information models and Data models - WG adopion? >
> On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote:
>
> > First, the entire information model will be rendered intoa YANG d= ata 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.
>
> My experience is that you usually only know whether the information mo= del
> 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 upda= tes ->
> information model updates
>
> A pure top-down approach will leave you with an info model which only<= br> > partially describes what happens in a data model. Now, this might be f= ine,
> 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 y= ou
> 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 u= p
> to the point that it is not important anymore for interoperability. >
> So the key question for me is which function the info model is suppose= d
> to fulfill.
>
> /js
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.jacobs-university.de/>

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa



--
regards,
John
--001a11c3c092afcd2c052d3226f7-- From nobody Thu Mar 3 21:18:12 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9701B3376 for ; Thu, 3 Mar 2016 21:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 VjLFJF5vqEUc for ; Thu, 3 Mar 2016 21:18:07 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F231B3372 for ; Thu, 3 Mar 2016 21:18:07 -0800 (PST) Received: by mail-lb0-x22a.google.com with SMTP id x1so48489017lbj.3 for ; Thu, 03 Mar 2016 21:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sOiknUYmHBAxnVaTWEvF6D6uwbSWIBrNuoVR2ZEvd+0=; b=myU5rAsyAoUHsQQ5w7JBAd9P7S1raZ8frvmOizh7GWXArKhVp9LJ2wuTqgmsvmxT9t JlpjttjiSrhLLbKtzgZ5e4H6MUZam2NlaCi3VpHcEwc0tLdHedYUvri7/upHdV7fphIH 92aZDIqiqd5SQua1O9OELPjiqOHF2uZLmnbniaWJXFL+RYLLCTP+7X4jReLuc7CJvQ0W QQcxF0iCMx9fnWq1HBBo1fUmmuvA84voaf4TfWJgjQp7oyb9LUjvb64uLSyXQi2dy95b rMgXxnAMZWOF/KoFBy0iyca65RSb1bZfscrut5zuwO74dYR3za/FMiBr+XhBlKmoZoGu Pe0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sOiknUYmHBAxnVaTWEvF6D6uwbSWIBrNuoVR2ZEvd+0=; b=f+eq4X7HXyYZ9yc1GzVttY7pvHgUQo9y7u0wQZGL4AMcSiq8LRAPwfWKXe+3dcqnEu dhPW86Jhyz7ep6pjQ+So57H8uvhz2gpioCuwWFMPE8HVfJAi6tQKV6lhxhyZWOvsw/X5 7fFu3VQL38IDF+sPOBHK0c/gXQYatZLMRAC7BpK20WlosrcyzNYddwGahw/CE+gpD9Ym CQVt0CxAbClv43Kp9ERPbFU0zElwwm7ffe1pwaHchjpxHC2++8KFuDfhOx0Ufytxj771 tiVVbU2RWKH6M6qc60ebhS8wD3OjA1YZCw6qrmasTocoEsil1zzKuvm+dm+6bAe6SyPS SbYw== X-Gm-Message-State: AD7BkJLB4BP2VW++T1EkIEhkPmF7Dj8Npd98YA284+XuHfmB/TFNktQlkUKRTiuVSm+1x9LRcRysdQAXzuWHqw== MIME-Version: 1.0 X-Received: by 10.25.78.71 with SMTP id c68mr2299646lfb.89.1457068685453; Thu, 03 Mar 2016 21:18:05 -0800 (PST) Received: by 10.25.156.76 with HTTP; Thu, 3 Mar 2016 21:18:05 -0800 (PST) In-Reply-To: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> <56D9011B.50803@joelhalpern.com> Date: Thu, 3 Mar 2016 21:18:05 -0800 Message-ID: From: John Strassner To: Zhoutianran , John Strassner Content-Type: multipart/alternative; boundary=001a114190e868f1d0052d323d41 Archived-At: Cc: John Strassner , Juergen Schoenwaelder , Andy Bierman , Nevil Brownlee , "Joel M. Halpern" , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 05:18:11 -0000 --001a114190e868f1d0052d323d41 Content-Type: text/plain; charset=UTF-8 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 wrote: > 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 > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Friday, March 04, 2016 11:30 AM > > To: Zhoutianran; John Strassner; Juergen Schoenwaelder > > Cc: Nevil Brownlee; Andy Bierman; SUPA list; strazpdj@gmail.com > > Subject: Re: [Supa] Information models and Data models - WG adopion? > > > > 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 > > > > On 3/3/16 10:23 PM, Zhoutianran wrote: > > > 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 > > > > > >> -----Original Message----- > > >> 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; strazpdj@gmail.com > > >> Subject: RE: [Supa] Information models and Data models - WG adopion? > > >> > > >> 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:supa-bounces@ietf.org] 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, > > >> > > >> 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 > > >> > > >>> -----Original Message----- > > >>> From: Juergen Schoenwaelder > > >>> [mailto:j.schoenwaelder@jacobs-university.de] > > >>> Sent: Wednesday, March 02, 2016 2:45 PM > > >>> To: Joel M. Halpern > > >>> Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list > > >>> Subject: Re: [Supa] Information models and Data models - WG adopion? > > >>> > > >>> On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote: > > >>> > > >>>> 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. > > >>> > > >>> 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 > > >> > > >> _______________________________________________ > > >> Supa mailing list > > >> Supa@ietf.org > > >> https://www.ietf.org/mailman/listinfo/supa > > > > -- regards, John --001a114190e868f1d0052d323d41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 (e= ven if it was a free tool), then what
are people supposed to do?<= /div>

The original PCIM and PCIMe info models, as well a= s several
others (e.g., IPsec work) were all RFCs and were all te= xt.

In addition, there are plenty of data models b= uilt from UML. There
is even a UML-to-YANG converter in process.<= /div>

If you have a technical contribution, please make = it.

On= Thu, Mar 3, 2016 at 9:01 PM, Zhoutianran <zhoutianran@huawei.com= > wrote:
In short to be clear.<= br> I am not opposed to do information modeling for DM generation and other ben= efits.
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 sou= rce communities, we can also use jira, gerrit, but may not.
We document the final data models with YANG in text.

Regards,
Tianran

> -----Original Message-----
> From: Joel M. Halpern [mailto:j= mh@joelhalpern.com]
> Sent: Friday, March 04, 2016 11:30 AM
> To: Zhoutianran; John Strassner; Juergen Schoenwaelder
> Cc: Nevil Brownlee; Andy Bierman; SUPA list; strazpdj@gmail.com
> Subject: Re: [Supa] Information models and Data models - WG adopion? >
> 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 a= nd
> 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.=C2=A0 So it is rather difficult to build one that focuses o= n a full
> UML diagram.=C2=A0 (And many people do not want to read the PDF.)
>
> Side note: The RFC Editor and the community are working on revisions t= o
> the process and rules for RFCs.=C2=A0 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 i= n
> the document.=C2=A0 This is included because we have found that many p= eople in
> the working group are not familiar with the ways things are done in UM= L.
> And we want everyone interested to be able to review and comment on th= e
> document.
>
> We are working on producing a YANG data model.=C2=A0 The charter is qu= ite clear
> that such is what we need to produce.
>
> Given that you say you are not opposed to the IM, I am left quite conf= used
> as to what you want.
>
> Yours,
> Joel
>
> On 3/3/16 10:23 PM, Zhoutianran wrote:
> > 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, whi= le in
> many other organizations, they use UML.
> >
> > You have a 100+ pages draft, but large content just repeat the ba= sic UML
> and OO concept, like the inherit, aggregation, subclass...
> >
> >
> > Tianran
> >
> >> -----Original Message-----
> >> 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; strazpdj@gmail.com
> >> Subject: RE: [Supa] Information models and Data models - WG a= dopion?
> >>
> >> It is actually more like the V-model than a spiral model - th= e spiral
> >> model is risk-driven.
> >>
> >> The point of model-driven software is to use the info model a= s the
> >> source that ties everything together, including requirements,=
> >> documentation, test, and implementation. You seem to be advoc= ating
> >> bottom-up data models, which produces separate silos of softw= are.
> >>
> >>
> >> -----Original Message-----
> >> From: Supa [mailto:s= upa-bounces@ietf.org] 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 a= dopion?
> >>
> >>
> >> 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 s= ystem 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 li= fe
> >> simpler for express intent and idea, and for interoperation.<= br> > >>
> >> A document with more than 100 pages just make all the things = complex.
> >> That's my humble opinion.
> >>
> >> Tianran
> >>
> >>> -----Original Message-----
> >>> From: Juergen Schoenwaelder
> >>> [mailto:j.schoenwaelder@jacobs-university.de]
> >>> Sent: Wednesday, March 02, 2016 2:45 PM
> >>> To: Joel M. Halpern
> >>> Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list<= br> > >>> Subject: Re: [Supa] Information models and Data models - = WG adopion?
> >>>
> >>> On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern= wrote:
> >>>
> >>>> 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.
> >>>
> >>> My experience is that you usually only know whether the i= nformation
> >>> model is reasonably complete and clear if you have done t= he whole
> >>> round-trip at least once, that is you have done:
> >>>
> >>> info model -> data model -> implementation -> da= ta model updates ->
> >>> information model updates
> >>>
> >>> A pure top-down approach will leave you with an info mode= l which
> >>> only partially describes what happens in a data model. No= w, this
> >>> might be fine, depending on _why_ you define an info mode= l. If you
> >>> do the info model because you expect interoperability bas= ed 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 b= ecause 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 p= oint that
> >>> it is not important
> >> anymore for interoperability.
> >>>
> >>> So the key question for me is which function the info mod= el is
> >>> supposed to fulfill.
> >>>
> >>> /js
> >>>
> >>> --
> >>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Jacobs University Bremen gGmbH
> >>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Campus Ring 1 | 28759 Bremen | Germany
> >>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<http://www.jacobs-university.de/>
> >>
> >> _______________________________________________
> >> Supa mailing list
> >> Supa@ietf.org
> >> https://www.ietf.org/mailman/listinfo/supa
> >



--
regards,
John
--001a114190e868f1d0052d323d41-- From nobody Thu Mar 3 21:20:58 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB991B3381 for ; Thu, 3 Mar 2016 21:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 6A3upoYSxZ_p for ; Thu, 3 Mar 2016 21:20:54 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8411B2A2A for ; Thu, 3 Mar 2016 21:20:53 -0800 (PST) Received: by mail-lb0-x231.google.com with SMTP id bc4so48511453lbc.2 for ; Thu, 03 Mar 2016 21:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Bb45w6/ERLrUqHojvkrwyg31QR2Z2/TZDIRClW0zUlM=; b=yfkEu30uBMf2W9EeJliXqCYE8eX4s1WKSCbdJuRtNHFiDaCFNxCmIhgZNxDRX+fbMI 2VMwoddmxRVAj9gQzjdZIMEAUTCfYOTw8Ty4JkUzVrcta2kLckyoHrJogx61v0Bty/Nb I/mh7dU+kv5xQpPiT78UGe035cA4RU4wLSTr14RojG162FShuxfUBsmJFv510/CpOYOC wrysDEI4O77HY8KWxzXabBliNS1MzNUnx0kAF1xgcaLyo6qBleS/JgGzG1W6RVJzNkcc zFV9ErATCv7qL0aSUs1FgRNtL3F3Fj/Us7zAskF+GFtuLf9D8/S77tUf1SpQvzUODD+7 BzcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Bb45w6/ERLrUqHojvkrwyg31QR2Z2/TZDIRClW0zUlM=; b=N0eD5vU9J+iyGit96bGkZxVOygH7YExkPjZMmw6jNTGFWi4iLEdMDO8P2R4DTEDDyG kqH3e0iz2HRCAwPd+woHFY8vf9loLRXPM3LyEgwTEmHCMhW9b7aCVxg3MuLi4P5SW5By yhtoDhLoOZqkuds5tUchRJUjsHWoH9JVyutP5Ll9+XmRlKfdo1l6iQIafHhHhjrMYWKz x8ncwtMWHOUBf78logjHqFGZKniY9qO//stfdATVYBSRWXXNGkYet/EpgUznG9iDvhHB W0gpwIax4H8/gW8VE1fkx15f+iHJmGK/lmwgCHIsx4mlT6EARucS+JnNVYwa5OC9Snrg w5jw== X-Gm-Message-State: AD7BkJJxdVga4PiZuj4J7XEUNRAmoGlX+3y/H8Kk9Nz2xSKbRHQGi1P6L/Xc105OGKkJPbVLhZtIrXcyOJVrYA== MIME-Version: 1.0 X-Received: by 10.25.44.18 with SMTP id s18mr2445368lfs.66.1457068851942; Thu, 03 Mar 2016 21:20:51 -0800 (PST) Received: by 10.25.156.76 with HTTP; Thu, 3 Mar 2016 21:20:51 -0800 (PST) In-Reply-To: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> Date: Thu, 3 Mar 2016 21:20:51 -0800 Message-ID: From: John Strassner To: Zhoutianran , John Strassner Content-Type: multipart/alternative; boundary=001a11402ece556921052d3247b5 Archived-At: Cc: John Strassner , Juergen Schoenwaelder , Andy Bierman , Nevil Brownlee , "Joel M. Halpern" , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 05:20:56 -0000 --001a11402ece556921052d3247b5 Content-Type: text/plain; charset=UTF-8 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 wrote: > 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 > > > -----Original Message----- > > 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; strazpdj@gmail.com > > Subject: RE: [Supa] Information models and Data models - WG adopion? > > > > 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:supa-bounces@ietf.org] 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, > > > > 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 > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Wednesday, March 02, 2016 2:45 PM > > > To: Joel M. Halpern > > > Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list > > > Subject: Re: [Supa] Information models and Data models - WG adopion? > > > > > > On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote: > > > > > > > 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. > > > > > > 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 > > > > _______________________________________________ > > Supa mailing list > > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > -- regards, John --001a11402ece556921052d3247b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Actually, you are missing my point. It's about mo= del-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 resp= onse.


On Thu, Mar 3, 2016 at 7:23 PM, Zhoutianran <zhoutia= nran@huawei.com> wrote:
I t= hink 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 an= d OO concept, like the inherit, aggregation, subclass...


Tianran

> -----Original Message-----
> 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; strazpdj@gmail.com
> Subject: RE: [Supa] Information models and Data models - WG adopion? >
> 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 sou= rce
> that ties everything together, including requirements, documentation, = test,
> and implementation. You seem to be advocating bottom-up data models, w= hich
> produces separate silos of software.
>
>
> -----Original Message-----
> From: Supa [mailto:supa-bounc= es@ietf.org] 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,
>
> Emmm, the round trip you mentioned much like the spiral model in softw= are
> engineering. That's of course a good way to do system design and > implementation.
>
> However, in this process, the information model is like an intermediar= y
> 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 f= or
> 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
>
> > -----Original Message-----
> > From: Juergen Schoenwaelder
> > [mailto:j= .schoenwaelder@jacobs-university.de]
> > Sent: Wednesday, March 02, 2016 2:45 PM
> > To: Joel M. Halpern
> > Cc: Andy Bierman; Nevil Brownlee; Zhoutianran; SUPA list
> > Subject: Re: [Supa] Information models and Data models - WG adopi= on?
> >
> > On Wed, Mar 02, 2016 at 12:09:58AM -0500, Joel M. Halpern wrote:<= br> > >
> > > First, the entire information model will be rendered intoa Y= ANG 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.
> >
> > My experience is that you usually only know whether the informati= on
> > 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 mod= el
> > 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 pre= pared
> > to diverge from the info model up to the point that it is not imp= ortant
> anymore for interoperability.
> >
> > So the key question for me is which function the info model is > > supposed to fulfill.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
>
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa



--
regards,
John
--001a11402ece556921052d3247b5-- From nobody Thu Mar 3 22:53:43 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6791B3424 for ; Thu, 3 Mar 2016 22:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 PEbLnWFSTFES for ; Thu, 3 Mar 2016 22:53:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F691B3423 for ; Thu, 3 Mar 2016 22:53:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFI00046; Fri, 04 Mar 2016 06:53:34 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Mar 2016 06:53:32 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.102]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 4 Mar 2016 14:53:23 +0800 From: Zhoutianran To: John Strassner Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2mOZC2OcBCLECSqIAKm8tvNJ9E7JYAgAAougCAABqTgIAB5T0AgABlnoCAASNagP//nuyAgACZa2A= Date: Fri, 4 Mar 2016 06:53:22 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2183B899DDNKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.56D930EF.0033, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 071bb84bb764e94a94ef44b694de3e28 Archived-At: Cc: John Strassner , Juergen Schoenwaelder , Andy Bierman , Nevil Brownlee , "Joel M. Halpern" , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 06:53:42 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2183B899DDNKGEML515MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlbiB5b3VyIHRoaXMgYW5kIGxhc3QgZW1haWwuDQoNCllvdXIgbG9naWMgaXM6IHRoaXMgaXMg SUVURiwgc28gdGV4dCBpcyBvbW5pcG90ZW50LCBzbyB5b3UgdXNlIHRleHQgdG8gZGVzY3JpYmUg SU0gd2l0aCAxMDArIHBhZ2VzIGRvY3VtZW50IGZvciBpbnRlcm9wZXJhdGlvbiwgYW5kIHRoZW4g Z2VuZXJhdGUgVU1McywgYW5kIGZpbmFsbHkgdXNlIFVNTC0+WUFORyB0b29sIHRvIGdlbmVyYXRl IGRhdGEgbW9kZWwuDQoNCk15IHN1Z2dlc3Rpb24gaXM6IFRleHQgdXNlZCBpbiBJRVRGIGlzIG5v dCBnb29kIGF0IGRlc2NyaWJlIElNLCBzbyB3ZSB1c2UgVU1MIGZvciBpbnRlcm9wZXJhdGlvbihi dXQgVU1MIG91dHB1dCBub3QgcXVhbGlmaWVzIFJGQyksIGFuZCB0aGVuIGdlbmVyYXRlIERNLg0K DQpBbSBJIG1pc3MgeW91ciBwb2ludD8gV2hpY2ggb25lIGlzIGVhc2llciB0byBpbXBsZW1lbnQ/ DQoNCg0KVGlhbnJhbg0KDQpGcm9tOiBKb2huIFN0cmFzc25lciBbbWFpbHRvOnN0cmF6cGRqQGdt YWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgTWFyY2ggMDQsIDIwMTYgMToyMSBQTQ0KVG86IFpob3V0 aWFucmFuOyBKb2huIFN0cmFzc25lcg0KQ2M6IEpvaG4gU3RyYXNzbmVyOyBKdWVyZ2VuIFNjaG9l bndhZWxkZXI7IEpvZWwgTS4gSGFscGVybjsgTmV2aWwgQnJvd25sZWU7IEFuZHkgQmllcm1hbjsg U1VQQSBsaXN0DQpTdWJqZWN0OiBSZTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0 YSBtb2RlbHMgLSBXRyBhZG9waW9uPw0KDQpBY3R1YWxseSwgeW91IGFyZSBtaXNzaW5nIG15IHBv aW50LiBJdCdzIGFib3V0IG1vZGVsLWRyaXZlbiBzb2Z0d2FyZS4NClRoaXMgaXMgbm90IHRoZSBP TUcsIGl0IGlzIHRoZSBJRVRGLiBUZXh0IGlzIG91ciBmcmllbmQuIFdlIG5lZWQgYQ0KdGV4dCBk b2N1bWVudCB0byBlc3RhYmxpc2ggV0cgdHJhY2VhYmlsaXR5IGZvciB0aGUgZGF0YSBtb2RlbC4N Cg0KSW4gYWRkaXRpb24sIHNlZSBteSBsYXN0IHJlc3BvbnNlLg0KDQoNCk9uIFRodSwgTWFyIDMs IDIwMTYgYXQgNzoyMyBQTSwgWmhvdXRpYW5yYW4gPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFp bHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20+PiB3cm90ZToNCkkgdGhpbmsgeW91IG1pc3MgbXkg cG9pbnQuDQoNCkkgYW0gbm90IGFnYWluc3QgSU0uIEJ1dCBhcyBhbiBpbnRlcm1lZGlhcnkgc3Rh dGUsIEkgdGhpbmsgSU0gbm8gbmVlZCB0byBiZSBkZWxpdmVyZWQgYXMgYW4gUkZDLg0KDQpBbmQg SSBkbyBub3QgdGhpbmsgdGV4dCBkb2N1bWVudCBpcyB0aGUgYmVzdCB0b29sIGZvciB0aGUgSU0s IHdoaWxlIGluIG1hbnkgb3RoZXIgb3JnYW5pemF0aW9ucywgdGhleSB1c2UgVU1MLg0KDQpZb3Ug aGF2ZSBhIDEwMCsgcGFnZXMgZHJhZnQsIGJ1dCBsYXJnZSBjb250ZW50IGp1c3QgcmVwZWF0IHRo ZSBiYXNpYyBVTUwgYW5kIE9PIGNvbmNlcHQsIGxpa2UgdGhlIGluaGVyaXQsIGFnZ3JlZ2F0aW9u LCBzdWJjbGFzcy4uLg0KDQoNClRpYW5yYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBKb2huIFN0cmFzc25lcg0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDA0LCAyMDE2 IDE6NDYgQU0NCj4gVG86IFpob3V0aWFucmFuOyBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IEpvZWwg TS4gSGFscGVybg0KPiBDYzogTmV2aWwgQnJvd25sZWU7IEFuZHkgQmllcm1hbjsgU1VQQSBsaXN0 OyBzdHJhenBkakBnbWFpbC5jb208bWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbT4NCj4gU3ViamVj dDogUkU6IFtTdXBhXSBJbmZvcm1hdGlvbiBtb2RlbHMgYW5kIERhdGEgbW9kZWxzIC0gV0cgYWRv cGlvbj8NCj4NCj4gSXQgaXMgYWN0dWFsbHkgbW9yZSBsaWtlIHRoZSBWLW1vZGVsIHRoYW4gYSBz cGlyYWwgbW9kZWwgLSB0aGUgc3BpcmFsIG1vZGVsDQo+IGlzIHJpc2stZHJpdmVuLg0KPg0KPiBU aGUgcG9pbnQgb2YgbW9kZWwtZHJpdmVuIHNvZnR3YXJlIGlzIHRvIHVzZSB0aGUgaW5mbyBtb2Rl bCBhcyB0aGUgc291cmNlDQo+IHRoYXQgdGllcyBldmVyeXRoaW5nIHRvZ2V0aGVyLCBpbmNsdWRp bmcgcmVxdWlyZW1lbnRzLCBkb2N1bWVudGF0aW9uLCB0ZXN0LA0KPiBhbmQgaW1wbGVtZW50YXRp b24uIFlvdSBzZWVtIHRvIGJlIGFkdm9jYXRpbmcgYm90dG9tLXVwIGRhdGEgbW9kZWxzLCB3aGlj aA0KPiBwcm9kdWNlcyBzZXBhcmF0ZSBzaWxvcyBvZiBzb2Z0d2FyZS4NCj4NCj4NCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFpob3V0 aWFucmFuDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDIsIDIwMTYgODowMSBQTQ0KPiBUbzog SnVlcmdlbiBTY2hvZW53YWVsZGVyOyBKb2VsIE0uIEhhbHBlcm4NCj4gQ2M6IE5ldmlsIEJyb3du bGVlOyBBbmR5IEJpZXJtYW47IFNVUEEgbGlzdA0KPiBTdWJqZWN0OiBSZTogW1N1cGFdIEluZm9y bWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBXRyBhZG9waW9uPw0KPg0KPg0KPiBIaSBK dWVyZ2VuLA0KPg0KPiBFbW1tLCB0aGUgcm91bmQgdHJpcCB5b3UgbWVudGlvbmVkIG11Y2ggbGlr ZSB0aGUgc3BpcmFsIG1vZGVsIGluIHNvZnR3YXJlDQo+IGVuZ2luZWVyaW5nLiBUaGF0J3Mgb2Yg Y291cnNlIGEgZ29vZCB3YXkgdG8gZG8gc3lzdGVtIGRlc2lnbiBhbmQNCj4gaW1wbGVtZW50YXRp b24uDQo+DQo+IEhvd2V2ZXIsIGluIHRoaXMgcHJvY2VzcywgdGhlIGluZm9ybWF0aW9uIG1vZGVs IGlzIGxpa2UgYW4gaW50ZXJtZWRpYXJ5DQo+IHN0YXRlLCBidXQgbm90IHRoZSBmaW5hbCBvdXRw dXQgKFJGQykgd2UgbmVlZC4NCj4gSSBtZWFuLCBldmVuIGlmIHdlIGRvIG5vdCBoYXZlIGEgSU0g UkZDLCB3ZSBjYW4gYWx3YXlzIGhhdmUgYSBzY3JhdGNoIG9yDQo+IFVNTCBkcmF3aW5nIHNoYXJl ZCBkdXJpbmcgdGhlIERNIGRlc2lnbi4gQW5kIHRob3NlIG1ha2UgbGlmZSBzaW1wbGVyIGZvcg0K PiBleHByZXNzIGludGVudCBhbmQgaWRlYSwgYW5kIGZvciBpbnRlcm9wZXJhdGlvbi4NCj4NCj4g QSBkb2N1bWVudCB3aXRoIG1vcmUgdGhhbiAxMDAgcGFnZXMganVzdCBtYWtlIGFsbCB0aGUgdGhp bmdzIGNvbXBsZXguIFRoYXQncw0KPiBteSBodW1ibGUgb3Bpbmlvbi4NCj4NCj4gVGlhbnJhbg0K Pg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSnVlcmdlbiBTY2hv ZW53YWVsZGVyDQo+ID4gW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT5dDQo+ID4gU2Vu dDogV2VkbmVzZGF5LCBNYXJjaCAwMiwgMjAxNiAyOjQ1IFBNDQo+ID4gVG86IEpvZWwgTS4gSGFs cGVybg0KPiA+IENjOiBBbmR5IEJpZXJtYW47IE5ldmlsIEJyb3dubGVlOyBaaG91dGlhbnJhbjsg U1VQQSBsaXN0DQo+ID4gU3ViamVjdDogUmU6IFtTdXBhXSBJbmZvcm1hdGlvbiBtb2RlbHMgYW5k IERhdGEgbW9kZWxzIC0gV0cgYWRvcGlvbj8NCj4gPg0KPiA+IE9uIFdlZCwgTWFyIDAyLCAyMDE2 IGF0IDEyOjA5OjU4QU0gLTA1MDAsIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4gPg0KPiA+ID4g Rmlyc3QsIHRoZSBlbnRpcmUgaW5mb3JtYXRpb24gbW9kZWwgd2lsbCBiZSByZW5kZXJlZCBpbnRv YSBZQU5HIGRhdGENCj4gbW9kZWwuDQo+ID4gPiBUaGUgYWR2YW50YWdlIG9mIGRpc2N1c3Npbmcg dGhlIGluZm9ybWF0aW9uIG1vZGVsIGlzIHRoYXQgd2UgY2FuDQo+ID4gPiBtYWtlIHN1cmUgdGhl IGluZm9ybWF0aW9uIGFuZCByZWxhdGlvbnNoaXBzIGFyZSByaWdodCBiZWZvcmUgZG9pbmcNCj4g PiA+IHRoZSB3b3JrIG9mIGdldHRpbmcgdGhlIFlBTkcgc3ludGF4IHJpZ2h0Lg0KPiA+DQo+ID4g TXkgZXhwZXJpZW5jZSBpcyB0aGF0IHlvdSB1c3VhbGx5IG9ubHkga25vdyB3aGV0aGVyIHRoZSBp bmZvcm1hdGlvbg0KPiA+IG1vZGVsIGlzIHJlYXNvbmFibHkgY29tcGxldGUgYW5kIGNsZWFyIGlm IHlvdSBoYXZlIGRvbmUgdGhlIHdob2xlDQo+ID4gcm91bmQtdHJpcCBhdCBsZWFzdCBvbmNlLCB0 aGF0IGlzIHlvdSBoYXZlIGRvbmU6DQo+ID4NCj4gPiBpbmZvIG1vZGVsIC0+IGRhdGEgbW9kZWwg LT4gaW1wbGVtZW50YXRpb24gLT4gZGF0YSBtb2RlbCB1cGRhdGVzIC0+DQo+ID4gaW5mb3JtYXRp b24gbW9kZWwgdXBkYXRlcw0KPiA+DQo+ID4gQSBwdXJlIHRvcC1kb3duIGFwcHJvYWNoIHdpbGwg bGVhdmUgeW91IHdpdGggYW4gaW5mbyBtb2RlbCB3aGljaCBvbmx5DQo+ID4gcGFydGlhbGx5IGRl c2NyaWJlcyB3aGF0IGhhcHBlbnMgaW4gYSBkYXRhIG1vZGVsLiBOb3csIHRoaXMgbWlnaHQgYmUN Cj4gPiBmaW5lLCBkZXBlbmRpbmcgb24gX3doeV8geW91IGRlZmluZSBhbiBpbmZvIG1vZGVsLiBJ ZiB5b3UgZG8gdGhlIGluZm8NCj4gPiBtb2RlbCBiZWNhdXNlIHlvdSBleHBlY3QgaW50ZXJvcGVy YWJpbGl0eSBiYXNlZCBvbiB0aGUgaW5mbyBtb2RlbCwNCj4gPiB0aGVuIEkgYmVsaWV2ZSBhIGZ1 bGwgcm91bmQtdHJpcCBpcyBuZWNlc3NhcnkgdG8gZ2V0IHRoZSBpbmZvIG1vZGVsDQo+ID4gcmVh c29uYWJseSBwcmVjaXNlLiBJZiB5b3UgZG8gdGhlIGluZm8gbW9kZWwgYmVjYXVzZSB5b3UgaGF2 ZSBubyBjbHVlDQo+ID4gb3IgYWdyZWVtZW50IGhvdyB0byB3cml0ZSBhIGRhdGEgbW9kZWwsIHRo ZW4gaXQgaXMgZmluZSB0byBiZSBwcmVwYXJlZA0KPiA+IHRvIGRpdmVyZ2UgZnJvbSB0aGUgaW5m byBtb2RlbCB1cCB0byB0aGUgcG9pbnQgdGhhdCBpdCBpcyBub3QgaW1wb3J0YW50DQo+IGFueW1v cmUgZm9yIGludGVyb3BlcmFiaWxpdHkuDQo+ID4NCj4gPiBTbyB0aGUga2V5IHF1ZXN0aW9uIGZv ciBtZSBpcyB3aGljaCBmdW5jdGlvbiB0aGUgaW5mbyBtb2RlbCBpcw0KPiA+IHN1cHBvc2VkIHRv IGZ1bGZpbGwuDQo+ID4NCj4gPiAvanMNCj4gPg0KPiA+IC0tDQo+ID4gSnVlcmdlbiBTY2hvZW53 YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPiBQaG9u ZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4g fCBHZXJtYW55DQo+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3 dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IFN1cGEgbWFpbGluZyBsaXN0DQo+IFN1cGFAaWV0Zi5v cmc8bWFpbHRvOlN1cGFAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc3VwYQ0KDQoNCg0KLS0NCnJlZ2FyZHMsDQpKb2huDQo= --_000_BBA82579FD347748BEADC4C445EA0F2183B899DDNKGEML515MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65paw5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2 IDkgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDmlrDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDkgMyAxIDEgMSAx IDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWVuIHlvdXIgdGhpcyBh bmQgbGFzdCBlbWFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPllvdXIgbG9naWMgaXM6IHRoaXMgaXMgSUVURiwgc28gdGV4dCBpcyBvbW5p cG90ZW50LCBzbyB5b3UgdXNlIHRleHQgdG8gZGVzY3JpYmUgSU0gd2l0aCAxMDAmIzQzOyBwYWdl cyBkb2N1bWVudCBmb3IgaW50ZXJvcGVyYXRpb24sIGFuZCB0aGVuIGdlbmVyYXRlIFVNTHMsDQog YW5kIGZpbmFsbHkgdXNlIFVNTC0mZ3Q7WUFORyB0b29sIHRvIGdlbmVyYXRlIGRhdGEgbW9kZWwu IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ TXkgc3VnZ2VzdGlvbiBpczogVGV4dCB1c2VkIGluIElFVEYgaXMgbm90IGdvb2QgYXQgZGVzY3Jp YmUgSU0sIHNvIHdlIHVzZSBVTUwgZm9yIGludGVyb3BlcmF0aW9uKGJ1dCBVTUwgb3V0cHV0IG5v dCBxdWFsaWZpZXMgUkZDKSwgYW5kIHRoZW4gZ2VuZXJhdGUgRE0uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5BbSBJIG1pc3MgeW91ciBwb2lu dD8gV2hpY2ggb25lIGlzIGVhc2llciB0byBpbXBsZW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGlhbnJhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEpvaG4gU3RyYXNzbmVyIFttYWlsdG86c3RyYXpwZGpA Z21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMDQsIDIwMTYgMToy MSBQTTxicj4NCjxiPlRvOjwvYj4gWmhvdXRpYW5yYW47IEpvaG4gU3RyYXNzbmVyPGJyPg0KPGI+ Q2M6PC9iPiBKb2huIFN0cmFzc25lcjsgSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBKb2VsIE0uIEhh bHBlcm47IE5ldmlsIEJyb3dubGVlOyBBbmR5IEJpZXJtYW47IFNVUEEgbGlzdDxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMg LSBXRyBhZG9waW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+QWN0dWFsbHksIHlvdSBhcmUgbWlzc2luZyBteSBwb2ludC4gSXQncyBhYm91dCBtb2Rl bC1kcml2ZW4gc29mdHdhcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgaXMgbm90IHRoZSBP TUcsIGl0IGlzIHRoZSBJRVRGLiBUZXh0IGlzIG91ciBmcmllbmQuIFdlIG5lZWQgYTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj50ZXh0IGRvY3VtZW50IHRvIGVzdGFibGlzaCBXRyB0cmFjZWFiaWxpdHkg Zm9yIHRoZSBkYXRhIG1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SW4gYWRkaXRpb24sIHNlZSBteSBsYXN0IHJlc3BvbnNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPk9uIFRodSwgTWFyIDMsIDIwMTYgYXQgNzoyMyBQTSwgWmhvdXRpYW5yYW4gJmx0 OzxhIGhyZWY9Im1haWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ emhvdXRpYW5yYW5AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRoaW5rIHlvdSBt aXNzIG15IHBvaW50Ljxicj4NCjxicj4NCkkgYW0gbm90IGFnYWluc3QgSU0uIEJ1dCBhcyBhbiBp bnRlcm1lZGlhcnkgc3RhdGUsIEkgdGhpbmsgSU0gbm8gbmVlZCB0byBiZSBkZWxpdmVyZWQgYXMg YW4gUkZDLjxicj4NCjxicj4NCkFuZCBJIGRvIG5vdCB0aGluayB0ZXh0IGRvY3VtZW50IGlzIHRo ZSBiZXN0IHRvb2wgZm9yIHRoZSBJTSwgd2hpbGUgaW4gbWFueSBvdGhlciBvcmdhbml6YXRpb25z LCB0aGV5IHVzZSBVTUwuPGJyPg0KPGJyPg0KWW91IGhhdmUgYSAxMDAmIzQzOyBwYWdlcyBkcmFm dCwgYnV0IGxhcmdlIGNvbnRlbnQganVzdCByZXBlYXQgdGhlIGJhc2ljIFVNTCBhbmQgT08gY29u Y2VwdCwgbGlrZSB0aGUgaW5oZXJpdCwgYWdncmVnYXRpb24sIHN1YmNsYXNzLi4uPGJyPg0KPGJy Pg0KPGJyPg0KVGlhbnJhbjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQomZ3Q7IEZyb206IEpvaG4gU3RyYXNzbmVyPGJyPg0KJmd0OyBTZW50OiBGcmlkYXks IE1hcmNoIDA0LCAyMDE2IDE6NDYgQU08YnI+DQomZ3Q7IFRvOiBaaG91dGlhbnJhbjsgSnVlcmdl biBTY2hvZW53YWVsZGVyOyBKb2VsIE0uIEhhbHBlcm48YnI+DQomZ3Q7IENjOiBOZXZpbCBCcm93 bmxlZTsgQW5keSBCaWVybWFuOyBTVVBBIGxpc3Q7IDxhIGhyZWY9Im1haWx0bzpzdHJhenBkakBn bWFpbC5jb20iPg0Kc3RyYXpwZGpAZ21haWwuY29tPC9hPjxicj4NCiZndDsgU3ViamVjdDogUkU6 IFtTdXBhXSBJbmZvcm1hdGlvbiBtb2RlbHMgYW5kIERhdGEgbW9kZWxzIC0gV0cgYWRvcGlvbj88 YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCBpcyBhY3R1YWxseSBtb3JlIGxpa2UgdGhlIFYtbW9kZWwg dGhhbiBhIHNwaXJhbCBtb2RlbCAtIHRoZSBzcGlyYWwgbW9kZWw8YnI+DQomZ3Q7IGlzIHJpc2st ZHJpdmVuLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBwb2ludCBvZiBtb2RlbC1kcml2ZW4gc29m dHdhcmUgaXMgdG8gdXNlIHRoZSBpbmZvIG1vZGVsIGFzIHRoZSBzb3VyY2U8YnI+DQomZ3Q7IHRo YXQgdGllcyBldmVyeXRoaW5nIHRvZ2V0aGVyLCBpbmNsdWRpbmcgcmVxdWlyZW1lbnRzLCBkb2N1 bWVudGF0aW9uLCB0ZXN0LDxicj4NCiZndDsgYW5kIGltcGxlbWVudGF0aW9uLiBZb3Ugc2VlbSB0 byBiZSBhZHZvY2F0aW5nIGJvdHRvbS11cCBkYXRhIG1vZGVscywgd2hpY2g8YnI+DQomZ3Q7IHBy b2R1Y2VzIHNlcGFyYXRlIHNpbG9zIG9mIHNvZnR3YXJlLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogU3VwYSBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmciPnN1cGEtYm91bmNl c0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBaaG91dGlhbnJhbjxicj4NCiZndDsgU2VudDog V2VkbmVzZGF5LCBNYXJjaCAwMiwgMjAxNiA4OjAxIFBNPGJyPg0KJmd0OyBUbzogSnVlcmdlbiBT Y2hvZW53YWVsZGVyOyBKb2VsIE0uIEhhbHBlcm48YnI+DQomZ3Q7IENjOiBOZXZpbCBCcm93bmxl ZTsgQW5keSBCaWVybWFuOyBTVVBBIGxpc3Q8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbU3VwYV0g SW5mb3JtYXRpb24gbW9kZWxzIGFuZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEhpIEp1ZXJnZW4sPGJyPg0KJmd0Ozxicj4NCiZndDsgRW1t bSwgdGhlIHJvdW5kIHRyaXAgeW91IG1lbnRpb25lZCBtdWNoIGxpa2UgdGhlIHNwaXJhbCBtb2Rl bCBpbiBzb2Z0d2FyZTxicj4NCiZndDsgZW5naW5lZXJpbmcuIFRoYXQncyBvZiBjb3Vyc2UgYSBn b29kIHdheSB0byBkbyBzeXN0ZW0gZGVzaWduIGFuZDxicj4NCiZndDsgaW1wbGVtZW50YXRpb24u PGJyPg0KJmd0Ozxicj4NCiZndDsgSG93ZXZlciwgaW4gdGhpcyBwcm9jZXNzLCB0aGUgaW5mb3Jt YXRpb24gbW9kZWwgaXMgbGlrZSBhbiBpbnRlcm1lZGlhcnk8YnI+DQomZ3Q7IHN0YXRlLCBidXQg bm90IHRoZSBmaW5hbCBvdXRwdXQgKFJGQykgd2UgbmVlZC48YnI+DQomZ3Q7IEkgbWVhbiwgZXZl biBpZiB3ZSBkbyBub3QgaGF2ZSBhIElNIFJGQywgd2UgY2FuIGFsd2F5cyBoYXZlIGEgc2NyYXRj aCBvcjxicj4NCiZndDsgVU1MIGRyYXdpbmcgc2hhcmVkIGR1cmluZyB0aGUgRE0gZGVzaWduLiBB bmQgdGhvc2UgbWFrZSBsaWZlIHNpbXBsZXIgZm9yPGJyPg0KJmd0OyBleHByZXNzIGludGVudCBh bmQgaWRlYSwgYW5kIGZvciBpbnRlcm9wZXJhdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBIGRv Y3VtZW50IHdpdGggbW9yZSB0aGFuIDEwMCBwYWdlcyBqdXN0IG1ha2UgYWxsIHRoZSB0aGluZ3Mg Y29tcGxleC4gVGhhdCdzPGJyPg0KJmd0OyBteSBodW1ibGUgb3Bpbmlvbi48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBUaWFucmFuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXI8YnI+ DQomZ3Q7ICZndDsgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29i cy11bml2ZXJzaXR5LmRlIj5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8L2E+ XTxicj4NCiZndDsgJmd0OyBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDAyLCAyMDE2IDI6NDUgUE08 YnI+DQomZ3Q7ICZndDsgVG86IEpvZWwgTS4gSGFscGVybjxicj4NCiZndDsgJmd0OyBDYzogQW5k eSBCaWVybWFuOyBOZXZpbCBCcm93bmxlZTsgWmhvdXRpYW5yYW47IFNVUEEgbGlzdDxicj4NCiZn dDsgJmd0OyBTdWJqZWN0OiBSZTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBt b2RlbHMgLSBXRyBhZG9waW9uPzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPbiBXZWQs IE1hciAwMiwgMjAxNiBhdCAxMjowOTo1OEFNIC0wNTAwLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgRmlyc3QsIHRoZSBlbnRpcmUgaW5m b3JtYXRpb24gbW9kZWwgd2lsbCBiZSByZW5kZXJlZCBpbnRvYSBZQU5HIGRhdGE8YnI+DQomZ3Q7 IG1vZGVsLjxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoZSBhZHZhbnRhZ2Ugb2YgZGlzY3Vzc2luZyB0 aGUgaW5mb3JtYXRpb24gbW9kZWwgaXMgdGhhdCB3ZSBjYW48YnI+DQomZ3Q7ICZndDsgJmd0OyBt YWtlIHN1cmUgdGhlIGluZm9ybWF0aW9uIGFuZCByZWxhdGlvbnNoaXBzIGFyZSByaWdodCBiZWZv cmUgZG9pbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGUgd29yayBvZiBnZXR0aW5nIHRoZSBZQU5H IHN5bnRheCByaWdodC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTXkgZXhwZXJpZW5j ZSBpcyB0aGF0IHlvdSB1c3VhbGx5IG9ubHkga25vdyB3aGV0aGVyIHRoZSBpbmZvcm1hdGlvbjxi cj4NCiZndDsgJmd0OyBtb2RlbCBpcyByZWFzb25hYmx5IGNvbXBsZXRlIGFuZCBjbGVhciBpZiB5 b3UgaGF2ZSBkb25lIHRoZSB3aG9sZTxicj4NCiZndDsgJmd0OyByb3VuZC10cmlwIGF0IGxlYXN0 IG9uY2UsIHRoYXQgaXMgeW91IGhhdmUgZG9uZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgaW5mbyBtb2RlbCAtJmd0OyBkYXRhIG1vZGVsIC0mZ3Q7IGltcGxlbWVudGF0aW9uIC0mZ3Q7 IGRhdGEgbW9kZWwgdXBkYXRlcyAtJmd0Ozxicj4NCiZndDsgJmd0OyBpbmZvcm1hdGlvbiBtb2Rl bCB1cGRhdGVzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEEgcHVyZSB0b3AtZG93biBh cHByb2FjaCB3aWxsIGxlYXZlIHlvdSB3aXRoIGFuIGluZm8gbW9kZWwgd2hpY2ggb25seTxicj4N CiZndDsgJmd0OyBwYXJ0aWFsbHkgZGVzY3JpYmVzIHdoYXQgaGFwcGVucyBpbiBhIGRhdGEgbW9k ZWwuIE5vdywgdGhpcyBtaWdodCBiZTxicj4NCiZndDsgJmd0OyBmaW5lLCBkZXBlbmRpbmcgb24g X3doeV8geW91IGRlZmluZSBhbiBpbmZvIG1vZGVsLiBJZiB5b3UgZG8gdGhlIGluZm88YnI+DQom Z3Q7ICZndDsgbW9kZWwgYmVjYXVzZSB5b3UgZXhwZWN0IGludGVyb3BlcmFiaWxpdHkgYmFzZWQg b24gdGhlIGluZm8gbW9kZWwsPGJyPg0KJmd0OyAmZ3Q7IHRoZW4gSSBiZWxpZXZlIGEgZnVsbCBy b3VuZC10cmlwIGlzIG5lY2Vzc2FyeSB0byBnZXQgdGhlIGluZm8gbW9kZWw8YnI+DQomZ3Q7ICZn dDsgcmVhc29uYWJseSBwcmVjaXNlLiBJZiB5b3UgZG8gdGhlIGluZm8gbW9kZWwgYmVjYXVzZSB5 b3UgaGF2ZSBubyBjbHVlPGJyPg0KJmd0OyAmZ3Q7IG9yIGFncmVlbWVudCBob3cgdG8gd3JpdGUg YSBkYXRhIG1vZGVsLCB0aGVuIGl0IGlzIGZpbmUgdG8gYmUgcHJlcGFyZWQ8YnI+DQomZ3Q7ICZn dDsgdG8gZGl2ZXJnZSBmcm9tIHRoZSBpbmZvIG1vZGVsIHVwIHRvIHRoZSBwb2ludCB0aGF0IGl0 IGlzIG5vdCBpbXBvcnRhbnQ8YnI+DQomZ3Q7IGFueW1vcmUgZm9yIGludGVyb3BlcmFiaWxpdHku PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFNvIHRoZSBrZXkgcXVlc3Rpb24gZm9yIG1l IGlzIHdoaWNoIGZ1bmN0aW9uIHRoZSBpbmZvIG1vZGVsIGlzPGJyPg0KJmd0OyAmZ3Q7IHN1cHBv c2VkIHRvIGZ1bGZpbGwuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC9qczxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0OyBKdWVyZ2VuIFNjaG9lbndh ZWxkZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phY29icyBVbml2 ZXJzaXR5IEJyZW1lbiBnR21iSDxicj4NCiZndDsgJmd0OyBQaG9uZTogJiM0Mzs0OSA0MjEgMjAw IDM1ODcmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4 NzU5IEJyZW1lbiB8IEdlcm1hbnk8YnI+DQomZ3Q7ICZndDsgRmF4OiZuYnNwOyAmbmJzcDsmIzQz OzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEg aHJlZj0iaHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8iIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7IFN1cGEgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86U3VwYUBpZXRm Lm9yZyI+U3VwYUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8 YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5yZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5Kb2huPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BBA82579FD347748BEADC4C445EA0F2183B899DDNKGEML515MBSchi_-- From nobody Fri Mar 4 01:29:05 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA81B1B356D for ; Fri, 4 Mar 2016 01:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Fe_a6bW3gBC3 for ; Fri, 4 Mar 2016 01:29:00 -0800 (PST) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17DD1B3573 for ; Fri, 4 Mar 2016 01:28:59 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud2.xs4all.net with ESMTP id RlUu1s01E3vXPcr01lUv35; Fri, 04 Mar 2016 10:28:57 +0100 To: John Strassner References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> From: "Bert Wijnen (IETF)" Message-ID: <56D95556.2030303@bwijnen.net> Date: Fri, 4 Mar 2016 10:28:54 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: John Strassner , "Joel M. Halpern" , Andy Bierman , Nevil Brownlee , Zhoutianran , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 09:29:03 -0000 Inline: On 04/03/16 06:06, John Strassner 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". > > 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)? > > 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) > wrote: > > Inline > > On 03/03/16 16:48, Joel M. Halpern wrote: > > 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". > > 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 > > Yours, > Joel > > On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: > > 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 > >> > wrote: > > 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. > > > > 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. > > > > > > > > John > > > > Andy > > > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org > >] 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, > > 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 > > > -----Original Message----- > > From: Supa [mailto:supa-bounces@ietf.org > >] 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"). > > > > 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:supa-bounces@ietf.org > >] On Behalf Of IETF > > >> Secretariat > > >> Sent: Monday, February 29, 2016 6:35 AM > > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org > > >; > > >> supa-chairs@ietf.org >; > supa@ietf.org > > > >> 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 > > >> Supa@ietf.org > > > >> 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 > > > > _______________________________________________ > > Supa mailing list > > Supa@ietf.org > > > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > > > > -- > regards, > John > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa From nobody Fri Mar 4 02:10:57 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C07E1B35CC for ; Fri, 4 Mar 2016 02:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 RYaprUlOKmOz for ; Fri, 4 Mar 2016 02:10:44 -0800 (PST) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326A61B35F1 for ; Fri, 4 Mar 2016 02:10:44 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud2.xs4all.net with ESMTP id RmAh1s0113vXPcr01mAilV; Fri, 04 Mar 2016 11:10:42 +0100 To: "King, Daniel" , "Joel M. Halpern" , Andy Bierman , John Strassner , Zhoutianran References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> From: "Bert Wijnen (IETF)" Message-ID: <56D95F20.7080006@bwijnen.net> Date: Fri, 4 Mar 2016 11:10:40 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 10:10:48 -0000 On 03/03/16 17:41, King, Daniel wrote: > 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? Dan, I am willing to take initiative on this. I saw in one of Johns postings: 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. 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. > > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: 03 March 2016 16:13 > To: Joel M. Halpern ; Andy Bierman ; John Strassner > Cc: Zhoutianran ; Nevil Brownlee ; SUPA list > Subject: Re: [Supa] Information models and Data models - WG adopion? > > Inline > > On 03/03/16 16:48, Joel M. Halpern wrote: >> 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". > 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 >> Yours, >> Joel >> >> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: >>> 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 >>>> > >>>> wrote: >>>> >>>> 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. >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> John >>>> >>>> >>>> >>>> Andy >>>> >>>> >>>> -----Original Message----- >>>> From: Supa [mailto:supa-bounces@ietf.org >>>> ] 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, >>>> >>>> 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 >>>> >>>> > -----Original Message----- >>>> > From: Supa [mailto:supa-bounces@ietf.org >>>> ] 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"). >>>> > >>>> > 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:supa-bounces@ietf.org >>>> ] On Behalf Of IETF >>>> > >> Secretariat >>>> > >> Sent: Monday, February 29, 2016 6:35 AM >>>> > >> To: draft-strassner-supa-generic-policy-info-model@ietf.org >>>> ; >>>> > >> supa-chairs@ietf.org ; >>>> supa@ietf.org >>>> > >> 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 >>>> > >> Supa@ietf.org >>>> > >> 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 >>>> > >>>> > _______________________________________________ >>>> > Supa mailing list >>>> > Supa@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/supa >>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Fri Mar 4 05:34:52 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2661A0049 for ; Fri, 4 Mar 2016 05:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.144 X-Spam-Level: * X-Spam-Status: No, score=1.144 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_LOLITA1=1.865, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=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 uRsOUKlLmINP for ; Fri, 4 Mar 2016 05:34:47 -0800 (PST) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3666D1A0041 for ; Fri, 4 Mar 2016 05:34:47 -0800 (PST) Received: from ex-1-ht0.lancs.ac.uk ([10.42.18.57] helo=EX-1-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1abpsF-00019S-OB; Fri, 04 Mar 2016 13:34:31 +0000 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-1-HT0.lancs.local ([fe80::d9e8:ad10:d075:a6b6%12]) with mapi id 14.03.0266.001; Fri, 4 Mar 2016 13:34:31 +0000 From: "King, Daniel" To: "Bert Wijnen (IETF)" , "Joel M. Halpern" , Andy Bierman , John Strassner , Zhoutianran Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2aGXTF8TS3OES1mXu6TQc0IZ9Ff0UAgAGQUICAAB1EgIAArWMAgAAFyoCAAAbwgIAAA5kQgAEpiwCAADizwA== Date: Fri, 4 Mar 2016 13:34:30 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A8BCBDA45@EX-0-MB2.lancs.local> References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> <56D95F20.7080006@bwijnen.net> In-Reply-To: <56D95F20.7080006@bwijnen.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.96.75.153] x-iss-local-domain: 1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 13:34:51 -0000 Hi Bert,=20 Thank for taking the initiative. We can make sure there is time on the agen= da for the I-D.=20 BR, Dan.=20 -----Original Message----- From: Bert Wijnen (IETF) [mailto:bwietf@bwijnen.net]=20 Sent: 04 March 2016 10:11 To: King, Daniel ; Joel M. Halpern ; Andy Bierman ; John Strassner ; Zhoutianran Cc: Nevil Brownlee ; SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? On 03/03/16 17:41, King, Daniel wrote: > Hi All. > > We have a placeholder in the SUPA Charter for: > > 1) An explanation of the scope of the policy-based management framework a= nd 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, ap= plicability and relationships ("system overview") would be reasonable conte= nt for a framework document mentioned in the Charter? > > Furthermore, Andy, Tianran and Bert all seem willing to support developme= nt (via direct contributions) for the framework/architecture document? Dan, I am willing to take initiative on this. I saw in one of Johns postings: 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. 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 s= tarting 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. > > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen=20 > (IETF) > Sent: 03 March 2016 16:13 > To: Joel M. Halpern ; Andy Bierman=20 > ; John Strassner > Cc: Zhoutianran ; Nevil Brownlee=20 > ; SUPA list > Subject: Re: [Supa] Information models and Data models - WG adopion? > > Inline > > On 03/03/16 16:48, Joel M. Halpern wrote: >> Two separate but related quesitons. >> >> 1) Can you help use find the places where the model / text is too=20 >> implementation specific? There are a few places where in describing=20 >> enumerations the model calls for integers. In the mapping to YANG, I ha= ve already started replacing those with Enumerations. Are there other kind= s of over-specificity? >> >> 2) The charter allows for a range of implementations of the SUPA=20 >> system. Folks may recall I asked in the room at the last meeting=20 >> whether our chartered allowd both communication between a control=20 >> 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. Thi= s does make it rather interesting to define the "architecture". > Mmmm... both concurrently, or did he mean that we as a WG can make a choi= ce what we prefer and standardize that? > If we do both concurrently or a longside each other, can we then still gu= arantee 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=20 >> with regard to policy execution status, where the model makes some assum= ptions about the structure of policy delivery. For the most part, those sh= ould be removed. Assistance in finding >> them is appreciated. I suspect that some of them are necessary, and tho= se 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 coul= d amend the charter to permit an architecture document. >> > I would say an "Architecture" or "System Overview" document would be a go= od thing. > > Bert >> Yours, >> Joel >> >> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: >>> 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=20 >>>> >>> > >>>> wrote: >>>> >>>> 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 inheren= t >>>> relationships easier to visualize and define. >>>> 2) An information model separates the logical design from the >>>> physical design of the system, enabling a deeper understandi= ng >>>> 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. >>>> >>>> >>>> >>>> It seems to me that your draft has many details related to the=20 >>>> abstraction of policy logic, but also many aspects that look like=20 >>>> implementation details. >>>> Perhaps it can be simplified if the implementation details were remove= d. >>>> >>>> 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=20 >>>> 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=20 >>>> level or the controller level? What data is available for policy=20 >>>> 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=20 >>>> 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=20 >>>> a workable solution will require a lot more than that. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> John >>>> >>>> >>>> >>>> Andy >>>> >>>> >>>> -----Original Message----- >>>> From: Supa [mailto:supa-bounces@ietf.org=20 >>>> ] 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 adopi= on? >>>> >>>> Hi Nevil, >>>> >>>> I am not arguing information model is useless, but it can be=20 >>>> worked out in other organizations if necessary, e.g. TMF. >>>> If in SUPA we can worked on YANG data models directly, why we=20 >>>> firstly work on an information model and then translate it to >>>> YANG data model? >>>> It just not makes sense to me. >>>> >>>> Tianran >>>> >>>> > -----Original Message----- >>>> > From: Supa [mailto:supa-bounces@ietf.org=20 >>>> ] 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=20 >>>> adopion? >>>> > >>>> > >>>> > Hi Tianran: >>>> > >>>> > In my experiences, having a well-defined information model=20 >>>> is a good starting >>>> > point. It allows different implementations, each of which=20 >>>> can develop it's >>>> > own data model - in other words, the information model is a=20 >>>> good unifying >>>> > influence - which is why publishing such a document is the=20 >>>> second of our >>>> > chart items. I hope that getting a good data model will=20 >>>> help us with the >>>> > first chart item ("scope of the policy-based management=20 >>>> framework"). >>>> > >>>> > draft-strassner-supa-generic-policy-info-model is the only SUPA >>>> > information model that's had any work done on it since IETF=20 >>>> 95, therefore >>>> > I've proposed it for WG adoption. >>>> > >>>> > As for the third charter item - "set of YANG data models",=20 >>>> there are two >>>> > of these on the SUPA documents page. It would help at this=20 >>>> stage if their >>>> > authors could comment on this list about the status of these=20 >>>> drafts. In >>>> > particular, jave they been working on a new version? >>>> > >>>> > Overall, we really need more discussion on the list of=20 >>>> 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=20 >>>> do we spend >>>> > time working on this information model? >>>> > > >>>> > > Why not focus on the ECA YANG data model directly as=20 >>>> standard track? >>>> > > >>>> > > >>>> > > Tianran >>>> > > >>>> > >> -----Original Message----- >>>> > >> From: Supa [mailto:supa-bounces@ietf.org=20 >>>> ] On Behalf Of IETF >>>> > >> Secretariat >>>> > >> Sent: Monday, February 29, 2016 6:35 AM >>>> > >> To:=20 >>>> draft-strassner-supa-generic-policy-info-model@ietf.org >>>> ; >>>> > >> supa-chairs@ietf.org ;=20 >>>> supa@ietf.org >>>> > >> Subject: [Supa] The SUPA WG has placed >>>> > >> draft-strassner-supa-generic-policy-info-model in state=20 >>>> "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=20 >>>> charter items >>>> > >> build on this >>>> > >> >>>> > >> _______________________________________________ >>>> > >> Supa mailing list >>>> > >> Supa@ietf.org >>>> > >> 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 >>>> > >>>> > _______________________________________________ >>>> > Supa mailing list >>>> > Supa@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/supa >>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Fri Mar 4 06:26:07 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428281A037A for ; Fri, 4 Mar 2016 06:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 m9aL7fjRJ9LC for ; Fri, 4 Mar 2016 06:26:02 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ECBD1A0373 for ; Fri, 4 Mar 2016 06:26:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0AD17240AFF; Fri, 4 Mar 2016 06:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1457101562; bh=yogVV2Hc3W/N1cCf5nEXt7hTPpoJPVefUxtzkakUKCc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=V3EB9g0oUVQd1iYJN2YwDeIYQmJqSDpDgHZBK6x7QNru8ylKXH0NFuIq4itag8SB0 rjc6i3TpNbXYNEJyKimBEytoUEiXaGAvAtAXe4bvaHuFhra69OIFwQXMxdcR4YR95M WPk69TccKOyfG1sdI1MQHZjYSLSXXsRJw6r0nE0k= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 0CA31240305; Fri, 4 Mar 2016 06:25:55 -0800 (PST) To: "Bert Wijnen (IETF)" , John Strassner References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> <56D95556.2030303@bwijnen.net> From: "Joel M. Halpern" Message-ID: <56D99AF1.8030104@joelhalpern.com> Date: Fri, 4 Mar 2016 09:25:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D95556.2030303@bwijnen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: John Strassner , Zhoutianran , Nevil Brownlee , Andy Bierman , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 14:26:05 -0000 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: > Inline: > > On 04/03/16 06:06, John Strassner 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". >> > 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)? >> >> 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) > > wrote: >> >> Inline >> >> On 03/03/16 16:48, Joel M. Halpern wrote: >> >> 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". >> >> 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 >> >> Yours, >> Joel >> >> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: >> >> 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 >> > >> > >> >> wrote: >> >> 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. >> >> >> >> 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. >> >> >> >> >> >> >> >> John >> >> >> >> Andy >> >> >> -----Original Message----- >> From: Supa [mailto:supa-bounces@ietf.org >> >> > >] 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, >> >> 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 >> >> > -----Original Message----- >> > From: Supa [mailto:supa-bounces@ietf.org >> >> > >] 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"). >> > >> > 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:supa-bounces@ietf.org >> >> > >] On Behalf Of IETF >> > >> Secretariat >> > >> Sent: Monday, February 29, 2016 6:35 AM >> > >> To: >> draft-strassner-supa-generic-policy-info-model@ietf.org >> >> >> >> > >> >; >> > >> supa-chairs@ietf.org >> > >; >> supa@ietf.org >> > >> > >> 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 >> > >> Supa@ietf.org >> > >> > >> 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 >> > >> > _______________________________________________ >> > Supa mailing list >> > Supa@ietf.org >> > >> > https://www.ietf.org/mailman/listinfo/supa >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/supa >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/supa >> >> >> >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> >> >> >> -- >> regards, >> John >> >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Fri Mar 4 08:12:27 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6694F1A6F61 for ; Fri, 4 Mar 2016 08:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 AkcXusHsh2uj for ; Fri, 4 Mar 2016 08:12:20 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D71C1A6F5D for ; Fri, 4 Mar 2016 08:12:19 -0800 (PST) Received: by mail-lb0-x236.google.com with SMTP id k15so66576301lbg.0 for ; Fri, 04 Mar 2016 08:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=m6lPY+HRYlZPH/tYGnUZILuNRQBepd/B3KKyAmsxN90=; b=n44yNRpA4hr8Pue4c0AYWDZwkPkT8kekMtKlO7VOnuyS+jv7ZsmbCuigVCWJ/BAXsg xg7i/SaIr+weU6iITvLvJT7LzE4CcslNQenYaaP5hBgBEXBFmxfUvDczYR9CNpmFwgJe lxjEHcrutC9SBbHE32uhozEgoxiUYFTpOS0EjysTqVgHZiKIZM0uMVBY+hCYfQSoWGUn av4Btkn1moWzxEi2hLuF1E0Z23OBBiOzflJbpZxLwOlT6Pe+EnJ9x6pxKioNhwPZuSCj o6PHWYsqFi0qHdi9a8tNHXGMsaZXmfkLtUF9xjQiFMA1pOk5jvJT+N8AbO8ekyHhvrFF paOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=m6lPY+HRYlZPH/tYGnUZILuNRQBepd/B3KKyAmsxN90=; b=Y4ogny24+F0h/JX7NsCBIrveoDWZRIYOE40bVUv97MkZ/eakrct4noBldChCkP5eyx MMJjL/AdEFDw9lnY4IkhXswkODkjmDfepD+bVVTuA501Y/vxnzZxoA9NNeNT3d0mSkfh weW78ttDizbLPAwak3cp4qpaX0UYOuLZD60E6A2ds6DxZp3Q4WbGVC7jqIasFFBWfT+B KjvVzLJdYoUyAtFmwW8AJW/eoNDZPTQoWFsHF1Pe5R/N707bJAdZ7qZRGvKu7kMRMggX UZkfMUNKPVzWRIkleSWA8xqelgWHmUY7DdwGCJlw8Awlt3WTXVQ9UNagRWjvbQoVvMQD RhLQ== X-Gm-Message-State: AD7BkJJpqRmaPWNGZCb3/zYCygYKpTAwIe+JP8Jg+aQy/6/40DqvwYDNx49WaC3GBZp1ES5euF7aLGhGmDjNjA== MIME-Version: 1.0 X-Received: by 10.25.143.141 with SMTP id r135mr3818389lfd.100.1457107937033; Fri, 04 Mar 2016 08:12:17 -0800 (PST) Received: by 10.25.156.76 with HTTP; Fri, 4 Mar 2016 08:12:16 -0800 (PST) In-Reply-To: <56D99AF1.8030104@joelhalpern.com> References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> <56D95556.2030303@bwijnen.net> <56D99AF1.8030104@joelhalpern.com> Date: Fri, 4 Mar 2016 08:12:16 -0800 Message-ID: From: John Strassner To: "Joel M. Halpern" , John Strassner Content-Type: multipart/alternative; boundary=001a114016e4fc8619052d3b6071 Archived-At: Cc: John Strassner , Andy Bierman , "Bert Wijnen \(IETF\)" , Nevil Brownlee , Zhoutianran , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 16:12:25 -0000 --001a114016e4fc8619052d3b6071 Content-Type: text/plain; charset=UTF-8 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 wrote: > 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: > >> Inline: >> >> On 04/03/16 06:06, John Strassner 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". >>> > 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)? >>> >>> 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) >> > wrote: >>> >>> Inline >>> >>> On 03/03/16 16:48, Joel M. Halpern wrote: >>> >>> 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". >>> >>> 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 >>> >>> Yours, >>> Joel >>> >>> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: >>> >>> 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 >>> >> >>> >> >> >>> wrote: >>> >>> 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. >>> >>> >>> >>> 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. >>> >>> >>> >>> >>> >>> >>> >>> John >>> >>> >>> >>> Andy >>> >>> >>> -----Original Message----- >>> From: Supa [mailto:supa-bounces@ietf.org >>> >>> >> >] 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, >>> >>> 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 >>> >>> > -----Original Message----- >>> > From: Supa [mailto:supa-bounces@ietf.org >>> >>> >> >] 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"). >>> > >>> > 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:supa-bounces@ietf.org >>> >>> >> >] On Behalf Of IETF >>> > >> Secretariat >>> > >> Sent: Monday, February 29, 2016 6:35 AM >>> > >> To: >>> draft-strassner-supa-generic-policy-info-model@ietf.org >>> >>> >>> >>> >> >>> >; >>> > >> supa-chairs@ietf.org >>> >> >; >>> supa@ietf.org >>> > >>> > >> 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 >>> > >> Supa@ietf.org >>> > >>> > >> 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 >>> > >>> > _______________________________________________ >>> > Supa mailing list >>> > Supa@ietf.org >>> > >>> > https://www.ietf.org/mailman/listinfo/supa >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> > >>> https://www.ietf.org/mailman/listinfo/supa >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> > >>> https://www.ietf.org/mailman/listinfo/supa >>> >>> >>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >>> >>> >>> >>> -- >>> regards, >>> John >>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> -- regards, John --001a114016e4fc8619052d3b6071 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Joel. These two cases SHOULD both be sup= ported
by the model. They stress different aspects of the model a= nd
implementations, but are complementary in past
imple= mentations that I have done.

regards,
Jo= hn

On = Fri, Mar 4, 2016 at 6:25 AM, Joel M. Halpern <jmh@joelhalpern.com&g= t; wrote:
The obverse is that by d= ealing 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 th= e 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:
Inline:

On 04/03/16 06:06, John Strassner wrote:
>> 2) The charter allows for a range of implementations of the SUPA >>=C2=A0 =C2=A0 =C2=A0 system.=C2=A0 Folks may recall I asked in the = room at the last meeting
>>=C2=A0 =C2=A0 =C2=A0 whether our chartered allowd both communicatio= n between a
>>=C2=A0 =C2=A0 =C2=A0 control system and a device, and communication= between a
>>=C2=A0 =C2=A0 =C2=A0 policy repository and a policy engine.=C2=A0 I= was told by the AD that
>>=C2=A0 =C2=A0 =C2=A0 the chartered allowed both.=C2=A0 This does ma= ke it rather interesting
>>=C2=A0 =C2=A0 =C2=A0 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)?

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) <bwietf@bwijnen.net
<mailto:bwietf@b= wijnen.net>> wrote:

=C2=A0 =C2=A0 Inline

=C2=A0 =C2=A0 On 03/03/16 16:48, Joel M. Halpern wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Two separate but related quesitons.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) The charter allows for a range of implementa= tions of the
SUPA system.=C2=A0 Folks may recall I asked in the room at the last
=C2=A0 =C2=A0 =C2=A0 =C2=A0 meeting whether our chartered allowd both commu= nication
between a control system and a device, and communication between a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 policy repository and a policy engine.=C2=A0 I = was told by the AD
that the chartered allowed both.=C2=A0 This does make it rather
=C2=A0 =C2=A0 =C2=A0 =C2=A0 interesting to define the "architecture&qu= ot;.

=C2=A0 =C2=A0 Mmmm... both concurrently, or did he mean that we as a WG can= make
a choice what we prefer
=C2=A0 =C2=A0 and standardize that?
=C2=A0 =C2=A0 If we do both concurrently or a longside each other, can we t= hen
still guarantee interoperability
=C2=A0 =C2=A0 (which I think is one of our main objctives, no)?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2') I do think that there are a few places = in the model,
particularly with regard to policy execution status, where the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 model makes some assumptions about the structur= e of policy
delivery.=C2=A0 For the most part, those should be removed.
Assistance in finding them is appreciated.=C2=A0 I suspect that some of
them are necessary, and those should be explicitly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 described.=C2=A0 =C2=A0(And we should make sure= the working group agrees
with the assumptions.)

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

=C2=A0 =C2=A0 I would say an "Architecture" or "System Overv= iew" document would
be a good thing.

=C2=A0 =C2=A0 Bert

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yours,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Joel

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Very good and practical question = raised by Andy!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bert

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 03/03/16 06:06, Andy Bierman w= rote:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Wed, Mar 2, 2016= at 7:21 PM, John Strassner
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <John.sc.Strassner@huawei= .com
<mailto:John.sc.Strassner@huawei.com>
<mailto:John.sc.Strassner@huawei.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:John.sc.Strassne= r@huawei.com>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:

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

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



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 It seems to me that= your draft has many details
related to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 abstraction
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of policy logic, bu= t also many aspects that look like
implementation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 details.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Perhaps it can be s= implified if the implementation
details were removed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I am more intereste= d in the SUPA Architecture document
first.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I don't see how= we can agree on an info-model in the
absence
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of a system archite= cture.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Does SUPA run anywh= ere? What does it even mean to
implement SUPA?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Will people be able= to build interoperable SUPA
engines from the RFCs?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Is there a differen= ce between a SUPA engine running at
the device level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 or the controller l= evel?=C2=A0 What data is available for
policy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enforcement analysi= s?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Is this configurabl= e through YANG modules implemented
by a SUPA engine?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 How are policies de= fined and managed within the SUPA
implementation?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 How is device confi= g altered to implement policy?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 How are device oper= ational state and statistics used
to verify policy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation?

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







=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 John<= br>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Andy


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----= Original Message-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 From:= Supa [mailto:su= pa-bounces@ietf.org
<mailto:supa-= bounces@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:supa-bounces@ietf.org
<mailto:supa-= bounces@ietf.org>>] On Behalf Of Zhoutianran
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent:= Tuesday, March 01, 2016 7:29 PM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To: N= evil Brownlee
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc: S= UPA list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subje= ct: Re: [Supa] Information models and Data
models - WG adopion?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Ne= vil,

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tianr= an

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = -----Original Message-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = From: Supa [mailto:supa-bounces@ietf.org
<mailto:supa-= bounces@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:supa-bounces@ietf.org
<mailto:supa-= bounces@ietf.org>>] On Behalf Of Nevil Brownlee
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = Sent: Wednesday, March 02, 2016 6:56 AM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = To: Zhoutianran
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = Cc: SUPA list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = Subject: Re: [Supa] Information models and Data
models - WG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 adopion?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = Hi Tianran:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = In my experiences, having a well-defined
information model is a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 good starting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = point.=C2=A0 It allows different implementations,
each of which can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 develop it's =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = own data model - in other words, the information
model is a good
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unifying
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = influence - which is why publishing such a
document is the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 second of our
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = chart items.=C2=A0 I hope that getting a good data
model will help us
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = first chart item ("scope of the policy-based
management
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 framework"). =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = draft-strassner-supa-generic-policy-info-model
is the only SUPA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = information model that's had any work done on it
since IETF 95,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 therefore
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = I've proposed it for WG adoption.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = As for the third charter item - "set of YANG
data models", there
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are two
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = of these on the SUPA documents page.=C2=A0 It would
help at this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stage if their
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = authors could comment on this list about the
status of these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 drafts.=C2=A0 In =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = particular, jave they been working on a new
version?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = Overall, we really need more discussion on the
list of what's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 happening
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = with the SUPA work!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = Cheers, Nevil
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = On 1/03/16 6:13 pm, Zhoutianran wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = > If this is a poll for WG adoption, I would say
not support.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = > If we want to finally generate YANG data
models here, why do
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 we spend
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = time working on this information model?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = > Why not focus on the ECA YANG data model
directly as standard
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 track?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = > Tianran
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> -----Original Message-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> From: Supa [mailto:supa-bounces@ietf.org
<mailto:supa-= bounces@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:supa-bounces@ietf.org
<mailto:supa-= bounces@ietf.org>>] On Behalf Of IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> Secretariat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> Sent: Monday, February 29, 2016 6:35 AM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> To:
draft-strassner-supa-generic-policy-info-model@ietf.org

<mailto:draft-strassner-supa-generic-policy-info-model= @ietf.org>

<mailto:draft-strassner-supa-generic-policy-info-model= @ietf.org

<mailto:draft-strassner-supa-generic-policy-info-model= @ietf.org>>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> supa-cha= irs@ietf.org
<mailto:supa-c= hairs@ietf.org> <mailto:supa-chairs@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:supa-chairs@ietf.org= >>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 supa@ietf.org <mailto:supa@ietf.org>
<mailto:supa@ietf.org= <mailto:supa@iet= f.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> Subject: [Supa] The SUPA WG has placed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >>
draft-strassner-supa-generic-policy-info-model in state "Call
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> Adoption By WG Issued"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> The SUPA WG has placed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-strassner-sup= a-generic-policy-info-model
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> in state Call For Adoption By WG Issued
(entered by Nevil
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Brownlee)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> The document is available at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br>
https://datatracker.ietf.org/do= c/draft-strassner-supa-generic-policy-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> i
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> nfo-model/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> Comment:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> This is the first of our charter documents,
the other charter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 items
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> build on this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> Supa mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> Supa@ietf.org <mailto:Supa@ietf.= org>
<mailto:Supa@ietf.org= <mailto:Supa@iet= f.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = >> https://www.ietf.org/mailman/listinfo/supa =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br>
---------------------------------------------------------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >= =C2=A0 =C2=A0Nevil Brownlee Computer Science
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Department
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >= =C2=A0 =C2=A0Phone: +64 9 373 7599 x88941
<tel:%2B64%209%20373%207599%20x88941>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0The University of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Auckland
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >= =C2=A0 =C2=A0FAX: +64 9 373 7453
<tel:%2B64%209%20373%207453>=C2=A0 =C2=A0Private Bag 92019, Auckland = 1142, New
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Zealand
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = Supa mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = Supa@ietf.org <ma= ilto:Supa@ietf.org&g= t;
<mailto:Supa@ietf.org= <mailto:Supa@iet= f.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = https://www.ietf.org/mailman/listinfo/supa

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Supa = mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Supa@ietf.org <mailto:Supa@ietf.org>
<mailto:Supa@ietf.org= <mailto:Supa@iet= f.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tps://www.ietf.org/mailman/listinfo/supa

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Supa = mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Supa@ietf.org <mailto:Supa@ietf.org>
<mailto:Supa@ietf.org= <mailto:Supa@iet= f.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tps://www.ietf.org/mailman/listinfo/supa




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Supa mailing list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Supa@ietf.org <mailto:Supa@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tps://www.ietf.org/mailman/listinfo/supa


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _________________________________= ______________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Supa mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Supa@ietf.org <mailto:Supa@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf= .org/mailman/listinfo/supa


=C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Supa mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Supa@ietf.org <mailto:Supa@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/l= istinfo/supa


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Supa mailing list
=C2=A0 =C2=A0 Supa@ietf.= org <mailto:Supa@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/supa




--
regards,
John


_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa




--
regards,
John
--001a114016e4fc8619052d3b6071-- From nobody Fri Mar 4 10:01:50 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B3E1A6FED for ; Fri, 4 Mar 2016 10:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 pjd9zETcvutf for ; Fri, 4 Mar 2016 10:01:42 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EE11A6FE1 for ; Fri, 4 Mar 2016 10:01:41 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id cf7so53636419lbb.1 for ; Fri, 04 Mar 2016 10:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=SmRuzsktuH4HFxahfdT2QvUybdrL2of0IBzf2cOI+OE=; b=ChQESO+MFOU4E17AODTPjz8gxmjN+cuGZN4/sf/LhVk65HHd2bjL3dV5MCHR2NKfkj 11P368tDSu690Fp713Lw2KBbUeBdH4hZFfYU2po/OJ2z7ThXgyyQGE09vUQrgx+gBT1g kBBRTh2tZlWQ2e2QAojO0hsEPmDMeR8XlYX4FQS1Csdaevmnm/EnoDRo5yKQyOvtTLXi qg9f3whEsw4cNVDB9gbjIxLiJmFW0X1/5UgOik0zpENVRcEDFkRZlwrduoXomEdOXmcG 7s9pkpgtTuw6PFy3veb6fOlbOblcP+r8XRLFcgs9I0aefmM6KenWDnoOEbW9z8EQCVcW DQKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=SmRuzsktuH4HFxahfdT2QvUybdrL2of0IBzf2cOI+OE=; b=UG2hZeT3Q4PL70Cue58VGNX0NcHHrkLWMkEbEUurftZuPyY85Xz7o0N5BflsBbwK/9 aI+5nGKXVV1XuGhzHf3RpKm5ElFHPQMQ7/DOLZYTxXci080ZFhQvJWA/ODk3cLuC9Y/7 HGMiWFC0ZsP/BXe7RZNgcr616tXEPDaaFBWn93K6StZlBQzkD0RfNdytRMjbLK+9syAK SJrJZisTNyJJPlLkizjoNoBg35N2+TpdjlMQKIdEDd/JFJtJFwSblhzAHcuMOcPSN4qa AG9n1Zh+YLrkqxvi4q+7hlbJ2DilCz2IwJ6Z3f6B6tEgq1cbBBPCq4dUcjOmxPEs88mB kj1A== X-Gm-Message-State: AD7BkJLzwuivSRzoa8UZ4BNRp64e2slcrX/i52zc1X2fgllPlGlvLFLhl6qiH7y6OVVgSMOZzuxNEsBbOoSogQ== MIME-Version: 1.0 X-Received: by 10.112.147.65 with SMTP id ti1mr2871957lbb.119.1457114499965; Fri, 04 Mar 2016 10:01:39 -0800 (PST) Received: by 10.112.110.68 with HTTP; Fri, 4 Mar 2016 10:01:39 -0800 (PST) In-Reply-To: <5FD5189A-9B4A-4F7F-9856-169EAB8B1171@me.com> References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> <56D95F20.7080006@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBDA45@EX-0-MB2.lancs.local> <909DAC0E-7372-448D-A670-DF302157B0AC@cisco.com> <5FD5189A-9B4A-4F7F-9856-169EAB8B1171@me.com> Date: Fri, 4 Mar 2016 10:01:39 -0800 Message-ID: From: Andy Bierman To: "Jason Coleman (colemaj)" Content-Type: multipart/alternative; boundary=047d7b3441be2afdbd052d3ce88c Archived-At: Cc: John Strassner , Zhoutianran , "Bert Wijnen \(IETF\)" , Nevil Brownlee , "King, Daniel" , "Joel M. Halpern" , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 18:01:48 -0000 --047d7b3441be2afdbd052d3ce88c Content-Type: text/plain; charset=UTF-8 On Fri, Mar 4, 2016 at 9:29 AM, Jason Coleman (colemaj) 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" < > supa-bounces@ietf.org on behalf of d.king@lancaster.ac.uk> wrote: > > > >>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:bwietf@bwijnen.net] > >>Sent: 04 March 2016 10:11 > >>To: King, Daniel ; Joel M. Halpern < > jmh@joelhalpern.com>; Andy Bierman ; John Strassner < > John.sc.Strassner@huawei.com>; Zhoutianran > >>Cc: Nevil Brownlee ; SUPA list > > >>Subject: Re: [Supa] Information models and Data models - WG adopion? > >> > >>On 03/03/16 17:41, King, Daniel wrote: > >>> 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? > >>Dan, I am willing to take initiative on this. > >> > >>I saw in one of Johns postings: > >> 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. > >> > >>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. > >>> > >>> -----Original Message----- > >>> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen > >>> (IETF) > >>> Sent: 03 March 2016 16:13 > >>> To: Joel M. Halpern ; Andy Bierman > >>> ; John Strassner > >>> Cc: Zhoutianran ; Nevil Brownlee > >>> ; SUPA list > >>> Subject: Re: [Supa] Information models and Data models - WG adopion? > >>> > >>> Inline > >>> > >>> On 03/03/16 16:48, Joel M. Halpern wrote: > >>>> 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". > >>> 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 > >>>> Yours, > >>>> Joel > >>>> > >>>> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: > >>>>> 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 > >>>>>> >>>>>> > > >>>>>> wrote: > >>>>>> > >>>>>> 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. > >>>>>> > >>>>>> > >>>>>> > >>>>>> 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. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> John > >>>>>> > >>>>>> > >>>>>> > >>>>>> Andy > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Supa [mailto:supa-bounces@ietf.org > >>>>>> ] 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, > >>>>>> > >>>>>> 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 > >>>>>> > >>>>>> > -----Original Message----- > >>>>>> > From: Supa [mailto:supa-bounces@ietf.org > >>>>>> ] 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"). > >>>>>> > > >>>>>> > 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:supa-bounces@ietf.org > >>>>>> ] On Behalf Of IETF > >>>>>> > >> Secretariat > >>>>>> > >> Sent: Monday, February 29, 2016 6:35 AM > >>>>>> > >> To: > >>>>>> draft-strassner-supa-generic-policy-info-model@ietf.org > >>>>>> ; > >>>>>> > >> supa-chairs@ietf.org ; > >>>>>> supa@ietf.org > >>>>>> > >> 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 > >>>>>> > >> Supa@ietf.org > >>>>>> > >> 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 > >>>>>> > > >>>>>> > _______________________________________________ > >>>>>> > Supa mailing list > >>>>>> > Supa@ietf.org > >>>>>> > https://www.ietf.org/mailman/listinfo/supa > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Supa mailing list > >>>>>> Supa@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/supa > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Supa mailing list > >>>>>> Supa@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/supa > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Supa mailing list > >>>>>> Supa@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/supa > >>>>> _______________________________________________ > >>>>> Supa mailing list > >>>>> Supa@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/supa > >>>>> > >>>> _______________________________________________ > >>>> Supa mailing list > >>>> Supa@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/supa > >>>> > >>> _______________________________________________ > >>> Supa mailing list > >>> Supa@ietf.org > >>> https://www.ietf.org/mailman/listinfo/supa > >>> > >>> _______________________________________________ > >>> Supa mailing list > >>> Supa@ietf.org > >>> https://www.ietf.org/mailman/listinfo/supa > >>> > >> > >>_______________________________________________ > >>Supa mailing list > >>Supa@ietf.org > >>https://www.ietf.org/mailman/listinfo/supa > --047d7b3441be2afdbd052d3ce88c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 4, 2016 at 9:29 AM, Jason Coleman (colemaj) <colemaj@cisco= .com> 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 partici= pate as well, since Bert is willing to take the lead.

<= div>It is quite possible I do not understand the development plan implied b= y the charter.

I was hoping we would end up with t= he following standards:

=C2=A0 1) one standard way= to express a SUPA policy
=C2=A0 2) one standard "SUPA engin= e" definition that is capable of understanding and enforcing specific = policies
=C2=A0 =C2=A0 =C2=A0 2a) device-level SUPA can only acce= ss policy and enforce policy on itself
=C2=A0 =C2=A0 =C2=A0 2b) c= ontroller-level SUPA can be configured to communicate with multiple network= elements
=C2=A0 =C2=A03) one or more standard protocols should b= e selected (e.g., NETCONF, RESTCONF) for
=C2=A0 =C2=A0 =C2=A0 =C2= =A0communication between (2b) and network elements, to support policy enfor= cement

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


An= dy



=C2=A0
>
>As for the information model versus data model discussion, I think that= an information model is required to allow for different data models to fol= low a common structure.
>It is possible to create a data model first, but that data model may no= t fit in well with other data models.=C2=A0 This is why the information mod= el exists to allow for things that may extend that data model or are in pla= ce for other data models.
>
>At this time the focus is on Event, Condition, Action, but there will b= e further management structures to define.
>The information model supports a general structure and then provides de= tails on ECA.=C2=A0 That general structure is important for future data mod= els as well.
>Those may be YANG or other people may chose to use the information mode= l to create a data model in a different way.
>
>The architecture document would define the role of the information mode= l 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 su= pported by the information model and what else the WG Charter has defined a= nd possibly where we go next.
>
>Jason
>
>
>
>On 3/4/16, 7:34 AM, "Supa on behalf of King, Daniel" <supa-bounces@ietf.org on behalf of= d.king@lancaster.ac.uk> w= rote:
>
>>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:bwietf@bwijnen.net]
>>Sent: 04 March 2016 10:11
>>To: King, Daniel <d.ki= ng@lancaster.ac.uk>; Joel M. Halpern <jmh@joelhalpern.com>; Andy Bierman <andy@yumaworks.com>; John Strassner <John.sc.Strassner@huawei.com&g= t;; Zhoutianran <zhoutianran@h= uawei.com>
>>Cc: Nevil Brownlee <n.brownlee@auckland.ac.nz>; SUPA list <supa@ietf.org>
>>Subject: Re: [Supa] Information models and Data models - WG adopion= ?
>>
>>On 03/03/16 17:41, King, Daniel wrote:
>>> Hi=C2=A0 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" discus= sing architecture, applicability and relationships ("system overview&q= uot;) would be reasonable content for a framework document mentioned in the= Charter?
>>>
>>> Furthermore, Andy, Tianran and Bert all seem willing to suppor= t development (via direct contributions) for the framework/architecture doc= ument?
>>Dan, I am willing to take initiative on this.
>>
>>I saw in one of Johns postings:
>>=C2=A0 =C2=A0 Well, we don't have an architecture document curr= ently in our charter
>>=C2=A0 =C2=A0 (though I would support amending the charter to inclu= de this). In the
>>=C2=A0 =C2=A0 (now expired) proposition draft (which we are now wor= king on to reissue),
>>=C2=A0 =C2=A0 there was an exemplary architecture.
>>
>>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 tha= t as a starting point?
>>
>>Dan/Nevil, if we submit an in initial I-D timely, do you think we c= an spend some time on it in our IETF95 session?
>>
>>Thanks,
>>Bert
>>
>>
>>
>>> BR, Dan.
>>>
>>> -----Original Message-----
>>> From: Supa [mailto:su= pa-bounces@ietf.org] On Behalf Of Bert Wijnen
>>> (IETF)
>>> Sent: 03 March 2016 16:13
>>> To: Joel M. Halpern <jmh@joelhalpern.com>; Andy Bierman
>>> <andy@yumaworks.com>; John Strassner <= John.sc.Strassner@huawei.com>
>>> Cc: Zhoutianran <= zhoutianran@huawei.com>; Nevil Brownlee
>>> <n.brownlee@au= ckland.ac.nz>; SUPA list <supa@i= etf.org>
>>> Subject: Re: [Supa] Information models and Data models - WG ad= opion?
>>>
>>> Inline
>>>
>>> On 03/03/16 16:48, Joel M. Halpern wrote:
>>>> Two separate but related quesitons.
>>>>
>>>> 1) Can you help use find the places where the model / text= is too
>>>> implementation specific?=C2=A0 There are a few places wher= e in describing
>>>> enumerations the model calls for integers.=C2=A0 In the ma= pping to YANG, I have already started replacing those with Enumerations.=C2= =A0 Are there other kinds of over-specificity?
>>>>
>>>> 2) The charter allows for a range of implementations of th= e SUPA
>>>> system.=C2=A0 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 re= pository and a policy engine.=C2=A0 I was told by the AD that the chartered= allowed both.=C2=A0 This does make it rather interesting to define the &qu= ot;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 th= en still guarantee interoperability (which I think is one of our main objct= ives, no)?
>>>> 2') I do think that there are a few places in the mode= l, particularly
>>>> with regard to policy execution status, where the model ma= kes some assumptions about the structure of policy delivery.=C2=A0 For the = most part, those should be removed.=C2=A0 Assistance in finding
>>>> them is appreciated.=C2=A0 I suspect that some of them are= necessary, and those should be explicitly described.=C2=A0 =C2=A0(And we s= hould make
>>>> sure the working group agrees with the assumptions.)
>>>>
>>>> 3) (minor) The charter permits the information model.=C2= =A0 I presume we could amend the charter to permit an architecture document= .
>>>>
>>> I would say an "Architecture" or "System Overvi= ew" document would be a good thing.
>>>
>>> Bert
>>>> Yours,
>>>> Joel
>>>>
>>>> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote:
>>>>> 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
>>>>>> <John.sc.Strassner@huawei.com
>>>>>> <mailto:John.sc.Strassner@huawei.com>>
>>>>>> wrote:
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 We should work on an informati= on model for several reasons, even if
>>>>>>=C2=A0 =C2=A0 =C2=A0 there is only target data mode= l (i.e., YANG):
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) An information model= can define how data are related to each
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other inde= pendent of implementation. This is much harder to do
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in YANG. H= ence, the information model may make these inherent
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0relationsh= ips easier to visualize and define.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) An information model= separates the logical design from the
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0physical d= esign of the system, enabling a deeper understanding
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of both in= dependent of implementation. This can be used to
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0produce mo= re powerful implementations.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3) If an information mo= del is worked on in another organization,
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0there is n= o guarantee that its output will be useful to the
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF. I am= active in the TM Forum, which you cited; they are
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in general= not worried about implementing YANG models, much
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0less produ= cing optimal YANG models.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 4) This enables other S= DOs and fora, which do not use YANG, to
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more easil= y understand our output.
>>>>>>
>>>>>>
>>>>>>
>>>>>> It seems to me that your draft has many details re= lated 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 docu= ment 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 en= gines from the RFCs?
>>>>>> Is there a difference between a SUPA engine runnin= g at the device
>>>>>> level or the controller level?=C2=A0 What data is = available for policy
>>>>>> enforcement analysis?
>>>>>> Is this configurable through YANG modules implemen= ted by a SUPA engine?
>>>>>> How are policies defined and managed within the SU= PA implementation?
>>>>>> How is device config altered to implement policy?<= br> >>>>>> How are device operational state and statistics us= ed to verify
>>>>>> policy implementation?
>>>>>>
>>>>>> A precise description of policy logic might be a g= ood thing to have.
>>>>>> I am not objecting to an info model doc.=C2=A0 A s= ystem architecture and
>>>>>> a workable solution will require a lot more than t= hat.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 John
>>>>>>
>>>>>>
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 -----Original Message-----
>>>>>>=C2=A0 =C2=A0 =C2=A0 From: Supa [mailto:supa-bounces@ietf.org
>>>>>> <mailto:supa-bounces@ietf.org>] On Behalf Of Zhoutianran
>>>>>>=C2=A0 =C2=A0 =C2=A0 Sent: Tuesday, March 01, 2016 = 7:29 PM
>>>>>>=C2=A0 =C2=A0 =C2=A0 To: Nevil Brownlee
>>>>>>=C2=A0 =C2=A0 =C2=A0 Cc: SUPA list
>>>>>>=C2=A0 =C2=A0 =C2=A0 Subject: Re: [Supa] Informatio= n models and Data models - WG adopion?
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 Hi Nevil,
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 I am not arguing information m= odel is useless, but it can be
>>>>>> worked out in other organizations if necessary, e.= g. TMF.
>>>>>>=C2=A0 =C2=A0 =C2=A0 If in SUPA we can worked on YA= NG data models directly, why we
>>>>>> firstly work on an information model and then tran= slate it to
>>>>>>=C2=A0 =C2=A0 =C2=A0 YANG data model?
>>>>>>=C2=A0 =C2=A0 =C2=A0 It just not makes sense to me.=
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 Tianran
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 > -----Original Message----= -
>>>>>>=C2=A0 =C2=A0 =C2=A0 > From: Supa [mailto:supa-bounces@ietf.org
>>>>>> <mailto:supa-bounces@ietf.org>] On Behalf Of Nevil Brownlee
>>>>>>=C2=A0 =C2=A0 =C2=A0 > Sent: Wednesday, March 02= , 2016 6:56 AM
>>>>>>=C2=A0 =C2=A0 =C2=A0 > To: Zhoutianran
>>>>>>=C2=A0 =C2=A0 =C2=A0 > Cc: SUPA list
>>>>>>=C2=A0 =C2=A0 =C2=A0 > Subject: Re: [Supa] Infor= mation models and Data models - WG
>>>>>> adopion?
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > Hi Tianran:
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > In my experiences, having= a well-defined information model
>>>>>> is a good starting
>>>>>>=C2=A0 =C2=A0 =C2=A0 > point.=C2=A0 It allows di= fferent implementations, each of which
>>>>>> can develop it's
>>>>>>=C2=A0 =C2=A0 =C2=A0 > own data model - in other= words, the information model is a
>>>>>> good unifying
>>>>>>=C2=A0 =C2=A0 =C2=A0 > influence - which is why = publishing such a document is the
>>>>>> second of our
>>>>>>=C2=A0 =C2=A0 =C2=A0 > chart items.=C2=A0 I hope= that getting a good data model will
>>>>>> help us with the
>>>>>>=C2=A0 =C2=A0 =C2=A0 > first chart item ("s= cope of the policy-based management
>>>>>> framework").
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > draft-strassner-supa-gene= ric-policy-info-model is the only SUPA
>>>>>>=C2=A0 =C2=A0 =C2=A0 > information model that= 9;s had any work done on it since IETF
>>>>>> 95, therefore
>>>>>>=C2=A0 =C2=A0 =C2=A0 > I've proposed it for = WG adoption.
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > As for the third charter = item - "set of YANG data models",
>>>>>> there are two
>>>>>>=C2=A0 =C2=A0 =C2=A0 > of these on the SUPA docu= ments page.=C2=A0 It would help at this
>>>>>> stage if their
>>>>>>=C2=A0 =C2=A0 =C2=A0 > authors could comment on = this list about the status of these
>>>>>> drafts.=C2=A0 In
>>>>>>=C2=A0 =C2=A0 =C2=A0 > particular, jave they bee= n working on a new version?
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > Overall, we really need m= ore discussion on the list of
>>>>>> what's happening
>>>>>>=C2=A0 =C2=A0 =C2=A0 > with the SUPA work!
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > Cheers, Nevil
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > On 1/03/16 6:13 pm, Zhout= ianran wrote:
>>>>>>=C2=A0 =C2=A0 =C2=A0 > > If this is a poll fo= r WG adoption, I would say not support.
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > > If we want to finall= y generate YANG data models here, why
>>>>>> do we spend
>>>>>>=C2=A0 =C2=A0 =C2=A0 > time working on this info= rmation model?
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > > Why not focus on the= ECA YANG data model directly as
>>>>>> standard track?
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > > Tianran
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> -----Original Me= ssage-----
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> From: Supa [mail= to:supa-bounces@ietf.org
>>>>>> <mailto:supa-bounces@ietf.org>] On Behalf Of IETF
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> Secretariat
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> Sent: Monday, Fe= bruary 29, 2016 6:35 AM
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> To:
>>>>>> draft-strassner-supa-generic-policy-info-model@iet= f.org
>>>>>> <mailto:draft-strassner-supa-generic-policy-inf= o-model@ietf.org>;
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> supa-chairs@ietf.org <mailto:supa-chairs@ietf.org>;
>>>>>> supa@ietf.org= <mailto:supa@ietf.org>
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> Subject: [Supa] = The SUPA WG has placed
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> draft-strassner-= supa-generic-policy-info-model in state
>>>>>> "Call For
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> Adoption By WG I= ssued"
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >>
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >>
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> The SUPA WG has = placed
>>>>>> draft-strassner-supa-generic-policy-info-model
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> in state Call Fo= r Adoption By WG Issued (entered by Nevil
>>>>>> Brownlee)
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >>
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> The document is = available at
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >>
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>> https:= //datatracker.ietf.org/doc/draft-strassner-supa-generic-policy-
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> i
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> nfo-model/
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >>
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >>
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> Comment:
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> This is the firs= t of our charter documents, the other
>>>>>> charter items
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> build on this >>>>>>=C2=A0 =C2=A0 =C2=A0 > >>
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> ________________= _______________________________
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> Supa mailing lis= t
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> Supa@ietf.org <mailto:Supa@ietf.org>
>>>>>>=C2=A0 =C2=A0 =C2=A0 > >> https://www.ietf.org/mailman/listinfo/supa
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > --
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>> --------------------------------------------------= -------------------
>>>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0Nevil Brownle= e=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Computer Science
>>>>>> Department
>>>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0Phone: +64 9 = 373 7599 x88941=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Universi= ty of
>>>>>> Auckland
>>>>>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0FAX: +64 9 37= 3 7453=C2=A0 =C2=A0Private Bag 92019, Auckland 1142, New
>>>>>> Zealand
>>>>>>=C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 > _________________________= ______________________
>>>>>>=C2=A0 =C2=A0 =C2=A0 > Supa mailing list
>>>>>>=C2=A0 =C2=A0 =C2=A0 > Supa@ietf.org <mailto:Supa@= ietf.org>
>>>>>>=C2=A0 =C2=A0 =C2=A0 > https://= www.ietf.org/mailman/listinfo/supa
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 ______________________________= _________________
>>>>>>=C2=A0 =C2=A0 =C2=A0 Supa mailing list
>>>>>>=C2=A0 =C2=A0 =C2=A0 Supa@ietf.org <mailto:Supa@ietf.= org>
>>>>>>=C2=A0 =C2=A0 =C2=A0 https://www.i= etf.org/mailman/listinfo/supa
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 ______________________________= _________________
>>>>>>=C2=A0 =C2=A0 =C2=A0 Supa mailing list
>>>>>>=C2=A0 =C2=A0 =C2=A0 Supa@ietf.org <mailto:Supa@ietf.= org>
>>>>>>=C2=A0 =C2=A0 =C2=A0 https://www.i= etf.org/mailman/listinfo/supa
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ >>>>>> Supa mailing list
>>>>>> Supa@ietf.org=
>>>>>> https://www.ietf.org/mailman/list= info/supa
>>>>> _______________________________________________
>>>>> Supa mailing list
>>>>> Supa@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo= /supa
>>>>>
>>>> _______________________________________________
>>>> Supa mailing list
>>>> Supa@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sup= a
>>>>
>>> _______________________________________________
>>> Supa mailing list
>>> Supa@ietf.org
>>> https://www.ietf.org/mailman/listinfo/supa
>>>
>>> _______________________________________________
>>> Supa mailing list
>>> Supa@ietf.org
>>> https://www.ietf.org/mailman/listinfo/supa
>>>
>>
>>_______________________________________________
>>Supa mailing list
>>Supa@ietf.org
>>https://www.ietf.org/mailman/listinfo/supa

--047d7b3441be2afdbd052d3ce88c-- From nobody Fri Mar 4 11:23:44 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161201A8859 for ; Fri, 4 Mar 2016 11:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Meky4_zjoSWJ for ; Fri, 4 Mar 2016 11:23:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8581A885C for ; Fri, 4 Mar 2016 11:23:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFI69120; Fri, 04 Mar 2016 19:23:34 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Mar 2016 19:23:32 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.143]) by SJCEML702-CHM.china.huawei.com ([169.254.4.108]) with mapi id 14.03.0235.001; Fri, 4 Mar 2016 11:23:20 -0800 From: John Strassner To: Zhoutianran , John Strassner Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2rx5wdWV9zckyTIiHCBdvZs59F+M4AgAAougCAABqUgIABZGaAgABfE5CAASjEAIAAIOOAgAAZ2gCAAEfXUA== Date: Fri, 4 Mar 2016 19:23:19 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.94] Content-Type: multipart/alternative; boundary="_000_B818037A70EDCC4A86113DA25EC02098201EB6D8SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56D9E0B7.009B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.143, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 071bb84bb764e94a94ef44b694de3e28 Archived-At: Cc: Nevil Brownlee , "Joel M. Halpern" , Juergen Schoenwaelder , Andy Bierman , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:23:43 -0000 --_000_B818037A70EDCC4A86113DA25EC02098201EB6D8SJCEML701CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBZb3VyIGxvZ2ljIGlzOiB0aGlzIGlzIElFVEYsIHNvIHRleHQgaXMgb21uaXBvdGVudCwNCg0K Tm90IG9tbmlwb3RlbnQsIGJ1dCBhcHBsaWNhYmxlIGFuZCByZWxldmFudC4NCg0KPiBzbyB5b3Ug dXNlIHRleHQgdG8gZGVzY3JpYmUgSU0gd2l0aCAxMDArIHBhZ2VzIGRvY3VtZW50IGZvcg0KPiBp bnRlcm9wZXJhdGlvbiwgYW5kIHRoZW4gZ2VuZXJhdGUgVU1McywgYW5kIGZpbmFsbHkgdXNlDQo+ IFVNTC0+WUFORyB0b29sIHRvIGdlbmVyYXRlIGRhdGEgbW9kZWwuDQoNCkkgZmFpbCB0byB1bmRl cnN0YW5kIHlvdXIgcG9pbnQuIEhvcGVmdWxseSB5b3UgZG8gbm90IHRoaW5rIHRoYXQgVU1MIGlz DQpqdXN0IGJ1aWxkaW5nIHByZXR0eSBwaWN0dXJlczsgdGhlIHVuZGVybHlpbmcgKipsYW5ndWFn ZSoqIG9mIFVNTCBpcw0KTU9GLCBhbmQgTU9GIGlzIHRleHQuIE1vcmUgcGFydGljdWxhcmx5LCB0 aGUgZ3JhcGhpY2FsIGZvcm1hdCBpbiBVTUwNCmlzIG5vdCBub3JtYXRpdmU7IHRoZSB0ZXh0dWFs IHBhcnQgaXMuDQoNCj4gTXkgc3VnZ2VzdGlvbiBpczogVGV4dCB1c2VkIGluIElFVEYgaXMgbm90 IGdvb2QgYXQgZGVzY3JpYmUgSU0sDQo+IHNvIHdlIHVzZSBVTUwgZm9yIGludGVyb3BlcmF0aW9u KGJ1dCBVTUwgb3V0cHV0IG5vdCBxdWFsaWZpZXMNCj4gUkZDKSwgYW5kIHRoZW4gZ2VuZXJhdGUg RE0uDQo+DQo+IEFtIEkgbWlzcyB5b3VyIHBvaW50PyBXaGljaCBvbmUgaXMgZWFzaWVyIHRvIGlt cGxlbWVudD8NCg0KQUxMIFVNTCB0b29scyBjYW4gZ2VuZXJhdGUgZGF0YSBtb2RlbHMgYW5kIGNv ZGUuIFdoZXRoZXIgdGhleSBhcmUNCmdyYXBoaWNhbCBhbmQvb3IgdGV4dHVhbCBpcyBpcnJlbGV2 YW50Lg0KDQpJIHNhaWQgdGhhdCB0aGVyZSBpcyBhbiBvcGVuIHNvdXJjZSBlZmZvcnQgdG8gcHJv ZHVjZSBZQU5HIGZyb20gVU1MLiBJDQpkaWQgbm90IHNheSB0aGF0IEkgd2FzIHVzaW5nIHRoYXQg bWVjaGFuaXNtLg0KDQpGaW5hbGx5LCBob3cgY2FuIHRoZSBXRyBkaXNjdXNzIHRoZSBpbmZvIG1v ZGVsIGlmIGl0IGlzIG5vdCBpbiB0ZXh0Pw0KDQoNCg0KRnJvbTogWmhvdXRpYW5yYW4NClNlbnQ6 IFRodXJzZGF5LCBNYXJjaCAwMywgMjAxNiAxMDo1MyBQTQ0KVG86IEpvaG4gU3RyYXNzbmVyDQpD YzogSm9obiBTdHJhc3NuZXI7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgSm9lbCBNLiBIYWxwZXJu OyBOZXZpbCBCcm93bmxlZTsgQW5keSBCaWVybWFuOyBTVVBBIGxpc3QNClN1YmplY3Q6IFJFOiBb U3VwYV0gSW5mb3JtYXRpb24gbW9kZWxzIGFuZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/DQoN ClNlZW4geW91ciB0aGlzIGFuZCBsYXN0IGVtYWlsLg0KDQpZb3VyIGxvZ2ljIGlzOiB0aGlzIGlz IElFVEYsIHNvIHRleHQgaXMgb21uaXBvdGVudCwgc28geW91IHVzZSB0ZXh0IHRvIGRlc2NyaWJl IElNIHdpdGggMTAwKyBwYWdlcyBkb2N1bWVudCBmb3IgaW50ZXJvcGVyYXRpb24sIGFuZCB0aGVu IGdlbmVyYXRlIFVNTHMsIGFuZCBmaW5hbGx5IHVzZSBVTUwtPllBTkcgdG9vbCB0byBnZW5lcmF0 ZSBkYXRhIG1vZGVsLg0KDQpNeSBzdWdnZXN0aW9uIGlzOiBUZXh0IHVzZWQgaW4gSUVURiBpcyBu b3QgZ29vZCBhdCBkZXNjcmliZSBJTSwgc28gd2UgdXNlIFVNTCBmb3IgaW50ZXJvcGVyYXRpb24o YnV0IFVNTCBvdXRwdXQgbm90IHF1YWxpZmllcyBSRkMpLCBhbmQgdGhlbiBnZW5lcmF0ZSBETS4N Cg0KQW0gSSBtaXNzIHlvdXIgcG9pbnQ/IFdoaWNoIG9uZSBpcyBlYXNpZXIgdG8gaW1wbGVtZW50 Pw0KDQoNClRpYW5yYW4NCg0KRnJvbTogSm9obiBTdHJhc3NuZXIgW21haWx0bzpzdHJhenBkakBn bWFpbC5jb21dDQpTZW50OiBGcmlkYXksIE1hcmNoIDA0LCAyMDE2IDE6MjEgUE0NClRvOiBaaG91 dGlhbnJhbjsgSm9obiBTdHJhc3NuZXINCkNjOiBKb2huIFN0cmFzc25lcjsgSnVlcmdlbiBTY2hv ZW53YWVsZGVyOyBKb2VsIE0uIEhhbHBlcm47IE5ldmlsIEJyb3dubGVlOyBBbmR5IEJpZXJtYW47 IFNVUEEgbGlzdA0KU3ViamVjdDogUmU6IFtTdXBhXSBJbmZvcm1hdGlvbiBtb2RlbHMgYW5kIERh dGEgbW9kZWxzIC0gV0cgYWRvcGlvbj8NCg0KQWN0dWFsbHksIHlvdSBhcmUgbWlzc2luZyBteSBw b2ludC4gSXQncyBhYm91dCBtb2RlbC1kcml2ZW4gc29mdHdhcmUuDQpUaGlzIGlzIG5vdCB0aGUg T01HLCBpdCBpcyB0aGUgSUVURi4gVGV4dCBpcyBvdXIgZnJpZW5kLiBXZSBuZWVkIGENCnRleHQg ZG9jdW1lbnQgdG8gZXN0YWJsaXNoIFdHIHRyYWNlYWJpbGl0eSBmb3IgdGhlIGRhdGEgbW9kZWwu DQoNCkluIGFkZGl0aW9uLCBzZWUgbXkgbGFzdCByZXNwb25zZS4NCg0KDQpPbiBUaHUsIE1hciAz LCAyMDE2IGF0IDc6MjMgUE0sIFpob3V0aWFucmFuIDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPG1h aWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tPj4gd3JvdGU6DQpJIHRoaW5rIHlvdSBtaXNzIG15 IHBvaW50Lg0KDQpJIGFtIG5vdCBhZ2FpbnN0IElNLiBCdXQgYXMgYW4gaW50ZXJtZWRpYXJ5IHN0 YXRlLCBJIHRoaW5rIElNIG5vIG5lZWQgdG8gYmUgZGVsaXZlcmVkIGFzIGFuIFJGQy4NCg0KQW5k IEkgZG8gbm90IHRoaW5rIHRleHQgZG9jdW1lbnQgaXMgdGhlIGJlc3QgdG9vbCBmb3IgdGhlIElN LCB3aGlsZSBpbiBtYW55IG90aGVyIG9yZ2FuaXphdGlvbnMsIHRoZXkgdXNlIFVNTC4NCg0KWW91 IGhhdmUgYSAxMDArIHBhZ2VzIGRyYWZ0LCBidXQgbGFyZ2UgY29udGVudCBqdXN0IHJlcGVhdCB0 aGUgYmFzaWMgVU1MIGFuZCBPTyBjb25jZXB0LCBsaWtlIHRoZSBpbmhlcml0LCBhZ2dyZWdhdGlv biwgc3ViY2xhc3MuLi4NCg0KDQpUaWFucmFuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogSm9obiBTdHJhc3NuZXINCj4gU2VudDogRnJpZGF5LCBNYXJjaCAwNCwgMjAx NiAxOjQ2IEFNDQo+IFRvOiBaaG91dGlhbnJhbjsgSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBKb2Vs IE0uIEhhbHBlcm4NCj4gQ2M6IE5ldmlsIEJyb3dubGVlOyBBbmR5IEJpZXJtYW47IFNVUEEgbGlz dDsgc3RyYXpwZGpAZ21haWwuY29tPG1haWx0bzpzdHJhenBkakBnbWFpbC5jb20+DQo+IFN1Ympl Y3Q6IFJFOiBbU3VwYV0gSW5mb3JtYXRpb24gbW9kZWxzIGFuZCBEYXRhIG1vZGVscyAtIFdHIGFk b3Bpb24/DQo+DQo+IEl0IGlzIGFjdHVhbGx5IG1vcmUgbGlrZSB0aGUgVi1tb2RlbCB0aGFuIGEg c3BpcmFsIG1vZGVsIC0gdGhlIHNwaXJhbCBtb2RlbA0KPiBpcyByaXNrLWRyaXZlbi4NCj4NCj4g VGhlIHBvaW50IG9mIG1vZGVsLWRyaXZlbiBzb2Z0d2FyZSBpcyB0byB1c2UgdGhlIGluZm8gbW9k ZWwgYXMgdGhlIHNvdXJjZQ0KPiB0aGF0IHRpZXMgZXZlcnl0aGluZyB0b2dldGhlciwgaW5jbHVk aW5nIHJlcXVpcmVtZW50cywgZG9jdW1lbnRhdGlvbiwgdGVzdCwNCj4gYW5kIGltcGxlbWVudGF0 aW9uLiBZb3Ugc2VlbSB0byBiZSBhZHZvY2F0aW5nIGJvdHRvbS11cCBkYXRhIG1vZGVscywgd2hp Y2gNCj4gcHJvZHVjZXMgc2VwYXJhdGUgc2lsb3Mgb2Ygc29mdHdhcmUuDQo+DQo+DQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBaaG91 dGlhbnJhbg0KPiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDAyLCAyMDE2IDg6MDEgUE0NCj4gVG86 IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgSm9lbCBNLiBIYWxwZXJuDQo+IENjOiBOZXZpbCBCcm93 bmxlZTsgQW5keSBCaWVybWFuOyBTVVBBIGxpc3QNCj4gU3ViamVjdDogUmU6IFtTdXBhXSBJbmZv cm1hdGlvbiBtb2RlbHMgYW5kIERhdGEgbW9kZWxzIC0gV0cgYWRvcGlvbj8NCj4NCj4NCj4gSGkg SnVlcmdlbiwNCj4NCj4gRW1tbSwgdGhlIHJvdW5kIHRyaXAgeW91IG1lbnRpb25lZCBtdWNoIGxp a2UgdGhlIHNwaXJhbCBtb2RlbCBpbiBzb2Z0d2FyZQ0KPiBlbmdpbmVlcmluZy4gVGhhdCdzIG9m IGNvdXJzZSBhIGdvb2Qgd2F5IHRvIGRvIHN5c3RlbSBkZXNpZ24gYW5kDQo+IGltcGxlbWVudGF0 aW9uLg0KPg0KPiBIb3dldmVyLCBpbiB0aGlzIHByb2Nlc3MsIHRoZSBpbmZvcm1hdGlvbiBtb2Rl bCBpcyBsaWtlIGFuIGludGVybWVkaWFyeQ0KPiBzdGF0ZSwgYnV0IG5vdCB0aGUgZmluYWwgb3V0 cHV0IChSRkMpIHdlIG5lZWQuDQo+IEkgbWVhbiwgZXZlbiBpZiB3ZSBkbyBub3QgaGF2ZSBhIElN IFJGQywgd2UgY2FuIGFsd2F5cyBoYXZlIGEgc2NyYXRjaCBvcg0KPiBVTUwgZHJhd2luZyBzaGFy ZWQgZHVyaW5nIHRoZSBETSBkZXNpZ24uIEFuZCB0aG9zZSBtYWtlIGxpZmUgc2ltcGxlciBmb3IN Cj4gZXhwcmVzcyBpbnRlbnQgYW5kIGlkZWEsIGFuZCBmb3IgaW50ZXJvcGVyYXRpb24uDQo+DQo+ IEEgZG9jdW1lbnQgd2l0aCBtb3JlIHRoYW4gMTAwIHBhZ2VzIGp1c3QgbWFrZSBhbGwgdGhlIHRo aW5ncyBjb21wbGV4LiBUaGF0J3MNCj4gbXkgaHVtYmxlIG9waW5pb24uDQo+DQo+IFRpYW5yYW4N Cj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEp1ZXJnZW4gU2No b2Vud2FlbGRlcg0KPiA+IFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+XQ0KPiA+IFNl bnQ6IFdlZG5lc2RheSwgTWFyY2ggMDIsIDIwMTYgMjo0NSBQTQ0KPiA+IFRvOiBKb2VsIE0uIEhh bHBlcm4NCj4gPiBDYzogQW5keSBCaWVybWFuOyBOZXZpbCBCcm93bmxlZTsgWmhvdXRpYW5yYW47 IFNVUEEgbGlzdA0KPiA+IFN1YmplY3Q6IFJlOiBbU3VwYV0gSW5mb3JtYXRpb24gbW9kZWxzIGFu ZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/DQo+ID4NCj4gPiBPbiBXZWQsIE1hciAwMiwgMjAx NiBhdCAxMjowOTo1OEFNIC0wNTAwLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4NCj4gPiA+ IEZpcnN0LCB0aGUgZW50aXJlIGluZm9ybWF0aW9uIG1vZGVsIHdpbGwgYmUgcmVuZGVyZWQgaW50 b2EgWUFORyBkYXRhDQo+IG1vZGVsLg0KPiA+ID4gVGhlIGFkdmFudGFnZSBvZiBkaXNjdXNzaW5n IHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBpcyB0aGF0IHdlIGNhbg0KPiA+ID4gbWFrZSBzdXJlIHRo ZSBpbmZvcm1hdGlvbiBhbmQgcmVsYXRpb25zaGlwcyBhcmUgcmlnaHQgYmVmb3JlIGRvaW5nDQo+ ID4gPiB0aGUgd29yayBvZiBnZXR0aW5nIHRoZSBZQU5HIHN5bnRheCByaWdodC4NCj4gPg0KPiA+ IE15IGV4cGVyaWVuY2UgaXMgdGhhdCB5b3UgdXN1YWxseSBvbmx5IGtub3cgd2hldGhlciB0aGUg aW5mb3JtYXRpb24NCj4gPiBtb2RlbCBpcyByZWFzb25hYmx5IGNvbXBsZXRlIGFuZCBjbGVhciBp ZiB5b3UgaGF2ZSBkb25lIHRoZSB3aG9sZQ0KPiA+IHJvdW5kLXRyaXAgYXQgbGVhc3Qgb25jZSwg dGhhdCBpcyB5b3UgaGF2ZSBkb25lOg0KPiA+DQo+ID4gaW5mbyBtb2RlbCAtPiBkYXRhIG1vZGVs IC0+IGltcGxlbWVudGF0aW9uIC0+IGRhdGEgbW9kZWwgdXBkYXRlcyAtPg0KPiA+IGluZm9ybWF0 aW9uIG1vZGVsIHVwZGF0ZXMNCj4gPg0KPiA+IEEgcHVyZSB0b3AtZG93biBhcHByb2FjaCB3aWxs IGxlYXZlIHlvdSB3aXRoIGFuIGluZm8gbW9kZWwgd2hpY2ggb25seQ0KPiA+IHBhcnRpYWxseSBk ZXNjcmliZXMgd2hhdCBoYXBwZW5zIGluIGEgZGF0YSBtb2RlbC4gTm93LCB0aGlzIG1pZ2h0IGJl DQo+ID4gZmluZSwgZGVwZW5kaW5nIG9uIF93aHlfIHlvdSBkZWZpbmUgYW4gaW5mbyBtb2RlbC4g SWYgeW91IGRvIHRoZSBpbmZvDQo+ID4gbW9kZWwgYmVjYXVzZSB5b3UgZXhwZWN0IGludGVyb3Bl cmFiaWxpdHkgYmFzZWQgb24gdGhlIGluZm8gbW9kZWwsDQo+ID4gdGhlbiBJIGJlbGlldmUgYSBm dWxsIHJvdW5kLXRyaXAgaXMgbmVjZXNzYXJ5IHRvIGdldCB0aGUgaW5mbyBtb2RlbA0KPiA+IHJl YXNvbmFibHkgcHJlY2lzZS4gSWYgeW91IGRvIHRoZSBpbmZvIG1vZGVsIGJlY2F1c2UgeW91IGhh dmUgbm8gY2x1ZQ0KPiA+IG9yIGFncmVlbWVudCBob3cgdG8gd3JpdGUgYSBkYXRhIG1vZGVsLCB0 aGVuIGl0IGlzIGZpbmUgdG8gYmUgcHJlcGFyZWQNCj4gPiB0byBkaXZlcmdlIGZyb20gdGhlIGlu Zm8gbW9kZWwgdXAgdG8gdGhlIHBvaW50IHRoYXQgaXQgaXMgbm90IGltcG9ydGFudA0KPiBhbnlt b3JlIGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KPiA+DQo+ID4gU28gdGhlIGtleSBxdWVzdGlvbiBm b3IgbWUgaXMgd2hpY2ggZnVuY3Rpb24gdGhlIGluZm8gbW9kZWwgaXMNCj4gPiBzdXBwb3NlZCB0 byBmdWxmaWxsLg0KPiA+DQo+ID4gL2pzDQo+ID4NCj4gPiAtLQ0KPiA+IEp1ZXJnZW4gU2Nob2Vu d2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4gUGhv bmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVu IHwgR2VybWFueQ0KPiA+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93 d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBTdXBhIG1haWxpbmcgbGlzdA0KPiBTdXBhQGlldGYu b3JnPG1haWx0bzpTdXBhQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3N1cGENCg0KDQoNCi0tDQpyZWdhcmRzLA0KSm9obg0K --_000_B818037A70EDCC4A86113DA25EC02098201EB6D8SJCEML701CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7fQ0KIC8qIFN0eWxlIERlZmluaXRp b25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47 fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IFlvdXIgbG9n aWMgaXM6IHRoaXMgaXMgSUVURiwgc28gdGV4dCBpcyBvbW5pcG90ZW50LDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj5Ob3Qgb21uaXBvdGVudCwgYnV0IGFwcGxpY2FibGUgYW5k IHJlbGV2YW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBzbyB5b3UgdXNl IHRleHQgdG8gZGVzY3JpYmUgSU0gd2l0aCAxMDAmIzQzOyBwYWdlcyBkb2N1bWVudCBmb3I8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBp bnRlcm9wZXJhdGlvbiwgYW5kIHRoZW4gZ2VuZXJhdGUgVU1McywgYW5kIGZpbmFsbHkgdXNlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsg VU1MLSZndDtZQU5HIHRvb2wgdG8gZ2VuZXJhdGUgZGF0YSBtb2RlbC4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PkkgZmFpbCB0byB1bmRlcnN0YW5kIHlvdXIgcG9pbnQuIEhvcGVmdWxseSB5b3UgZG8gbm90IHRo aW5rIHRoYXQgVU1MIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+anVzdCBidWls ZGluZyBwcmV0dHkgcGljdHVyZXM7IHRoZSB1bmRlcmx5aW5nICoqbGFuZ3VhZ2UqKiBvZiBVTUwg aXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5NT0YsIGFuZCBNT0YgaXMgdGV4dC4g TW9yZSBwYXJ0aWN1bGFybHksIHRoZSBncmFwaGljYWwgZm9ybWF0IGluIFVNTDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPmlzIG5vdCBub3JtYXRpdmU7IHRoZSB0ZXh0dWFsIHBhcnQg aXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mZ3Q7IE15IHN1Z2dlc3Rpb24gaXM6IFRleHQgdXNlZCBpbiBJRVRGIGlzIG5vdCBnb29kIGF0 IGRlc2NyaWJlIElNLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBzbyB3ZSB1c2UgVU1MIGZvciBpbnRl cm9wZXJhdGlvbihidXQgVU1MIG91dHB1dCBub3QgcXVhbGlmaWVzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m Z3Q7IFJGQyksIGFuZCB0aGVuIGdlbmVyYXRlIERNLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBBbSBJIG1pc3MgeW91ciBwb2ludD8gV2hpY2ggb25lIGlz IGVhc2llciB0byBpbXBsZW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+QUxMIFVNTCB0b29scyBjYW4gZ2Vu ZXJhdGUgZGF0YSBtb2RlbHMgYW5kIGNvZGUuIFdoZXRoZXIgdGhleSBhcmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj5ncmFwaGljYWwgYW5kL29yIHRleHR1YWwgaXMgaXJyZWxldmFu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 DQpjb2xvcjojMUY0OTdEIj5JIHNhaWQgdGhhdCB0aGVyZSBpcyBhbiBvcGVuIHNvdXJjZSBlZmZv cnQgdG8gcHJvZHVjZSBZQU5HIGZyb20gVU1MLiBJPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFG NDk3RCI+ZGlkIG5vdCBzYXkgdGhhdCBJIHdhcyB1c2luZyB0aGF0IG1lY2hhbmlzbS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj5GaW5hbGx5LCBob3cgY2FuIHRoZSBXRyBkaXNjdXNzIHRoZSBpbmZvIG1vZGVsIGlm IGl0IGlzIG5vdCBpbiB0ZXh0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gWmhvdXRpYW5yYW4NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggMDMs IDIwMTYgMTA6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gU3RyYXNzbmVyPGJyPg0KPGI+Q2M6 PC9iPiBKb2huIFN0cmFzc25lcjsgSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBKb2VsIE0uIEhhbHBl cm47IE5ldmlsIEJyb3dubGVlOyBBbmR5IEJpZXJtYW47IFNVUEEgbGlzdDxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSRTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBX RyBhZG9waW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+U2VlbiB5b3VyIHRoaXMgYW5kIGxhc3QgZW1haWwu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQpj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPllvdXIgbG9naWMgaXM6IHRoaXMgaXMg SUVURiwgc28gdGV4dCBpcyBvbW5pcG90ZW50LCBzbyB5b3UgdXNlIHRleHQgdG8gZGVzY3JpYmUg SU0gd2l0aCAxMDAmIzQzOyBwYWdlcyBkb2N1bWVudCBmb3IgaW50ZXJvcGVyYXRpb24sIGFuZCB0 aGVuIGdlbmVyYXRlIFVNTHMsIGFuZCBmaW5hbGx5DQogdXNlIFVNTC0mZ3Q7WUFORyB0b29sIHRv IGdlbmVyYXRlIGRhdGEgbW9kZWwuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5N eSBzdWdnZXN0aW9uIGlzOiBUZXh0IHVzZWQgaW4gSUVURiBpcyBub3QgZ29vZCBhdCBkZXNjcmli ZSBJTSwgc28gd2UgdXNlIFVNTCBmb3IgaW50ZXJvcGVyYXRpb24oYnV0IFVNTCBvdXRwdXQgbm90 IHF1YWxpZmllcyBSRkMpLCBhbmQgdGhlbiBnZW5lcmF0ZSBETS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+QW0gSSBtaXNzIHlvdXIgcG9pbnQ/IFdoaWNoIG9u ZSBpcyBlYXNpZXIgdG8gaW1wbGVtZW50PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPlRpYW5yYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IEpvaG4gU3RyYXNzbmVyIFttYWlsdG86c3RyYXpwZGpAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IEZyaWRheSwgTWFyY2ggMDQsIDIwMTYgMToyMSBQTTxicj4NCjxiPlRvOjwvYj4gWmhv dXRpYW5yYW47IEpvaG4gU3RyYXNzbmVyPGJyPg0KPGI+Q2M6PC9iPiBKb2huIFN0cmFzc25lcjsg SnVlcmdlbiBTY2hvZW53YWVsZGVyOyBKb2VsIE0uIEhhbHBlcm47IE5ldmlsIEJyb3dubGVlOyBB bmR5IEJpZXJtYW47IFNVUEEgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1N1cGFdIElu Zm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBXRyBhZG9waW9uPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWN0dWFs bHksIHlvdSBhcmUgbWlzc2luZyBteSBwb2ludC4gSXQncyBhYm91dCBtb2RlbC1kcml2ZW4gc29m dHdhcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGlzIGlzIG5vdCB0aGUgT01HLCBpdCBpcyB0aGUgSUVURi4gVGV4dCBpcyBvdXIgZnJpZW5k LiBXZSBuZWVkIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnRleHQgZG9jdW1lbnQgdG8gZXN0YWJsaXNoIFdHIHRyYWNlYWJpbGl0eSBmb3IgdGhl IGRhdGEgbW9kZWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkluIGFkZGl0aW9uLCBzZWUgbXkgbGFzdCByZXNwb25zZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1hciAz LCAyMDE2IGF0IDc6MjMgUE0sIFpob3V0aWFucmFuICZsdDs8YSBocmVmPSJtYWlsdG86emhvdXRp YW5yYW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnpob3V0aWFucmFuQGh1YXdlaS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhp bmsgeW91IG1pc3MgbXkgcG9pbnQuPGJyPg0KPGJyPg0KSSBhbSBub3QgYWdhaW5zdCBJTS4gQnV0 IGFzIGFuIGludGVybWVkaWFyeSBzdGF0ZSwgSSB0aGluayBJTSBubyBuZWVkIHRvIGJlIGRlbGl2 ZXJlZCBhcyBhbiBSRkMuPGJyPg0KPGJyPg0KQW5kIEkgZG8gbm90IHRoaW5rIHRleHQgZG9jdW1l bnQgaXMgdGhlIGJlc3QgdG9vbCBmb3IgdGhlIElNLCB3aGlsZSBpbiBtYW55IG90aGVyIG9yZ2Fu aXphdGlvbnMsIHRoZXkgdXNlIFVNTC48YnI+DQo8YnI+DQpZb3UgaGF2ZSBhIDEwMCYjNDM7IHBh Z2VzIGRyYWZ0LCBidXQgbGFyZ2UgY29udGVudCBqdXN0IHJlcGVhdCB0aGUgYmFzaWMgVU1MIGFu ZCBPTyBjb25jZXB0LCBsaWtlIHRoZSBpbmhlcml0LCBhZ2dyZWdhdGlvbiwgc3ViY2xhc3MuLi48 YnI+DQo8YnI+DQo8YnI+DQpUaWFucmFuPGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogSm9obiBTdHJhc3NuZXI8YnI+DQomZ3Q7IFNlbnQ6 IEZyaWRheSwgTWFyY2ggMDQsIDIwMTYgMTo0NiBBTTxicj4NCiZndDsgVG86IFpob3V0aWFucmFu OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IEpvZWwgTS4gSGFscGVybjxicj4NCiZndDsgQ2M6IE5l dmlsIEJyb3dubGVlOyBBbmR5IEJpZXJtYW47IFNVUEEgbGlzdDsgPGEgaHJlZj0ibWFpbHRvOnN0 cmF6cGRqQGdtYWlsLmNvbSI+DQpzdHJhenBkakBnbWFpbC5jb208L2E+PGJyPg0KJmd0OyBTdWJq ZWN0OiBSRTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBXRyBh ZG9waW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7IEl0IGlzIGFjdHVhbGx5IG1vcmUgbGlrZSB0aGUg Vi1tb2RlbCB0aGFuIGEgc3BpcmFsIG1vZGVsIC0gdGhlIHNwaXJhbCBtb2RlbDxicj4NCiZndDsg aXMgcmlzay1kcml2ZW4uPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIHBvaW50IG9mIG1vZGVsLWRy aXZlbiBzb2Z0d2FyZSBpcyB0byB1c2UgdGhlIGluZm8gbW9kZWwgYXMgdGhlIHNvdXJjZTxicj4N CiZndDsgdGhhdCB0aWVzIGV2ZXJ5dGhpbmcgdG9nZXRoZXIsIGluY2x1ZGluZyByZXF1aXJlbWVu dHMsIGRvY3VtZW50YXRpb24sIHRlc3QsPGJyPg0KJmd0OyBhbmQgaW1wbGVtZW50YXRpb24uIFlv dSBzZWVtIHRvIGJlIGFkdm9jYXRpbmcgYm90dG9tLXVwIGRhdGEgbW9kZWxzLCB3aGljaDxicj4N CiZndDsgcHJvZHVjZXMgc2VwYXJhdGUgc2lsb3Mgb2Ygc29mdHdhcmUuPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9t OiBTdXBhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZyI+c3Vw YS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFpob3V0aWFucmFuPGJyPg0KJmd0 OyBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDAyLCAyMDE2IDg6MDEgUE08YnI+DQomZ3Q7IFRvOiBK dWVyZ2VuIFNjaG9lbndhZWxkZXI7IEpvZWwgTS4gSGFscGVybjxicj4NCiZndDsgQ2M6IE5ldmls IEJyb3dubGVlOyBBbmR5IEJpZXJtYW47IFNVUEEgbGlzdDxicj4NCiZndDsgU3ViamVjdDogUmU6 IFtTdXBhXSBJbmZvcm1hdGlvbiBtb2RlbHMgYW5kIERhdGEgbW9kZWxzIC0gV0cgYWRvcGlvbj88 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgSnVlcmdlbiw8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBFbW1tLCB0aGUgcm91bmQgdHJpcCB5b3UgbWVudGlvbmVkIG11Y2ggbGlrZSB0aGUgc3Bp cmFsIG1vZGVsIGluIHNvZnR3YXJlPGJyPg0KJmd0OyBlbmdpbmVlcmluZy4gVGhhdCdzIG9mIGNv dXJzZSBhIGdvb2Qgd2F5IHRvIGRvIHN5c3RlbSBkZXNpZ24gYW5kPGJyPg0KJmd0OyBpbXBsZW1l bnRhdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBIb3dldmVyLCBpbiB0aGlzIHByb2Nlc3MsIHRo ZSBpbmZvcm1hdGlvbiBtb2RlbCBpcyBsaWtlIGFuIGludGVybWVkaWFyeTxicj4NCiZndDsgc3Rh dGUsIGJ1dCBub3QgdGhlIGZpbmFsIG91dHB1dCAoUkZDKSB3ZSBuZWVkLjxicj4NCiZndDsgSSBt ZWFuLCBldmVuIGlmIHdlIGRvIG5vdCBoYXZlIGEgSU0gUkZDLCB3ZSBjYW4gYWx3YXlzIGhhdmUg YSBzY3JhdGNoIG9yPGJyPg0KJmd0OyBVTUwgZHJhd2luZyBzaGFyZWQgZHVyaW5nIHRoZSBETSBk ZXNpZ24uIEFuZCB0aG9zZSBtYWtlIGxpZmUgc2ltcGxlciBmb3I8YnI+DQomZ3Q7IGV4cHJlc3Mg aW50ZW50IGFuZCBpZGVhLCBhbmQgZm9yIGludGVyb3BlcmF0aW9uLjxicj4NCiZndDs8YnI+DQom Z3Q7IEEgZG9jdW1lbnQgd2l0aCBtb3JlIHRoYW4gMTAwIHBhZ2VzIGp1c3QgbWFrZSBhbGwgdGhl IHRoaW5ncyBjb21wbGV4LiBUaGF0J3M8YnI+DQomZ3Q7IG15IGh1bWJsZSBvcGluaW9uLjxicj4N CiZndDs8YnI+DQomZ3Q7IFRpYW5yYW48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IEp1ZXJnZW4gU2Nob2Vud2Fl bGRlcjxicj4NCiZndDsgJmd0OyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0 eS5kZTwvYT5dPGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDIsIDIwMTYg Mjo0NSBQTTxicj4NCiZndDsgJmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuPGJyPg0KJmd0OyAmZ3Q7 IENjOiBBbmR5IEJpZXJtYW47IE5ldmlsIEJyb3dubGVlOyBaaG91dGlhbnJhbjsgU1VQQSBsaXN0 PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbU3VwYV0gSW5mb3JtYXRpb24gbW9kZWxzIGFu ZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IE9uIFdlZCwgTWFyIDAyLCAyMDE2IGF0IDEyOjA5OjU4QU0gLTA1MDAsIEpvZWwgTS4gSGFscGVy biB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBGaXJzdCwgdGhlIGVu dGlyZSBpbmZvcm1hdGlvbiBtb2RlbCB3aWxsIGJlIHJlbmRlcmVkIGludG9hIFlBTkcgZGF0YTxi cj4NCiZndDsgbW9kZWwuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIGFkdmFudGFnZSBvZiBkaXNj dXNzaW5nIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBpcyB0aGF0IHdlIGNhbjxicj4NCiZndDsgJmd0 OyAmZ3Q7IG1ha2Ugc3VyZSB0aGUgaW5mb3JtYXRpb24gYW5kIHJlbGF0aW9uc2hpcHMgYXJlIHJp Z2h0IGJlZm9yZSBkb2luZzxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSB3b3JrIG9mIGdldHRpbmcg dGhlIFlBTkcgc3ludGF4IHJpZ2h0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBNeSBl eHBlcmllbmNlIGlzIHRoYXQgeW91IHVzdWFsbHkgb25seSBrbm93IHdoZXRoZXIgdGhlIGluZm9y bWF0aW9uPGJyPg0KJmd0OyAmZ3Q7IG1vZGVsIGlzIHJlYXNvbmFibHkgY29tcGxldGUgYW5kIGNs ZWFyIGlmIHlvdSBoYXZlIGRvbmUgdGhlIHdob2xlPGJyPg0KJmd0OyAmZ3Q7IHJvdW5kLXRyaXAg YXQgbGVhc3Qgb25jZSwgdGhhdCBpcyB5b3UgaGF2ZSBkb25lOjxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyBpbmZvIG1vZGVsIC0mZ3Q7IGRhdGEgbW9kZWwgLSZndDsgaW1wbGVtZW50YXRp b24gLSZndDsgZGF0YSBtb2RlbCB1cGRhdGVzIC0mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IGluZm9ybWF0 aW9uIG1vZGVsIHVwZGF0ZXM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQSBwdXJlIHRv cC1kb3duIGFwcHJvYWNoIHdpbGwgbGVhdmUgeW91IHdpdGggYW4gaW5mbyBtb2RlbCB3aGljaCBv bmx5PGJyPg0KJmd0OyAmZ3Q7IHBhcnRpYWxseSBkZXNjcmliZXMgd2hhdCBoYXBwZW5zIGluIGEg ZGF0YSBtb2RlbC4gTm93LCB0aGlzIG1pZ2h0IGJlPGJyPg0KJmd0OyAmZ3Q7IGZpbmUsIGRlcGVu ZGluZyBvbiBfd2h5XyB5b3UgZGVmaW5lIGFuIGluZm8gbW9kZWwuIElmIHlvdSBkbyB0aGUgaW5m bzxicj4NCiZndDsgJmd0OyBtb2RlbCBiZWNhdXNlIHlvdSBleHBlY3QgaW50ZXJvcGVyYWJpbGl0 eSBiYXNlZCBvbiB0aGUgaW5mbyBtb2RlbCw8YnI+DQomZ3Q7ICZndDsgdGhlbiBJIGJlbGlldmUg YSBmdWxsIHJvdW5kLXRyaXAgaXMgbmVjZXNzYXJ5IHRvIGdldCB0aGUgaW5mbyBtb2RlbDxicj4N CiZndDsgJmd0OyByZWFzb25hYmx5IHByZWNpc2UuIElmIHlvdSBkbyB0aGUgaW5mbyBtb2RlbCBi ZWNhdXNlIHlvdSBoYXZlIG5vIGNsdWU8YnI+DQomZ3Q7ICZndDsgb3IgYWdyZWVtZW50IGhvdyB0 byB3cml0ZSBhIGRhdGEgbW9kZWwsIHRoZW4gaXQgaXMgZmluZSB0byBiZSBwcmVwYXJlZDxicj4N CiZndDsgJmd0OyB0byBkaXZlcmdlIGZyb20gdGhlIGluZm8gbW9kZWwgdXAgdG8gdGhlIHBvaW50 IHRoYXQgaXQgaXMgbm90IGltcG9ydGFudDxicj4NCiZndDsgYW55bW9yZSBmb3IgaW50ZXJvcGVy YWJpbGl0eS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgU28gdGhlIGtleSBxdWVzdGlv biBmb3IgbWUgaXMgd2hpY2ggZnVuY3Rpb24gdGhlIGluZm8gbW9kZWwgaXM8YnI+DQomZ3Q7ICZn dDsgc3VwcG9zZWQgdG8gZnVsZmlsbC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgL2pz PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tPGJyPg0KJmd0OyAmZ3Q7IEp1ZXJnZW4g U2Nob2Vud2FlbGRlciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SmFj b2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPGJyPg0KJmd0OyAmZ3Q7IFBob25lOiAmIzQzOzQ5 IDQyMSAyMDAgMzU4NyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDYW1wdXMgUmlu ZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueTxicj4NCiZndDsgJmd0OyBGYXg6Jm5ic3A7ICZu YnNwOyYjNDM7NDkgNDIxIDIwMCAzMTAzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZsdDs8YSBocmVmPSJodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgU3VwYSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpT dXBhQGlldGYub3JnIj5TdXBhQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8 YnI+DQotLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkpvaG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B818037A70EDCC4A86113DA25EC02098201EB6D8SJCEML701CHMchi_-- From nobody Fri Mar 4 12:46:30 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB941A1BE7 for ; Fri, 4 Mar 2016 09:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 daQUJKEIbAcR for ; Fri, 4 Mar 2016 09:28:33 -0800 (PST) Received: from st11p00im-asmtp004.me.com (st11p00im-asmtp004.me.com [17.172.80.98]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D071A1BDF for ; Fri, 4 Mar 2016 09:28:33 -0800 (PST) Received: from [10.99.70.118] (unknown [72.163.2.251]) by st11p00im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O3I00BNCZ7IHH20@st11p00im-asmtp004.me.com> for supa@ietf.org; Fri, 04 Mar 2016 17:28:32 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-04_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1603040307 User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Fri, 04 Mar 2016 11:28:29 -0600 From: colemaj Sender: "Jason Coleman (colemaj)" To: "King, Daniel" , "Bert Wijnen (IETF)" , "Joel M. Halpern" , Andy Bierman , John Strassner , Zhoutianran Message-id: <909DAC0E-7372-448D-A670-DF302157B0AC@cisco.com> Thread-topic: [Supa] Information models and Data models - WG adopion? References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> <56D95F20.7080006@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBDA45@EX-0-MB2.lancs.local> In-reply-to: <65174429B5AF4C45BD0798810EC48E0A8BCBDA45@EX-0-MB2.lancs.local> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 04 Mar 2016 12:46:19 -0800 Cc: Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 17:28:37 -0000 I would like to be part of working on an architecture document as well. 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" wrote: >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:bwietf@bwijnen.net] >Sent: 04 March 2016 10:11 >To: King, Daniel ; Joel M. Halpern ; Andy Bierman ; John Strassner ; Zhoutianran >Cc: Nevil Brownlee ; SUPA list >Subject: Re: [Supa] Information models and Data models - WG adopion? > >On 03/03/16 17:41, King, Daniel wrote: >> 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? >Dan, I am willing to take initiative on this. > >I saw in one of Johns postings: > 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. > >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. >> >> -----Original Message----- >> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen >> (IETF) >> Sent: 03 March 2016 16:13 >> To: Joel M. Halpern ; Andy Bierman >> ; John Strassner >> Cc: Zhoutianran ; Nevil Brownlee >> ; SUPA list >> Subject: Re: [Supa] Information models and Data models - WG adopion? >> >> Inline >> >> On 03/03/16 16:48, Joel M. Halpern wrote: >>> 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". >> 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 >>> Yours, >>> Joel >>> >>> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: >>>> 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 >>>>> >>>> > >>>>> wrote: >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> Andy >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Supa [mailto:supa-bounces@ietf.org >>>>> ] 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, >>>>> >>>>> 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 >>>>> >>>>> > -----Original Message----- >>>>> > From: Supa [mailto:supa-bounces@ietf.org >>>>> ] 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"). >>>>> > >>>>> > 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:supa-bounces@ietf.org >>>>> ] On Behalf Of IETF >>>>> > >> Secretariat >>>>> > >> Sent: Monday, February 29, 2016 6:35 AM >>>>> > >> To: >>>>> draft-strassner-supa-generic-policy-info-model@ietf.org >>>>> ; >>>>> > >> supa-chairs@ietf.org ; >>>>> supa@ietf.org >>>>> > >> 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 >>>>> > >> Supa@ietf.org >>>>> > >> 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 >>>>> > >>>>> > _______________________________________________ >>>>> > Supa mailing list >>>>> > Supa@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/supa >>>>> >>>>> _______________________________________________ >>>>> Supa mailing list >>>>> Supa@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/supa >>>>> >>>>> _______________________________________________ >>>>> Supa mailing list >>>>> Supa@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/supa >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Supa mailing list >>>>> Supa@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/supa >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> > >_______________________________________________ >Supa mailing list >Supa@ietf.org >https://www.ietf.org/mailman/listinfo/supa From nobody Fri Mar 4 12:46:32 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2B21A1DBD for ; Fri, 4 Mar 2016 09:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 6HMTqPXYC69w for ; Fri, 4 Mar 2016 09:29:50 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7CD1A1BF3 for ; Fri, 4 Mar 2016 09:29:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21372; q=dns/txt; s=iport; t=1457112590; x=1458322190; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QtPEVQBTV24cmcFaAvUkFCX1YrMOHifmr6w8mpX2VZU=; b=CAA90wnAWtYy4YPT5kPm6djksldK1w83eOrXe2q26OBkiFiz1PWY0k/S 8ukgL6v8SBj05EUSiRTyL83QagMZbkprvIu0H1pS9in6IO/Mi85gjLNpM 8Aaaglt5NzhUNGNI5SxAJcP1zc4vT9ycQfttirShugUvkAyw5RnLe1YdR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzBQB4xdlW/4ENJK1dDoMsUm0GukKBa?= =?us-ascii?q?RcKhW4CHIEbOhIBAQEBAQEBZCeEQQEBAQQBAQEaBhE6BAIFDAICAgEIEQEDAQE?= =?us-ascii?q?BAgIjAwICAhkMCxQBAgYIAgQBDQUbiAcOrwqPCAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAREEBHeHCgiCRoQJEQEcCBAiAoJGK4EPBYdWBIcFiEIBhV2XA45RAScCOYI?= =?us-ascii?q?EGYENO2oBh3s0fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,536,1449532800"; d="scan'208";a="83297021" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2016 17:29:48 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u24HTmLZ016882 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Mar 2016 17:29:48 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Mar 2016 11:29:47 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Fri, 4 Mar 2016 11:29:47 -0600 From: "Jason Coleman (colemaj)" To: "King, Daniel" , "Bert Wijnen (IETF)" , "Joel M. Halpern" , Andy Bierman , John Strassner , Zhoutianran Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdWuW0ubFgwgXiUGdmadZc6KKEQ== Date: Fri, 4 Mar 2016 17:29:47 +0000 Message-ID: <5FD5189A-9B4A-4F7F-9856-169EAB8B1171@me.com> References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> <56D95F20.7080006@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBDA45@EX-0-MB2.lancs.local> <909DAC0E-7372-448D-A670-DF302157B0AC@cisco.com> In-Reply-To: <909DAC0E-7372-448D-A670-DF302157B0AC@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.70.118] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 04 Mar 2016 12:46:20 -0800 Cc: Nevil Brownlee , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 17:29:54 -0000 U2VuZGluZyBhZ2FpbiB3LyB0aGUgY29ycmVjdCBlbWFpbCBhZGRyZXNzIHRoaXMgdGltZToNCg0K DQoNCg0KDQo+SSB3b3VsZCBsaWtlIHRvIGJlIHBhcnQgb2Ygd29ya2luZyBvbiBhbiBhcmNoaXRl Y3R1cmUgZG9jdW1lbnQgYXMgd2VsbC4NCj4NCj5BcyBmb3IgdGhlIGluZm9ybWF0aW9uIG1vZGVs IHZlcnN1cyBkYXRhIG1vZGVsIGRpc2N1c3Npb24sIEkgdGhpbmsgdGhhdCBhbiBpbmZvcm1hdGlv biBtb2RlbCBpcyByZXF1aXJlZCB0byBhbGxvdyBmb3IgZGlmZmVyZW50IGRhdGEgbW9kZWxzIHRv IGZvbGxvdyBhIGNvbW1vbiBzdHJ1Y3R1cmUuICANCj5JdCBpcyBwb3NzaWJsZSB0byBjcmVhdGUg YSBkYXRhIG1vZGVsIGZpcnN0LCBidXQgdGhhdCBkYXRhIG1vZGVsIG1heSBub3QgZml0IGluIHdl bGwgd2l0aCBvdGhlciBkYXRhIG1vZGVscy4gIFRoaXMgaXMgd2h5IHRoZSBpbmZvcm1hdGlvbiBt b2RlbCBleGlzdHMgdG8gYWxsb3cgZm9yIHRoaW5ncyB0aGF0IG1heSBleHRlbmQgdGhhdCBkYXRh IG1vZGVsIG9yIGFyZSBpbiBwbGFjZSBmb3Igb3RoZXIgZGF0YSBtb2RlbHMuDQo+DQo+QXQgdGhp cyB0aW1lIHRoZSBmb2N1cyBpcyBvbiBFdmVudCwgQ29uZGl0aW9uLCBBY3Rpb24sIGJ1dCB0aGVy ZSB3aWxsIGJlIGZ1cnRoZXIgbWFuYWdlbWVudCBzdHJ1Y3R1cmVzIHRvIGRlZmluZS4NCj5UaGUg aW5mb3JtYXRpb24gbW9kZWwgc3VwcG9ydHMgYSBnZW5lcmFsIHN0cnVjdHVyZSBhbmQgdGhlbiBw cm92aWRlcyBkZXRhaWxzIG9uIEVDQS4gIFRoYXQgZ2VuZXJhbCBzdHJ1Y3R1cmUgaXMgaW1wb3J0 YW50IGZvciBmdXR1cmUgZGF0YSBtb2RlbHMgYXMgd2VsbC4NCj5UaG9zZSBtYXkgYmUgWUFORyBv ciBvdGhlciBwZW9wbGUgbWF5IGNob3NlIHRvIHVzZSB0aGUgaW5mb3JtYXRpb24gbW9kZWwgdG8g Y3JlYXRlIGEgZGF0YSBtb2RlbCBpbiBhIGRpZmZlcmVudCB3YXkuDQo+DQo+VGhlIGFyY2hpdGVj dHVyZSBkb2N1bWVudCB3b3VsZCBkZWZpbmUgdGhlIHJvbGUgb2YgdGhlIGluZm9ybWF0aW9uIG1v ZGVsIGNsZWFybHksIHdoaWNoIEkgdGhpbmsgdGhhdCBwYXJ0IG9mIHRoZSBJRCB0aGF0IEpvaG4s IEpvZWwsIGFuZCBJIHdvcmtlZCBvbiBhdHRlbXB0cyB0byBkbyBhcyB3ZWxsLCBhbmQgdGhlbiBj YW4gc2hvdyBob3cgdGhlIGRhdGEgbW9kZWxzIHdpbGwgYmUgc3VwcG9ydGVkIGJ5IHRoZSBpbmZv cm1hdGlvbiBtb2RlbCBhbmQgd2hhdCBlbHNlIHRoZSBXRyBDaGFydGVyIGhhcyBkZWZpbmVkIGFu ZCBwb3NzaWJseSB3aGVyZSB3ZSBnbyBuZXh0Lg0KPg0KPkphc29uDQo+DQo+DQo+DQo+T24gMy80 LzE2LCA3OjM0IEFNLCAiU3VwYSBvbiBiZWhhbGYgb2YgS2luZywgRGFuaWVsIiA8c3VwYS1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBkLmtpbmdAbGFuY2FzdGVyLmFjLnVrPiB3cm90ZToN Cj4NCj4+SGkgQmVydCwgDQo+Pg0KPj5UaGFuayBmb3IgdGFraW5nIHRoZSBpbml0aWF0aXZlLiBX ZSBjYW4gbWFrZSBzdXJlIHRoZXJlIGlzIHRpbWUgb24gdGhlIGFnZW5kYSBmb3IgdGhlIEktRC4g DQo+Pg0KPj5CUiwgRGFuLiANCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZy b206IEJlcnQgV2lqbmVuIChJRVRGKSBbbWFpbHRvOmJ3aWV0ZkBid2lqbmVuLm5ldF0gDQo+PlNl bnQ6IDA0IE1hcmNoIDIwMTYgMTA6MTENCj4+VG86IEtpbmcsIERhbmllbCA8ZC5raW5nQGxhbmNh c3Rlci5hYy51az47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT47IEFuZHkg Qmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPjsgSm9obiBTdHJhc3NuZXIgPEpvaG4uc2MuU3Ry YXNzbmVyQGh1YXdlaS5jb20+OyBaaG91dGlhbnJhbiA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4N Cj4+Q2M6IE5ldmlsIEJyb3dubGVlIDxuLmJyb3dubGVlQGF1Y2tsYW5kLmFjLm56PjsgU1VQQSBs aXN0IDxzdXBhQGlldGYub3JnPg0KPj5TdWJqZWN0OiBSZTogW1N1cGFdIEluZm9ybWF0aW9uIG1v ZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBXRyBhZG9waW9uPw0KPj4NCj4+T24gMDMvMDMvMTYgMTc6 NDEsIEtpbmcsIERhbmllbCB3cm90ZToNCj4+PiBIaSAgQWxsLg0KPj4+DQo+Pj4gV2UgaGF2ZSBh IHBsYWNlaG9sZGVyIGluIHRoZSBTVVBBIENoYXJ0ZXIgZm9yOg0KPj4+DQo+Pj4gMSkgQW4gZXhw bGFuYXRpb24gb2YgdGhlIHNjb3BlIG9mIHRoZSBwb2xpY3ktYmFzZWQgbWFuYWdlbWVudCBmcmFt ZXdvcmsgYW5kIGhvdyBpdCByZWxhdGVzIHRvIGV4aXN0aW5nIHdvcmsgb2YgdGhlIElFVEYuDQo+ Pj4NCj4+PiBBIHByb3Bvc2FsIGZvciB0aGlzIGRvY3VtZW50IGhhcyBub3QgYmVlbiBmb3J0aGNv bWluZyB0aHVzIGZhci4gSXQgd291bGQgc2VlbSB0aGF0IGEgIlBvbGljeS1iYXNlZCBNYW5hZ2Vt ZW50IEZyYW1ld29yayIgZGlzY3Vzc2luZyBhcmNoaXRlY3R1cmUsIGFwcGxpY2FiaWxpdHkgYW5k IHJlbGF0aW9uc2hpcHMgKCJzeXN0ZW0gb3ZlcnZpZXciKSB3b3VsZCBiZSByZWFzb25hYmxlIGNv bnRlbnQgZm9yIGEgZnJhbWV3b3JrIGRvY3VtZW50IG1lbnRpb25lZCBpbiB0aGUgQ2hhcnRlcj8N Cj4+Pg0KPj4+IEZ1cnRoZXJtb3JlLCBBbmR5LCBUaWFucmFuIGFuZCBCZXJ0IGFsbCBzZWVtIHdp bGxpbmcgdG8gc3VwcG9ydCBkZXZlbG9wbWVudCAodmlhIGRpcmVjdCBjb250cmlidXRpb25zKSBm b3IgdGhlIGZyYW1ld29yay9hcmNoaXRlY3R1cmUgZG9jdW1lbnQ/DQo+PkRhbiwgSSBhbSB3aWxs aW5nIHRvIHRha2UgaW5pdGlhdGl2ZSBvbiB0aGlzLg0KPj4NCj4+SSBzYXcgaW4gb25lIG9mIEpv aG5zIHBvc3RpbmdzOg0KPj4gICAgV2VsbCwgd2UgZG9uJ3QgaGF2ZSBhbiBhcmNoaXRlY3R1cmUg ZG9jdW1lbnQgY3VycmVudGx5IGluIG91ciBjaGFydGVyDQo+PiAgICAodGhvdWdoIEkgd291bGQg c3VwcG9ydCBhbWVuZGluZyB0aGUgY2hhcnRlciB0byBpbmNsdWRlIHRoaXMpLiBJbiB0aGUNCj4+ ICAgIChub3cgZXhwaXJlZCkgcHJvcG9zaXRpb24gZHJhZnQgKHdoaWNoIHdlIGFyZSBub3cgd29y a2luZyBvbiB0byByZWlzc3VlKSwNCj4+ICAgIHRoZXJlIHdhcyBhbiBleGVtcGxhcnkgYXJjaGl0 ZWN0dXJlLg0KPj4NCj4+Sm9obiwgZG8geW91IGhhdmUgdGhlIHBpZWNlIG9mIHRleHQgaW4gYW4g WE1MIGZpbGUgKEktRCBzb3VyY2UgZmlsZSkgYW5kIGlmIHNvLCBjYW4geW91IHNlbmQgdGhhdCB0 byBtZS4gSSBhc3N1bWUgeW91IGFyZSBPSyB3aXRoIHVzIHVzaW5nIHRoYXQgYXMgYSBzdGFydGlu ZyBwb2ludD8NCj4+DQo+PkRhbi9OZXZpbCwgaWYgd2Ugc3VibWl0IGFuIGluIGluaXRpYWwgSS1E IHRpbWVseSwgZG8geW91IHRoaW5rIHdlIGNhbiBzcGVuZCBzb21lIHRpbWUgb24gaXQgaW4gb3Vy IElFVEY5NSBzZXNzaW9uPw0KPj4NCj4+VGhhbmtzLA0KPj5CZXJ0DQo+Pg0KPj4NCj4+DQo+Pj4g QlIsIERhbi4NCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTog U3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlcnQgV2lq bmVuIA0KPj4+IChJRVRGKQ0KPj4+IFNlbnQ6IDAzIE1hcmNoIDIwMTYgMTY6MTMNCj4+PiBUbzog Sm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsgQW5keSBCaWVybWFuIA0KPj4+ IDxhbmR5QHl1bWF3b3Jrcy5jb20+OyBKb2huIFN0cmFzc25lciA8Sm9obi5zYy5TdHJhc3NuZXJA aHVhd2VpLmNvbT4NCj4+PiBDYzogWmhvdXRpYW5yYW4gPHpob3V0aWFucmFuQGh1YXdlaS5jb20+ OyBOZXZpbCBCcm93bmxlZSANCj4+PiA8bi5icm93bmxlZUBhdWNrbGFuZC5hYy5uej47IFNVUEEg bGlzdCA8c3VwYUBpZXRmLm9yZz4NCj4+PiBTdWJqZWN0OiBSZTogW1N1cGFdIEluZm9ybWF0aW9u IG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBXRyBhZG9waW9uPw0KPj4+DQo+Pj4gSW5saW5lDQo+ Pj4NCj4+PiBPbiAwMy8wMy8xNiAxNjo0OCwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4+PiBU d28gc2VwYXJhdGUgYnV0IHJlbGF0ZWQgcXVlc2l0b25zLg0KPj4+Pg0KPj4+PiAxKSBDYW4geW91 IGhlbHAgdXNlIGZpbmQgdGhlIHBsYWNlcyB3aGVyZSB0aGUgbW9kZWwgLyB0ZXh0IGlzIHRvbyAN Cj4+Pj4gaW1wbGVtZW50YXRpb24gc3BlY2lmaWM/ICBUaGVyZSBhcmUgYSBmZXcgcGxhY2VzIHdo ZXJlIGluIGRlc2NyaWJpbmcgDQo+Pj4+IGVudW1lcmF0aW9ucyB0aGUgbW9kZWwgY2FsbHMgZm9y IGludGVnZXJzLiAgSW4gdGhlIG1hcHBpbmcgdG8gWUFORywgSSBoYXZlIGFscmVhZHkgc3RhcnRl ZCByZXBsYWNpbmcgdGhvc2Ugd2l0aCBFbnVtZXJhdGlvbnMuICBBcmUgdGhlcmUgb3RoZXIga2lu ZHMgb2Ygb3Zlci1zcGVjaWZpY2l0eT8NCj4+Pj4NCj4+Pj4gMikgVGhlIGNoYXJ0ZXIgYWxsb3dz IGZvciBhIHJhbmdlIG9mIGltcGxlbWVudGF0aW9ucyBvZiB0aGUgU1VQQSANCj4+Pj4gc3lzdGVt LiAgRm9sa3MgbWF5IHJlY2FsbCBJIGFza2VkIGluIHRoZSByb29tIGF0IHRoZSBsYXN0IG1lZXRp bmcgDQo+Pj4+IHdoZXRoZXIgb3VyIGNoYXJ0ZXJlZCBhbGxvd2QgYm90aCBjb21tdW5pY2F0aW9u IGJldHdlZW4gYSBjb250cm9sIA0KPj4+PiBzeXN0ZW0gYW5kIGEgZGV2aWNlLCBhbmQgY29tbXVu aWNhdGlvbiBiZXR3ZWVuIGEgcG9saWN5IHJlcG9zaXRvcnkgYW5kIGEgcG9saWN5IGVuZ2luZS4g IEkgd2FzIHRvbGQgYnkgdGhlIEFEIHRoYXQgdGhlIGNoYXJ0ZXJlZCBhbGxvd2VkIGJvdGguICBU aGlzIGRvZXMgbWFrZSBpdCByYXRoZXIgaW50ZXJlc3RpbmcgdG8gZGVmaW5lIHRoZSAiYXJjaGl0 ZWN0dXJlIi4NCj4+PiBNbW1tLi4uIGJvdGggY29uY3VycmVudGx5LCBvciBkaWQgaGUgbWVhbiB0 aGF0IHdlIGFzIGEgV0cgY2FuIG1ha2UgYSBjaG9pY2Ugd2hhdCB3ZSBwcmVmZXIgYW5kIHN0YW5k YXJkaXplIHRoYXQ/DQo+Pj4gSWYgd2UgZG8gYm90aCBjb25jdXJyZW50bHkgb3IgYSBsb25nc2lk ZSBlYWNoIG90aGVyLCBjYW4gd2UgdGhlbiBzdGlsbCBndWFyYW50ZWUgaW50ZXJvcGVyYWJpbGl0 eSAod2hpY2ggSSB0aGluayBpcyBvbmUgb2Ygb3VyIG1haW4gb2JqY3RpdmVzLCBubyk/DQo+Pj4+ IDInKSBJIGRvIHRoaW5rIHRoYXQgdGhlcmUgYXJlIGEgZmV3IHBsYWNlcyBpbiB0aGUgbW9kZWws IHBhcnRpY3VsYXJseSANCj4+Pj4gd2l0aCByZWdhcmQgdG8gcG9saWN5IGV4ZWN1dGlvbiBzdGF0 dXMsIHdoZXJlIHRoZSBtb2RlbCBtYWtlcyBzb21lIGFzc3VtcHRpb25zIGFib3V0IHRoZSBzdHJ1 Y3R1cmUgb2YgcG9saWN5IGRlbGl2ZXJ5LiAgRm9yIHRoZSBtb3N0IHBhcnQsIHRob3NlIHNob3Vs ZCBiZSByZW1vdmVkLiAgQXNzaXN0YW5jZSBpbiBmaW5kaW5nDQo+Pj4+IHRoZW0gaXMgYXBwcmVj aWF0ZWQuICBJIHN1c3BlY3QgdGhhdCBzb21lIG9mIHRoZW0gYXJlIG5lY2Vzc2FyeSwgYW5kIHRo b3NlIHNob3VsZCBiZSBleHBsaWNpdGx5IGRlc2NyaWJlZC4gICAoQW5kIHdlIHNob3VsZCBtYWtl DQo+Pj4+IHN1cmUgdGhlIHdvcmtpbmcgZ3JvdXAgYWdyZWVzIHdpdGggdGhlIGFzc3VtcHRpb25z LikNCj4+Pj4NCj4+Pj4gMykgKG1pbm9yKSBUaGUgY2hhcnRlciBwZXJtaXRzIHRoZSBpbmZvcm1h dGlvbiBtb2RlbC4gIEkgcHJlc3VtZSB3ZSBjb3VsZCBhbWVuZCB0aGUgY2hhcnRlciB0byBwZXJt aXQgYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50Lg0KPj4+Pg0KPj4+IEkgd291bGQgc2F5IGFuICJB cmNoaXRlY3R1cmUiIG9yICJTeXN0ZW0gT3ZlcnZpZXciIGRvY3VtZW50IHdvdWxkIGJlIGEgZ29v ZCB0aGluZy4NCj4+Pg0KPj4+IEJlcnQNCj4+Pj4gWW91cnMsDQo+Pj4+IEpvZWwNCj4+Pj4NCj4+ Pj4gT24gMy8zLzE2IDEwOjI3IEFNLCBCZXJ0IFdpam5lbiAoSUVURikgd3JvdGU6DQo+Pj4+PiBW ZXJ5IGdvb2QgYW5kIHByYWN0aWNhbCBxdWVzdGlvbiByYWlzZWQgYnkgQW5keSENCj4+Pj4+DQo+ Pj4+PiBCZXJ0DQo+Pj4+Pg0KPj4+Pj4gT24gMDMvMDMvMTYgMDY6MDYsIEFuZHkgQmllcm1hbiB3 cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IE9uIFdlZCwgTWFyIDIsIDIwMTYgYXQgNzoyMSBQTSwgSm9o biBTdHJhc3NuZXIgDQo+Pj4+Pj4gPEpvaG4uc2MuU3RyYXNzbmVyQGh1YXdlaS5jb20gDQo+Pj4+ Pj4gPG1haWx0bzpKb2huLnNjLlN0cmFzc25lckBodWF3ZWkuY29tPj4NCj4+Pj4+PiB3cm90ZToN Cj4+Pj4+Pg0KPj4+Pj4+ICAgICAgV2Ugc2hvdWxkIHdvcmsgb24gYW4gaW5mb3JtYXRpb24gbW9k ZWwgZm9yIHNldmVyYWwgcmVhc29ucywgZXZlbiBpZg0KPj4+Pj4+ICAgICAgdGhlcmUgaXMgb25s eSB0YXJnZXQgZGF0YSBtb2RlbCAoaS5lLiwgWUFORyk6DQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICAg MSkgQW4gaW5mb3JtYXRpb24gbW9kZWwgY2FuIGRlZmluZSBob3cgZGF0YSBhcmUgcmVsYXRlZCB0 byBlYWNoDQo+Pj4+Pj4gICAgICAgICAgIG90aGVyIGluZGVwZW5kZW50IG9mIGltcGxlbWVudGF0 aW9uLiBUaGlzIGlzIG11Y2ggaGFyZGVyIHRvIGRvDQo+Pj4+Pj4gICAgICAgICAgIGluIFlBTkcu IEhlbmNlLCB0aGUgaW5mb3JtYXRpb24gbW9kZWwgbWF5IG1ha2UgdGhlc2UgaW5oZXJlbnQNCj4+ Pj4+PiAgICAgICAgICAgcmVsYXRpb25zaGlwcyBlYXNpZXIgdG8gdmlzdWFsaXplIGFuZCBkZWZp bmUuDQo+Pj4+Pj4gICAgICAgIDIpIEFuIGluZm9ybWF0aW9uIG1vZGVsIHNlcGFyYXRlcyB0aGUg bG9naWNhbCBkZXNpZ24gZnJvbSB0aGUNCj4+Pj4+PiAgICAgICAgICAgcGh5c2ljYWwgZGVzaWdu IG9mIHRoZSBzeXN0ZW0sIGVuYWJsaW5nIGEgZGVlcGVyIHVuZGVyc3RhbmRpbmcNCj4+Pj4+PiAg ICAgICAgICAgb2YgYm90aCBpbmRlcGVuZGVudCBvZiBpbXBsZW1lbnRhdGlvbi4gVGhpcyBjYW4g YmUgdXNlZCB0bw0KPj4+Pj4+ICAgICAgICAgICBwcm9kdWNlIG1vcmUgcG93ZXJmdWwgaW1wbGVt ZW50YXRpb25zLg0KPj4+Pj4+ICAgICAgICAzKSBJZiBhbiBpbmZvcm1hdGlvbiBtb2RlbCBpcyB3 b3JrZWQgb24gaW4gYW5vdGhlciBvcmdhbml6YXRpb24sDQo+Pj4+Pj4gICAgICAgICAgIHRoZXJl IGlzIG5vIGd1YXJhbnRlZSB0aGF0IGl0cyBvdXRwdXQgd2lsbCBiZSB1c2VmdWwgdG8gdGhlDQo+ Pj4+Pj4gICAgICAgICAgIElFVEYuIEkgYW0gYWN0aXZlIGluIHRoZSBUTSBGb3J1bSwgd2hpY2gg eW91IGNpdGVkOyB0aGV5IGFyZQ0KPj4+Pj4+ICAgICAgICAgICBpbiBnZW5lcmFsIG5vdCB3b3Jy aWVkIGFib3V0IGltcGxlbWVudGluZyBZQU5HIG1vZGVscywgbXVjaA0KPj4+Pj4+ICAgICAgICAg ICBsZXNzIHByb2R1Y2luZyBvcHRpbWFsIFlBTkcgbW9kZWxzLg0KPj4+Pj4+ICAgICAgICA0KSBU aGlzIGVuYWJsZXMgb3RoZXIgU0RPcyBhbmQgZm9yYSwgd2hpY2ggZG8gbm90IHVzZSBZQU5HLCB0 bw0KPj4+Pj4+ICAgICAgICAgICBtb3JlIGVhc2lseSB1bmRlcnN0YW5kIG91ciBvdXRwdXQuDQo+ Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gSXQgc2VlbXMgdG8gbWUgdGhhdCB5b3VyIGRy YWZ0IGhhcyBtYW55IGRldGFpbHMgcmVsYXRlZCB0byB0aGUgDQo+Pj4+Pj4gYWJzdHJhY3Rpb24g b2YgcG9saWN5IGxvZ2ljLCBidXQgYWxzbyBtYW55IGFzcGVjdHMgdGhhdCBsb29rIGxpa2UgDQo+ Pj4+Pj4gaW1wbGVtZW50YXRpb24gZGV0YWlscy4NCj4+Pj4+PiBQZXJoYXBzIGl0IGNhbiBiZSBz aW1wbGlmaWVkIGlmIHRoZSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHdlcmUgcmVtb3ZlZC4NCj4+ Pj4+Pg0KPj4+Pj4+IEkgYW0gbW9yZSBpbnRlcmVzdGVkIGluIHRoZSBTVVBBIEFyY2hpdGVjdHVy ZSBkb2N1bWVudCBmaXJzdC4NCj4+Pj4+PiBJIGRvbid0IHNlZSBob3cgd2UgY2FuIGFncmVlIG9u IGFuIGluZm8tbW9kZWwgaW4gdGhlIGFic2VuY2Ugb2YgYSANCj4+Pj4+PiBzeXN0ZW0gYXJjaGl0 ZWN0dXJlLg0KPj4+Pj4+DQo+Pj4+Pj4gRG9lcyBTVVBBIHJ1biBhbnl3aGVyZT8gV2hhdCBkb2Vz IGl0IGV2ZW4gbWVhbiB0byBpbXBsZW1lbnQgU1VQQT8NCj4+Pj4+PiBXaWxsIHBlb3BsZSBiZSBh YmxlIHRvIGJ1aWxkIGludGVyb3BlcmFibGUgU1VQQSBlbmdpbmVzIGZyb20gdGhlIFJGQ3M/DQo+ Pj4+Pj4gSXMgdGhlcmUgYSBkaWZmZXJlbmNlIGJldHdlZW4gYSBTVVBBIGVuZ2luZSBydW5uaW5n IGF0IHRoZSBkZXZpY2UgDQo+Pj4+Pj4gbGV2ZWwgb3IgdGhlIGNvbnRyb2xsZXIgbGV2ZWw/ICBX aGF0IGRhdGEgaXMgYXZhaWxhYmxlIGZvciBwb2xpY3kgDQo+Pj4+Pj4gZW5mb3JjZW1lbnQgYW5h bHlzaXM/DQo+Pj4+Pj4gSXMgdGhpcyBjb25maWd1cmFibGUgdGhyb3VnaCBZQU5HIG1vZHVsZXMg aW1wbGVtZW50ZWQgYnkgYSBTVVBBIGVuZ2luZT8NCj4+Pj4+PiBIb3cgYXJlIHBvbGljaWVzIGRl ZmluZWQgYW5kIG1hbmFnZWQgd2l0aGluIHRoZSBTVVBBIGltcGxlbWVudGF0aW9uPw0KPj4+Pj4+ IEhvdyBpcyBkZXZpY2UgY29uZmlnIGFsdGVyZWQgdG8gaW1wbGVtZW50IHBvbGljeT8NCj4+Pj4+ PiBIb3cgYXJlIGRldmljZSBvcGVyYXRpb25hbCBzdGF0ZSBhbmQgc3RhdGlzdGljcyB1c2VkIHRv IHZlcmlmeSANCj4+Pj4+PiBwb2xpY3kgaW1wbGVtZW50YXRpb24/DQo+Pj4+Pj4NCj4+Pj4+PiBB IHByZWNpc2UgZGVzY3JpcHRpb24gb2YgcG9saWN5IGxvZ2ljIG1pZ2h0IGJlIGEgZ29vZCB0aGlu ZyB0byBoYXZlLg0KPj4+Pj4+IEkgYW0gbm90IG9iamVjdGluZyB0byBhbiBpbmZvIG1vZGVsIGRv Yy4gIEEgc3lzdGVtIGFyY2hpdGVjdHVyZSBhbmQgDQo+Pj4+Pj4gYSB3b3JrYWJsZSBzb2x1dGlv biB3aWxsIHJlcXVpcmUgYSBsb3QgbW9yZSB0aGFuIHRoYXQuDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiAgICAgIEpvaG4NCj4+ Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBBbmR5DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+ ICAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiAgICAgIEZyb206IFN1cGEg W21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmcgDQo+Pj4+Pj4gPG1haWx0bzpzdXBhLWJvdW5j ZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgWmhvdXRpYW5yYW4NCj4+Pj4+PiAgICAgIFNlbnQ6 IFR1ZXNkYXksIE1hcmNoIDAxLCAyMDE2IDc6MjkgUE0NCj4+Pj4+PiAgICAgIFRvOiBOZXZpbCBC cm93bmxlZQ0KPj4+Pj4+ICAgICAgQ2M6IFNVUEEgbGlzdA0KPj4+Pj4+ICAgICAgU3ViamVjdDog UmU6IFtTdXBhXSBJbmZvcm1hdGlvbiBtb2RlbHMgYW5kIERhdGEgbW9kZWxzIC0gV0cgYWRvcGlv bj8NCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgSGkgTmV2aWwsDQo+Pj4+Pj4NCj4+Pj4+PiAgICAgIEkg YW0gbm90IGFyZ3VpbmcgaW5mb3JtYXRpb24gbW9kZWwgaXMgdXNlbGVzcywgYnV0IGl0IGNhbiBi ZSANCj4+Pj4+PiB3b3JrZWQgb3V0IGluIG90aGVyIG9yZ2FuaXphdGlvbnMgaWYgbmVjZXNzYXJ5 LCBlLmcuIFRNRi4NCj4+Pj4+PiAgICAgIElmIGluIFNVUEEgd2UgY2FuIHdvcmtlZCBvbiBZQU5H IGRhdGEgbW9kZWxzIGRpcmVjdGx5LCB3aHkgd2UgDQo+Pj4+Pj4gZmlyc3RseSB3b3JrIG9uIGFu IGluZm9ybWF0aW9uIG1vZGVsIGFuZCB0aGVuIHRyYW5zbGF0ZSBpdCB0bw0KPj4+Pj4+ICAgICAg WUFORyBkYXRhIG1vZGVsPw0KPj4+Pj4+ICAgICAgSXQganVzdCBub3QgbWFrZXMgc2Vuc2UgdG8g bWUuDQo+Pj4+Pj4NCj4+Pj4+PiAgICAgIFRpYW5yYW4NCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+ICAgICAgPiBGcm9tOiBTdXBhIFttYWls dG86c3VwYS1ib3VuY2VzQGlldGYub3JnIA0KPj4+Pj4+IDxtYWlsdG86c3VwYS1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIE5ldmlsIEJyb3dubGVlDQo+Pj4+Pj4gICAgICA+IFNlbnQ6 IFdlZG5lc2RheSwgTWFyY2ggMDIsIDIwMTYgNjo1NiBBTQ0KPj4+Pj4+ICAgICAgPiBUbzogWmhv dXRpYW5yYW4NCj4+Pj4+PiAgICAgID4gQ2M6IFNVUEEgbGlzdA0KPj4+Pj4+ICAgICAgPiBTdWJq ZWN0OiBSZTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBXRyAN Cj4+Pj4+PiBhZG9waW9uPw0KPj4+Pj4+ICAgICAgPg0KPj4+Pj4+ICAgICAgPg0KPj4+Pj4+ICAg ICAgPiBIaSBUaWFucmFuOg0KPj4+Pj4+ICAgICAgPg0KPj4+Pj4+ICAgICAgPiBJbiBteSBleHBl cmllbmNlcywgaGF2aW5nIGEgd2VsbC1kZWZpbmVkIGluZm9ybWF0aW9uIG1vZGVsIA0KPj4+Pj4+ IGlzIGEgZ29vZCBzdGFydGluZw0KPj4+Pj4+ICAgICAgPiBwb2ludC4gIEl0IGFsbG93cyBkaWZm ZXJlbnQgaW1wbGVtZW50YXRpb25zLCBlYWNoIG9mIHdoaWNoIA0KPj4+Pj4+IGNhbiBkZXZlbG9w IGl0J3MNCj4+Pj4+PiAgICAgID4gb3duIGRhdGEgbW9kZWwgLSBpbiBvdGhlciB3b3JkcywgdGhl IGluZm9ybWF0aW9uIG1vZGVsIGlzIGEgDQo+Pj4+Pj4gZ29vZCB1bmlmeWluZw0KPj4+Pj4+ICAg ICAgPiBpbmZsdWVuY2UgLSB3aGljaCBpcyB3aHkgcHVibGlzaGluZyBzdWNoIGEgZG9jdW1lbnQg aXMgdGhlIA0KPj4+Pj4+IHNlY29uZCBvZiBvdXINCj4+Pj4+PiAgICAgID4gY2hhcnQgaXRlbXMu ICBJIGhvcGUgdGhhdCBnZXR0aW5nIGEgZ29vZCBkYXRhIG1vZGVsIHdpbGwgDQo+Pj4+Pj4gaGVs cCB1cyB3aXRoIHRoZQ0KPj4+Pj4+ICAgICAgPiBmaXJzdCBjaGFydCBpdGVtICgic2NvcGUgb2Yg dGhlIHBvbGljeS1iYXNlZCBtYW5hZ2VtZW50IA0KPj4+Pj4+IGZyYW1ld29yayIpLg0KPj4+Pj4+ ICAgICAgPg0KPj4+Pj4+ICAgICAgPiBkcmFmdC1zdHJhc3NuZXItc3VwYS1nZW5lcmljLXBvbGlj eS1pbmZvLW1vZGVsIGlzIHRoZSBvbmx5IFNVUEENCj4+Pj4+PiAgICAgID4gaW5mb3JtYXRpb24g bW9kZWwgdGhhdCdzIGhhZCBhbnkgd29yayBkb25lIG9uIGl0IHNpbmNlIElFVEYgDQo+Pj4+Pj4g OTUsIHRoZXJlZm9yZQ0KPj4+Pj4+ICAgICAgPiBJJ3ZlIHByb3Bvc2VkIGl0IGZvciBXRyBhZG9w dGlvbi4NCj4+Pj4+PiAgICAgID4NCj4+Pj4+PiAgICAgID4gQXMgZm9yIHRoZSB0aGlyZCBjaGFy dGVyIGl0ZW0gLSAic2V0IG9mIFlBTkcgZGF0YSBtb2RlbHMiLCANCj4+Pj4+PiB0aGVyZSBhcmUg dHdvDQo+Pj4+Pj4gICAgICA+IG9mIHRoZXNlIG9uIHRoZSBTVVBBIGRvY3VtZW50cyBwYWdlLiAg SXQgd291bGQgaGVscCBhdCB0aGlzIA0KPj4+Pj4+IHN0YWdlIGlmIHRoZWlyDQo+Pj4+Pj4gICAg ICA+IGF1dGhvcnMgY291bGQgY29tbWVudCBvbiB0aGlzIGxpc3QgYWJvdXQgdGhlIHN0YXR1cyBv ZiB0aGVzZSANCj4+Pj4+PiBkcmFmdHMuICBJbg0KPj4+Pj4+ICAgICAgPiBwYXJ0aWN1bGFyLCBq YXZlIHRoZXkgYmVlbiB3b3JraW5nIG9uIGEgbmV3IHZlcnNpb24/DQo+Pj4+Pj4gICAgICA+DQo+ Pj4+Pj4gICAgICA+IE92ZXJhbGwsIHdlIHJlYWxseSBuZWVkIG1vcmUgZGlzY3Vzc2lvbiBvbiB0 aGUgbGlzdCBvZiANCj4+Pj4+PiB3aGF0J3MgaGFwcGVuaW5nDQo+Pj4+Pj4gICAgICA+IHdpdGgg dGhlIFNVUEEgd29yayENCj4+Pj4+PiAgICAgID4NCj4+Pj4+PiAgICAgID4gQ2hlZXJzLCBOZXZp bA0KPj4+Pj4+ICAgICAgPg0KPj4+Pj4+ICAgICAgPg0KPj4+Pj4+ICAgICAgPiBPbiAxLzAzLzE2 IDY6MTMgcG0sIFpob3V0aWFucmFuIHdyb3RlOg0KPj4+Pj4+ICAgICAgPiA+IElmIHRoaXMgaXMg YSBwb2xsIGZvciBXRyBhZG9wdGlvbiwgSSB3b3VsZCBzYXkgbm90IHN1cHBvcnQuDQo+Pj4+Pj4g ICAgICA+ID4NCj4+Pj4+PiAgICAgID4gPiBJZiB3ZSB3YW50IHRvIGZpbmFsbHkgZ2VuZXJhdGUg WUFORyBkYXRhIG1vZGVscyBoZXJlLCB3aHkgDQo+Pj4+Pj4gZG8gd2Ugc3BlbmQNCj4+Pj4+PiAg ICAgID4gdGltZSB3b3JraW5nIG9uIHRoaXMgaW5mb3JtYXRpb24gbW9kZWw/DQo+Pj4+Pj4gICAg ICA+ID4NCj4+Pj4+PiAgICAgID4gPiBXaHkgbm90IGZvY3VzIG9uIHRoZSBFQ0EgWUFORyBkYXRh IG1vZGVsIGRpcmVjdGx5IGFzIA0KPj4+Pj4+IHN0YW5kYXJkIHRyYWNrPw0KPj4+Pj4+ICAgICAg PiA+DQo+Pj4+Pj4gICAgICA+ID4NCj4+Pj4+PiAgICAgID4gPiBUaWFucmFuDQo+Pj4+Pj4gICAg ICA+ID4NCj4+Pj4+PiAgICAgID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+ PiAgICAgID4gPj4gRnJvbTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZyANCj4+ Pj4+PiA8bWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBJRVRGDQo+ Pj4+Pj4gICAgICA+ID4+IFNlY3JldGFyaWF0DQo+Pj4+Pj4gICAgICA+ID4+IFNlbnQ6IE1vbmRh eSwgRmVicnVhcnkgMjksIDIwMTYgNjozNSBBTQ0KPj4+Pj4+ICAgICAgPiA+PiBUbzogDQo+Pj4+ Pj4gZHJhZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5mby1tb2RlbEBpZXRmLm9y Zw0KPj4+Pj4+IDxtYWlsdG86ZHJhZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5m by1tb2RlbEBpZXRmLm9yZz47DQo+Pj4+Pj4gICAgICA+ID4+IHN1cGEtY2hhaXJzQGlldGYub3Jn IDxtYWlsdG86c3VwYS1jaGFpcnNAaWV0Zi5vcmc+OyANCj4+Pj4+PiBzdXBhQGlldGYub3JnIDxt YWlsdG86c3VwYUBpZXRmLm9yZz4NCj4+Pj4+PiAgICAgID4gPj4gU3ViamVjdDogW1N1cGFdIFRo ZSBTVVBBIFdHIGhhcyBwbGFjZWQNCj4+Pj4+PiAgICAgID4gPj4gZHJhZnQtc3RyYXNzbmVyLXN1 cGEtZ2VuZXJpYy1wb2xpY3ktaW5mby1tb2RlbCBpbiBzdGF0ZSANCj4+Pj4+PiAiQ2FsbCBGb3IN Cj4+Pj4+PiAgICAgID4gPj4gQWRvcHRpb24gQnkgV0cgSXNzdWVkIg0KPj4+Pj4+ICAgICAgPiA+ Pg0KPj4+Pj4+ICAgICAgPiA+Pg0KPj4+Pj4+ICAgICAgPiA+PiBUaGUgU1VQQSBXRyBoYXMgcGxh Y2VkDQo+Pj4+Pj4gZHJhZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5mby1tb2Rl bA0KPj4+Pj4+ICAgICAgPiA+PiBpbiBzdGF0ZSBDYWxsIEZvciBBZG9wdGlvbiBCeSBXRyBJc3N1 ZWQgKGVudGVyZWQgYnkgTmV2aWwNCj4+Pj4+PiBCcm93bmxlZSkNCj4+Pj4+PiAgICAgID4gPj4N Cj4+Pj4+PiAgICAgID4gPj4gVGhlIGRvY3VtZW50IGlzIGF2YWlsYWJsZSBhdA0KPj4+Pj4+ICAg ICAgPiA+Pg0KPj4+Pj4+ICAgICAgPg0KPj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXN0cmFzc25lci1zdXBhLWdlbmVyaWMtcG9saWN5LQ0KPj4+Pj4+ICAgICAg PiA+PiBpDQo+Pj4+Pj4gICAgICA+ID4+IG5mby1tb2RlbC8NCj4+Pj4+PiAgICAgID4gPj4NCj4+ Pj4+PiAgICAgID4gPj4NCj4+Pj4+PiAgICAgID4gPj4gQ29tbWVudDoNCj4+Pj4+PiAgICAgID4g Pj4gVGhpcyBpcyB0aGUgZmlyc3Qgb2Ygb3VyIGNoYXJ0ZXIgZG9jdW1lbnRzLCB0aGUgb3RoZXIg DQo+Pj4+Pj4gY2hhcnRlciBpdGVtcw0KPj4+Pj4+ICAgICAgPiA+PiBidWlsZCBvbiB0aGlzDQo+ Pj4+Pj4gICAgICA+ID4+DQo+Pj4+Pj4gICAgICA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gICAgICA+ID4+IFN1cGEgbWFpbGluZyBs aXN0DQo+Pj4+Pj4gICAgICA+ID4+IFN1cGFAaWV0Zi5vcmcgPG1haWx0bzpTdXBhQGlldGYub3Jn Pg0KPj4+Pj4+ICAgICAgPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N1cGENCj4+Pj4+PiAgICAgID4NCj4+Pj4+PiAgICAgID4NCj4+Pj4+PiAgICAgID4gLS0NCj4+ Pj4+PiAgICAgID4NCj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+PiAgICAgID4gICBOZXZpbCBC cm93bmxlZSAgICAgICAgICAgICAgICAgICAgICAgICAgQ29tcHV0ZXIgU2NpZW5jZQ0KPj4+Pj4+ IERlcGFydG1lbnQNCj4+Pj4+PiAgICAgID4gICBQaG9uZTogKzY0IDkgMzczIDc1OTkgeDg4OTQx ICAgICAgICAgICAgIFRoZSBVbml2ZXJzaXR5IG9mDQo+Pj4+Pj4gQXVja2xhbmQNCj4+Pj4+PiAg ICAgID4gICBGQVg6ICs2NCA5IDM3MyA3NDUzICAgUHJpdmF0ZSBCYWcgOTIwMTksIEF1Y2tsYW5k IDExNDIsIE5ldw0KPj4+Pj4+IFplYWxhbmQNCj4+Pj4+PiAgICAgID4NCj4+Pj4+PiAgICAgID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiAg ICAgID4gU3VwYSBtYWlsaW5nIGxpc3QNCj4+Pj4+PiAgICAgID4gU3VwYUBpZXRmLm9yZyA8bWFp bHRvOlN1cGFAaWV0Zi5vcmc+DQo+Pj4+Pj4gICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3VwYQ0KPj4+Pj4+DQo+Pj4+Pj4gICAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+ICAgICAgU3VwYSBtYWlsaW5n IGxpc3QNCj4+Pj4+PiAgICAgIFN1cGFAaWV0Zi5vcmcgPG1haWx0bzpTdXBhQGlldGYub3JnPg0K Pj4+Pj4+ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhDQo+ Pj4+Pj4NCj4+Pj4+PiAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4gICAgICBTdXBhIG1haWxpbmcgbGlzdA0KPj4+Pj4+ICAgICAgU3Vw YUBpZXRmLm9yZyA8bWFpbHRvOlN1cGFAaWV0Zi5vcmc+DQo+Pj4+Pj4gICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+Pj4gU3VwYSBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBTdXBhQGlldGYub3JnDQo+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhDQo+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gU3Vw YSBtYWlsaW5nIGxpc3QNCj4+Pj4+IFN1cGFAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KPj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gU3VwYSBtYWlsaW5nIGxpc3QN Cj4+Pj4gU3VwYUBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3N1cGENCj4+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+IFN1cGEgbWFpbGluZyBsaXN0DQo+Pj4gU3VwYUBpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KPj4+DQo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBTdXBh IG1haWxpbmcgbGlzdA0KPj4+IFN1cGFAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCj4+Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+U3VwYSBtYWlsaW5nIGxpc3QNCj4+U3VwYUBp ZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCg== From nobody Fri Mar 4 12:46:33 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8A61A88A9 for ; Fri, 4 Mar 2016 11:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 YJKoCU-GwIwq for ; Fri, 4 Mar 2016 11:39:32 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A845A1A8896 for ; Fri, 4 Mar 2016 11:39:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31092; q=dns/txt; s=iport; t=1457120371; x=1458329971; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NdIdiIM2AbK4O9+0GRNjOxAowxllxRARdYXnZQEhz2M=; b=KuNvtV4K0c7gOVkBML8GwglHbVyVED+GwMB4HOkeQBwl10jWDuq5Att7 oSBGgn3TAaJH1a9oYQJujEAS7e+cdffe6BTZa2SKA48oAYtkMlHOcOwZb h+4KWIPxde4yk17N1xdxnIgeKHFa4i/Yvzy8Ed/ZplD56xQ5Ox2wG8dAd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtBQAj5NlW/51dJa1aA4JuTFJtBrpCg?= =?us-ascii?q?WkXAQmCPIMyAhyBGzoSAQEBAQEBAWQnhEEBAQEEAQEBIAQGQQQHDAICAgEIEAE?= =?us-ascii?q?DAQEBASAHAwICAhkGBgsUCQgCBAENBRmHdAMSDq8/ijENhEUBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEVBIgBgVF9gjyBTAERASMBBwkKAQwJAgYJgjkrgQ8FkniEKQG?= =?us-ascii?q?LcoF1gWKERIhThwqHRwEnATqDZWoBh3s0fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,537,1449532800"; d="scan'208,217";a="245010278" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2016 19:39:30 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u24JdTMa024610 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Mar 2016 19:39:29 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Mar 2016 13:39:29 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Fri, 4 Mar 2016 13:39:29 -0600 From: "Jason Coleman (colemaj)" To: Zhoutianran , John Strassner Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdcVAt0YFUdFWz068id3T3Yluwp9JJEaAgAAZ2gCAAHF2AA== Date: Fri, 4 Mar 2016 19:39:29 +0000 Message-ID: <32532D43-803C-4F6C-8C3A-410E3CE65A42@cisco.com> References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.70.118] Content-Type: multipart/alternative; boundary="_000_32532D43803C4F6C8C3A410E3CE65A42ciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 04 Mar 2016 12:46:20 -0800 Cc: John Strassner , Juergen Schoenwaelder , Andy Bierman , Nevil Brownlee , "Joel M. Halpern" , SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:39:35 -0000 --_000_32532D43803C4F6C8C3A410E3CE65A42ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcVGV4dCB1c2VkIGluIElFVEYgaXMgbm90IGdvb2QgYXQgZGVzY3JpYmUgSU3igJ0NCg0KV2hp bGUgdGhpcyBtYXkgYmUgdHJ1ZSBmb3IgeW91LCBkbyB5b3UgYmVsaWV2ZSB0aGF0IHRoaXMgaXMg dHJ1ZSBmb3IgZXZlcnlvbmUgdGhhdCBpcyBnb2luZyB0byB3b3JrIG9uIGEgZGF0YSBtb2RlbD8N CkkgdGhpbmsgdGhhdCB5b3UgYXJlIGluIGFncmVlbWVudCB0aGF0IHRoZSBJTSBuZWVkcyB0byBi ZSBkb2N1bWVudGVkLg0KVGhlIHByb2Nlc3MgZm9yIGRvY3VtZW50aW5nIHRoaW5ncyBpbiBJRVRG IGlzIGluIHRleHQuDQoNCllvdSBjb250aW51ZSB0byBtZW50aW9uIHRoZSBsZW5ndGggb2YgdGhl IGRyYWZ0LiAgSWYgeW91IGhhdmUgYSBzcGVjaWZpYyBpc3N1ZSB3aXRoIHRoZSBsZW5ndGgsIHRo ZW4gcGxlYXNlIHJlZmVyZW5jZSB5b3VyIGlzc3VlIHdpdGggdGhlIGxlbmd0aCBvZiB0aGUgZHJh ZnQuDQoNCkhvd2V2ZXIgaXQgYXBwZWFycyB0aGF0IHlvdXIgaXNzdWUgaXMgdGhhdCB5b3Ugd2lz aCB0byBjcmVhdGUgYSBVTUwgYW5kIHVzZSB0aGF0IGFzIGEgcmVmZXJlbmNlIGFsdGhvdWdoIFVN TCBjYW4gbm90IGJlIHBhcnQgb2YgSUVURiBhdCB0aGlzIHRpbWUuICBUaGVyZWZvcmUsIHdoYXQg aXMgdGhlIHBvaW50IG9mIHVzaW5nIFVNTD8NCg0KVU1MIGRvZXMgYSBncmVhdCBqb2Igb2Ygc2hv d2luZyByZWxhdGlvbnNoaXBzLCBidXQgbm9uZSBvZiB0aGUgcmVhc29ucyB3aHkgYSByZWxhdGlv bnNoaXAgZXhpc3RzIGJldHdlZW4gZWxlbWVudHMgaW4gdGhlIFVNTC4gIFRoZSB0ZXh0IHByb3Zp ZGVzIHRoaXMgaW5mb3JtYXRpb24uDQoNCkphc29uDQoNCkZyb206IFN1cGEgPHN1cGEtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFpo b3V0aWFucmFuIDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPG1haWx0bzp6aG91dGlhbnJhbkBodWF3 ZWkuY29tPj4NCkRhdGU6IEZyaWRheSwgTWFyY2ggNCwgMjAxNiBhdCAxMjo1MyBBTQ0KVG86IEpv aG4gU3RyYXNzbmVyIDxzdHJhenBkakBnbWFpbC5jb208bWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNv bT4+DQpDYzogSm9obiBTdHJhc3NuZXIgPEpvaG4uc2MuU3RyYXNzbmVyQGh1YXdlaS5jb208bWFp bHRvOkpvaG4uc2MuU3RyYXNzbmVyQGh1YXdlaS5jb20+PiwgSnVlcmdlbiBTY2hvZW53YWVsZGVy IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2Fl bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+LCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtz LmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4sIE5ldmlsIEJyb3dubGVlIDxuLmJyb3du bGVlQGF1Y2tsYW5kLmFjLm56PG1haWx0bzpuLmJyb3dubGVlQGF1Y2tsYW5kLmFjLm56Pj4sICJK b2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPj4sIFNVUEEgbGlzdCA8c3VwYUBpZXRmLm9yZzxtYWlsdG86c3VwYUBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMg LSBXRyBhZG9waW9uPw0KDQpTZWVuIHlvdXIgdGhpcyBhbmQgbGFzdCBlbWFpbC4NCg0KWW91ciBs b2dpYyBpczogdGhpcyBpcyBJRVRGLCBzbyB0ZXh0IGlzIG9tbmlwb3RlbnQsIHNvIHlvdSB1c2Ug dGV4dCB0byBkZXNjcmliZSBJTSB3aXRoIDEwMCsgcGFnZXMgZG9jdW1lbnQgZm9yIGludGVyb3Bl cmF0aW9uLCBhbmQgdGhlbiBnZW5lcmF0ZSBVTUxzLCBhbmQgZmluYWxseSB1c2UgVU1MLT5ZQU5H IHRvb2wgdG8gZ2VuZXJhdGUgZGF0YSBtb2RlbC4NCg0KTXkgc3VnZ2VzdGlvbiBpczogVGV4dCB1 c2VkIGluIElFVEYgaXMgbm90IGdvb2QgYXQgZGVzY3JpYmUgSU0sIHNvIHdlIHVzZSBVTUwgZm9y IGludGVyb3BlcmF0aW9uKGJ1dCBVTUwgb3V0cHV0IG5vdCBxdWFsaWZpZXMgUkZDKSwgYW5kIHRo ZW4gZ2VuZXJhdGUgRE0uDQoNCkFtIEkgbWlzcyB5b3VyIHBvaW50PyBXaGljaCBvbmUgaXMgZWFz aWVyIHRvIGltcGxlbWVudD8NCg0KDQpUaWFucmFuDQoNCkZyb206IEpvaG4gU3RyYXNzbmVyIFtt YWlsdG86c3RyYXpwZGpAZ21haWwuY29tXQ0KU2VudDogRnJpZGF5LCBNYXJjaCAwNCwgMjAxNiAx OjIxIFBNDQpUbzogWmhvdXRpYW5yYW47IEpvaG4gU3RyYXNzbmVyDQpDYzogSm9obiBTdHJhc3Nu ZXI7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgSm9lbCBNLiBIYWxwZXJuOyBOZXZpbCBCcm93bmxl ZTsgQW5keSBCaWVybWFuOyBTVVBBIGxpc3QNClN1YmplY3Q6IFJlOiBbU3VwYV0gSW5mb3JtYXRp b24gbW9kZWxzIGFuZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/DQoNCkFjdHVhbGx5LCB5b3Ug YXJlIG1pc3NpbmcgbXkgcG9pbnQuIEl0J3MgYWJvdXQgbW9kZWwtZHJpdmVuIHNvZnR3YXJlLg0K VGhpcyBpcyBub3QgdGhlIE9NRywgaXQgaXMgdGhlIElFVEYuIFRleHQgaXMgb3VyIGZyaWVuZC4g V2UgbmVlZCBhDQp0ZXh0IGRvY3VtZW50IHRvIGVzdGFibGlzaCBXRyB0cmFjZWFiaWxpdHkgZm9y IHRoZSBkYXRhIG1vZGVsLg0KDQpJbiBhZGRpdGlvbiwgc2VlIG15IGxhc3QgcmVzcG9uc2UuDQoN Cg0KT24gVGh1LCBNYXIgMywgMjAxNiBhdCA3OjIzIFBNLCBaaG91dGlhbnJhbiA8emhvdXRpYW5y YW5AaHVhd2VpLmNvbTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KSSB0 aGluayB5b3UgbWlzcyBteSBwb2ludC4NCg0KSSBhbSBub3QgYWdhaW5zdCBJTS4gQnV0IGFzIGFu IGludGVybWVkaWFyeSBzdGF0ZSwgSSB0aGluayBJTSBubyBuZWVkIHRvIGJlIGRlbGl2ZXJlZCBh cyBhbiBSRkMuDQoNCkFuZCBJIGRvIG5vdCB0aGluayB0ZXh0IGRvY3VtZW50IGlzIHRoZSBiZXN0 IHRvb2wgZm9yIHRoZSBJTSwgd2hpbGUgaW4gbWFueSBvdGhlciBvcmdhbml6YXRpb25zLCB0aGV5 IHVzZSBVTUwuDQoNCllvdSBoYXZlIGEgMTAwKyBwYWdlcyBkcmFmdCwgYnV0IGxhcmdlIGNvbnRl bnQganVzdCByZXBlYXQgdGhlIGJhc2ljIFVNTCBhbmQgT08gY29uY2VwdCwgbGlrZSB0aGUgaW5o ZXJpdCwgYWdncmVnYXRpb24sIHN1YmNsYXNzLi4uDQoNCg0KVGlhbnJhbg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvaG4gU3RyYXNzbmVyDQo+IFNlbnQ6IEZyaWRh eSwgTWFyY2ggMDQsIDIwMTYgMTo0NiBBTQ0KPiBUbzogWmhvdXRpYW5yYW47IEp1ZXJnZW4gU2No b2Vud2FlbGRlcjsgSm9lbCBNLiBIYWxwZXJuDQo+IENjOiBOZXZpbCBCcm93bmxlZTsgQW5keSBC aWVybWFuOyBTVVBBIGxpc3Q7IHN0cmF6cGRqQGdtYWlsLmNvbTxtYWlsdG86c3RyYXpwZGpAZ21h aWwuY29tPg0KPiBTdWJqZWN0OiBSRTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0 YSBtb2RlbHMgLSBXRyBhZG9waW9uPw0KPg0KPiBJdCBpcyBhY3R1YWxseSBtb3JlIGxpa2UgdGhl IFYtbW9kZWwgdGhhbiBhIHNwaXJhbCBtb2RlbCAtIHRoZSBzcGlyYWwgbW9kZWwNCj4gaXMgcmlz ay1kcml2ZW4uDQo+DQo+IFRoZSBwb2ludCBvZiBtb2RlbC1kcml2ZW4gc29mdHdhcmUgaXMgdG8g dXNlIHRoZSBpbmZvIG1vZGVsIGFzIHRoZSBzb3VyY2UNCj4gdGhhdCB0aWVzIGV2ZXJ5dGhpbmcg dG9nZXRoZXIsIGluY2x1ZGluZyByZXF1aXJlbWVudHMsIGRvY3VtZW50YXRpb24sIHRlc3QsDQo+ IGFuZCBpbXBsZW1lbnRhdGlvbi4gWW91IHNlZW0gdG8gYmUgYWR2b2NhdGluZyBib3R0b20tdXAg ZGF0YSBtb2RlbHMsIHdoaWNoDQo+IHByb2R1Y2VzIHNlcGFyYXRlIHNpbG9zIG9mIHNvZnR3YXJl Lg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdXBhIFttYWls dG86c3VwYS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgWmhvdXRpYW5yYW4NCj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAwMiwgMjAx NiA4OjAxIFBNDQo+IFRvOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IEpvZWwgTS4gSGFscGVybg0K PiBDYzogTmV2aWwgQnJvd25sZWU7IEFuZHkgQmllcm1hbjsgU1VQQSBsaXN0DQo+IFN1YmplY3Q6 IFJlOiBbU3VwYV0gSW5mb3JtYXRpb24gbW9kZWxzIGFuZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bp b24/DQo+DQo+DQo+IEhpIEp1ZXJnZW4sDQo+DQo+IEVtbW0sIHRoZSByb3VuZCB0cmlwIHlvdSBt ZW50aW9uZWQgbXVjaCBsaWtlIHRoZSBzcGlyYWwgbW9kZWwgaW4gc29mdHdhcmUNCj4gZW5naW5l ZXJpbmcuIFRoYXQncyBvZiBjb3Vyc2UgYSBnb29kIHdheSB0byBkbyBzeXN0ZW0gZGVzaWduIGFu ZA0KPiBpbXBsZW1lbnRhdGlvbi4NCj4NCj4gSG93ZXZlciwgaW4gdGhpcyBwcm9jZXNzLCB0aGUg aW5mb3JtYXRpb24gbW9kZWwgaXMgbGlrZSBhbiBpbnRlcm1lZGlhcnkNCj4gc3RhdGUsIGJ1dCBu b3QgdGhlIGZpbmFsIG91dHB1dCAoUkZDKSB3ZSBuZWVkLg0KPiBJIG1lYW4sIGV2ZW4gaWYgd2Ug ZG8gbm90IGhhdmUgYSBJTSBSRkMsIHdlIGNhbiBhbHdheXMgaGF2ZSBhIHNjcmF0Y2ggb3INCj4g VU1MIGRyYXdpbmcgc2hhcmVkIGR1cmluZyB0aGUgRE0gZGVzaWduLiBBbmQgdGhvc2UgbWFrZSBs aWZlIHNpbXBsZXIgZm9yDQo+IGV4cHJlc3MgaW50ZW50IGFuZCBpZGVhLCBhbmQgZm9yIGludGVy b3BlcmF0aW9uLg0KPg0KPiBBIGRvY3VtZW50IHdpdGggbW9yZSB0aGFuIDEwMCBwYWdlcyBqdXN0 IG1ha2UgYWxsIHRoZSB0aGluZ3MgY29tcGxleC4gVGhhdCdzDQo+IG15IGh1bWJsZSBvcGluaW9u Lg0KPg0KPiBUaWFucmFuDQo+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBG cm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gPiBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBq YWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJz aXR5LmRlPl0NCj4gPiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDAyLCAyMDE2IDI6NDUgUE0NCj4g PiBUbzogSm9lbCBNLiBIYWxwZXJuDQo+ID4gQ2M6IEFuZHkgQmllcm1hbjsgTmV2aWwgQnJvd25s ZWU7IFpob3V0aWFucmFuOyBTVVBBIGxpc3QNCj4gPiBTdWJqZWN0OiBSZTogW1N1cGFdIEluZm9y bWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBXRyBhZG9waW9uPw0KPiA+DQo+ID4gT24g V2VkLCBNYXIgMDIsIDIwMTYgYXQgMTI6MDk6NThBTSAtMDUwMCwgSm9lbCBNLiBIYWxwZXJuIHdy b3RlOg0KPiA+DQo+ID4gPiBGaXJzdCwgdGhlIGVudGlyZSBpbmZvcm1hdGlvbiBtb2RlbCB3aWxs IGJlIHJlbmRlcmVkIGludG9hIFlBTkcgZGF0YQ0KPiBtb2RlbC4NCj4gPiA+IFRoZSBhZHZhbnRh Z2Ugb2YgZGlzY3Vzc2luZyB0aGUgaW5mb3JtYXRpb24gbW9kZWwgaXMgdGhhdCB3ZSBjYW4NCj4g PiA+IG1ha2Ugc3VyZSB0aGUgaW5mb3JtYXRpb24gYW5kIHJlbGF0aW9uc2hpcHMgYXJlIHJpZ2h0 IGJlZm9yZSBkb2luZw0KPiA+ID4gdGhlIHdvcmsgb2YgZ2V0dGluZyB0aGUgWUFORyBzeW50YXgg cmlnaHQuDQo+ID4NCj4gPiBNeSBleHBlcmllbmNlIGlzIHRoYXQgeW91IHVzdWFsbHkgb25seSBr bm93IHdoZXRoZXIgdGhlIGluZm9ybWF0aW9uDQo+ID4gbW9kZWwgaXMgcmVhc29uYWJseSBjb21w bGV0ZSBhbmQgY2xlYXIgaWYgeW91IGhhdmUgZG9uZSB0aGUgd2hvbGUNCj4gPiByb3VuZC10cmlw IGF0IGxlYXN0IG9uY2UsIHRoYXQgaXMgeW91IGhhdmUgZG9uZToNCj4gPg0KPiA+IGluZm8gbW9k ZWwgLT4gZGF0YSBtb2RlbCAtPiBpbXBsZW1lbnRhdGlvbiAtPiBkYXRhIG1vZGVsIHVwZGF0ZXMg LT4NCj4gPiBpbmZvcm1hdGlvbiBtb2RlbCB1cGRhdGVzDQo+ID4NCj4gPiBBIHB1cmUgdG9wLWRv d24gYXBwcm9hY2ggd2lsbCBsZWF2ZSB5b3Ugd2l0aCBhbiBpbmZvIG1vZGVsIHdoaWNoIG9ubHkN Cj4gPiBwYXJ0aWFsbHkgZGVzY3JpYmVzIHdoYXQgaGFwcGVucyBpbiBhIGRhdGEgbW9kZWwuIE5v dywgdGhpcyBtaWdodCBiZQ0KPiA+IGZpbmUsIGRlcGVuZGluZyBvbiBfd2h5XyB5b3UgZGVmaW5l IGFuIGluZm8gbW9kZWwuIElmIHlvdSBkbyB0aGUgaW5mbw0KPiA+IG1vZGVsIGJlY2F1c2UgeW91 IGV4cGVjdCBpbnRlcm9wZXJhYmlsaXR5IGJhc2VkIG9uIHRoZSBpbmZvIG1vZGVsLA0KPiA+IHRo ZW4gSSBiZWxpZXZlIGEgZnVsbCByb3VuZC10cmlwIGlzIG5lY2Vzc2FyeSB0byBnZXQgdGhlIGlu Zm8gbW9kZWwNCj4gPiByZWFzb25hYmx5IHByZWNpc2UuIElmIHlvdSBkbyB0aGUgaW5mbyBtb2Rl bCBiZWNhdXNlIHlvdSBoYXZlIG5vIGNsdWUNCj4gPiBvciBhZ3JlZW1lbnQgaG93IHRvIHdyaXRl IGEgZGF0YSBtb2RlbCwgdGhlbiBpdCBpcyBmaW5lIHRvIGJlIHByZXBhcmVkDQo+ID4gdG8gZGl2 ZXJnZSBmcm9tIHRoZSBpbmZvIG1vZGVsIHVwIHRvIHRoZSBwb2ludCB0aGF0IGl0IGlzIG5vdCBp bXBvcnRhbnQNCj4gYW55bW9yZSBmb3IgaW50ZXJvcGVyYWJpbGl0eS4NCj4gPg0KPiA+IFNvIHRo ZSBrZXkgcXVlc3Rpb24gZm9yIG1lIGlzIHdoaWNoIGZ1bmN0aW9uIHRoZSBpbmZvIG1vZGVsIGlz DQo+ID4gc3VwcG9zZWQgdG8gZnVsZmlsbC4NCj4gPg0KPiA+IC9qcw0KPiA+DQo+ID4gLS0NCj4g PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1l biBnR21iSA0KPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcg MSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAg ICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU3VwYSBtYWlsaW5nIGxp c3QNCj4gU3VwYUBpZXRmLm9yZzxtYWlsdG86U3VwYUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhDQoNCg0KDQotLQ0KcmVnYXJkcywNCkpvaG4N Cg== --_000_32532D43803C4F6C8C3A410E3CE65A42ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <50EA4B8D6CDB3A4EA170167E5C09A804@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48Zm9udCBm YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPuKAnDwvZm9udD48Zm9udCBjb2xvcj0iIzFmNDk3ZCIg ZmFjZT0iQ291cmllciBOZXciPlRleHQmbmJzcDs8L2ZvbnQ+PHNwYW4gc3R5bGU9ImNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPnVzZWQgaW4gSUVU RiBpcyBub3QgZ29vZCBhdCBkZXNjcmliZSBJTTwvc3Bhbj48Zm9udCBjb2xvcj0iIzFmNDk3ZCIg ZmFjZT0iQ291cmllciBOZXciPuKAnTwvZm9udD48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPjxicj4N Cjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJk OyI+PGZvbnQgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNvdXJpZXIgTmV3Ij5XaGlsZSB0aGlzIG1h eSBiZSB0cnVlIGZvciB5b3UsIGRvIHlvdSBiZWxpZXZlIHRoYXQgdGhpcyBpcyB0cnVlIGZvciBl dmVyeW9uZSZuYnNwO3RoYXQgaXMmbmJzcDtnb2luZyB0byB3b3JrIG9uIGEgZGF0YSBtb2RlbD88 L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsi Pjxmb250IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDb3VyaWVyIE5ldyI+SSB0aGluayB0aGF0IHlv dSBhcmUgaW4gYWdyZWVtZW50IHRoYXQgdGhlIElNIG5lZWRzIHRvIGJlIGRvY3VtZW50ZWQuPC9m b250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48 Zm9udCBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ291cmllciBOZXciPlRoZSBwcm9jZXNzIGZvciBk b2N1bWVudGluZyB0aGluZ3MgaW4gSUVURiBpcyBpbiB0ZXh0LjwvZm9udD48L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGZvbnQgY29sb3I9IiMxZjQ5 N2QiIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxmb250IGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDb3VyaWVyIE5ldyI+WW91IGNvbnRpbnVlIHRvIG1lbnRpb24gdGhlIGxlbmd0aCBvZiB0aGUg ZHJhZnQuICZuYnNwO0lmIHlvdSBoYXZlIGEgc3BlY2lmaWMgaXNzdWUgd2l0aCB0aGUgbGVuZ3Ro LCB0aGVuIHBsZWFzZSByZWZlcmVuY2UgeW91ciBpc3N1ZSB3aXRoIHRoZSBsZW5ndGggb2YgdGhl IGRyYWZ0LiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Vi a2l0LXN0YW5kYXJkOyI+PGZvbnQgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNvdXJpZXIgTmV3Ij48 YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFu ZGFyZDsiPjxmb250IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDb3VyaWVyIE5ldyI+SG93ZXZlciBp dCBhcHBlYXJzIHRoYXQgeW91ciBpc3N1ZSBpcyB0aGF0IHlvdSB3aXNoIHRvIGNyZWF0ZSBhIFVN TCBhbmQgdXNlIHRoYXQgYXMgYSByZWZlcmVuY2UgYWx0aG91Z2ggVU1MIGNhbiBub3QgYmUgcGFy dCBvZiBJRVRGIGF0IHRoaXMgdGltZS4gJm5ic3A7VGhlcmVmb3JlLCB3aGF0IGlzIHRoZSBwb2lu dA0KIG9mIHVzaW5nIFVNTD88L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog LXdlYmtpdC1zdGFuZGFyZDsiPjxmb250IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDb3VyaWVyIE5l dyI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQt c3RhbmRhcmQ7Ij48Zm9udCBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ291cmllciBOZXciPlVNTCBk b2VzIGEgZ3JlYXQgam9iIG9mIHNob3dpbmcgcmVsYXRpb25zaGlwcywgYnV0IG5vbmUgb2YgdGhl IHJlYXNvbnMgd2h5IGEgcmVsYXRpb25zaGlwIGV4aXN0cyBiZXR3ZWVuIGVsZW1lbnRzIGluIHRo ZSBVTUwuICZuYnNwO1RoZSB0ZXh0IHByb3ZpZGVzIHRoaXMgaW5mb3JtYXRpb24uJm5ic3A7PC9m b250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iIj4NCjxkaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pkphc29uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRl eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+U3VwYSAmbHQ7PGEgaHJlZj0ibWFp bHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZyI+c3VwYS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg b24gYmVoYWxmIG9mIFpob3V0aWFucmFuICZsdDs8YSBocmVmPSJtYWlsdG86emhvdXRpYW5yYW5A aHVhd2VpLmNvbSI+emhvdXRpYW5yYW5AaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXksIE1hcmNoIDQsIDIwMTYg YXQgMTI6NTMgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh bj5Kb2huIFN0cmFzc25lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbSI+ c3RyYXpwZGpAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+Q2M6IDwvc3Bhbj5Kb2huIFN0cmFzc25lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOkpvaG4u c2MuU3RyYXNzbmVyQGh1YXdlaS5jb20iPkpvaG4uc2MuU3RyYXNzbmVyQGh1YXdlaS5jb208L2E+ Jmd0OywgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53 YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIj5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl cnNpdHkuZGU8L2E+Jmd0OywNCiBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5 QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7LCBOZXZpbCBCcm93bmxl ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm4uYnJvd25sZWVAYXVja2xhbmQuYWMubnoiPm4uYnJvd25s ZWVAYXVja2xhbmQuYWMubno8L2E+Jmd0OywgJnF1b3Q7Sm9lbCBNLiBIYWxwZXJuJnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNv bTwvYT4mZ3Q7LCBTVVBBIGxpc3QNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cGFAaWV0Zi5vcmci PnN1cGFAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5TdWJqZWN0OiA8L3NwYW4+UmU6IFtTdXBhXSBJbmZvcm1hdGlvbiBtb2RlbHMgYW5kIERhdGEg bW9kZWxzIC0gV0cgYWRvcGlvbj88YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JF Qy1odG1sNDAiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29y ZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9u cyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgi Ow0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTrmlrDlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgOSAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOaWsOWui+S9 kyI7DQoJcGFub3NlLTE6MiAxIDYgOSAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGxhbmc9IlpI LUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+U2VlbiB5b3VyIHRoaXMgYW5kIGxhc3QgZW1haWwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3VyIGxvZ2ljIGlzOiB0aGlzIGlz IElFVEYsIHNvIHRleHQgaXMgb21uaXBvdGVudCwgc28geW91IHVzZSB0ZXh0IHRvIGRlc2NyaWJl IElNIHdpdGggMTAwJiM0MzsgcGFnZXMgZG9jdW1lbnQgZm9yIGludGVyb3BlcmF0aW9uLCBhbmQg dGhlbiBnZW5lcmF0ZSBVTUxzLA0KIGFuZCBmaW5hbGx5IHVzZSBVTUwtJmd0O1lBTkcgdG9vbCB0 byBnZW5lcmF0ZSBkYXRhIG1vZGVsLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IHN1Z2dlc3Rpb24gaXM6IFRleHQgdXNlZCBpbiBJRVRG IGlzIG5vdCBnb29kIGF0IGRlc2NyaWJlIElNLCBzbyB3ZSB1c2UgVU1MIGZvciBpbnRlcm9wZXJh dGlvbihidXQgVU1MIG91dHB1dCBub3QgcXVhbGlmaWVzIFJGQyksIGFuZCB0aGVuIGdlbmVyYXRl IERNLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QW0gSSBtaXNzIHlvdXIgcG9pbnQ/IFdoaWNoIG9uZSBpcyBlYXNpZXIgdG8gaW1wbGVtZW50 PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRpYW5yYW48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJp ZjsiPiBKb2huIFN0cmFzc25lciBbPGEgaHJlZj0ibWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbSI+ bWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBNYXJjaCAwNCwgMjAxNiAxOjIxIFBNPGJyPg0KPGI+VG86PC9iPiBaaG91dGlhbnJhbjsgSm9o biBTdHJhc3NuZXI8YnI+DQo8Yj5DYzo8L2I+IEpvaG4gU3RyYXNzbmVyOyBKdWVyZ2VuIFNjaG9l bndhZWxkZXI7IEpvZWwgTS4gSGFscGVybjsgTmV2aWwgQnJvd25sZWU7IEFuZHkgQmllcm1hbjsg U1VQQSBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU3VwYV0gSW5mb3JtYXRpb24gbW9k ZWxzIGFuZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BY3R1YWxseSwgeW91IGFyZSBtaXNzaW5nIG15IHBv aW50LiBJdCdzIGFib3V0IG1vZGVsLWRyaXZlbiBzb2Z0d2FyZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+VGhpcyBpcyBub3QgdGhlIE9NRywgaXQgaXMgdGhlIElFVEYuIFRleHQgaXMgb3VyIGZyaWVu ZC4gV2UgbmVlZCBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRleHQgZG9jdW1lbnQgdG8gZXN0YWJs aXNoIFdHIHRyYWNlYWJpbGl0eSBmb3IgdGhlIGRhdGEgbW9kZWwuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBhZGRpdGlvbiwgc2VlIG15IGxhc3Qg cmVzcG9uc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBNYXIgMywgMjAxNiBhdCA3OjIz IFBNLCBaaG91dGlhbnJhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5j b20iIHRhcmdldD0iX2JsYW5rIj56aG91dGlhbnJhbkBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkkgdGhpbmsgeW91IG1pc3MgbXkgcG9pbnQuPGJyPg0KPGJyPg0KSSBhbSBub3QgYWdh aW5zdCBJTS4gQnV0IGFzIGFuIGludGVybWVkaWFyeSBzdGF0ZSwgSSB0aGluayBJTSBubyBuZWVk IHRvIGJlIGRlbGl2ZXJlZCBhcyBhbiBSRkMuPGJyPg0KPGJyPg0KQW5kIEkgZG8gbm90IHRoaW5r IHRleHQgZG9jdW1lbnQgaXMgdGhlIGJlc3QgdG9vbCBmb3IgdGhlIElNLCB3aGlsZSBpbiBtYW55 IG90aGVyIG9yZ2FuaXphdGlvbnMsIHRoZXkgdXNlIFVNTC48YnI+DQo8YnI+DQpZb3UgaGF2ZSBh IDEwMCYjNDM7IHBhZ2VzIGRyYWZ0LCBidXQgbGFyZ2UgY29udGVudCBqdXN0IHJlcGVhdCB0aGUg YmFzaWMgVU1MIGFuZCBPTyBjb25jZXB0LCBsaWtlIHRoZSBpbmhlcml0LCBhZ2dyZWdhdGlvbiwg c3ViY2xhc3MuLi48YnI+DQo8YnI+DQo8YnI+DQpUaWFucmFuPGJyPg0KPGJyPg0KJmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogSm9obiBTdHJhc3NuZXI8YnI+ DQomZ3Q7IFNlbnQ6IEZyaWRheSwgTWFyY2ggMDQsIDIwMTYgMTo0NiBBTTxicj4NCiZndDsgVG86 IFpob3V0aWFucmFuOyBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IEpvZWwgTS4gSGFscGVybjxicj4N CiZndDsgQ2M6IE5ldmlsIEJyb3dubGVlOyBBbmR5IEJpZXJtYW47IFNVUEEgbGlzdDsgPGEgaHJl Zj0ibWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbSI+DQpzdHJhenBkakBnbWFpbC5jb208L2E+PGJy Pg0KJmd0OyBTdWJqZWN0OiBSRTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBt b2RlbHMgLSBXRyBhZG9waW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7IEl0IGlzIGFjdHVhbGx5IG1v cmUgbGlrZSB0aGUgVi1tb2RlbCB0aGFuIGEgc3BpcmFsIG1vZGVsIC0gdGhlIHNwaXJhbCBtb2Rl bDxicj4NCiZndDsgaXMgcmlzay1kcml2ZW4uPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIHBvaW50 IG9mIG1vZGVsLWRyaXZlbiBzb2Z0d2FyZSBpcyB0byB1c2UgdGhlIGluZm8gbW9kZWwgYXMgdGhl IHNvdXJjZTxicj4NCiZndDsgdGhhdCB0aWVzIGV2ZXJ5dGhpbmcgdG9nZXRoZXIsIGluY2x1ZGlu ZyByZXF1aXJlbWVudHMsIGRvY3VtZW50YXRpb24sIHRlc3QsPGJyPg0KJmd0OyBhbmQgaW1wbGVt ZW50YXRpb24uIFlvdSBzZWVtIHRvIGJlIGFkdm9jYXRpbmcgYm90dG9tLXVwIGRhdGEgbW9kZWxz LCB3aGljaDxicj4NCiZndDsgcHJvZHVjZXMgc2VwYXJhdGUgc2lsb3Mgb2Ygc29mdHdhcmUuPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyBGcm9tOiBTdXBhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnN1cGEtYm91bmNlc0Bp ZXRmLm9yZyI+c3VwYS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFpob3V0aWFu cmFuPGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDAyLCAyMDE2IDg6MDEgUE08YnI+ DQomZ3Q7IFRvOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IEpvZWwgTS4gSGFscGVybjxicj4NCiZn dDsgQ2M6IE5ldmlsIEJyb3dubGVlOyBBbmR5IEJpZXJtYW47IFNVUEEgbGlzdDxicj4NCiZndDsg U3ViamVjdDogUmU6IFtTdXBhXSBJbmZvcm1hdGlvbiBtb2RlbHMgYW5kIERhdGEgbW9kZWxzIC0g V0cgYWRvcGlvbj88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgSnVlcmdlbiw8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBFbW1tLCB0aGUgcm91bmQgdHJpcCB5b3UgbWVudGlvbmVkIG11Y2gg bGlrZSB0aGUgc3BpcmFsIG1vZGVsIGluIHNvZnR3YXJlPGJyPg0KJmd0OyBlbmdpbmVlcmluZy4g VGhhdCdzIG9mIGNvdXJzZSBhIGdvb2Qgd2F5IHRvIGRvIHN5c3RlbSBkZXNpZ24gYW5kPGJyPg0K Jmd0OyBpbXBsZW1lbnRhdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBIb3dldmVyLCBpbiB0aGlz IHByb2Nlc3MsIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBpcyBsaWtlIGFuIGludGVybWVkaWFyeTxi cj4NCiZndDsgc3RhdGUsIGJ1dCBub3QgdGhlIGZpbmFsIG91dHB1dCAoUkZDKSB3ZSBuZWVkLjxi cj4NCiZndDsgSSBtZWFuLCBldmVuIGlmIHdlIGRvIG5vdCBoYXZlIGEgSU0gUkZDLCB3ZSBjYW4g YWx3YXlzIGhhdmUgYSBzY3JhdGNoIG9yPGJyPg0KJmd0OyBVTUwgZHJhd2luZyBzaGFyZWQgZHVy aW5nIHRoZSBETSBkZXNpZ24uIEFuZCB0aG9zZSBtYWtlIGxpZmUgc2ltcGxlciBmb3I8YnI+DQom Z3Q7IGV4cHJlc3MgaW50ZW50IGFuZCBpZGVhLCBhbmQgZm9yIGludGVyb3BlcmF0aW9uLjxicj4N CiZndDs8YnI+DQomZ3Q7IEEgZG9jdW1lbnQgd2l0aCBtb3JlIHRoYW4gMTAwIHBhZ2VzIGp1c3Qg bWFrZSBhbGwgdGhlIHRoaW5ncyBjb21wbGV4LiBUaGF0J3M8YnI+DQomZ3Q7IG15IGh1bWJsZSBv cGluaW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRpYW5yYW48YnI+DQomZ3Q7PGJyPg0KJmd0OyAm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IEp1ZXJn ZW4gU2Nob2Vud2FlbGRlcjxicj4NCiZndDsgJmd0OyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiPmouc2Nob2Vud2FlbGRlckBqYWNv YnMtdW5pdmVyc2l0eS5kZTwvYT5dPGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgTWFy Y2ggMDIsIDIwMTYgMjo0NSBQTTxicj4NCiZndDsgJmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuPGJy Pg0KJmd0OyAmZ3Q7IENjOiBBbmR5IEJpZXJtYW47IE5ldmlsIEJyb3dubGVlOyBaaG91dGlhbnJh bjsgU1VQQSBsaXN0PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbU3VwYV0gSW5mb3JtYXRp b24gbW9kZWxzIGFuZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IE9uIFdlZCwgTWFyIDAyLCAyMDE2IGF0IDEyOjA5OjU4QU0gLTA1MDAsIEpv ZWwgTS4gSGFscGVybiB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBG aXJzdCwgdGhlIGVudGlyZSBpbmZvcm1hdGlvbiBtb2RlbCB3aWxsIGJlIHJlbmRlcmVkIGludG9h IFlBTkcgZGF0YTxicj4NCiZndDsgbW9kZWwuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIGFkdmFu dGFnZSBvZiBkaXNjdXNzaW5nIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBpcyB0aGF0IHdlIGNhbjxi cj4NCiZndDsgJmd0OyAmZ3Q7IG1ha2Ugc3VyZSB0aGUgaW5mb3JtYXRpb24gYW5kIHJlbGF0aW9u c2hpcHMgYXJlIHJpZ2h0IGJlZm9yZSBkb2luZzxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSB3b3Jr IG9mIGdldHRpbmcgdGhlIFlBTkcgc3ludGF4IHJpZ2h0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBNeSBleHBlcmllbmNlIGlzIHRoYXQgeW91IHVzdWFsbHkgb25seSBrbm93IHdoZXRo ZXIgdGhlIGluZm9ybWF0aW9uPGJyPg0KJmd0OyAmZ3Q7IG1vZGVsIGlzIHJlYXNvbmFibHkgY29t cGxldGUgYW5kIGNsZWFyIGlmIHlvdSBoYXZlIGRvbmUgdGhlIHdob2xlPGJyPg0KJmd0OyAmZ3Q7 IHJvdW5kLXRyaXAgYXQgbGVhc3Qgb25jZSwgdGhhdCBpcyB5b3UgaGF2ZSBkb25lOjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBpbmZvIG1vZGVsIC0mZ3Q7IGRhdGEgbW9kZWwgLSZndDsg aW1wbGVtZW50YXRpb24gLSZndDsgZGF0YSBtb2RlbCB1cGRhdGVzIC0mZ3Q7PGJyPg0KJmd0OyAm Z3Q7IGluZm9ybWF0aW9uIG1vZGVsIHVwZGF0ZXM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgQSBwdXJlIHRvcC1kb3duIGFwcHJvYWNoIHdpbGwgbGVhdmUgeW91IHdpdGggYW4gaW5mbyBt b2RlbCB3aGljaCBvbmx5PGJyPg0KJmd0OyAmZ3Q7IHBhcnRpYWxseSBkZXNjcmliZXMgd2hhdCBo YXBwZW5zIGluIGEgZGF0YSBtb2RlbC4gTm93LCB0aGlzIG1pZ2h0IGJlPGJyPg0KJmd0OyAmZ3Q7 IGZpbmUsIGRlcGVuZGluZyBvbiBfd2h5XyB5b3UgZGVmaW5lIGFuIGluZm8gbW9kZWwuIElmIHlv dSBkbyB0aGUgaW5mbzxicj4NCiZndDsgJmd0OyBtb2RlbCBiZWNhdXNlIHlvdSBleHBlY3QgaW50 ZXJvcGVyYWJpbGl0eSBiYXNlZCBvbiB0aGUgaW5mbyBtb2RlbCw8YnI+DQomZ3Q7ICZndDsgdGhl biBJIGJlbGlldmUgYSBmdWxsIHJvdW5kLXRyaXAgaXMgbmVjZXNzYXJ5IHRvIGdldCB0aGUgaW5m byBtb2RlbDxicj4NCiZndDsgJmd0OyByZWFzb25hYmx5IHByZWNpc2UuIElmIHlvdSBkbyB0aGUg aW5mbyBtb2RlbCBiZWNhdXNlIHlvdSBoYXZlIG5vIGNsdWU8YnI+DQomZ3Q7ICZndDsgb3IgYWdy ZWVtZW50IGhvdyB0byB3cml0ZSBhIGRhdGEgbW9kZWwsIHRoZW4gaXQgaXMgZmluZSB0byBiZSBw cmVwYXJlZDxicj4NCiZndDsgJmd0OyB0byBkaXZlcmdlIGZyb20gdGhlIGluZm8gbW9kZWwgdXAg dG8gdGhlIHBvaW50IHRoYXQgaXQgaXMgbm90IGltcG9ydGFudDxicj4NCiZndDsgYW55bW9yZSBm b3IgaW50ZXJvcGVyYWJpbGl0eS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgU28gdGhl IGtleSBxdWVzdGlvbiBmb3IgbWUgaXMgd2hpY2ggZnVuY3Rpb24gdGhlIGluZm8gbW9kZWwgaXM8 YnI+DQomZ3Q7ICZndDsgc3VwcG9zZWQgdG8gZnVsZmlsbC48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgL2pzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tPGJyPg0KJmd0OyAm Z3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7SmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPGJyPg0KJmd0OyAmZ3Q7IFBo b25lOiAmIzQzOzQ5IDQyMSAyMDAgMzU4NyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueTxicj4NCiZndDsgJmd0OyBG YXg6Jm5ic3A7ICZuYnNwOyYjNDM7NDkgNDIxIDIwMCAzMTAzJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRl LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgU3VwYSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhy ZWY9Im1haWx0bzpTdXBhQGlldGYub3JnIj5TdXBhQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPnJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkpvaG48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_32532D43803C4F6C8C3A410E3CE65A42ciscocom_-- From nobody Sun Mar 6 13:42:09 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14241B3A5F for ; Sun, 6 Mar 2016 13:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 hUcxY25cFGJS for ; Sun, 6 Mar 2016 13:42:05 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9B61B3A57 for ; Sun, 6 Mar 2016 13:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1457300525; x=1488836525; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4KaJ661fBibHBtJ5lFsuYd0RhcfDWIr5p9HxnvkF+AY=; b=cBmSeWikfj1as95OhJx1YXuuuHQVSwtFBZpCPUuJt9CRZojcuWCTwWSf P6QAs41BBJIGz2L4xzWtTzvkAswnyPLDvh0OVD9qFiOmOHjAOWB3Kjeti Ev/5SXmMo7MxYKF5IT52UakWebboXd8GwM6XuzFecZ5BFOdlnCq66+9Wd 7v9blJiuWIah9uJP1YHK1SL6PNCuBv9b2L3dx+YK6I4v91AaJhfH3Iovi HGpe/OFsHcutfO78hf+9KhMC6wAGz6jAV4qMzdsv2FFCSejjq6DgDJZyp bjPSmJqjs2dX+9Y+457ixrgCaF6DkX9CDMMpkozJqnNZaimNkcitzWuFA w==; X-IronPort-AV: E=Sophos;i="5.22,547,1449486000"; d="scan'208";a="72227956" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.7 - Outgoing - Outgoing-SSL Received: from sc-cs-316051.uoa.auckland.ac.nz (HELO [130.216.38.7]) ([130.216.38.7]) by mx4-int.auckland.ac.nz with ESMTP; 07 Mar 2016 10:42:01 +1300 To: Zhoutianran , "Joel M. Halpern" , John Strassner , Juergen Schoenwaelder References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D675A6.5010409@joelhalpern.com> <20160302064505.GA30528@elstar.local> <56D9011B.50803@joelhalpern.com> From: Nevil Brownlee Message-ID: <56DCA428.8010509@auckland.ac.nz> Date: Mon, 7 Mar 2016 10:42:00 +1300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Andy Bierman , SUPA list , "strazpdj@gmail.com" Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 21:42:07 -0000 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 supa-chairs@ietf.org Cheers, Nevil On 4/03/16 6:01 pm, Zhoutianran wrote: > 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 -- --------------------------------------------------------------------- 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 nobody Sun Mar 6 19:50:32 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2581A885D for ; Sun, 6 Mar 2016 19:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 1Ts-mzldiF-V for ; Sun, 6 Mar 2016 19:50:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF491A8855 for ; Sun, 6 Mar 2016 19:50:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJR62214; Mon, 07 Mar 2016 03:48:56 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 7 Mar 2016 03:48:55 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.102]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 7 Mar 2016 11:48:51 +0800 From: Zhoutianran To: "colemaj@cisco.com" Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2mOZC2OcBCLECSqIAKm8tvNJ9FdHGAgAEVCICAAB1DgIAArWQAgAAFyoCAAAbwgIAAB/cAgAElLACAADj0AIAAQV+AgAQ2smA= Date: Mon, 7 Mar 2016 03:48:50 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> <56D95F20.7080006@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBDA45@EX-0-MB2.lancs.local> <909DAC0E-7372-448D-A670-DF302157B0AC@cisco.com> In-Reply-To: <909DAC0E-7372-448D-A670-DF302157B0AC@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown, refid=x_failed, ip=unknown, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32, mode=multiengine Archived-At: Cc: SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 03:50:31 -0000 SGkgSmFzb24sDQoNCj5BcyBmb3IgdGhlIGluZm9ybWF0aW9uIG1vZGVsIHZlcnN1cyBkYXRhIG1v ZGVsIGRpc2N1c3Npb24sIEkgdGhpbmsgdGhhdCBhbiBpbmZvcm1hdGlvbiBtb2RlbCBpcyByZXF1 aXJlZCB0byBhbGxvdyBmb3IgZGlmZmVyZW50IGRhdGEgbW9kZWxzIHRvIGZvbGxvdyBhIGNvbW1v biBzdHJ1Y3R1cmUuDQoNCj5UaGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IHdvdWxkIGRlZmluZSB0 aGUgcm9sZSBvZiB0aGUgaW5mb3JtYXRpb24gbW9kZWwgY2xlYXJseQ0KDQpJIHdvdWxkIHZlcnkg bGlrZSB0byBzZWUgdGhpcyBiZWVuIGRpc2N1c3NlZCBhbmQgYWRkcmVzc2VkIGluIHRoZSBhcmNo aXRlY3R1cmUgZG9jdW1lbnQuDQpFc3BlY2lhbGx5LCANCjEuIEhvdyB0aGUgaW5mb3JtYXRpb24g bW9kZWwgY2FuIGhlbHAgZGF0YSBtb2RlbCBnZW5lcmF0aW9uIGlmIHdlIGtub3cgd2Ugd2lsbCBk ZWxpdmVyIFlBTkcgRE1zPyBJIG1lYW4gb24gb25lIGhhbmQgd2UgY2FuIGltcHJvdmUgdGhlIGlu Zm9ybWF0aW9uIG1vZGVsLCB0aGVuIGdlbmVyYXRlIGEgWUFORyBETTsgb24gdGhlIG90aGVyIGhh bmQsIHdlIGNhbiBqdXN0IHdvcmsgb24gYSBZQU5HIERNcyBhbmQgaW1wcm92ZSBpdC4gV2hhdCdz IHRoZSBkaWZmZXJlbmNlPyANCjIuIFdoYXQgc2hvdWxkIGJlIGRlZmluZWQgaW4gSU0sIHdoYXQg aW4gRE0uIEJlc3Qgd2l0aCBzb21lIGV4YW1wbGVzLiBBZnRlciBhbGwsIElNIGNhbm5vdCBiZSB1 c2VkIGluIGEgc3lzdGVtIGltcGxlbWVudGF0aW9uLCB3ZSBuZWVkIERNcy4gDQozLiBXZSBjYW4g ZGVmaW5lIGEgWUFORyBETSB3aXRoICJhdWdtZW50IiwgImdyb3VwaW5nLXVzZSIsIG9yIGRlc2ln biBpdGVtcyB3aXRoICJ0eXBlLXZhbHVlIiBwYWlyLiBTbyB0aGF0IHRoZXJlIHdpbGwgYmUgZ2Vu ZXJpYyBETSBhbmQgc3BlY2lmaWMgRE0uIFRoZW4gaG93IGNhbiBJTSBiZSBtb3JlIGZvciBETS4N Cg0KSWYgdGhvc2UgY291bGQgYmUgYWRkcmVzcywgSSB0aGluayB0aGF0IHdpbGwgYmUgbXVjaCBo ZWxwLg0KDQpCZXN0LA0KVGlhbnJhbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IEphc29uIENvbGVtYW4gKGNvbGVtYWopIFttYWlsdG86Y29sZW1hakBjaXNjby5jb21d IE9uIEJlaGFsZiBPZg0KPiBjb2xlbWFqDQo+IFNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAwNSwgMjAx NiAxOjI4IEFNDQo+IFRvOiBLaW5nLCBEYW5pZWw7IEJlcnQgV2lqbmVuIChJRVRGKTsgSm9lbCBN LiBIYWxwZXJuOyBBbmR5IEJpZXJtYW47IEpvaG4NCj4gU3RyYXNzbmVyOyBaaG91dGlhbnJhbg0K PiBDYzogTmV2aWwgQnJvd25sZWU7IFNVUEEgbGlzdA0KPiBTdWJqZWN0OiBSZTogW1N1cGFdIElu Zm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBXRyBhZG9waW9uPw0KPiANCj4gSSB3 b3VsZCBsaWtlIHRvIGJlIHBhcnQgb2Ygd29ya2luZyBvbiBhbiBhcmNoaXRlY3R1cmUgZG9jdW1l bnQgYXMgd2VsbC4NCj4gDQo+IEFzIGZvciB0aGUgaW5mb3JtYXRpb24gbW9kZWwgdmVyc3VzIGRh dGEgbW9kZWwgZGlzY3Vzc2lvbiwgSSB0aGluayB0aGF0DQo+IGFuIGluZm9ybWF0aW9uIG1vZGVs IGlzIHJlcXVpcmVkIHRvIGFsbG93IGZvciBkaWZmZXJlbnQgZGF0YSBtb2RlbHMgdG8gZm9sbG93 DQo+IGEgY29tbW9uIHN0cnVjdHVyZS4NCj4gSXQgaXMgcG9zc2libGUgdG8gY3JlYXRlIGEgZGF0 YSBtb2RlbCBmaXJzdCwgYnV0IHRoYXQgZGF0YSBtb2RlbCBtYXkgbm90DQo+IGZpdCBpbiB3ZWxs IHdpdGggb3RoZXIgZGF0YSBtb2RlbHMuICBUaGlzIGlzIHdoeSB0aGUgaW5mb3JtYXRpb24gbW9k ZWwgZXhpc3RzDQo+IHRvIGFsbG93IGZvciB0aGluZ3MgdGhhdCBtYXkgZXh0ZW5kIHRoYXQgZGF0 YSBtb2RlbCBvciBhcmUgaW4gcGxhY2UgZm9yDQo+IG90aGVyIGRhdGEgbW9kZWxzLg0KPiANCj4g QXQgdGhpcyB0aW1lIHRoZSBmb2N1cyBpcyBvbiBFdmVudCwgQ29uZGl0aW9uLCBBY3Rpb24sIGJ1 dCB0aGVyZSB3aWxsIGJlDQo+IGZ1cnRoZXIgbWFuYWdlbWVudCBzdHJ1Y3R1cmVzIHRvIGRlZmlu ZS4NCj4gVGhlIGluZm9ybWF0aW9uIG1vZGVsIHN1cHBvcnRzIGEgZ2VuZXJhbCBzdHJ1Y3R1cmUg YW5kIHRoZW4gcHJvdmlkZXMgZGV0YWlscw0KPiBvbiBFQ0EuICBUaGF0IGdlbmVyYWwgc3RydWN0 dXJlIGlzIGltcG9ydGFudCBmb3IgZnV0dXJlIGRhdGEgbW9kZWxzIGFzIHdlbGwuDQo+IFRob3Nl IG1heSBiZSBZQU5HIG9yIG90aGVyIHBlb3BsZSBtYXkgY2hvc2UgdG8gdXNlIHRoZSBpbmZvcm1h dGlvbiBtb2RlbA0KPiB0byBjcmVhdGUgYSBkYXRhIG1vZGVsIGluIGEgZGlmZmVyZW50IHdheS4N Cj4gDQo+IFRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgd291bGQgZGVmaW5lIHRoZSByb2xlIG9m IHRoZSBpbmZvcm1hdGlvbiBtb2RlbA0KPiBjbGVhcmx5LCB3aGljaCBJIHRoaW5rIHRoYXQgcGFy dCBvZiB0aGUgSUQgdGhhdCBKb2huLCBKb2VsLCBhbmQgSSB3b3JrZWQNCj4gb24gYXR0ZW1wdHMg dG8gZG8gYXMgd2VsbCwgYW5kIHRoZW4gY2FuIHNob3cgaG93IHRoZSBkYXRhIG1vZGVscyB3aWxs IGJlDQo+IHN1cHBvcnRlZCBieSB0aGUgaW5mb3JtYXRpb24gbW9kZWwgYW5kIHdoYXQgZWxzZSB0 aGUgV0cgQ2hhcnRlciBoYXMgZGVmaW5lZA0KPiBhbmQgcG9zc2libHkgd2hlcmUgd2UgZ28gbmV4 dC4NCj4gDQo+IEphc29uDQo+IA0KPiANCj4gDQo+IE9uIDMvNC8xNiwgNzozNCBBTSwgIlN1cGEg b24gYmVoYWxmIG9mIEtpbmcsIERhbmllbCIgPHN1cGEtYm91bmNlc0BpZXRmLm9yZw0KPiBvbiBi ZWhhbGYgb2YgZC5raW5nQGxhbmNhc3Rlci5hYy51az4gd3JvdGU6DQo+IA0KPiA+SGkgQmVydCwN Cj4gPg0KPiA+VGhhbmsgZm9yIHRha2luZyB0aGUgaW5pdGlhdGl2ZS4gV2UgY2FuIG1ha2Ugc3Vy ZSB0aGVyZSBpcyB0aW1lIG9uIHRoZQ0KPiBhZ2VuZGEgZm9yIHRoZSBJLUQuDQo+ID4NCj4gPkJS LCBEYW4uDQo+ID4NCj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID5Gcm9tOiBCZXJ0 IFdpam5lbiAoSUVURikgW21haWx0bzpid2lldGZAYndpam5lbi5uZXRdDQo+ID5TZW50OiAwNCBN YXJjaCAyMDE2IDEwOjExDQo+ID5UbzogS2luZywgRGFuaWVsIDxkLmtpbmdAbGFuY2FzdGVyLmFj LnVrPjsgSm9lbCBNLiBIYWxwZXJuDQo+ID48am1oQGpvZWxoYWxwZXJuLmNvbT47IEFuZHkgQmll cm1hbiA8YW5keUB5dW1hd29ya3MuY29tPjsgSm9obg0KPiA+U3RyYXNzbmVyIDxKb2huLnNjLlN0 cmFzc25lckBodWF3ZWkuY29tPjsgWmhvdXRpYW5yYW4NCj4gPjx6aG91dGlhbnJhbkBodWF3ZWku Y29tPg0KPiA+Q2M6IE5ldmlsIEJyb3dubGVlIDxuLmJyb3dubGVlQGF1Y2tsYW5kLmFjLm56Pjsg U1VQQSBsaXN0DQo+ID48c3VwYUBpZXRmLm9yZz4NCj4gPlN1YmplY3Q6IFJlOiBbU3VwYV0gSW5m b3JtYXRpb24gbW9kZWxzIGFuZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/DQo+ID4NCj4gPk9u IDAzLzAzLzE2IDE3OjQxLCBLaW5nLCBEYW5pZWwgd3JvdGU6DQo+ID4+IEhpICBBbGwuDQo+ID4+ DQo+ID4+IFdlIGhhdmUgYSBwbGFjZWhvbGRlciBpbiB0aGUgU1VQQSBDaGFydGVyIGZvcjoNCj4g Pj4NCj4gPj4gMSkgQW4gZXhwbGFuYXRpb24gb2YgdGhlIHNjb3BlIG9mIHRoZSBwb2xpY3ktYmFz ZWQgbWFuYWdlbWVudCBmcmFtZXdvcmsNCj4gYW5kIGhvdyBpdCByZWxhdGVzIHRvIGV4aXN0aW5n IHdvcmsgb2YgdGhlIElFVEYuDQo+ID4+DQo+ID4+IEEgcHJvcG9zYWwgZm9yIHRoaXMgZG9jdW1l bnQgaGFzIG5vdCBiZWVuIGZvcnRoY29taW5nIHRodXMgZmFyLiBJdCB3b3VsZA0KPiBzZWVtIHRo YXQgYSAiUG9saWN5LWJhc2VkIE1hbmFnZW1lbnQgRnJhbWV3b3JrIiBkaXNjdXNzaW5nIGFyY2hp dGVjdHVyZSwNCj4gYXBwbGljYWJpbGl0eSBhbmQgcmVsYXRpb25zaGlwcyAoInN5c3RlbSBvdmVy dmlldyIpIHdvdWxkIGJlIHJlYXNvbmFibGUNCj4gY29udGVudCBmb3IgYSBmcmFtZXdvcmsgZG9j dW1lbnQgbWVudGlvbmVkIGluIHRoZSBDaGFydGVyPw0KPiA+Pg0KPiA+PiBGdXJ0aGVybW9yZSwg QW5keSwgVGlhbnJhbiBhbmQgQmVydCBhbGwgc2VlbSB3aWxsaW5nIHRvIHN1cHBvcnQNCj4gZGV2 ZWxvcG1lbnQgKHZpYSBkaXJlY3QgY29udHJpYnV0aW9ucykgZm9yIHRoZSBmcmFtZXdvcmsvYXJj aGl0ZWN0dXJlDQo+IGRvY3VtZW50Pw0KPiA+RGFuLCBJIGFtIHdpbGxpbmcgdG8gdGFrZSBpbml0 aWF0aXZlIG9uIHRoaXMuDQo+ID4NCj4gPkkgc2F3IGluIG9uZSBvZiBKb2hucyBwb3N0aW5nczoN Cj4gPiAgICBXZWxsLCB3ZSBkb24ndCBoYXZlIGFuIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBjdXJy ZW50bHkgaW4gb3VyIGNoYXJ0ZXINCj4gPiAgICAodGhvdWdoIEkgd291bGQgc3VwcG9ydCBhbWVu ZGluZyB0aGUgY2hhcnRlciB0byBpbmNsdWRlIHRoaXMpLiBJbiB0aGUNCj4gPiAgICAobm93IGV4 cGlyZWQpIHByb3Bvc2l0aW9uIGRyYWZ0ICh3aGljaCB3ZSBhcmUgbm93IHdvcmtpbmcgb24gdG8g cmVpc3N1ZSksDQo+ID4gICAgdGhlcmUgd2FzIGFuIGV4ZW1wbGFyeSBhcmNoaXRlY3R1cmUuDQo+ ID4NCj4gPkpvaG4sIGRvIHlvdSBoYXZlIHRoZSBwaWVjZSBvZiB0ZXh0IGluIGFuIFhNTCBmaWxl IChJLUQgc291cmNlIGZpbGUpIGFuZA0KPiBpZiBzbywgY2FuIHlvdSBzZW5kIHRoYXQgdG8gbWUu IEkgYXNzdW1lIHlvdSBhcmUgT0sgd2l0aCB1cyB1c2luZyB0aGF0IGFzDQo+IGEgc3RhcnRpbmcg cG9pbnQ/DQo+ID4NCj4gPkRhbi9OZXZpbCwgaWYgd2Ugc3VibWl0IGFuIGluIGluaXRpYWwgSS1E IHRpbWVseSwgZG8geW91IHRoaW5rIHdlIGNhbiBzcGVuZA0KPiBzb21lIHRpbWUgb24gaXQgaW4g b3VyIElFVEY5NSBzZXNzaW9uPw0KPiA+DQo+ID5UaGFua3MsDQo+ID5CZXJ0DQo+ID4NCj4gPg0K PiA+DQo+ID4+IEJSLCBEYW4uDQo+ID4+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBCZXJ0IFdpam5lbg0KPiA+PiAoSUVURikNCj4gPj4gU2VudDogMDMgTWFyY2ggMjAxNiAx NjoxMw0KPiA+PiBUbzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsgQW5k eSBCaWVybWFuDQo+ID4+IDxhbmR5QHl1bWF3b3Jrcy5jb20+OyBKb2huIFN0cmFzc25lciA8Sm9o bi5zYy5TdHJhc3NuZXJAaHVhd2VpLmNvbT4NCj4gPj4gQ2M6IFpob3V0aWFucmFuIDx6aG91dGlh bnJhbkBodWF3ZWkuY29tPjsgTmV2aWwgQnJvd25sZWUNCj4gPj4gPG4uYnJvd25sZWVAYXVja2xh bmQuYWMubno+OyBTVVBBIGxpc3QgPHN1cGFAaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6IFJlOiBb U3VwYV0gSW5mb3JtYXRpb24gbW9kZWxzIGFuZCBEYXRhIG1vZGVscyAtIFdHIGFkb3Bpb24/DQo+ ID4+DQo+ID4+IElubGluZQ0KPiA+Pg0KPiA+PiBPbiAwMy8wMy8xNiAxNjo0OCwgSm9lbCBNLiBI YWxwZXJuIHdyb3RlOg0KPiA+Pj4gVHdvIHNlcGFyYXRlIGJ1dCByZWxhdGVkIHF1ZXNpdG9ucy4N Cj4gPj4+DQo+ID4+PiAxKSBDYW4geW91IGhlbHAgdXNlIGZpbmQgdGhlIHBsYWNlcyB3aGVyZSB0 aGUgbW9kZWwgLyB0ZXh0IGlzIHRvbw0KPiA+Pj4gaW1wbGVtZW50YXRpb24gc3BlY2lmaWM/ICBU aGVyZSBhcmUgYSBmZXcgcGxhY2VzIHdoZXJlIGluIGRlc2NyaWJpbmcNCj4gPj4+IGVudW1lcmF0 aW9ucyB0aGUgbW9kZWwgY2FsbHMgZm9yIGludGVnZXJzLiAgSW4gdGhlIG1hcHBpbmcgdG8gWUFO RywgSQ0KPiBoYXZlIGFscmVhZHkgc3RhcnRlZCByZXBsYWNpbmcgdGhvc2Ugd2l0aCBFbnVtZXJh dGlvbnMuICBBcmUgdGhlcmUgb3RoZXINCj4ga2luZHMgb2Ygb3Zlci1zcGVjaWZpY2l0eT8NCj4g Pj4+DQo+ID4+PiAyKSBUaGUgY2hhcnRlciBhbGxvd3MgZm9yIGEgcmFuZ2Ugb2YgaW1wbGVtZW50 YXRpb25zIG9mIHRoZSBTVVBBDQo+ID4+PiBzeXN0ZW0uICBGb2xrcyBtYXkgcmVjYWxsIEkgYXNr ZWQgaW4gdGhlIHJvb20gYXQgdGhlIGxhc3QgbWVldGluZw0KPiA+Pj4gd2hldGhlciBvdXIgY2hh cnRlcmVkIGFsbG93ZCBib3RoIGNvbW11bmljYXRpb24gYmV0d2VlbiBhIGNvbnRyb2wNCj4gPj4+ IHN5c3RlbSBhbmQgYSBkZXZpY2UsIGFuZCBjb21tdW5pY2F0aW9uIGJldHdlZW4gYSBwb2xpY3kg cmVwb3NpdG9yeSBhbmQNCj4gYSBwb2xpY3kgZW5naW5lLiAgSSB3YXMgdG9sZCBieSB0aGUgQUQg dGhhdCB0aGUgY2hhcnRlcmVkIGFsbG93ZWQgYm90aC4gIFRoaXMNCj4gZG9lcyBtYWtlIGl0IHJh dGhlciBpbnRlcmVzdGluZyB0byBkZWZpbmUgdGhlICJhcmNoaXRlY3R1cmUiLg0KPiA+PiBNbW1t Li4uIGJvdGggY29uY3VycmVudGx5LCBvciBkaWQgaGUgbWVhbiB0aGF0IHdlIGFzIGEgV0cgY2Fu IG1ha2UgYQ0KPiBjaG9pY2Ugd2hhdCB3ZSBwcmVmZXIgYW5kIHN0YW5kYXJkaXplIHRoYXQ/DQo+ ID4+IElmIHdlIGRvIGJvdGggY29uY3VycmVudGx5IG9yIGEgbG9uZ3NpZGUgZWFjaCBvdGhlciwg Y2FuIHdlIHRoZW4gc3RpbGwNCj4gZ3VhcmFudGVlIGludGVyb3BlcmFiaWxpdHkgKHdoaWNoIEkg dGhpbmsgaXMgb25lIG9mIG91ciBtYWluIG9iamN0aXZlcywNCj4gbm8pPw0KPiA+Pj4gMicpIEkg ZG8gdGhpbmsgdGhhdCB0aGVyZSBhcmUgYSBmZXcgcGxhY2VzIGluIHRoZSBtb2RlbCwNCj4gPj4+ IHBhcnRpY3VsYXJseSB3aXRoIHJlZ2FyZCB0byBwb2xpY3kgZXhlY3V0aW9uIHN0YXR1cywgd2hl cmUgdGhlIG1vZGVsDQo+IG1ha2VzIHNvbWUgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIHN0cnVjdHVy ZSBvZiBwb2xpY3kgZGVsaXZlcnkuICBGb3IgdGhlIG1vc3QNCj4gcGFydCwgdGhvc2Ugc2hvdWxk IGJlIHJlbW92ZWQuICBBc3Npc3RhbmNlIGluIGZpbmRpbmcNCj4gPj4+IHRoZW0gaXMgYXBwcmVj aWF0ZWQuICBJIHN1c3BlY3QgdGhhdCBzb21lIG9mIHRoZW0gYXJlIG5lY2Vzc2FyeSwgYW5kDQo+ IHRob3NlIHNob3VsZCBiZSBleHBsaWNpdGx5IGRlc2NyaWJlZC4gICAoQW5kIHdlIHNob3VsZCBt YWtlDQo+ID4+PiBzdXJlIHRoZSB3b3JraW5nIGdyb3VwIGFncmVlcyB3aXRoIHRoZSBhc3N1bXB0 aW9ucy4pDQo+ID4+Pg0KPiA+Pj4gMykgKG1pbm9yKSBUaGUgY2hhcnRlciBwZXJtaXRzIHRoZSBp bmZvcm1hdGlvbiBtb2RlbC4gIEkgcHJlc3VtZSB3ZSBjb3VsZA0KPiBhbWVuZCB0aGUgY2hhcnRl ciB0byBwZXJtaXQgYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50Lg0KPiA+Pj4NCj4gPj4gSSB3b3Vs ZCBzYXkgYW4gIkFyY2hpdGVjdHVyZSIgb3IgIlN5c3RlbSBPdmVydmlldyIgZG9jdW1lbnQgd291 bGQgYmUNCj4gYSBnb29kIHRoaW5nLg0KPiA+Pg0KPiA+PiBCZXJ0DQo+ID4+PiBZb3VycywNCj4g Pj4+IEpvZWwNCj4gPj4+DQo+ID4+PiBPbiAzLzMvMTYgMTA6MjcgQU0sIEJlcnQgV2lqbmVuIChJ RVRGKSB3cm90ZToNCj4gPj4+PiBWZXJ5IGdvb2QgYW5kIHByYWN0aWNhbCBxdWVzdGlvbiByYWlz ZWQgYnkgQW5keSENCj4gPj4+Pg0KPiA+Pj4+IEJlcnQNCj4gPj4+Pg0KPiA+Pj4+IE9uIDAzLzAz LzE2IDA2OjA2LCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+IE9uIFdlZCwg TWFyIDIsIDIwMTYgYXQgNzoyMSBQTSwgSm9obiBTdHJhc3NuZXINCj4gPj4+Pj4gPEpvaG4uc2Mu U3RyYXNzbmVyQGh1YXdlaS5jb20NCj4gPj4+Pj4gPG1haWx0bzpKb2huLnNjLlN0cmFzc25lckBo dWF3ZWkuY29tPj4NCj4gPj4+Pj4gd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgV2Ugc2hv dWxkIHdvcmsgb24gYW4gaW5mb3JtYXRpb24gbW9kZWwgZm9yIHNldmVyYWwgcmVhc29ucywgZXZl bg0KPiBpZg0KPiA+Pj4+PiAgICAgIHRoZXJlIGlzIG9ubHkgdGFyZ2V0IGRhdGEgbW9kZWwgKGku ZS4sIFlBTkcpOg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAgMSkgQW4gaW5mb3JtYXRpb24gbW9k ZWwgY2FuIGRlZmluZSBob3cgZGF0YSBhcmUgcmVsYXRlZCB0byBlYWNoDQo+ID4+Pj4+ICAgICAg ICAgICBvdGhlciBpbmRlcGVuZGVudCBvZiBpbXBsZW1lbnRhdGlvbi4gVGhpcyBpcyBtdWNoIGhh cmRlciB0bw0KPiBkbw0KPiA+Pj4+PiAgICAgICAgICAgaW4gWUFORy4gSGVuY2UsIHRoZSBpbmZv cm1hdGlvbiBtb2RlbCBtYXkgbWFrZSB0aGVzZSBpbmhlcmVudA0KPiA+Pj4+PiAgICAgICAgICAg cmVsYXRpb25zaGlwcyBlYXNpZXIgdG8gdmlzdWFsaXplIGFuZCBkZWZpbmUuDQo+ID4+Pj4+ICAg ICAgICAyKSBBbiBpbmZvcm1hdGlvbiBtb2RlbCBzZXBhcmF0ZXMgdGhlIGxvZ2ljYWwgZGVzaWdu IGZyb20gdGhlDQo+ID4+Pj4+ICAgICAgICAgICBwaHlzaWNhbCBkZXNpZ24gb2YgdGhlIHN5c3Rl bSwgZW5hYmxpbmcgYSBkZWVwZXINCj4gdW5kZXJzdGFuZGluZw0KPiA+Pj4+PiAgICAgICAgICAg b2YgYm90aCBpbmRlcGVuZGVudCBvZiBpbXBsZW1lbnRhdGlvbi4gVGhpcyBjYW4gYmUgdXNlZCB0 bw0KPiA+Pj4+PiAgICAgICAgICAgcHJvZHVjZSBtb3JlIHBvd2VyZnVsIGltcGxlbWVudGF0aW9u cy4NCj4gPj4+Pj4gICAgICAgIDMpIElmIGFuIGluZm9ybWF0aW9uIG1vZGVsIGlzIHdvcmtlZCBv biBpbiBhbm90aGVyIG9yZ2FuaXphdGlvbiwNCj4gPj4+Pj4gICAgICAgICAgIHRoZXJlIGlzIG5v IGd1YXJhbnRlZSB0aGF0IGl0cyBvdXRwdXQgd2lsbCBiZSB1c2VmdWwgdG8gdGhlDQo+ID4+Pj4+ ICAgICAgICAgICBJRVRGLiBJIGFtIGFjdGl2ZSBpbiB0aGUgVE0gRm9ydW0sIHdoaWNoIHlvdSBj aXRlZDsgdGhleSBhcmUNCj4gPj4+Pj4gICAgICAgICAgIGluIGdlbmVyYWwgbm90IHdvcnJpZWQg YWJvdXQgaW1wbGVtZW50aW5nIFlBTkcgbW9kZWxzLCBtdWNoDQo+ID4+Pj4+ICAgICAgICAgICBs ZXNzIHByb2R1Y2luZyBvcHRpbWFsIFlBTkcgbW9kZWxzLg0KPiA+Pj4+PiAgICAgICAgNCkgVGhp cyBlbmFibGVzIG90aGVyIFNET3MgYW5kIGZvcmEsIHdoaWNoIGRvIG5vdCB1c2UgWUFORywgdG8N Cj4gPj4+Pj4gICAgICAgICAgIG1vcmUgZWFzaWx5IHVuZGVyc3RhbmQgb3VyIG91dHB1dC4NCj4g Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gSXQgc2VlbXMgdG8gbWUgdGhhdCB5b3Vy IGRyYWZ0IGhhcyBtYW55IGRldGFpbHMgcmVsYXRlZCB0byB0aGUNCj4gPj4+Pj4gYWJzdHJhY3Rp b24gb2YgcG9saWN5IGxvZ2ljLCBidXQgYWxzbyBtYW55IGFzcGVjdHMgdGhhdCBsb29rIGxpa2UN Cj4gPj4+Pj4gaW1wbGVtZW50YXRpb24gZGV0YWlscy4NCj4gPj4+Pj4gUGVyaGFwcyBpdCBjYW4g YmUgc2ltcGxpZmllZCBpZiB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyB3ZXJlDQo+IHJlbW92 ZWQuDQo+ID4+Pj4+DQo+ID4+Pj4+IEkgYW0gbW9yZSBpbnRlcmVzdGVkIGluIHRoZSBTVVBBIEFy Y2hpdGVjdHVyZSBkb2N1bWVudCBmaXJzdC4NCj4gPj4+Pj4gSSBkb24ndCBzZWUgaG93IHdlIGNh biBhZ3JlZSBvbiBhbiBpbmZvLW1vZGVsIGluIHRoZSBhYnNlbmNlIG9mIGENCj4gPj4+Pj4gc3lz dGVtIGFyY2hpdGVjdHVyZS4NCj4gPj4+Pj4NCj4gPj4+Pj4gRG9lcyBTVVBBIHJ1biBhbnl3aGVy ZT8gV2hhdCBkb2VzIGl0IGV2ZW4gbWVhbiB0byBpbXBsZW1lbnQgU1VQQT8NCj4gPj4+Pj4gV2ls bCBwZW9wbGUgYmUgYWJsZSB0byBidWlsZCBpbnRlcm9wZXJhYmxlIFNVUEEgZW5naW5lcyBmcm9t IHRoZSBSRkNzPw0KPiA+Pj4+PiBJcyB0aGVyZSBhIGRpZmZlcmVuY2UgYmV0d2VlbiBhIFNVUEEg ZW5naW5lIHJ1bm5pbmcgYXQgdGhlIGRldmljZQ0KPiA+Pj4+PiBsZXZlbCBvciB0aGUgY29udHJv bGxlciBsZXZlbD8gIFdoYXQgZGF0YSBpcyBhdmFpbGFibGUgZm9yIHBvbGljeQ0KPiA+Pj4+PiBl bmZvcmNlbWVudCBhbmFseXNpcz8NCj4gPj4+Pj4gSXMgdGhpcyBjb25maWd1cmFibGUgdGhyb3Vn aCBZQU5HIG1vZHVsZXMgaW1wbGVtZW50ZWQgYnkgYSBTVVBBIGVuZ2luZT8NCj4gPj4+Pj4gSG93 IGFyZSBwb2xpY2llcyBkZWZpbmVkIGFuZCBtYW5hZ2VkIHdpdGhpbiB0aGUgU1VQQSBpbXBsZW1l bnRhdGlvbj8NCj4gPj4+Pj4gSG93IGlzIGRldmljZSBjb25maWcgYWx0ZXJlZCB0byBpbXBsZW1l bnQgcG9saWN5Pw0KPiA+Pj4+PiBIb3cgYXJlIGRldmljZSBvcGVyYXRpb25hbCBzdGF0ZSBhbmQg c3RhdGlzdGljcyB1c2VkIHRvIHZlcmlmeQ0KPiA+Pj4+PiBwb2xpY3kgaW1wbGVtZW50YXRpb24/ DQo+ID4+Pj4+DQo+ID4+Pj4+IEEgcHJlY2lzZSBkZXNjcmlwdGlvbiBvZiBwb2xpY3kgbG9naWMg bWlnaHQgYmUgYSBnb29kIHRoaW5nIHRvIGhhdmUuDQo+ID4+Pj4+IEkgYW0gbm90IG9iamVjdGlu ZyB0byBhbiBpbmZvIG1vZGVsIGRvYy4gIEEgc3lzdGVtIGFyY2hpdGVjdHVyZQ0KPiA+Pj4+PiBh bmQgYSB3b3JrYWJsZSBzb2x1dGlvbiB3aWxsIHJlcXVpcmUgYSBsb3QgbW9yZSB0aGFuIHRoYXQu DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ ID4+Pj4+DQo+ID4+Pj4+ICAgICAgSm9obg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+ Pj4+PiBBbmR5DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPj4+Pj4gICAgICBGcm9tOiBTdXBhIFttYWlsdG86c3VwYS1ib3VuY2Vz QGlldGYub3JnDQo+ID4+Pj4+IDxtYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVo YWxmIE9mIFpob3V0aWFucmFuDQo+ID4+Pj4+ICAgICAgU2VudDogVHVlc2RheSwgTWFyY2ggMDEs IDIwMTYgNzoyOSBQTQ0KPiA+Pj4+PiAgICAgIFRvOiBOZXZpbCBCcm93bmxlZQ0KPiA+Pj4+PiAg ICAgIENjOiBTVVBBIGxpc3QNCj4gPj4+Pj4gICAgICBTdWJqZWN0OiBSZTogW1N1cGFdIEluZm9y bWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBXRw0KPiBhZG9waW9uPw0KPiA+Pj4+Pg0K PiA+Pj4+PiAgICAgIEhpIE5ldmlsLA0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgIEkgYW0gbm90IGFy Z3VpbmcgaW5mb3JtYXRpb24gbW9kZWwgaXMgdXNlbGVzcywgYnV0IGl0IGNhbiBiZQ0KPiA+Pj4+ PiB3b3JrZWQgb3V0IGluIG90aGVyIG9yZ2FuaXphdGlvbnMgaWYgbmVjZXNzYXJ5LCBlLmcuIFRN Ri4NCj4gPj4+Pj4gICAgICBJZiBpbiBTVVBBIHdlIGNhbiB3b3JrZWQgb24gWUFORyBkYXRhIG1v ZGVscyBkaXJlY3RseSwgd2h5IHdlDQo+ID4+Pj4+IGZpcnN0bHkgd29yayBvbiBhbiBpbmZvcm1h dGlvbiBtb2RlbCBhbmQgdGhlbiB0cmFuc2xhdGUgaXQgdG8NCj4gPj4+Pj4gICAgICBZQU5HIGRh dGEgbW9kZWw/DQo+ID4+Pj4+ICAgICAgSXQganVzdCBub3QgbWFrZXMgc2Vuc2UgdG8gbWUuDQo+ ID4+Pj4+DQo+ID4+Pj4+ICAgICAgVGlhbnJhbg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4gICAgICA+IEZyb206IFN1cGEgW21haWx0 bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPj4+Pj4gPG1haWx0bzpzdXBhLWJvdW5jZXNAaWV0 Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTmV2aWwgQnJvd25sZWUNCj4gPj4+Pj4gICAgICA+IFNlbnQ6 IFdlZG5lc2RheSwgTWFyY2ggMDIsIDIwMTYgNjo1NiBBTQ0KPiA+Pj4+PiAgICAgID4gVG86IFpo b3V0aWFucmFuDQo+ID4+Pj4+ICAgICAgPiBDYzogU1VQQSBsaXN0DQo+ID4+Pj4+ICAgICAgPiBT dWJqZWN0OiBSZTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBX Rw0KPiA+Pj4+PiBhZG9waW9uPw0KPiA+Pj4+PiAgICAgID4NCj4gPj4+Pj4gICAgICA+DQo+ID4+ Pj4+ICAgICAgPiBIaSBUaWFucmFuOg0KPiA+Pj4+PiAgICAgID4NCj4gPj4+Pj4gICAgICA+IElu IG15IGV4cGVyaWVuY2VzLCBoYXZpbmcgYSB3ZWxsLWRlZmluZWQgaW5mb3JtYXRpb24gbW9kZWwN Cj4gPj4+Pj4gaXMgYSBnb29kIHN0YXJ0aW5nDQo+ID4+Pj4+ICAgICAgPiBwb2ludC4gIEl0IGFs bG93cyBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zLCBlYWNoIG9mIHdoaWNoDQo+ID4+Pj4+IGNh biBkZXZlbG9wIGl0J3MNCj4gPj4+Pj4gICAgICA+IG93biBkYXRhIG1vZGVsIC0gaW4gb3RoZXIg d29yZHMsIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBpcyBhDQo+ID4+Pj4+IGdvb2QgdW5pZnlpbmcN Cj4gPj4+Pj4gICAgICA+IGluZmx1ZW5jZSAtIHdoaWNoIGlzIHdoeSBwdWJsaXNoaW5nIHN1Y2gg YSBkb2N1bWVudCBpcyB0aGUNCj4gPj4+Pj4gc2Vjb25kIG9mIG91cg0KPiA+Pj4+PiAgICAgID4g Y2hhcnQgaXRlbXMuICBJIGhvcGUgdGhhdCBnZXR0aW5nIGEgZ29vZCBkYXRhIG1vZGVsIHdpbGwN Cj4gPj4+Pj4gaGVscCB1cyB3aXRoIHRoZQ0KPiA+Pj4+PiAgICAgID4gZmlyc3QgY2hhcnQgaXRl bSAoInNjb3BlIG9mIHRoZSBwb2xpY3ktYmFzZWQgbWFuYWdlbWVudA0KPiA+Pj4+PiBmcmFtZXdv cmsiKS4NCj4gPj4+Pj4gICAgICA+DQo+ID4+Pj4+ICAgICAgPiBkcmFmdC1zdHJhc3NuZXItc3Vw YS1nZW5lcmljLXBvbGljeS1pbmZvLW1vZGVsIGlzIHRoZSBvbmx5DQo+IFNVUEENCj4gPj4+Pj4g ICAgICA+IGluZm9ybWF0aW9uIG1vZGVsIHRoYXQncyBoYWQgYW55IHdvcmsgZG9uZSBvbiBpdCBz aW5jZSBJRVRGDQo+ID4+Pj4+IDk1LCB0aGVyZWZvcmUNCj4gPj4+Pj4gICAgICA+IEkndmUgcHJv cG9zZWQgaXQgZm9yIFdHIGFkb3B0aW9uLg0KPiA+Pj4+PiAgICAgID4NCj4gPj4+Pj4gICAgICA+ IEFzIGZvciB0aGUgdGhpcmQgY2hhcnRlciBpdGVtIC0gInNldCBvZiBZQU5HIGRhdGEgbW9kZWxz IiwNCj4gPj4+Pj4gdGhlcmUgYXJlIHR3bw0KPiA+Pj4+PiAgICAgID4gb2YgdGhlc2Ugb24gdGhl IFNVUEEgZG9jdW1lbnRzIHBhZ2UuICBJdCB3b3VsZCBoZWxwIGF0IHRoaXMNCj4gPj4+Pj4gc3Rh Z2UgaWYgdGhlaXINCj4gPj4+Pj4gICAgICA+IGF1dGhvcnMgY291bGQgY29tbWVudCBvbiB0aGlz IGxpc3QgYWJvdXQgdGhlIHN0YXR1cyBvZg0KPiA+Pj4+PiB0aGVzZSBkcmFmdHMuICBJbg0KPiA+ Pj4+PiAgICAgID4gcGFydGljdWxhciwgamF2ZSB0aGV5IGJlZW4gd29ya2luZyBvbiBhIG5ldyB2 ZXJzaW9uPw0KPiA+Pj4+PiAgICAgID4NCj4gPj4+Pj4gICAgICA+IE92ZXJhbGwsIHdlIHJlYWxs eSBuZWVkIG1vcmUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBvZg0KPiA+Pj4+PiB3aGF0J3MgaGFw cGVuaW5nDQo+ID4+Pj4+ICAgICAgPiB3aXRoIHRoZSBTVVBBIHdvcmshDQo+ID4+Pj4+ICAgICAg Pg0KPiA+Pj4+PiAgICAgID4gQ2hlZXJzLCBOZXZpbA0KPiA+Pj4+PiAgICAgID4NCj4gPj4+Pj4g ICAgICA+DQo+ID4+Pj4+ICAgICAgPiBPbiAxLzAzLzE2IDY6MTMgcG0sIFpob3V0aWFucmFuIHdy b3RlOg0KPiA+Pj4+PiAgICAgID4gPiBJZiB0aGlzIGlzIGEgcG9sbCBmb3IgV0cgYWRvcHRpb24s IEkgd291bGQgc2F5IG5vdCBzdXBwb3J0Lg0KPiA+Pj4+PiAgICAgID4gPg0KPiA+Pj4+PiAgICAg ID4gPiBJZiB3ZSB3YW50IHRvIGZpbmFsbHkgZ2VuZXJhdGUgWUFORyBkYXRhIG1vZGVscyBoZXJl LCB3aHkNCj4gPj4+Pj4gZG8gd2Ugc3BlbmQNCj4gPj4+Pj4gICAgICA+IHRpbWUgd29ya2luZyBv biB0aGlzIGluZm9ybWF0aW9uIG1vZGVsPw0KPiA+Pj4+PiAgICAgID4gPg0KPiA+Pj4+PiAgICAg ID4gPiBXaHkgbm90IGZvY3VzIG9uIHRoZSBFQ0EgWUFORyBkYXRhIG1vZGVsIGRpcmVjdGx5IGFz DQo+ID4+Pj4+IHN0YW5kYXJkIHRyYWNrPw0KPiA+Pj4+PiAgICAgID4gPg0KPiA+Pj4+PiAgICAg ID4gPg0KPiA+Pj4+PiAgICAgID4gPiBUaWFucmFuDQo+ID4+Pj4+ICAgICAgPiA+DQo+ID4+Pj4+ ICAgICAgPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+PiAgICAgID4gPj4g RnJvbTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZw0KPiA+Pj4+PiA8bWFpbHRv OnN1cGEtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBJRVRGDQo+ID4+Pj4+ICAgICAg PiA+PiBTZWNyZXRhcmlhdA0KPiA+Pj4+PiAgICAgID4gPj4gU2VudDogTW9uZGF5LCBGZWJydWFy eSAyOSwgMjAxNiA2OjM1IEFNDQo+ID4+Pj4+ICAgICAgPiA+PiBUbzoNCj4gPj4+Pj4gZHJhZnQt c3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5mby1tb2RlbEBpZXRmLm9yZw0KPiA+Pj4+ PiA8bWFpbHRvOmRyYWZ0LXN0cmFzc25lci1zdXBhLWdlbmVyaWMtcG9saWN5LWluZm8tbW9kZWxA aWV0Zi5vcmc+Ow0KPiA+Pj4+PiAgICAgID4gPj4gc3VwYS1jaGFpcnNAaWV0Zi5vcmcgPG1haWx0 bzpzdXBhLWNoYWlyc0BpZXRmLm9yZz47DQo+ID4+Pj4+IHN1cGFAaWV0Zi5vcmcgPG1haWx0bzpz dXBhQGlldGYub3JnPg0KPiA+Pj4+PiAgICAgID4gPj4gU3ViamVjdDogW1N1cGFdIFRoZSBTVVBB IFdHIGhhcyBwbGFjZWQNCj4gPj4+Pj4gICAgICA+ID4+IGRyYWZ0LXN0cmFzc25lci1zdXBhLWdl bmVyaWMtcG9saWN5LWluZm8tbW9kZWwgaW4gc3RhdGUNCj4gPj4+Pj4gIkNhbGwgRm9yDQo+ID4+ Pj4+ICAgICAgPiA+PiBBZG9wdGlvbiBCeSBXRyBJc3N1ZWQiDQo+ID4+Pj4+ICAgICAgPiA+Pg0K PiA+Pj4+PiAgICAgID4gPj4NCj4gPj4+Pj4gICAgICA+ID4+IFRoZSBTVVBBIFdHIGhhcyBwbGFj ZWQNCj4gPj4+Pj4gZHJhZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5mby1tb2Rl bA0KPiA+Pj4+PiAgICAgID4gPj4gaW4gc3RhdGUgQ2FsbCBGb3IgQWRvcHRpb24gQnkgV0cgSXNz dWVkIChlbnRlcmVkIGJ5DQo+ID4+Pj4+IE5ldmlsDQo+ID4+Pj4+IEJyb3dubGVlKQ0KPiA+Pj4+ PiAgICAgID4gPj4NCj4gPj4+Pj4gICAgICA+ID4+IFRoZSBkb2N1bWVudCBpcyBhdmFpbGFibGUg YXQNCj4gPj4+Pj4gICAgICA+ID4+DQo+ID4+Pj4+ICAgICAgPg0KPiA+Pj4+Pg0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdHJhc3NuZXItc3VwYS1nZW5lcmljLXBv bGljeS0NCj4gPj4+Pj4gICAgICA+ID4+IGkNCj4gPj4+Pj4gICAgICA+ID4+IG5mby1tb2RlbC8N Cj4gPj4+Pj4gICAgICA+ID4+DQo+ID4+Pj4+ICAgICAgPiA+Pg0KPiA+Pj4+PiAgICAgID4gPj4g Q29tbWVudDoNCj4gPj4+Pj4gICAgICA+ID4+IFRoaXMgaXMgdGhlIGZpcnN0IG9mIG91ciBjaGFy dGVyIGRvY3VtZW50cywgdGhlIG90aGVyDQo+ID4+Pj4+IGNoYXJ0ZXIgaXRlbXMNCj4gPj4+Pj4g ICAgICA+ID4+IGJ1aWxkIG9uIHRoaXMNCj4gPj4+Pj4gICAgICA+ID4+DQo+ID4+Pj4+ICAgICAg PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ Pj4+PiAgICAgID4gPj4gU3VwYSBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4gICAgICA+ID4+IFN1cGFA aWV0Zi5vcmcgPG1haWx0bzpTdXBhQGlldGYub3JnPg0KPiA+Pj4+PiAgICAgID4gPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhDQo+ID4+Pj4+ICAgICAgPg0KPiA+ Pj4+PiAgICAgID4NCj4gPj4+Pj4gICAgICA+IC0tDQo+ID4+Pj4+ICAgICAgPg0KPiA+Pj4+Pg0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPj4+Pj4gICAgICA+ICAgTmV2aWwgQnJvd25sZWUgICAgICAgICAg ICAgICAgICAgICAgICAgIENvbXB1dGVyIFNjaWVuY2UNCj4gPj4+Pj4gRGVwYXJ0bWVudA0KPiA+ Pj4+PiAgICAgID4gICBQaG9uZTogKzY0IDkgMzczIDc1OTkgeDg4OTQxICAgICAgICAgICAgIFRo ZSBVbml2ZXJzaXR5IG9mDQo+ID4+Pj4+IEF1Y2tsYW5kDQo+ID4+Pj4+ICAgICAgPiAgIEZBWDog KzY0IDkgMzczIDc0NTMgICBQcml2YXRlIEJhZyA5MjAxOSwgQXVja2xhbmQgMTE0MiwgTmV3DQo+ ID4+Pj4+IFplYWxhbmQNCj4gPj4+Pj4gICAgICA+DQo+ID4+Pj4+ICAgICAgPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiAgICAgID4gU3Vw YSBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4gICAgICA+IFN1cGFAaWV0Zi5vcmcgPG1haWx0bzpTdXBh QGlldGYub3JnPg0KPiA+Pj4+PiAgICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zdXBhDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4gICAgICBTdXBhIG1haWxpbmcgbGlz dA0KPiA+Pj4+PiAgICAgIFN1cGFAaWV0Zi5vcmcgPG1haWx0bzpTdXBhQGlldGYub3JnPg0KPiA+ Pj4+PiAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KPiA+ Pj4+Pg0KPiA+Pj4+PiAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+Pj4+ICAgICAgU3VwYSBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4gICAgICBT dXBhQGlldGYub3JnIDxtYWlsdG86U3VwYUBpZXRmLm9yZz4NCj4gPj4+Pj4gICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCj4gPj4+Pj4NCj4gPj4+Pj4NCj4g Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4+Pj4gU3VwYSBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4gU3VwYUBp ZXRmLm9yZw0KPiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1 cGENCj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pj4+IFN1cGEgbWFpbGluZyBsaXN0DQo+ID4+Pj4gU3VwYUBpZXRmLm9yZw0KPiA+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KPiA+Pj4+DQo+ID4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4g U3VwYSBtYWlsaW5nIGxpc3QNCj4gPj4+IFN1cGFAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KPiA+Pj4NCj4gPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gU3VwYSBtYWlsaW5nIGxp c3QNCj4gPj4gU3VwYUBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3N1cGENCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4gU3VwYSBtYWlsaW5nIGxpc3QNCj4gPj4gU3VwYUBpZXRm Lm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCj4g Pj4NCj4gPg0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPlN1cGEgbWFpbGluZyBsaXN0DQo+ID5TdXBhQGlldGYub3JnDQo+ID5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCg0K From nobody Mon Mar 7 14:52:43 2016 Return-Path: X-Original-To: supa@ietfc.amsl.com Delivered-To: supa@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DA7C21CDD08 for ; Mon, 7 Mar 2016 14:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7Q4XpTml8gx for ; Mon, 7 Mar 2016 14:52:40 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 6FC3E1CDD0F for ; Mon, 7 Mar 2016 14:52:40 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id xr8so51749127lbb.1 for ; Mon, 07 Mar 2016 14:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=dFmSecf1tGtZyle/3hmxsOq1fqbeL+RHSEvKH4/F64E=; b=S0I3ensEmdTOW7PovjAlVjeOLM04KwOX/PHhHJRm4MsEJTGn3oOCz0ug0x+rMichLb xXe8uJeBg3QdeWV2X9UEh1x2NCfM69qlpdi6mqqCyXcuAz+WSy4aMDkIFtqPc2/amRIZ KGgrsxyh0TXI1I2MBj7bxAL8pfc9c2k9lz1wQ4qT/ED5jKnvNoPaDRj65sA9CqbgzfYn qkJNvIutxqyqU75SseW+7nzdGUCWYTKGkgmw/R4J9SWxvm2PwMgUL3wVEk+1Y3INxU17 tQ2aknsnWDlxgdHsq6TRBd3zpEpmfpOmf627+rJiEmoMtU1L3q3DsldL3KDbwWlFoBrJ m21w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=dFmSecf1tGtZyle/3hmxsOq1fqbeL+RHSEvKH4/F64E=; b=lJ5mkZK20i2p1Z9y0XIanv/eu0SlsGblAkeVWnPK9BvWMtWPrSrbFAYEPVyupi32n2 PceX6u3Gg+ryuOSa0KUrbDYJBgSWgaCfW8oDDiYg/x/RCjVdU8qI5aAGkzkgoBAn2TOE fKv3JK7vuYwQNSAJp0K2eF1ucIPoborgHdIfaQDY+V1B3th986j1lsZOTQq/FeWjINwi bN+jdrZqGbrC0Mzb0nzTT8NXC6VE4h8T5MO1yKejZnMGId0qbMxC4z3wLn3/EWdVRrhO SOJuxgqXKmvnIFlJPFY9POBFpGPDzpnAecbCuYApLles6vaJMUWN6lpQEpfkFVTgDpZS mAbg== X-Gm-Message-State: AD7BkJLP7hFYA2Rs3FDU1AiBQzoa+c6fFRyaP2W2+WItI1Pw/2DEWm/+NDS8NvpR+mntyEMDmR4kLFgPl6fmQw== MIME-Version: 1.0 X-Received: by 10.25.149.68 with SMTP id x65mr8657120lfd.138.1457391158578; Mon, 07 Mar 2016 14:52:38 -0800 (PST) Received: by 10.112.132.65 with HTTP; Mon, 7 Mar 2016 14:52:38 -0800 (PST) Date: Mon, 7 Mar 2016 14:52:38 -0800 Message-ID: From: Andy Bierman To: SUPA list Content-Type: multipart/alternative; boundary=001a114038824e68f4052d7d52a4 Archived-At: Subject: [Supa] SUPA charter questions X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 22:52:42 -0000 --001a114038824e68f4052d7d52a4 Content-Type: text/plain; charset=UTF-8 Hi, I have read the SUPA WG charter a few times. https://datatracker.ietf.org/wg/supa/charter/ The purpose of the YANG data models delivered in work item (3) is not that clear to me. 3) A set of YANG data models consisting of a base policy model for representing policy management concepts independent of the type or structure of a policy, plus an extension for defining policy rules according to the event-condition-action paradigm. In the items out of scope: Specific handling of policies (although the application document will provide some examples). Therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets is also out of scope. The charter also says: The working group will have succeeded when the SUPA policy constructs are re-used in future IETF specifications Can somebody explain the purpose of the YANG modules in (3)? What operator problems do they solve? It seems that the intent is for SUPA to create typedefs and possibly groupings that other WGs can use later in real YANG modules. It seems all interactions between a controller and an NE are out of scope and left as an implementation detail. Andy --001a114038824e68f4052d7d52a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have read the SUPA WG charter a f= ew times.

The purpose of the YANG data models delivered
in work item= (3) is not that clear to me.

Spec= ific handling of policies (although the application document will provide s= ome examples). Therefore the specification of a policy engine that maps a s= pecific policy instance to actual configuration snippets is also out of sco= pe.

<= /span>
The charter also says:
The working group will have succeeded when the SUPA pol= icy constructs are re-used in future IETF specifications

Can somebody explain the purpose of= the YANG modules in (3)?
What operator problems do they solve? It seems that the intent= is for
SUPA = to create typedefs and possibly groupings that other WGs can
use later in real YANG modu= les.

It seems all int= eractions between a controller and an NE are out of
scope and left as an implementation = detail.

<= /span>

Andy

--001a114038824e68f4052d7d52a4-- From nobody Mon Mar 7 15:23:16 2016 Return-Path: X-Original-To: supa@ietfc.amsl.com Delivered-To: supa@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 391EE1CDDAE for ; Mon, 7 Mar 2016 15:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBERAucInMOr for ; Mon, 7 Mar 2016 15:23:13 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 434231CDDAF for ; Mon, 7 Mar 2016 15:23:13 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 814591E46; Tue, 8 Mar 2016 00:23:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2ziOZbEAWauL; Tue, 8 Mar 2016 00:23:06 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 8 Mar 2016 00:23:10 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 600F52003B; Tue, 8 Mar 2016 00:23:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4ZmUQ3DzrP4R; Tue, 8 Mar 2016 00:23:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60CA420038; Tue, 8 Mar 2016 00:23:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 519D73A29F2A; Tue, 8 Mar 2016 00:23:08 +0100 (CET) Date: Tue, 8 Mar 2016 00:23:08 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20160307232308.GA5410@elstar.local> Mail-Followup-To: Andy Bierman , SUPA list References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: SUPA list Subject: Re: [Supa] SUPA charter questions X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 23:23:15 -0000 On Mon, Mar 07, 2016 at 02:52:38PM -0800, Andy Bierman wrote: > Hi, > > I have read the SUPA WG charter a few times. > https://datatracker.ietf.org/wg/supa/charter/ > > The purpose of the YANG data models delivered > in work item (3) is not that clear to me. > > 3) A set of YANG data models consisting of a base policy model for > representing policy management concepts independent of the type or > structure of a policy, plus an extension for defining policy rules > according to the event-condition-action paradigm. > > In the items out of scope: > Specific handling of policies (although the application document will > provide some examples). Therefore the specification of a policy engine that > maps a specific policy instance to actual configuration snippets is also > out of scope. > > The charter also says: > The working group will have succeeded when the SUPA policy constructs are > re-used in future IETF specifications > > Can somebody explain the purpose of the YANG modules in (3)? > What operator problems do they solve? It seems that the intent is for > SUPA to create typedefs and possibly groupings that other WGs can > use later in real YANG modules. > > It seems all interactions between a controller and an NE are out of > scope and left as an implementation detail. > Yep, unfortunately the SUPA charter is all about decoration but not the cake that makes a policy engine do real stuff. I had hoped that SUPA would allow me to express policy-driven operations on YANG defined data models, nicely integrating with NETCONF/RESTCONF primitives, i.e., a policy layer with well defined primitives that operate on YANG defined data models. But somehow this idea did not fly through the chartering process and instead SUPA is chartered to work on another policy meta-model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 7 15:38:34 2016 Return-Path: X-Original-To: supa@ietfc.amsl.com Delivered-To: supa@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E1E1F1CDE31 for ; Mon, 7 Mar 2016 15:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14eBvlkC6hDe for ; Mon, 7 Mar 2016 15:38:32 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id E1FD11CDE30 for ; Mon, 7 Mar 2016 15:38:32 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:4120:eee5:d666:3cfa]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u27NcVNT002138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Mar 2016 23:38:31 GMT (envelope-from joelja@bogus.com) To: Juergen Schoenwaelder , Andy Bierman References: <20160307232308.GA5410@elstar.local> From: joel jaeggli Message-ID: <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> Date: Mon, 7 Mar 2016 15:38:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160307232308.GA5410@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lB7mVBqFli0jtshftCKoVHxojfGIIxnfu" Archived-At: Cc: SUPA list Subject: Re: [Supa] SUPA charter questions X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 23:38:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lB7mVBqFli0jtshftCKoVHxojfGIIxnfu Content-Type: multipart/mixed; boundary="rREooo6wQ3VcBlxDERksxlAugq5G52jnc" From: joel jaeggli To: Juergen Schoenwaelder , Andy Bierman Cc: SUPA list Message-ID: <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> Subject: Re: [Supa] SUPA charter questions References: <20160307232308.GA5410@elstar.local> In-Reply-To: <20160307232308.GA5410@elstar.local> --rREooo6wQ3VcBlxDERksxlAugq5G52jnc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/7/16 3:23 PM, Juergen Schoenwaelder wrote: > On Mon, Mar 07, 2016 at 02:52:38PM -0800, Andy Bierman wrote: >> Hi, >> >> I have read the SUPA WG charter a few times. >> https://datatracker.ietf.org/wg/supa/charter/ >> >> The purpose of the YANG data models delivered >> in work item (3) is not that clear to me. >> >> 3) A set of YANG data models consisting of a base policy model for >> representing policy management concepts independent of the type or >> structure of a policy, plus an extension for defining policy rules >> according to the event-condition-action paradigm. >> >> In the items out of scope: >> Specific handling of policies (although the application document will >> provide some examples). Therefore the specification of a policy engine= that >> maps a specific policy instance to actual configuration snippets is al= so >> out of scope. >> >> The charter also says: >> The working group will have succeeded when the SUPA policy constructs = are >> re-used in future IETF specifications >> >> Can somebody explain the purpose of the YANG modules in (3)? >> What operator problems do they solve? It seems that the intent is for >> SUPA to create typedefs and possibly groupings that other WGs can >> use later in real YANG modules. >> >> It seems all interactions between a controller and an NE are out of >> scope and left as an implementation detail. >> >=20 > Yep, unfortunately the SUPA charter is all about decoration but not > the cake that makes a policy engine do real stuff. >=20 > I had hoped that SUPA would allow me to express policy-driven > operations on YANG defined data models, nicely integrating with > NETCONF/RESTCONF primitives, i.e., a policy layer with well defined > primitives that operate on YANG defined data models. But somehow this > idea did not fly through the chartering process and instead SUPA is > chartered to work on another policy meta-model. I'm a little disappointed with this discussion. Supa was chartered with a explicitly simple set of work items under the assumption that they could be completed in a timely fashion and that the working group could then move on. The fact that it doesn't attempt to do everything in one go should hopefully not be a surprise. Appropriately minded individuals don't need permission to infill the missing pieces for their application. the working group should not take up such items until it's rechartered. > /js >=20 --rREooo6wQ3VcBlxDERksxlAugq5G52jnc-- --lB7mVBqFli0jtshftCKoVHxojfGIIxnfu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbeEPYACgkQ8AA1q7Z/VrLqTQCeJ0/QZbogaptK6hNaa2Un/i3x KvwAoIOpaRpruMUz1H+yJzxD8eGK0mNf =ySvv -----END PGP SIGNATURE----- --lB7mVBqFli0jtshftCKoVHxojfGIIxnfu-- From nobody Mon Mar 7 16:19:28 2016 Return-Path: X-Original-To: supa@ietfc.amsl.com Delivered-To: supa@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B17AB1CDA57 for ; Mon, 7 Mar 2016 16:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4XbvXvKHeCo for ; Mon, 7 Mar 2016 16:19:25 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id B34331CD875 for ; Mon, 7 Mar 2016 16:19:24 -0800 (PST) Received: by mail-lb0-x22d.google.com with SMTP id x1so150370820lbj.3 for ; Mon, 07 Mar 2016 16:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=WL2ELcOVn8IVzLLfIId0EwyIvl8jDPDNhoiDL7vwkPg=; b=RAfnkmu5zIwVoWiTRJpIv6f/MzwiFCDTDnHGXWoU0hXGwU1TMeKnZ9saZFSToo4sGI r9FLdYSL1Ej2OAtezUbyrQruasV3S9vVh5oCJHxIc0TvNGd25uHYAPyJZZkSABWTx3Ne wu2B03SyiN7w6q9vflhxzbWNBvyzyhwCAHvs8KQQz/bjKfJ87ELLwS2yJaP2JRfaKb1I posrZ2I3ZDp3e0iCkG201LJm/6eBDWN8BVNwiiFFlkbLTraTfG47lewQG+tBSnheAhLI QkDBzkV2hnnWqzKswpOQIOFK2xCIBAAMW2L38gTHGLTnTalS2GX3g7uZzHIE2EHZWqWJ mIug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=WL2ELcOVn8IVzLLfIId0EwyIvl8jDPDNhoiDL7vwkPg=; b=jn9zvpVwlEy96JVcjcUvj86MYwkFA2Fkiyk+zyRUeXKHDSlKp01x8wJRqknbLddwNi mJ21a3qC0Isb1rpP17eUm42E6F57Re/Ncb+KsoqxKOESSRBpO/AnDV2165cmR86I6usS vR58WX9O9obT44KfeFoWQxSYFb3/aQEEtdPeLIU1ndlRKZAw85lLXZHfzq4141cAGHtc zrF3rFL7g5PyT3XUad6n3zeHUqI7R2q2ePVV4sSkGPrOQAGz1WzdN7RVJ0rUd32KyWtX t+Le1K+HlwqF/rrYoPfqikVTV0/hreCT48lovFV+BdJFWBnSHLyWYaGIqQA7EsEiDIXo NpTg== X-Gm-Message-State: AD7BkJLzwQ6MhAu/pG4E1IbrX/3dxgpyMXVXn6xVlwwVM2ciK0tVv3KrPHuWk5waCBSs03wD5QyIVARrJm/rmA== MIME-Version: 1.0 X-Received: by 10.112.171.163 with SMTP id av3mr8511917lbc.145.1457396362802; Mon, 07 Mar 2016 16:19:22 -0800 (PST) Received: by 10.112.132.65 with HTTP; Mon, 7 Mar 2016 16:19:22 -0800 (PST) In-Reply-To: <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> References: <20160307232308.GA5410@elstar.local> <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> Date: Mon, 7 Mar 2016 16:19:22 -0800 Message-ID: From: Andy Bierman To: joel jaeggli Content-Type: multipart/alternative; boundary=001a11c36b3680e1e3052d7e88bc Archived-At: Cc: Juergen Schoenwaelder , SUPA list Subject: Re: [Supa] SUPA charter questions X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 00:19:26 -0000 --001a11c36b3680e1e3052d7e88bc Content-Type: text/plain; charset=UTF-8 Hi, IMO the charter text is not completely clear. It reads as if the author had some phased solution in mind, but it is not specified anywhere. I guess we need an actual example of the generic data models and 1 domain-specific data model that uses them. Andy On Mon, Mar 7, 2016 at 3:38 PM, joel jaeggli wrote: > On 3/7/16 3:23 PM, Juergen Schoenwaelder wrote: > > On Mon, Mar 07, 2016 at 02:52:38PM -0800, Andy Bierman wrote: > >> Hi, > >> > >> I have read the SUPA WG charter a few times. > >> https://datatracker.ietf.org/wg/supa/charter/ > >> > >> The purpose of the YANG data models delivered > >> in work item (3) is not that clear to me. > >> > >> 3) A set of YANG data models consisting of a base policy model for > >> representing policy management concepts independent of the type or > >> structure of a policy, plus an extension for defining policy rules > >> according to the event-condition-action paradigm. > >> > >> In the items out of scope: > >> Specific handling of policies (although the application document will > >> provide some examples). Therefore the specification of a policy engine > that > >> maps a specific policy instance to actual configuration snippets is also > >> out of scope. > >> > >> The charter also says: > >> The working group will have succeeded when the SUPA policy constructs > are > >> re-used in future IETF specifications > >> > >> Can somebody explain the purpose of the YANG modules in (3)? > >> What operator problems do they solve? It seems that the intent is for > >> SUPA to create typedefs and possibly groupings that other WGs can > >> use later in real YANG modules. > >> > >> It seems all interactions between a controller and an NE are out of > >> scope and left as an implementation detail. > >> > > > > Yep, unfortunately the SUPA charter is all about decoration but not > > the cake that makes a policy engine do real stuff. > > > > I had hoped that SUPA would allow me to express policy-driven > > operations on YANG defined data models, nicely integrating with > > NETCONF/RESTCONF primitives, i.e., a policy layer with well defined > > primitives that operate on YANG defined data models. But somehow this > > idea did not fly through the chartering process and instead SUPA is > > chartered to work on another policy meta-model. > > I'm a little disappointed with this discussion. Supa was chartered with > a explicitly simple set of work items under the assumption that they > could be completed in a timely fashion and that the working group could > then move on. > > The fact that it doesn't attempt to do everything in one go should > hopefully not be a surprise. > > Appropriately minded individuals don't need permission to infill the > missing pieces for their application. the working group should not take > up such items until it's rechartered. > > > /js > > > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > --001a11c36b3680e1e3052d7e88bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

IMO the charter text is not complet= ely clear.
It reads as if the author had some phased solution in = mind,
but it is not specified anywhere.=C2=A0 I guess we need an = actual
example of the generic data models and 1 domain-specific
data model that uses them.


Andy


On Mon, Mar 7, 2016 at 3:38 PM, joel jaeggli <joelja@bogus= .com> wrote:
On 3/7/16 3:23= PM, Juergen Schoenwaelder wrote:
> On Mon, Mar 07, 2016 at 02:52:38PM -0800, Andy Bierman wrote:
>> Hi,
>>
>> I have read the SUPA WG charter a few times.
>> https://datatracker.ietf.org/wg/supa/charter/<= /a>
>>
>> The purpose of the YANG data models delivered
>> in work item (3) is not that clear to me.
>>
>> 3) A set of YANG data models consisting of a base policy model for=
>> representing policy management concepts independent of the type or=
>> structure of a policy, plus an extension for defining policy rules=
>> according to the event-condition-action paradigm.
>>
>> In the items out of scope:
>> Specific handling of policies (although the application document w= ill
>> provide some examples). Therefore the specification of a policy en= gine that
>> maps a specific policy instance to actual configuration snippets i= s also
>> out of scope.
>>
>> The charter also says:
>> The working group will have succeeded when the SUPA policy constru= cts are
>> re-used in future IETF specifications
>>
>> Can somebody explain the purpose of the YANG modules in (3)?
>> What operator problems do they solve? It seems that the intent is = for
>> SUPA to create typedefs and possibly groupings that other WGs can<= br> >> use later in real YANG modules.
>>
>> It seems all interactions between a controller and an NE are out o= f
>> scope and left as an implementation detail.
>>
>
> Yep, unfortunately the SUPA charter is all about decoration but not > the cake that makes a policy engine do real stuff.
>
> I had hoped that SUPA would allow me to express policy-driven
> operations on YANG defined data models, nicely integrating with
> NETCONF/RESTCONF primitives, i.e., a policy layer with well defined > primitives that operate on YANG defined data models. But somehow this<= br> > idea did not fly through the chartering process and instead SUPA is > chartered to work on another policy meta-model.

I'm a little disappointed with this discussion. Supa was chartered with=
a explicitly simple set of work items=C2=A0 under the assumption that they<= br> could be completed in a timely fashion and that the working group could
then move on.

The fact that it doesn't attempt to do everything in one go should
hopefully not be a surprise.

Appropriately minded individuals don't need permission to infill the missing pieces for their application. the working group should not take
up such items until it's rechartered.

> /js
>



_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa


--001a11c36b3680e1e3052d7e88bc-- From nobody Mon Mar 7 23:09:41 2016 Return-Path: X-Original-To: supa@ietfc.amsl.com Delivered-To: supa@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9002E1CE13B for ; Mon, 7 Mar 2016 23:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxdC4oPW0pjO for ; Mon, 7 Mar 2016 23:09:38 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 5BD691CDF41 for ; Mon, 7 Mar 2016 23:09:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 213921986; Tue, 8 Mar 2016 08:09:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BtiJQRZEE2PM; Tue, 8 Mar 2016 08:09:30 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 8 Mar 2016 08:09:36 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41C552003A; Tue, 8 Mar 2016 08:09:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8FFrYPM_Zg5D; Tue, 8 Mar 2016 08:09:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C853D20038; Tue, 8 Mar 2016 08:09:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9357D3A2A17A; Tue, 8 Mar 2016 08:09:34 +0100 (CET) Date: Tue, 8 Mar 2016 08:09:34 +0100 From: Juergen Schoenwaelder To: joel jaeggli Message-ID: <20160308070934.GB5979@elstar.local> Mail-Followup-To: joel jaeggli , Andy Bierman , SUPA list References: <20160307232308.GA5410@elstar.local> <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Andy Bierman , SUPA list Subject: Re: [Supa] SUPA charter questions X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 07:09:39 -0000 On Mon, Mar 07, 2016 at 03:38:30PM -0800, joel jaeggli wrote: > > > > Yep, unfortunately the SUPA charter is all about decoration but not > > the cake that makes a policy engine do real stuff. > > > > I had hoped that SUPA would allow me to express policy-driven > > operations on YANG defined data models, nicely integrating with > > NETCONF/RESTCONF primitives, i.e., a policy layer with well defined > > primitives that operate on YANG defined data models. But somehow this > > idea did not fly through the chartering process and instead SUPA is > > chartered to work on another policy meta-model. > > I'm a little disappointed with this discussion. Supa was chartered with > a explicitly simple set of work items under the assumption that they > could be completed in a timely fashion and that the working group could > then move on. For me, the idea of modeling clauses that consist of terms which again consist of variables and operators and values all as distinct policy objects is like letting programmers fill in the internal data structures of a compiler directly. Nobody I know of programs at that level of abstraction. The tools I have been using to administrate a small zoo of Unix boxes all use domain specific languages to express things like conditions and actions; they do not expose expression syntax trees as the level of abstraction to an administrator. > The fact that it doesn't attempt to do everything in one go should > hopefully not be a surprise. > > Appropriately minded individuals don't need permission to infill the > missing pieces for their application. the working group should not take > up such items until it's rechartered. Yep. I will stay silent and check back in a couple of years. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 8 00:09:56 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29DE12D50E for ; Mon, 7 Mar 2016 23:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkPDME6v59cJ for ; Mon, 7 Mar 2016 23:58:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BF712D508 for ; Mon, 7 Mar 2016 23:58:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJZ27333; Tue, 08 Mar 2016 07:58:47 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Mar 2016 07:58:43 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.102]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Tue, 8 Mar 2016 15:58:37 +0800 From: Zhoutianran To: "Natale, Bob" , "colemaj@cisco.com" Thread-Topic: [Supa] Information models and Data models - WG adoption? Thread-Index: AdF5C9Btf6PL2XwARoWr2zneEGCjlQAA7oAw Date: Tue, 8 Mar 2016 07:58:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56DE8638.0086, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b1ea50a832a4032734448fedb993812e Archived-At: Cc: SUPA list Subject: Re: [Supa] Information models and Data models - WG adoption? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 07:58:57 -0000 > 1. A good way to answer that is with several other questions, e.g.: "Befo= re > YANG there was what?" "After YANG there will be what?" "From the broader > marketplace perspective, how many other non-YANG approaches to DM express= ion > must/should be supported?" If YANG DM is not the only derivable DM in this WG, I would like to withdra= w this question. > -----Original Message----- > From: Natale, Bob [mailto:RNATALE@mitre.org] > Sent: Tuesday, March 08, 2016 3:26 PM > To: Zhoutianran; colemaj@cisco.com > Cc: SUPA list > Subject: RE: [Supa] Information models and Data models - WG adoption? >=20 > Hi Tianran, >=20 > From a distant lurker (calibrate accordingly).... >=20 > From some of your other posts, I believe you already know the answers to > your questions below, so please don't consider my responses here to be a > sign of disrespect ... but I hate to see such questions left dangling, so > just to close the loop, so to speak: >=20 > 1. A good way to answer that is with several other questions, e.g.: "Befo= re > YANG there was what?" "After YANG there will be what?" "From the broader > marketplace perspective, how many other non-YANG approaches to DM express= ion > must/should be supported?" >=20 > 2. Established knowledge. RFC 3444, for a start. >=20 > 3. See #1 and #2 above. >=20 > While it is often pragmatically utilitarian for the IETF to take a narrow > view about WHAT to standardize -- i.e., such an approach often has a posi= tive > ROI for all concerned -- such is not the case for policy-based management= , > given the relative offsets from state-of-practice to need. However (while > this is not my position), it is reasonable to suggest that in such cases > the IETF should decline to pursue the requisite standards and hand that > task off to some other SDO. That's a more reasonable position when it is > NOT accompanied by a decision to pursue yet-another-niche-solution (YANS) > in the interim. In the PBM case, it is the plethora of YANS in the absenc= e > of a general model that is now an equal contributor (along with the natur= e > of the beast itself) to the complexity of finding a more general solutio= n. > (Note that "more general" does not equate to a "universal" solution ... > solution scope should be slightly problem space and marketplace driven > however.) >=20 > As Juergen has noted since I started composing this post, the more genera= l > solution adds a time delay relative to the possibility of any viable disc= rete > solution. However, if my assertion that each new such discrete solution > merely adds to both the need for and the difficulty of designing the more > general solution is true, then ... well, you can do the math for yourself= . >=20 > Avanti, > BobN >=20 > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Zhoutianran > Sent: Sunday, March 06, 2016 10:49 PM > To: colemaj@cisco.com > Cc: SUPA list > Subject: Re: [Supa] Information models and Data models - WG adopion? >=20 > Hi Jason, >=20 > >As for the information model versus data model discussion, I think that > an information model is required to allow for different data models to fo= llow > a common structure. >=20 > >The architecture document would define the role of the information > >model clearly >=20 > I would very like to see this been discussed and addressed in the archite= cture > 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. Aft= er > 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 item= s > with "type-value" pair. So that there will be generic DM and specific DM. > Then how can IM be more for DM. >=20 > If those could be address, I think that will be much help. >=20 > Best, > Tianran >=20 > > -----Original Message----- > > From: Jason Coleman (colemaj) [mailto:colemaj@cisco.com] 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 > > Cc: Nevil Brownlee; SUPA list > > Subject: Re: [Supa] Information models and Data models - WG adopion? > > > > I would like to be part of working on an architecture document as well. > > > > 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 mo= dels > 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" > > wrote: > > > > >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:bwietf@bwijnen.net] > > >Sent: 04 March 2016 10:11 > > >To: King, Daniel ; Joel M. Halpern > > >; Andy Bierman ; John > > >Strassner ; Zhoutianran > > > > > >Cc: Nevil Brownlee ; SUPA list > > > > > >Subject: Re: [Supa] Information models and Data models - WG adopion? > > > > > >On 03/03/16 17:41, King, Daniel wrote: > > >> 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? > > >Dan, I am willing to take initiative on this. > > > > > >I saw in one of Johns postings: > > > Well, we don't have an architecture document currently in our char= ter > > > (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. > > > > > >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. > > >> > > >> -----Original Message----- > > >> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen > > >> (IETF) > > >> Sent: 03 March 2016 16:13 > > >> To: Joel M. Halpern ; Andy Bierman > > >> ; John Strassner > > >> Cc: Zhoutianran ; Nevil Brownlee > > >> ; SUPA list > > >> Subject: Re: [Supa] Information models and Data models - WG adopion? > > >> > > >> Inline > > >> > > >> On 03/03/16 16:48, Joel M. Halpern wrote: > > >>> 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= ". > > >> 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 > > >>> Yours, > > >>> Joel > > >>> > > >>> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: > > >>>> 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 > > >>>>> > >>>>> > > > >>>>> wrote: > > >>>>> > > >>>>> 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 in= herent > > >>>>> 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 organiz= ation, > > >>>>> there is no guarantee that its output will be useful to > the > > >>>>> IETF. I am active in the TM Forum, which you cited; the= y > 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. > > >>>>> > > >>>>> > > >>>>> > > >>>>> 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 implementati= on? > > >>>>> 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 ha= ve. > > >>>>> 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:supa-bounces@ietf.org > > >>>>> ] 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, > > >>>>> > > >>>>> 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 > > >>>>> > > >>>>> > -----Original Message----- > > >>>>> > From: Supa [mailto:supa-bounces@ietf.org > > >>>>> ] 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"). > > >>>>> > > > >>>>> > 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 suppo= rt. > > >>>>> > > > > >>>>> > > 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:supa-bounces@ietf.org > > >>>>> ] On Behalf Of IETF > > >>>>> > >> Secretariat > > >>>>> > >> Sent: Monday, February 29, 2016 6:35 AM > > >>>>> > >> To: > > >>>>> draft-strassner-supa-generic-policy-info-model@ietf.org > > >>>>> > ; > > >>>>> > >> supa-chairs@ietf.org ; > > >>>>> supa@ietf.org > > >>>>> > >> 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 > > >>>>> > >> Supa@ietf.org > > >>>>> > >> 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 > > >>>>> > > > >>>>> > _______________________________________________ > > >>>>> > Supa mailing list > > >>>>> > Supa@ietf.org > > >>>>> > https://www.ietf.org/mailman/listinfo/supa > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Supa mailing list > > >>>>> Supa@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/supa > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Supa mailing list > > >>>>> Supa@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/supa > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Supa mailing list > > >>>>> Supa@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/supa > > >>>> _______________________________________________ > > >>>> Supa mailing list > > >>>> Supa@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/supa > > >>>> > > >>> _______________________________________________ > > >>> Supa mailing list > > >>> Supa@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/supa > > >>> > > >> _______________________________________________ > > >> Supa mailing list > > >> Supa@ietf.org > > >> https://www.ietf.org/mailman/listinfo/supa > > >> > > >> _______________________________________________ > > >> Supa mailing list > > >> Supa@ietf.org > > >> https://www.ietf.org/mailman/listinfo/supa > > >> > > > > > >_______________________________________________ > > >Supa mailing list > > >Supa@ietf.org > > >https://www.ietf.org/mailman/listinfo/supa >=20 > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa From nobody Tue Mar 8 01:21:17 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ED812D58A for ; Tue, 8 Mar 2016 01:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-yCfU-S2GyF for ; Tue, 8 Mar 2016 01:21:11 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 8165212D585 for ; Tue, 8 Mar 2016 01:21:10 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CD6936C4054; Tue, 8 Mar 2016 02:26:34 -0500 (EST) Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id B9DE46C4053; Tue, 8 Mar 2016 02:26:34 -0500 (EST) Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 8 Mar 2016 02:26:34 -0500 Received: from gcc01-CY1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Tue, 8 Mar 2016 02:26:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=swcTd8FuQaogQfo6JtYT+hV3G58ic/FNvz7ZTGNxSkM=; b=mdQNieMBe8tP2daZegpT7zVFmsz/MQCImLclvoDnukWsYWvJgRUzzHqsGswbjpw5hjYarKl1yPac4OoEmkEcBTspBKA05ZBR0UCGCDDkKbYSufVskDdWUOXlG/sr2R9MLw+Qk+LHVpOZnJvbq2ZNpCunGYTr4T8B/pgSba+4kAw= Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0921.namprd09.prod.outlook.com (10.163.89.14) with Microsoft SMTP Server (TLS) id 15.1.427.16; Tue, 8 Mar 2016 07:26:27 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.0427.019; Tue, 8 Mar 2016 07:26:26 +0000 From: "Natale, Bob" To: Zhoutianran , "colemaj@cisco.com" Thread-Topic: [Supa] Information models and Data models - WG adoption? Thread-Index: AdF5C9Btf6PL2XwARoWr2zneEGCjlQ== Date: Tue, 8 Mar 2016 07:26:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=mitre.org; x-originating-ip: [192.80.55.88] x-ms-office365-filtering-correlation-id: 7513a59e-e192-4f0f-a58e-08d34722f5c2 x-microsoft-exchange-diagnostics: 1; CY1PR09MB0921; 5:vDiuiilDpr9+VNsm5XN7Ur+3oB2/orz/vM7jLW05dWNLwZMH616i3UdLS7FAZ8gP+iZa9pzcKIXURjgvFD5ziDGutNgmTqFrafqMsjt6iDHDWaHpMMqHzSiDo6yKcypYor2AXpYbHcXf9sOe0Sf4iw==; 24:gmLm9t5Rv8UfytGGOYMIdgnRsL+vuzqoFeltER3Rq4KSNArPv0oy2y0QhTu0cxdsOoTx+FK+HHZBXjwwbKCZXHbx1l1dgURvLsKA+/3g5NU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0921; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR09MB0921; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0921; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(51444003)(13464003)(24454002)(479174004)(377454003)(53754006)(189998001)(76576001)(86362001)(561944003)(92566002)(1096002)(1220700001)(5001770100001)(77096005)(40100003)(122556002)(3280700002)(4326007)(15975445007)(81166005)(3846002)(586003)(3660700001)(74316001)(33656002)(2501003)(2900100001)(10400500002)(5004730100002)(87936001)(19580395003)(19580405001)(50986999)(54356999)(5002640100001)(2906002)(6116002)(102836003)(5008740100001)(5003600100002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0921; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2016 07:26:26.4037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0921 X-OriginatorOrg: mitre.org Archived-At: Cc: SUPA list Subject: Re: [Supa] Information models and Data models - WG adoption? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 09:21:16 -0000 Hi Tianran, >From a distant lurker (calibrate accordingly).... >From some of your other posts, I believe you already know the answers to yo= ur questions below, so please don't consider my responses here to be a sign= of disrespect ... but I hate to see such questions left dangling, so just = to close the loop, so to speak: 1. A good way to answer that is with several other questions, e.g.: "Before= YANG there was what?" "After YANG there will be what?" "From the broader m= arketplace perspective, how many other non-YANG approaches to DM expression= must/should be supported?" 2. Established knowledge. RFC 3444, for a start. 3. See #1 and #2 above. While it is often pragmatically utilitarian for the IETF to take a narrow v= iew about WHAT to standardize -- i.e., such an approach often has a positiv= e ROI for all concerned -- such is not the case for policy-based management= , given the relative offsets from state-of-practice to need. However (while= this is not my position), it is reasonable to suggest that in such cases t= he IETF should decline to pursue the requisite standards and hand that task= off to some other SDO. That's a more reasonable position when it is NOT ac= companied by a decision to pursue yet-another-niche-solution (YANS) in the = interim. In the PBM case, it is the plethora of YANS in the absence of a ge= neral model that is now an equal contributor (along with the nature of the = beast itself) to the complexity of finding a more general solution. (Note = that "more general" does not equate to a "universal" solution ... solution = scope should be slightly problem space and marketplace driven however.) As Juergen has noted since I started composing this post, the more general = solution adds a time delay relative to the possibility of any viable discre= te solution. However, if my assertion that each new such discrete solution = merely adds to both the need for and the difficulty of designing the more g= eneral solution is true, then ... well, you can do the math for yourself. Avanti, BobN -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Zhoutianran Sent: Sunday, March 06, 2016 10:49 PM To: colemaj@cisco.com Cc: SUPA list Subject: Re: [Supa] Information models and Data models - WG adopion? Hi Jason, >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. >The architecture document would define the role of the information=20 >model clearly I would very like to see this been discussed and addressed in the architect= ure document. Especially, 1. How the information model can help data model generation if we know we w= ill deliver YANG DMs? I mean on one hand we can improve the information mod= el, then generate a YANG DM; on the other hand, we can just work on a YANG = DMs and improve it. What's the difference?=20 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.=20 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. T= hen how can IM be more for DM. If those could be address, I think that will be much help. Best, Tianran > -----Original Message----- > From: Jason Coleman (colemaj) [mailto:colemaj@cisco.com] On Behalf Of=20 > colemaj > Sent: Saturday, March 05, 2016 1:28 AM > To: King, Daniel; Bert Wijnen (IETF); Joel M. Halpern; Andy Bierman;=20 > John Strassner; Zhoutianran > Cc: Nevil Brownlee; SUPA list > Subject: Re: [Supa] Information models and Data models - WG adopion? >=20 > I would like to be part of working on an architecture document as well. >=20 > As for the information model versus data model discussion, I think=20 > that an information model is required to allow for different data=20 > models to follow a common structure. > It is possible to create a data model first, but that data model may=20 > not fit in well with other data models. This is why the information=20 > model exists to allow for things that may extend that data model or=20 > are in place for other data models. >=20 > At this time the focus is on Event, Condition, Action, but there will=20 > be further management structures to define. > The information model supports a general structure and then provides=20 > details on ECA. That general structure is important for future data mode= ls as well. > Those may be YANG or other people may chose to use the information=20 > model to create a data model in a different way. >=20 > The architecture document would define the role of the information=20 > model clearly, which I think that part of the ID that John, Joel, and=20 > I worked on attempts to do as well, and then can show how the data=20 > models will be supported by the information model and what else the WG=20 > Charter has defined and possibly where we go next. >=20 > Jason >=20 >=20 >=20 > On 3/4/16, 7:34 AM, "Supa on behalf of King, Daniel"=20 > wrote: >=20 > >Hi Bert, > > > >Thank for taking the initiative. We can make sure there is time on=20 > >the > agenda for the I-D. > > > >BR, Dan. > > > >-----Original Message----- > >From: Bert Wijnen (IETF) [mailto:bwietf@bwijnen.net] > >Sent: 04 March 2016 10:11 > >To: King, Daniel ; Joel M. Halpern=20 > >; Andy Bierman ; John=20 > >Strassner ; Zhoutianran=20 > > > >Cc: Nevil Brownlee ; SUPA list=20 > > > >Subject: Re: [Supa] Information models and Data models - WG adopion? > > > >On 03/03/16 17:41, King, Daniel wrote: > >> Hi All. > >> > >> We have a placeholder in the SUPA Charter for: > >> > >> 1) An explanation of the scope of the policy-based management=20 > >> framework > and how it relates to existing work of the IETF. > >> > >> A proposal for this document has not been forthcoming thus far. It=20 > >> would > seem that a "Policy-based Management Framework" discussing=20 > architecture, applicability and relationships ("system overview")=20 > would be reasonable content for a framework document mentioned in the Cha= rter? > >> > >> Furthermore, Andy, Tianran and Bert all seem willing to support > development (via direct contributions) for the framework/architecture=20 > document? > >Dan, I am willing to take initiative on this. > > > >I saw in one of Johns postings: > > Well, we don't have an architecture document currently in our charte= r > > (though I would support amending the charter to include this). In th= e > > (now expired) proposition draft (which we are now working on to reis= sue), > > there was an exemplary architecture. > > > >John, do you have the piece of text in an XML file (I-D source file)=20 > >and > if so, can you send that to me. I assume you are OK with us using that=20 > as a starting point? > > > >Dan/Nevil, if we submit an in initial I-D timely, do you think we can=20 > >spend > some time on it in our IETF95 session? > > > >Thanks, > >Bert > > > > > > > >> BR, Dan. > >> > >> -----Original Message----- > >> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen > >> (IETF) > >> Sent: 03 March 2016 16:13 > >> To: Joel M. Halpern ; Andy Bierman=20 > >> ; John Strassner > >> Cc: Zhoutianran ; Nevil Brownlee=20 > >> ; SUPA list > >> Subject: Re: [Supa] Information models and Data models - WG adopion? > >> > >> Inline > >> > >> On 03/03/16 16:48, Joel M. Halpern wrote: > >>> Two separate but related quesitons. > >>> > >>> 1) Can you help use find the places where the model / text is too=20 > >>> implementation specific? There are a few places where in=20 > >>> describing enumerations the model calls for integers. In the=20 > >>> mapping to YANG, I > have already started replacing those with Enumerations. Are there=20 > other kinds of over-specificity? > >>> > >>> 2) The charter allows for a range of implementations of the SUPA=20 > >>> system. Folks may recall I asked in the room at the last meeting=20 > >>> whether our chartered allowd both communication between a control=20 > >>> system and a device, and communication between a policy repository=20 > >>> and > a policy engine. I was told by the AD that the chartered allowed=20 > 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=20 > >> a > choice what we prefer and standardize that? > >> If we do both concurrently or a longside each other, can we then=20 > >> still > guarantee interoperability (which I think is one of our main=20 > objctives, no)? > >>> 2') I do think that there are a few places in the model,=20 > >>> particularly with regard to policy execution status, where the=20 > >>> model > makes some assumptions about the structure of policy delivery. For=20 > the most part, those should be removed. Assistance in finding > >>> them is appreciated. I suspect that some of them are necessary,=20 > >>> 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=20 > >>> we could > amend the charter to permit an architecture document. > >>> > >> I would say an "Architecture" or "System Overview" document would=20 > >> be > a good thing. > >> > >> Bert > >>> Yours, > >>> Joel > >>> > >>> On 3/3/16 10:27 AM, Bert Wijnen (IETF) wrote: > >>>> 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=20 > >>>>> >>>>> > > >>>>> wrote: > >>>>> > >>>>> We should work on an information model for several reasons,=20 > >>>>> even > if > >>>>> there is only target data model (i.e., YANG): > >>>>> > >>>>> 1) An information model can define how data are related to e= ach > >>>>> other independent of implementation. This is much=20 > >>>>> harder to > do > >>>>> in YANG. Hence, the information model may make these inhe= rent > >>>>> relationships easier to visualize and define. > >>>>> 2) An information model separates the logical design from th= e > >>>>> physical design of the system, enabling a deeper > understanding > >>>>> of both independent of implementation. This can be used t= o > >>>>> produce more powerful implementations. > >>>>> 3) If an information model is worked on in another organizat= ion, > >>>>> there is no guarantee that its output will be useful to t= he > >>>>> IETF. I am active in the TM Forum, which you cited; they = are > >>>>> in general not worried about implementing YANG models, mu= ch > >>>>> less producing optimal YANG models. > >>>>> 4) This enables other SDOs and fora, which do not use YANG, = to > >>>>> more easily understand our output. > >>>>> > >>>>> > >>>>> > >>>>> It seems to me that your draft has many details related to the=20 > >>>>> abstraction of policy logic, but also many aspects that look=20 > >>>>> 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=20 > >>>>> 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 RF= Cs? > >>>>> Is there a difference between a SUPA engine running at the=20 > >>>>> device level or the controller level? What data is available=20 > >>>>> for policy enforcement analysis? > >>>>> Is this configurable through YANG modules implemented by a SUPA eng= ine? > >>>>> 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=20 > >>>>> 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=20 > >>>>> and a workable solution will require a lot more than that. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> John > >>>>> > >>>>> > >>>>> > >>>>> Andy > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Supa [mailto:supa-bounces@ietf.org=20 > >>>>> ] 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, > >>>>> > >>>>> I am not arguing information model is useless, but it can=20 > >>>>> be worked out in other organizations if necessary, e.g. TMF. > >>>>> If in SUPA we can worked on YANG data models directly, why=20 > >>>>> we firstly work on an information model and then translate it to > >>>>> YANG data model? > >>>>> It just not makes sense to me. > >>>>> > >>>>> Tianran > >>>>> > >>>>> > -----Original Message----- > >>>>> > From: Supa [mailto:supa-bounces@ietf.org=20 > >>>>> ] 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 -=20 > >>>>> WG adopion? > >>>>> > > >>>>> > > >>>>> > Hi Tianran: > >>>>> > > >>>>> > In my experiences, having a well-defined information=20 > >>>>> model is a good starting > >>>>> > point. It allows different implementations, each of=20 > >>>>> which can develop it's > >>>>> > own data model - in other words, the information model is=20 > >>>>> a good unifying > >>>>> > influence - which is why publishing such a document is=20 > >>>>> the second of our > >>>>> > chart items. I hope that getting a good data model will=20 > >>>>> help us with the > >>>>> > first chart item ("scope of the policy-based management=20 > >>>>> framework"). > >>>>> > > >>>>> > draft-strassner-supa-generic-policy-info-model is the=20 > >>>>> only > SUPA > >>>>> > information model that's had any work done on it since=20 > >>>>> IETF 95, therefore > >>>>> > I've proposed it for WG adoption. > >>>>> > > >>>>> > As for the third charter item - "set of YANG data=20 > >>>>> models", there are two > >>>>> > of these on the SUPA documents page. It would help at=20 > >>>>> this stage if their > >>>>> > authors could comment on this list about the status of=20 > >>>>> these drafts. In > >>>>> > particular, jave they been working on a new version? > >>>>> > > >>>>> > Overall, we really need more discussion on the list of=20 > >>>>> 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,=20 > >>>>> why do we spend > >>>>> > time working on this information model? > >>>>> > > > >>>>> > > Why not focus on the ECA YANG data model directly as=20 > >>>>> standard track? > >>>>> > > > >>>>> > > > >>>>> > > Tianran > >>>>> > > > >>>>> > >> -----Original Message----- > >>>>> > >> From: Supa [mailto:supa-bounces@ietf.org=20 > >>>>> ] On Behalf Of IETF > >>>>> > >> Secretariat > >>>>> > >> Sent: Monday, February 29, 2016 6:35 AM > >>>>> > >> To: > >>>>> draft-strassner-supa-generic-policy-info-model@ietf.org > >>>>> ; > >>>>> > >> supa-chairs@ietf.org ;=20 > >>>>> supa@ietf.org > >>>>> > >> Subject: [Supa] The SUPA WG has placed > >>>>> > >> draft-strassner-supa-generic-policy-info-model in=20 > >>>>> state "Call For > >>>>> > >> Adoption By WG Issued" > >>>>> > >> > >>>>> > >> > >>>>> > >> The SUPA WG has placed=20 > >>>>> draft-strassner-supa-generic-policy-info-model > >>>>> > >> in state Call For Adoption By WG Issued (entered by=20 > >>>>> 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=20 > >>>>> charter items > >>>>> > >> build on this > >>>>> > >> > >>>>> > >> _______________________________________________ > >>>>> > >> Supa mailing list > >>>>> > >> Supa@ietf.org > >>>>> > >> 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, Ne= w > >>>>> Zealand > >>>>> > > >>>>> > _______________________________________________ > >>>>> > Supa mailing list > >>>>> > Supa@ietf.org > >>>>> > https://www.ietf.org/mailman/listinfo/supa > >>>>> > >>>>> _______________________________________________ > >>>>> Supa mailing list > >>>>> Supa@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/supa > >>>>> > >>>>> _______________________________________________ > >>>>> Supa mailing list > >>>>> Supa@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/supa > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Supa mailing list > >>>>> Supa@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/supa > >>>> _______________________________________________ > >>>> Supa mailing list > >>>> Supa@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/supa > >>>> > >>> _______________________________________________ > >>> Supa mailing list > >>> Supa@ietf.org > >>> https://www.ietf.org/mailman/listinfo/supa > >>> > >> _______________________________________________ > >> Supa mailing list > >> Supa@ietf.org > >> https://www.ietf.org/mailman/listinfo/supa > >> > >> _______________________________________________ > >> Supa mailing list > >> Supa@ietf.org > >> https://www.ietf.org/mailman/listinfo/supa > >> > > > >_______________________________________________ > >Supa mailing list > >Supa@ietf.org > >https://www.ietf.org/mailman/listinfo/supa _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Tue Mar 8 02:45:15 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E264B12D5CA for ; Tue, 8 Mar 2016 02:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0MkYY8SvlQo for ; Tue, 8 Mar 2016 02:45:14 -0800 (PST) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5276212D61F for ; Tue, 8 Mar 2016 02:39:38 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud2.xs4all.net with ESMTP id TNfa1s00q3vXPcr01Nfbpm; Tue, 08 Mar 2016 11:39:36 +0100 To: Zhoutianran , "Natale, Bob" , "colemaj@cisco.com" References: From: "Bert Wijnen (IETF)" Message-ID: <56DEABE5.2000304@bwijnen.net> Date: Tue, 8 Mar 2016 11:39:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SUPA list Subject: Re: [Supa] Information models and Data models - WG adoption? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 10:45:15 -0000 On 08/03/16 08:58, Zhoutianran wrote: >> 1. A good way to answer that is with several other questions, e.g.: "Before >> >YANG there was what?" "After YANG there will be what?" "From the broader >> >marketplace perspective, how many other non-YANG approaches to DM expression >> >must/should be supported?" > If YANG DM is not the only derivable DM in this WG, I would like to withdraw this question. > > I suppose that a YANG DM will be one of the deliverables of this WG. And this WG will probably not do any data modeling in any other language. But other SDOs might have/use a different language to do data modeling. And as Bob stated, maybe a few (many) years from now, there is a YANS (or some other data modeling language that we(IETF) like better than YANG (I cannot yet imagine that, but that is an aside), then we may want to re-do the YANG DM in this new language. Much like we are now re-doing a lot of stuff in YANG modules that already exists in MIB modules. I do agree though that we SHOULD do the real DM as well as the IM (in whatever form we do the IM) so that we can prove that we can define an implementable DM. Hope this helps. Bert From nobody Tue Mar 8 07:38:45 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BDE12D7A2 for ; Tue, 8 Mar 2016 07:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMvs9j2rbwlf for ; Tue, 8 Mar 2016 07:38:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA44A12D7A4 for ; Tue, 8 Mar 2016 07:38:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFO41052; Tue, 08 Mar 2016 15:38:31 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Mar 2016 15:38:30 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.102]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Tue, 8 Mar 2016 23:38:23 +0800 From: Zhoutianran To: "Bert Wijnen (IETF)" , "Natale, Bob" , "colemaj@cisco.com" Thread-Topic: [Supa] Information models and Data models - WG adoption? Thread-Index: AdF5C9Btf6PL2XwARoWr2zneEGCjlQAA7oAw//+oaYCAANRiQw== Date: Tue, 8 Mar 2016 15:38:23 +0000 Message-ID: References: , <56DEABE5.2000304@bwijnen.net> In-Reply-To: <56DEABE5.2000304@bwijnen.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.227.200] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56DEF1F8.03F7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5bb6a1c66faba1548fa3c2b8f6ddd89c Archived-At: Cc: SUPA list Subject: Re: [Supa] Information models and Data models - WG adoption? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 15:38:42 -0000 VGhhdCBtYWtlcyBzZW5zZSB0byBtZS4NCkFuZCB0aGUgRE0gZG9jdW1lbnQgc2hvdWxkIGJlIG1v cmUgb24gaG93IHRvIHJlcHJlc2VudCBpbmZvcm1haXRvbnMgaW4gWUFORy4NCldoaWxlIHRoZSBJ TSBjYW4gaGF2ZSBtb3JlIHdvcmRzIGludHJvZHVjaW5nIHdoYXQgYW4gaXRlbSBpcyBhbmQgd2h5 IHdlIG5lZWQgYW4gaXRlbS4NCg0KVGlhbnJhbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kt6K8/sjLOiBCZXJ0IFdpam5lbiAoSUVURikgW2J3aWV0ZkBid2lqbmVu Lm5ldF0NCreiy83KsbzkOiAyMDE2xOoz1MI4yNUgMTg6MzkNCsrVvP7IyzogWmhvdXRpYW5yYW47 IE5hdGFsZSwgQm9iOyBjb2xlbWFqQGNpc2NvLmNvbQ0Ks63LzTogU1VQQSBsaXN0DQrW98ziOiBS ZTogW1N1cGFdIEluZm9ybWF0aW9uIG1vZGVscyBhbmQgRGF0YSBtb2RlbHMgLSBXRyBhZG9wdGlv bj8NCg0KT24gMDgvMDMvMTYgMDg6NTgsIFpob3V0aWFucmFuIHdyb3RlOg0KPj4gMS4gQSBnb29k IHdheSB0byBhbnN3ZXIgdGhhdCBpcyB3aXRoIHNldmVyYWwgb3RoZXIgcXVlc3Rpb25zLCBlLmcu OiAiQmVmb3JlDQo+PiA+WUFORyB0aGVyZSB3YXMgd2hhdD8iICJBZnRlciBZQU5HIHRoZXJlIHdp bGwgYmUgd2hhdD8iICJGcm9tIHRoZSBicm9hZGVyDQo+PiA+bWFya2V0cGxhY2UgcGVyc3BlY3Rp dmUsIGhvdyBtYW55IG90aGVyIG5vbi1ZQU5HIGFwcHJvYWNoZXMgdG8gRE0gZXhwcmVzc2lvbg0K Pj4gPm11c3Qvc2hvdWxkIGJlIHN1cHBvcnRlZD8iDQo+IElmIFlBTkcgRE0gaXMgbm90IHRoZSBv bmx5IGRlcml2YWJsZSBETSBpbiB0aGlzIFdHLCBJIHdvdWxkIGxpa2UgdG8gd2l0aGRyYXcgdGhp cyBxdWVzdGlvbi4NCj4NCj4NCkkgc3VwcG9zZSB0aGF0IGEgWUFORyBETSB3aWxsIGJlIG9uZSBv ZiB0aGUgZGVsaXZlcmFibGVzIG9mIHRoaXMgV0cuDQpBbmQgdGhpcyBXRyB3aWxsIHByb2JhYmx5 IG5vdCBkbyBhbnkgZGF0YSBtb2RlbGluZyBpbiBhbnkgb3RoZXIgbGFuZ3VhZ2UuDQoNCkJ1dCBv dGhlciBTRE9zIG1pZ2h0IGhhdmUvdXNlIGEgZGlmZmVyZW50IGxhbmd1YWdlIHRvIGRvIGRhdGEg bW9kZWxpbmcuDQpBbmQgYXMgQm9iIHN0YXRlZCwgbWF5YmUgYSBmZXcgKG1hbnkpIHllYXJzIGZy b20gbm93LCB0aGVyZSBpcyBhIFlBTlMNCihvciBzb21lIG90aGVyIGRhdGEgbW9kZWxpbmcgbGFu Z3VhZ2UgdGhhdCB3ZShJRVRGKSBsaWtlIGJldHRlciB0aGFuDQpZQU5HIChJIGNhbm5vdCB5ZXQg aW1hZ2luZSB0aGF0LCBidXQgdGhhdCBpcyBhbiBhc2lkZSksIHRoZW4gd2UgbWF5DQp3YW50IHRv IHJlLWRvIHRoZSBZQU5HIERNIGluIHRoaXMgbmV3IGxhbmd1YWdlLiBNdWNoIGxpa2Ugd2UgYXJl IG5vdw0KcmUtZG9pbmcgYSBsb3Qgb2Ygc3R1ZmYgaW4gWUFORyBtb2R1bGVzIHRoYXQgYWxyZWFk eSBleGlzdHMgaW4gTUlCDQptb2R1bGVzLg0KDQpJIGRvIGFncmVlIHRob3VnaCB0aGF0IHdlIFNI T1VMRCBkbyB0aGUgcmVhbCBETSBhcyB3ZWxsIGFzIHRoZSBJTQ0KKGluIHdoYXRldmVyIGZvcm0g d2UgZG8gdGhlIElNKSBzbyB0aGF0IHdlIGNhbiBwcm92ZSB0aGF0IHdlIGNhbiBkZWZpbmUNCmFu IGltcGxlbWVudGFibGUgRE0uDQoNCkhvcGUgdGhpcyBoZWxwcy4NCkJlcnQ= From nobody Tue Mar 8 08:05:26 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED1412D775 for ; Tue, 8 Mar 2016 08:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXmCqrToxd7u for ; Tue, 8 Mar 2016 08:05:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970EF12D7EA for ; Tue, 8 Mar 2016 08:04:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJZ97803; Tue, 08 Mar 2016 16:04:12 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Mar 2016 16:04:10 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.102]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Wed, 9 Mar 2016 00:04:03 +0800 From: Zhoutianran To: Andy Bierman Thread-Topic: [Supa] Information models and Data models - WG adopion? Thread-Index: AQHRdA2mOZC2OcBCLECSqIAKm8tvNJ9FdHGAgAEVCICAAB1DgIAArWQAgAAFyoCAAAbwgIAAB/cAgAElLACAADj0AIAAQV+AgAAAXYCAAAjogIAGqtWJ Date: Tue, 8 Mar 2016 16:04:02 +0000 Message-ID: References: <20160228223430.13221.49372.idtracker@ietfa.amsl.com> <56D61E15.1070302@auckland.ac.nz> <56D857D6.1010804@bwijnen.net> <56D85CB1.2070703@joelhalpern.com> <56D86283.2050403@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBD0B0@EX-0-MB2.lancs.local> <56D95F20.7080006@bwijnen.net> <65174429B5AF4C45BD0798810EC48E0A8BCBDA45@EX-0-MB2.lancs.local> <909DAC0E-7372-448D-A670-DF302157B0AC@cisco.com> <5FD5189A-9B4A-4F7F-9856-169EAB8B1171@me.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.227.200] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56DEF7FC.0495, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 97528be5817d802e4f99a7371c95f527 Archived-At: Cc: SUPA list , "Bert Wijnen \(IETF\)" Subject: Re: [Supa] Information models and Data models - WG adopion? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 16:05:23 -0000 TXkgYnJpZWYgdGhvdWdodHMgb24gU1VQQSBhcmNoIGlzIGFzIGZvbGxvd3M6IA0KDQoxLiBQb3Np dGlvbiBvZiB0aGUgcG9saWN5IGVuZ2luZQ0KTmV0d29yayBjYW4gYmUgbW9kZWxlZCB3aXRoIG11 bHRpcGxlIGxheWVycy4gUG9saWNpZXMgY2FuIGJlIGFwcGxpZWQgdG8gYWxsIHRoZSBsYXllcnMg dG8gYWNoaWV2ZSByZXF1aXJlbWVudHMgZnJvbSB2YXJpb3VzIHR5cGUgb2YgYWN0b3JzLg0KYSkg ZGV2aWNlLWxldmVsOiBwb2xpY3kgY2FuIG9ubHkgYmUgYWNjZXNzZWQgYW5kIGVuZm9yY2VkIG9u IG9uZSBkZXZpY2UuIFRoZSBwb2xpY3kgY29udHJvbHMgdGhlIGR5bmFtaWMgYmVoYXZpb3Vycywg ZS5nLiBRb1MsIGRlY2Fwc3VsYXRpb24sIGVuY2Fwc3VsYXRpb24sIGFuZCBmb3J3YXJkaW5nLiAN CmIpIG5ldHdvcmstbGV2ZWw6IHBvbGljeSBjYW4gYmUgY29uZmlndXJlZCB0byBjb21tdW5pY2F0 ZSB3aXRoIG11bHRpcGxlIG5ldHdvcmsgZWxlbWVudHMuIFRoZSBwb2xpY3kgY29udHJvbHMgdGhl IGFkanVzdG1lbnQgb2YgdGVjaG5pcXVlIHJlbGF0ZWQgbmV0d29yayBzb2x1dGlvbnMsIGUuZy4g TDNWUE4sIEwyVlBOLg0KYykgc2VydmljZS1sZXZlbDogcG9saWNpZXMgYXJlIGFic3RyYWN0ZWQg dG8gYmUgdGVjaG5pcXVlIGluZGVwZW5kZW50LCBhbmQgcHJvdmlkZWQgZm9yIHRoZSBoaWdoZXIg bGV2ZWwgdXNlcnMuIFRoZSBjdXN0b21lciBmYWNpbmcgcG9saWN5IGlzIHByb3ZpZGVkIHRvIHJl ZHVjZSB0aGUgb3BlcmF0aW9uIG9uIHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50LCBnZW5lcmljIFZQ TiBzZXJ2aWNlLCB1bmlmaWVkIHR1bm5lbCBzZXJ2aWNlcy4NCg0KMi4gcG9saWN5IGVuZ2luZSBm cmFtZXdvcmsNClRoaXMgaXMgYSBicmllZiBwb2xpY3kgZW5naW5lIGZyYW1ld29yay4NCg0KaGln aGVyIGxldmVsIGV2ZW50DQogIF4gICAgICAgICAgKyBwb2xpY3kgb3BlcmF0aW9ucw0KICB8ICAg ICAgICAgIHwNCiAgfCAgICAgICAgICB8DQorLSstLS0tLS0tLS0tdi0tLS0tLS0rDQp8ICAgICAg ICAgICAgICAgICAgICA8LS0tLS0tKw0KfCAgICBQb2xpY3kgRW5naW5lICAgfCAgY29uY3JldGUg cG9saWN5IERNDQp8ICAgICAgICAgICAgICAgICAgICB8DQorLV4tLS0tLS0tLS0tLS0tLS0tLS0r DQogIHwNCiAgfA0KICArIGxvd2VyIGxldmVsIGV2ZW50DQoNClRoZSBwb2xpY3kgZW5naW5lIGlz IGNvbmZpZ3VyZWQgd2l0aCBjb25jcmV0ZSBwb2xpY3kgRE1zLCBzbyB0aGF0IGl0IGNhbiBkZWFs IHdpdGggYXNzaWduZWQgcG9saWNpZXMuIFRoZSBjb25jcmV0ZSBwb2xpY3kgRE0gY2FuIGdlbmVy YXRlIGRhdGEtc3RvcmUgYW5kIG5vcnRoYm91bmQgaW50ZXJmYWNlIGZvciB0aGUgcG9saWN5IGVu Z2luZS4NCk9uZSBvciBtb3JlIHN0YW5kYXJkIHByb3RvY29scyBzaG91bGQgYmUgc2VsZWN0ZWQg KGUuZy4sIE5FVENPTkYsIFJFU1RDT05GKSBmb3IgcG9saWN5IG9wZXJhdGlvbnMgdG8gY29tbXVu aWNhdGUgd2l0aCB0aGUgUG9saWN5IEVuZ2luZS4gDQpUaGUgcG9saWN5IGVuZ2luZSBydW5zIHdp dGggbW9uaXRvcmluZyB0aGUgbG93ZXIgbGV2ZWwgZXZlbnRzIGZyb20gdGhlIHNvdXRoYm91bmQu DQpIaWdoZXIgbGV2ZWwgZXZlbnRzIG1heSBiZSBnZW5lcmF0ZWQgYnkgdGhlIHBvbGljeSBlbmdp bmUsIHNvIHRoYXQgcG9saWN5IGVuZ2luZSBvciBhcHBsaWNhdGlvbnMgc2l0dGluZyBvbiBhIGhp Z2hlciBsZXZlbCBjYW4gY29uc3VtZS4NCg0KMy4gcG9saWN5IGRhdGEgbW9kZWwNClRoZSBwb2xp Y3kgZGF0YSBtb2RlbCBkZXNjcmliZXMgaW4gZGV0YWlsIGFib3V0IHRoZSBwcm90b2NvbCBvcGVy YXRpb25zIGFuZCBkYXRhLXN0b3JlIGNvbnRlbnQuIEl0IHNlcnZlcyBhcyBhbiAiQVBJIGNvbnRy YWN0IiBob25vcmVkIGJ5IHRoZSBwb2xpY3kgZW5naW5lLCBhbmQgaXMgZXNzZW50aWFsIHRvIHRo ZSBtb2RlbCBkcml2ZW4gcG9saWN5IEFQSS4gVGhlIHdlbGwgZGVmaW5lZCBwb2xpY3kgbW9kZWwg c3RydWN0dXJlIGZhY2lsaXRpZXMgYm90aCBmbGV4aWJpbGl0eSBhbmQgZXh0ZW5zaWJpbGl0eS4N CmEpIGdlbmVyaWMgcG9saWN5IG1vZGVsOiBkZWZpbmVzIGEgZ2VuZXJpYyBwb2xpY3kgaGVhZGVy IGFuZCB0aGUgcG9saWN5IGJvZHkgc3RydWN0dXJlLiBUaGUgZ2VuZXJpYyBwb2xpY3kgaGVhZGVy IGNvbnRhaW5zIGluZm9ybWF0aW9uIG9uLCBlLmcuIG5hbWUsIGlkZW50aWZpZXIsIGxpZmUgY3lj bGUsIHdoaWNoIGNhbiBiZSBzaGFyZWQgYnkgYWxsIHRoZSBzcGVjaWZpYyBwb2xpY3kgbW9kZWxz LiBUaGUgZ2VuZXJpYyBwb2xpY3kgYm9keSBjb3VsZCBiZSBhIG9yZGVyZWQgbGlzdCBvZiBwb2xp Y3kgcnVsZXMuIEJ1dCB0aGUgZGV0YWlscyBvbiBob3cgdGhlIHBvbGljeSBydWxlIGxpa2UgaXMg ZXh0ZW5kZWQgYnkgdGhlIHNwZWNpZmljIHBvbGljeSBtb2RlbCwgZS5nLiBFQ0EgcG9saWN5IG1v ZGVsLg0KYikgc3BlY2lmaWMgcG9saWN5IG1vZGVsOiBpbmhlcml0cyBmcm9tIHRoZSBnZW5lcmlj IHBvbGljeSBtb2RlbCB3aXRoIHNwZWNpZmljIGV4dGVuc2lvbnMgb24gdGhlIHBvbGljeSBydWxl LiBGb3IgZXhhbXBsZSB0aGUgRUNBIHBvbGljeSBtb2RlbCBleHRlbmRzIHRoZSBwb2xpY3kgcnVs ZSB3aXRoIEV2ZW50LUNvbmRpdGlvbi1BY3Rpb24gZGVmaW5pdGlvbi4NCmMpIGNvbmNyZXRlIHBv bGljeSBtb2RlbDogaXMgcmVuZGVyZWQgYmFzZWQgb24gdGhlIHNwZWNpZmljIG1vZGVsIGJ5IFNE T3MsIHZlbmRvcnMgb3Igb3BlcmF0b3JzLiBJdCByZXByZXNlbnRzIGNvbmNyZXRlIHRlY2huaXF1 ZSBhbmQgdmVuZG9yIGltcGxlbWVudGF0aW9uLiBGb3IgZXhhbXBsZSwgYSBjb25jcmV0ZSBFdmVu dCwgbGlrZSB0aW1lIGV2ZW50LCBwYWNrZXQtaW4uDQoNCjQuIGluZm9ybWF0aW9uIG1vZGVsaW5n DQpIb3cgdGhlIGluZm9ybWF0aW9uIG1vZGVsIGNhbiBoZWxwIGRhdGEgbW9kZWwgZ2VuZXJhdGlv bj8gV2hhdCBzaG91bGQgYmUgZGVmaW5lZCBpbiBJTSwgd2hhdCBpbiBETT8NCmEpIFRoZSBETSBk b2N1bWVudCBzaG91bGQgYmUgbW9yZSBvbiBob3cgdG8gcmVwcmVzZW50IGluZm9ybWFpdG9ucyBp biBZQU5HLCB3aGlsZSB0aGUgSU0gZG9jdW1lbnQgY2FuIGhhdmUgbW9yZSB3b3JkcyBpbnRyb2R1 Y2luZyB3aGF0IGFuIGl0ZW0gaXMgYW5kIHdoeSB3ZSBuZWVkIGFuIGl0ZW0uDQpiKSBUaGUgSU0g aGVscHMgb3RoZXIgRE0gY3JlYXRpb24gcmF0aGVyIHRoYW4gWUFORyBib3RoIGluIGFuZCBvdXRz aWRlIElFVEYuDQoNCg0KQmVzdCwNClRpYW5yYW4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCreivP7IyzogQW5keSBCaWVybWFuIFthbmR5QHl1bWF3b3Jrcy5j b21dDQq3osvNyrG85DogMjAxNsTqM9TCNcjVIDI6MDENCsrVvP7IyzogSmFzb24gQ29sZW1hbiAo Y29sZW1haikNCrOty806IEtpbmcsIERhbmllbDsgQmVydCBXaWpuZW4gKElFVEYpOyBKb2VsIE0u IEhhbHBlcm47IEpvaG4gU3RyYXNzbmVyOyBaaG91dGlhbnJhbjsgTmV2aWwgQnJvd25sZWU7IFNV UEEgbGlzdA0K1vfM4jogUmU6IFtTdXBhXSBJbmZvcm1hdGlvbiBtb2RlbHMgYW5kIERhdGEgbW9k ZWxzIC0gV0cgYWRvcGlvbj8NCg0KDQpPbiBGcmksIE1hciA0LCAyMDE2IGF0IDk6MjkgQU0sIEph c29uIENvbGVtYW4gKGNvbGVtYWopIDxjb2xlbWFqQGNpc2NvLmNvbT4gd3JvdGU6DQoNClNlbmRp bmcgYWdhaW4gdy8gdGhlIGNvcnJlY3QgZW1haWwgYWRkcmVzcyB0aGlzIHRpbWU6DQoNCj5JIHdv dWxkIGxpa2UgdG8gYmUgcGFydCBvZiB3b3JraW5nIG9uIGFuIGFyY2hpdGVjdHVyZSBkb2N1bWVu dCBhcyB3ZWxsLg0KDQpJIHdvdWxkIGxpa2UgdG8gcGFydGljaXBhdGUgYXMgd2VsbCwgc2luY2Ug QmVydCBpcyB3aWxsaW5nIHRvIHRha2UgdGhlIGxlYWQuDQoNCkl0IGlzIHF1aXRlIHBvc3NpYmxl IEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIGRldmVsb3BtZW50IHBsYW4gaW1wbGllZCBieSB0aGUg Y2hhcnRlci4NCg0KDQpJIHdhcyBob3Bpbmcgd2Ugd291bGQgZW5kIHVwIHdpdGggdGhlIGZvbGxv d2luZyBzdGFuZGFyZHM6DQoNCg0KICAxKSBvbmUgc3RhbmRhcmQgd2F5IHRvIGV4cHJlc3MgYSBT VVBBIHBvbGljeQ0KICAyKSBvbmUgc3RhbmRhcmQgIlNVUEEgZW5naW5lIiBkZWZpbml0aW9uIHRo YXQgaXMgY2FwYWJsZSBvZiB1bmRlcnN0YW5kaW5nIGFuZCBlbmZvcmNpbmcgc3BlY2lmaWMgcG9s aWNpZXMNCiAgICAgIDJhKSBkZXZpY2UtbGV2ZWwgU1VQQSBjYW4gb25seSBhY2Nlc3MgcG9saWN5 IGFuZCBlbmZvcmNlIHBvbGljeSBvbiBpdHNlbGYNCiAgICAgIDJiKSBjb250cm9sbGVyLWxldmVs IFNVUEEgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gY29tbXVuaWNhdGUgd2l0aCBtdWx0aXBsZSBuZXR3 b3JrIGVsZW1lbnRzDQogICAzKSBvbmUgb3IgbW9yZSBzdGFuZGFyZCBwcm90b2NvbHMgc2hvdWxk IGJlIHNlbGVjdGVkIChlLmcuLCBORVRDT05GLCBSRVNUQ09ORikgZm9yDQogICAgICAgY29tbXVu aWNhdGlvbiBiZXR3ZWVuICgyYikgYW5kIG5ldHdvcmsgZWxlbWVudHMsIHRvIHN1cHBvcnQgcG9s aWN5IGVuZm9yY2VtZW50DQoNCg0KSU1PLCBTRE9zLCB2ZW5kb3JzIG9yIGV2ZW4gb3BlcmF0b3Jz IHNob3VsZCBiZSBhYmxlIHRvIHdyaXRlIFNVUEEgcG9saWNpZXMuDQoNCg0KDQoNCkFuZHkNCg0K DQoNCg0KDQoNCg0KPg0KPkFzIGZvciB0aGUgaW5mb3JtYXRpb24gbW9kZWwgdmVyc3VzIGRhdGEg bW9kZWwgZGlzY3Vzc2lvbiwgSSB0aGluayB0aGF0IGFuIGluZm9ybWF0aW9uIG1vZGVsIGlzIHJl cXVpcmVkIHRvIGFsbG93IGZvciBkaWZmZXJlbnQgZGF0YSBtb2RlbHMgdG8gZm9sbG93IGEgY29t bW9uIHN0cnVjdHVyZS4NCj5JdCBpcyBwb3NzaWJsZSB0byBjcmVhdGUgYSBkYXRhIG1vZGVsIGZp cnN0LCBidXQgdGhhdCBkYXRhIG1vZGVsIG1heSBub3QgZml0IGluIHdlbGwgd2l0aCBvdGhlciBk YXRhIG1vZGVscy4gIFRoaXMgaXMgd2h5IHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBleGlzdHMgdG8g YWxsb3cgZm9yIHRoaW5ncyB0aGF0IG1heSBleHRlbmQgdGhhdCBkYXRhIG1vZGVsIG9yIGFyZSBp biBwbGFjZSBmb3Igb3RoZXIgZGF0YSBtb2RlbHMuDQo+DQo+QXQgdGhpcyB0aW1lIHRoZSBmb2N1 cyBpcyBvbiBFdmVudCwgQ29uZGl0aW9uLCBBY3Rpb24sIGJ1dCB0aGVyZSB3aWxsIGJlIGZ1cnRo ZXIgbWFuYWdlbWVudCBzdHJ1Y3R1cmVzIHRvIGRlZmluZS4NCj5UaGUgaW5mb3JtYXRpb24gbW9k ZWwgc3VwcG9ydHMgYSBnZW5lcmFsIHN0cnVjdHVyZSBhbmQgdGhlbiBwcm92aWRlcyBkZXRhaWxz IG9uIEVDQS4gIFRoYXQgZ2VuZXJhbCBzdHJ1Y3R1cmUgaXMgaW1wb3J0YW50IGZvciBmdXR1cmUg ZGF0YSBtb2RlbHMgYXMgd2VsbC4NCj5UaG9zZSBtYXkgYmUgWUFORyBvciBvdGhlciBwZW9wbGUg bWF5IGNob3NlIHRvIHVzZSB0aGUgaW5mb3JtYXRpb24gbW9kZWwgdG8gY3JlYXRlIGEgZGF0YSBt b2RlbCBpbiBhIGRpZmZlcmVudCB3YXkuDQo+DQo+VGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCB3 b3VsZCBkZWZpbmUgdGhlIHJvbGUgb2YgdGhlIGluZm9ybWF0aW9uIG1vZGVsIGNsZWFybHksIHdo aWNoIEkgdGhpbmsgdGhhdCBwYXJ0IG9mIHRoZSBJRCB0aGF0IEpvaG4sIEpvZWwsIGFuZCBJIHdv cmtlZCBvbiBhdHRlbXB0cyB0byBkbyBhcyB3ZWxsLCBhbmQgdGhlbiBjYW4gc2hvdyBob3cgdGhl IGRhdGEgbW9kZWxzIHdpbGwgYmUgc3VwcG9ydGVkIGJ5IHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBh bmQgd2hhdCBlbHNlIHRoZSBXRyBDaGFydGVyIGhhcyBkZWZpbmVkIGFuZCBwb3NzaWJseSB3aGVy ZSB3ZSBnbyBuZXh0Lg0KPg0KPkphc29uDQo+DQo+DQo+DQo+T24gMy80LzE2LCA3OjM0IEFNLCAi U3VwYSBvbiBiZWhhbGYgb2YgS2luZywgRGFuaWVsIiA8c3VwYS1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBkLmtpbmdAbGFuY2FzdGVyLmFjLnVrPiB3cm90ZToNCj4NCj4+SGkgQmVydCwN Cj4+DQo+PlRoYW5rIGZvciB0YWtpbmcgdGhlIGluaXRpYXRpdmUuIFdlIGNhbiBtYWtlIHN1cmUg dGhlcmUgaXMgdGltZSBvbiB0aGUgYWdlbmRhIGZvciB0aGUgSS1ELg0KPj4NCj4+QlIsIERhbi4N Cj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IEJlcnQgV2lqbmVuIChJ RVRGKSBbbWFpbHRvOmJ3aWV0ZkBid2lqbmVuLm5ldF0NCj4+U2VudDogMDQgTWFyY2ggMjAxNiAx MDoxMQ0KPj5UbzogS2luZywgRGFuaWVsIDxkLmtpbmdAbGFuY2FzdGVyLmFjLnVrPjsgSm9lbCBN LiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3 b3Jrcy5jb20+OyBKb2huIFN0cmFzc25lciA8Sm9obi5zYy5TdHJhc3NuZXJAaHVhd2VpLmNvbT47 IFpob3V0aWFucmFuIDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPg0KPj5DYzogTmV2aWwgQnJvd25s ZWUgPG4uYnJvd25sZWVAYXVja2xhbmQuYWMubno+OyBTVVBBIGxpc3QgPHN1cGFAaWV0Zi5vcmc+ DQo+PlN1YmplY3Q6IFJlOiBbU3VwYV0gSW5mb3JtYXRpb24gbW9kZWxzIGFuZCBEYXRhIG1vZGVs cyAtIFdHIGFkb3Bpb24/DQo+Pg0KPj5PbiAwMy8wMy8xNiAxNzo0MSwgS2luZywgRGFuaWVsIHdy b3RlOg0KPj4+IEhpICBBbGwuDQo+Pj4NCj4+PiBXZSBoYXZlIGEgcGxhY2Vob2xkZXIgaW4gdGhl IFNVUEEgQ2hhcnRlciBmb3I6DQo+Pj4NCj4+PiAxKSBBbiBleHBsYW5hdGlvbiBvZiB0aGUgc2Nv cGUgb2YgdGhlIHBvbGljeS1iYXNlZCBtYW5hZ2VtZW50IGZyYW1ld29yayBhbmQgaG93IGl0IHJl bGF0ZXMgdG8gZXhpc3Rpbmcgd29yayBvZiB0aGUgSUVURi4NCj4+Pg0KPj4+IEEgcHJvcG9zYWwg Zm9yIHRoaXMgZG9jdW1lbnQgaGFzIG5vdCBiZWVuIGZvcnRoY29taW5nIHRodXMgZmFyLiBJdCB3 b3VsZCBzZWVtIHRoYXQgYSAiUG9saWN5LWJhc2VkIE1hbmFnZW1lbnQgRnJhbWV3b3JrIiBkaXNj dXNzaW5nIGFyY2hpdGVjdHVyZSwgYXBwbGljYWJpbGl0eSBhbmQgcmVsYXRpb25zaGlwcyAoInN5 c3RlbSBvdmVydmlldyIpIHdvdWxkIGJlIHJlYXNvbmFibGUgY29udGVudCBmb3IgYSBmcmFtZXdv cmsgZG9jdW1lbnQgbWVudGlvbmVkIGluIHRoZSBDaGFydGVyPw0KPj4+DQo+Pj4gRnVydGhlcm1v cmUsIEFuZHksIFRpYW5yYW4gYW5kIEJlcnQgYWxsIHNlZW0gd2lsbGluZyB0byBzdXBwb3J0IGRl dmVsb3BtZW50ICh2aWEgZGlyZWN0IGNvbnRyaWJ1dGlvbnMpIGZvciB0aGUgZnJhbWV3b3JrL2Fy Y2hpdGVjdHVyZSBkb2N1bWVudD8NCj4+RGFuLCBJIGFtIHdpbGxpbmcgdG8gdGFrZSBpbml0aWF0 aXZlIG9uIHRoaXMuDQo+Pg0KPj5JIHNhdyBpbiBvbmUgb2YgSm9obnMgcG9zdGluZ3M6DQo+PiAg ICBXZWxsLCB3ZSBkb24ndCBoYXZlIGFuIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBjdXJyZW50bHkg aW4gb3VyIGNoYXJ0ZXINCj4+ICAgICh0aG91Z2ggSSB3b3VsZCBzdXBwb3J0IGFtZW5kaW5nIHRo ZSBjaGFydGVyIHRvIGluY2x1ZGUgdGhpcykuIEluIHRoZQ0KPj4gICAgKG5vdyBleHBpcmVkKSBw cm9wb3NpdGlvbiBkcmFmdCAod2hpY2ggd2UgYXJlIG5vdyB3b3JraW5nIG9uIHRvIHJlaXNzdWUp LA0KPj4gICAgdGhlcmUgd2FzIGFuIGV4ZW1wbGFyeSBhcmNoaXRlY3R1cmUuDQo+Pg0KPj5Kb2hu LCBkbyB5b3UgaGF2ZSB0aGUgcGllY2Ugb2YgdGV4dCBpbiBhbiBYTUwgZmlsZSAoSS1EIHNvdXJj ZSBmaWxlKSBhbmQgaWYgc28sIGNhbiB5b3Ugc2VuZCB0aGF0IHRvIG1lLiBJIGFzc3VtZSB5b3Ug YXJlIE9LIHdpdGggdXMgdXNpbmcgdGhhdCBhcyBhIHN0YXJ0aW5nIHBvaW50Pw0KPj4NCj4+RGFu L05ldmlsLCBpZiB3ZSBzdWJtaXQgYW4gaW4gaW5pdGlhbCBJLUQgdGltZWx5LCBkbyB5b3UgdGhp bmsgd2UgY2FuIHNwZW5kIHNvbWUgdGltZSBvbiBpdCBpbiBvdXIgSUVURjk1IHNlc3Npb24/DQo+ Pg0KPj5UaGFua3MsDQo+PkJlcnQNCj4+DQo+Pg0KPj4NCj4+PiBCUiwgRGFuLg0KPj4+DQo+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBTdXBhIFttYWlsdG86c3VwYS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVydCBXaWpuZW4NCj4+PiAoSUVURikNCj4+ PiBTZW50OiAwMyBNYXJjaCAyMDE2IDE2OjEzDQo+Pj4gVG86IEpvZWwgTS4gSGFscGVybiA8am1o QGpvZWxoYWxwZXJuLmNvbT47IEFuZHkgQmllcm1hbg0KPj4+IDxhbmR5QHl1bWF3b3Jrcy5jb20+ OyBKb2huIFN0cmFzc25lciA8Sm9obi5zYy5TdHJhc3NuZXJAaHVhd2VpLmNvbT4NCj4+PiBDYzog WmhvdXRpYW5yYW4gPHpob3V0aWFucmFuQGh1YXdlaS5jb20+OyBOZXZpbCBCcm93bmxlZQ0KPj4+ IDxuLmJyb3dubGVlQGF1Y2tsYW5kLmFjLm56PjsgU1VQQSBsaXN0IDxzdXBhQGlldGYub3JnPg0K Pj4+IFN1YmplY3Q6IFJlOiBbU3VwYV0gSW5mb3JtYXRpb24gbW9kZWxzIGFuZCBEYXRhIG1vZGVs cyAtIFdHIGFkb3Bpb24/DQo+Pj4NCj4+PiBJbmxpbmUNCj4+Pg0KPj4+IE9uIDAzLzAzLzE2IDE2 OjQ4LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+Pj4+IFR3byBzZXBhcmF0ZSBidXQgcmVsYXRl ZCBxdWVzaXRvbnMuDQo+Pj4+DQo+Pj4+IDEpIENhbiB5b3UgaGVscCB1c2UgZmluZCB0aGUgcGxh Y2VzIHdoZXJlIHRoZSBtb2RlbCAvIHRleHQgaXMgdG9vDQo+Pj4+IGltcGxlbWVudGF0aW9uIHNw ZWNpZmljPyAgVGhlcmUgYXJlIGEgZmV3IHBsYWNlcyB3aGVyZSBpbiBkZXNjcmliaW5nDQo+Pj4+ IGVudW1lcmF0aW9ucyB0aGUgbW9kZWwgY2FsbHMgZm9yIGludGVnZXJzLiAgSW4gdGhlIG1hcHBp bmcgdG8gWUFORywgSSBoYXZlIGFscmVhZHkgc3RhcnRlZCByZXBsYWNpbmcgdGhvc2Ugd2l0aCBF bnVtZXJhdGlvbnMuICBBcmUgdGhlcmUgb3RoZXIga2luZHMgb2Ygb3Zlci1zcGVjaWZpY2l0eT8N Cj4+Pj4NCj4+Pj4gMikgVGhlIGNoYXJ0ZXIgYWxsb3dzIGZvciBhIHJhbmdlIG9mIGltcGxlbWVu dGF0aW9ucyBvZiB0aGUgU1VQQQ0KPj4+PiBzeXN0ZW0uICBGb2xrcyBtYXkgcmVjYWxsIEkgYXNr ZWQgaW4gdGhlIHJvb20gYXQgdGhlIGxhc3QgbWVldGluZw0KPj4+PiB3aGV0aGVyIG91ciBjaGFy dGVyZWQgYWxsb3dkIGJvdGggY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGEgY29udHJvbA0KPj4+PiBz eXN0ZW0gYW5kIGEgZGV2aWNlLCBhbmQgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGEgcG9saWN5IHJl cG9zaXRvcnkgYW5kIGEgcG9saWN5IGVuZ2luZS4gIEkgd2FzIHRvbGQgYnkgdGhlIEFEIHRoYXQg dGhlIGNoYXJ0ZXJlZCBhbGxvd2VkIGJvdGguICBUaGlzIGRvZXMgbWFrZSBpdCByYXRoZXIgaW50 ZXJlc3RpbmcgdG8gZGVmaW5lIHRoZSAiYXJjaGl0ZWN0dXJlIi4NCj4+PiBNbW1tLi4uIGJvdGgg Y29uY3VycmVudGx5LCBvciBkaWQgaGUgbWVhbiB0aGF0IHdlIGFzIGEgV0cgY2FuIG1ha2UgYSBj aG9pY2Ugd2hhdCB3ZSBwcmVmZXIgYW5kIHN0YW5kYXJkaXplIHRoYXQ/DQo+Pj4gSWYgd2UgZG8g Ym90aCBjb25jdXJyZW50bHkgb3IgYSBsb25nc2lkZSBlYWNoIG90aGVyLCBjYW4gd2UgdGhlbiBz dGlsbCBndWFyYW50ZWUgaW50ZXJvcGVyYWJpbGl0eSAod2hpY2ggSSB0aGluayBpcyBvbmUgb2Yg b3VyIG1haW4gb2JqY3RpdmVzLCBubyk/DQo+Pj4+IDInKSBJIGRvIHRoaW5rIHRoYXQgdGhlcmUg YXJlIGEgZmV3IHBsYWNlcyBpbiB0aGUgbW9kZWwsIHBhcnRpY3VsYXJseQ0KPj4+PiB3aXRoIHJl Z2FyZCB0byBwb2xpY3kgZXhlY3V0aW9uIHN0YXR1cywgd2hlcmUgdGhlIG1vZGVsIG1ha2VzIHNv bWUgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIHN0cnVjdHVyZSBvZiBwb2xpY3kgZGVsaXZlcnkuICBG b3IgdGhlIG1vc3QgcGFydCwgdGhvc2Ugc2hvdWxkIGJlIHJlbW92ZWQuICBBc3Npc3RhbmNlIGlu IGZpbmRpbmcNCj4+Pj4gdGhlbSBpcyBhcHByZWNpYXRlZC4gIEkgc3VzcGVjdCB0aGF0IHNvbWUg b2YgdGhlbSBhcmUgbmVjZXNzYXJ5LCBhbmQgdGhvc2Ugc2hvdWxkIGJlIGV4cGxpY2l0bHkgZGVz Y3JpYmVkLiAgIChBbmQgd2Ugc2hvdWxkIG1ha2UNCj4+Pj4gc3VyZSB0aGUgd29ya2luZyBncm91 cCBhZ3JlZXMgd2l0aCB0aGUgYXNzdW1wdGlvbnMuKQ0KPj4+Pg0KPj4+PiAzKSAobWlub3IpIFRo ZSBjaGFydGVyIHBlcm1pdHMgdGhlIGluZm9ybWF0aW9uIG1vZGVsLiAgSSBwcmVzdW1lIHdlIGNv dWxkIGFtZW5kIHRoZSBjaGFydGVyIHRvIHBlcm1pdCBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQu DQo+Pj4+DQo+Pj4gSSB3b3VsZCBzYXkgYW4gIkFyY2hpdGVjdHVyZSIgb3IgIlN5c3RlbSBPdmVy dmlldyIgZG9jdW1lbnQgd291bGQgYmUgYSBnb29kIHRoaW5nLg0KPj4+DQo+Pj4gQmVydA0KPj4+ PiBZb3VycywNCj4+Pj4gSm9lbA0KPj4+Pg0KPj4+PiBPbiAzLzMvMTYgMTA6MjcgQU0sIEJlcnQg V2lqbmVuIChJRVRGKSB3cm90ZToNCj4+Pj4+IFZlcnkgZ29vZCBhbmQgcHJhY3RpY2FsIHF1ZXN0 aW9uIHJhaXNlZCBieSBBbmR5IQ0KPj4+Pj4NCj4+Pj4+IEJlcnQNCj4+Pj4+DQo+Pj4+PiBPbiAw My8wMy8xNiAwNjowNiwgQW5keSBCaWVybWFuIHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4gT24gV2Vk LCBNYXIgMiwgMjAxNiBhdCA3OjIxIFBNLCBKb2huIFN0cmFzc25lcg0KPj4+Pj4+IDxKb2huLnNj LlN0cmFzc25lckBodWF3ZWkuY29tDQo+Pj4+Pj4gPG1haWx0bzpKb2huLnNjLlN0cmFzc25lckBo dWF3ZWkuY29tPj4NCj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgV2Ugc2hvdWxk IHdvcmsgb24gYW4gaW5mb3JtYXRpb24gbW9kZWwgZm9yIHNldmVyYWwgcmVhc29ucywgZXZlbiBp Zg0KPj4+Pj4+ICAgICAgdGhlcmUgaXMgb25seSB0YXJnZXQgZGF0YSBtb2RlbCAoaS5lLiwgWUFO Ryk6DQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICAgMSkgQW4gaW5mb3JtYXRpb24gbW9kZWwgY2FuIGRl ZmluZSBob3cgZGF0YSBhcmUgcmVsYXRlZCB0byBlYWNoDQo+Pj4+Pj4gICAgICAgICAgIG90aGVy IGluZGVwZW5kZW50IG9mIGltcGxlbWVudGF0aW9uLiBUaGlzIGlzIG11Y2ggaGFyZGVyIHRvIGRv DQo+Pj4+Pj4gICAgICAgICAgIGluIFlBTkcuIEhlbmNlLCB0aGUgaW5mb3JtYXRpb24gbW9kZWwg bWF5IG1ha2UgdGhlc2UgaW5oZXJlbnQNCj4+Pj4+PiAgICAgICAgICAgcmVsYXRpb25zaGlwcyBl YXNpZXIgdG8gdmlzdWFsaXplIGFuZCBkZWZpbmUuDQo+Pj4+Pj4gICAgICAgIDIpIEFuIGluZm9y bWF0aW9uIG1vZGVsIHNlcGFyYXRlcyB0aGUgbG9naWNhbCBkZXNpZ24gZnJvbSB0aGUNCj4+Pj4+ PiAgICAgICAgICAgcGh5c2ljYWwgZGVzaWduIG9mIHRoZSBzeXN0ZW0sIGVuYWJsaW5nIGEgZGVl cGVyIHVuZGVyc3RhbmRpbmcNCj4+Pj4+PiAgICAgICAgICAgb2YgYm90aCBpbmRlcGVuZGVudCBv ZiBpbXBsZW1lbnRhdGlvbi4gVGhpcyBjYW4gYmUgdXNlZCB0bw0KPj4+Pj4+ICAgICAgICAgICBw cm9kdWNlIG1vcmUgcG93ZXJmdWwgaW1wbGVtZW50YXRpb25zLg0KPj4+Pj4+ICAgICAgICAzKSBJ ZiBhbiBpbmZvcm1hdGlvbiBtb2RlbCBpcyB3b3JrZWQgb24gaW4gYW5vdGhlciBvcmdhbml6YXRp b24sDQo+Pj4+Pj4gICAgICAgICAgIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IGl0cyBvdXRw dXQgd2lsbCBiZSB1c2VmdWwgdG8gdGhlDQo+Pj4+Pj4gICAgICAgICAgIElFVEYuIEkgYW0gYWN0 aXZlIGluIHRoZSBUTSBGb3J1bSwgd2hpY2ggeW91IGNpdGVkOyB0aGV5IGFyZQ0KPj4+Pj4+ICAg ICAgICAgICBpbiBnZW5lcmFsIG5vdCB3b3JyaWVkIGFib3V0IGltcGxlbWVudGluZyBZQU5HIG1v ZGVscywgbXVjaA0KPj4+Pj4+ICAgICAgICAgICBsZXNzIHByb2R1Y2luZyBvcHRpbWFsIFlBTkcg bW9kZWxzLg0KPj4+Pj4+ICAgICAgICA0KSBUaGlzIGVuYWJsZXMgb3RoZXIgU0RPcyBhbmQgZm9y YSwgd2hpY2ggZG8gbm90IHVzZSBZQU5HLCB0bw0KPj4+Pj4+ICAgICAgICAgICBtb3JlIGVhc2ls eSB1bmRlcnN0YW5kIG91ciBvdXRwdXQuDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4g SXQgc2VlbXMgdG8gbWUgdGhhdCB5b3VyIGRyYWZ0IGhhcyBtYW55IGRldGFpbHMgcmVsYXRlZCB0 byB0aGUNCj4+Pj4+PiBhYnN0cmFjdGlvbiBvZiBwb2xpY3kgbG9naWMsIGJ1dCBhbHNvIG1hbnkg YXNwZWN0cyB0aGF0IGxvb2sgbGlrZQ0KPj4+Pj4+IGltcGxlbWVudGF0aW9uIGRldGFpbHMuDQo+ Pj4+Pj4gUGVyaGFwcyBpdCBjYW4gYmUgc2ltcGxpZmllZCBpZiB0aGUgaW1wbGVtZW50YXRpb24g ZGV0YWlscyB3ZXJlIHJlbW92ZWQuDQo+Pj4+Pj4NCj4+Pj4+PiBJIGFtIG1vcmUgaW50ZXJlc3Rl ZCBpbiB0aGUgU1VQQSBBcmNoaXRlY3R1cmUgZG9jdW1lbnQgZmlyc3QuDQo+Pj4+Pj4gSSBkb24n dCBzZWUgaG93IHdlIGNhbiBhZ3JlZSBvbiBhbiBpbmZvLW1vZGVsIGluIHRoZSBhYnNlbmNlIG9m IGENCj4+Pj4+PiBzeXN0ZW0gYXJjaGl0ZWN0dXJlLg0KPj4+Pj4+DQo+Pj4+Pj4gRG9lcyBTVVBB IHJ1biBhbnl3aGVyZT8gV2hhdCBkb2VzIGl0IGV2ZW4gbWVhbiB0byBpbXBsZW1lbnQgU1VQQT8N Cj4+Pj4+PiBXaWxsIHBlb3BsZSBiZSBhYmxlIHRvIGJ1aWxkIGludGVyb3BlcmFibGUgU1VQQSBl bmdpbmVzIGZyb20gdGhlIFJGQ3M/DQo+Pj4+Pj4gSXMgdGhlcmUgYSBkaWZmZXJlbmNlIGJldHdl ZW4gYSBTVVBBIGVuZ2luZSBydW5uaW5nIGF0IHRoZSBkZXZpY2UNCj4+Pj4+PiBsZXZlbCBvciB0 aGUgY29udHJvbGxlciBsZXZlbD8gIFdoYXQgZGF0YSBpcyBhdmFpbGFibGUgZm9yIHBvbGljeQ0K Pj4+Pj4+IGVuZm9yY2VtZW50IGFuYWx5c2lzPw0KPj4+Pj4+IElzIHRoaXMgY29uZmlndXJhYmxl IHRocm91Z2ggWUFORyBtb2R1bGVzIGltcGxlbWVudGVkIGJ5IGEgU1VQQSBlbmdpbmU/DQo+Pj4+ Pj4gSG93IGFyZSBwb2xpY2llcyBkZWZpbmVkIGFuZCBtYW5hZ2VkIHdpdGhpbiB0aGUgU1VQQSBp bXBsZW1lbnRhdGlvbj8NCj4+Pj4+PiBIb3cgaXMgZGV2aWNlIGNvbmZpZyBhbHRlcmVkIHRvIGlt cGxlbWVudCBwb2xpY3k/DQo+Pj4+Pj4gSG93IGFyZSBkZXZpY2Ugb3BlcmF0aW9uYWwgc3RhdGUg YW5kIHN0YXRpc3RpY3MgdXNlZCB0byB2ZXJpZnkNCj4+Pj4+PiBwb2xpY3kgaW1wbGVtZW50YXRp b24/DQo+Pj4+Pj4NCj4+Pj4+PiBBIHByZWNpc2UgZGVzY3JpcHRpb24gb2YgcG9saWN5IGxvZ2lj IG1pZ2h0IGJlIGEgZ29vZCB0aGluZyB0byBoYXZlLg0KPj4+Pj4+IEkgYW0gbm90IG9iamVjdGlu ZyB0byBhbiBpbmZvIG1vZGVsIGRvYy4gIEEgc3lzdGVtIGFyY2hpdGVjdHVyZSBhbmQNCj4+Pj4+ PiBhIHdvcmthYmxlIHNvbHV0aW9uIHdpbGwgcmVxdWlyZSBhIGxvdCBtb3JlIHRoYW4gdGhhdC4N Cj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0K Pj4+Pj4+ICAgICAgSm9obg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEFuZHkNCj4+ Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ Pj4+ICAgICAgRnJvbTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZw0KPj4+Pj4+ IDxtYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFpob3V0aWFucmFu DQo+Pj4+Pj4gICAgICBTZW50OiBUdWVzZGF5LCBNYXJjaCAwMSwgMjAxNiA3OjI5IFBNDQo+Pj4+ Pj4gICAgICBUbzogTmV2aWwgQnJvd25sZWUNCj4+Pj4+PiAgICAgIENjOiBTVVBBIGxpc3QNCj4+ Pj4+PiAgICAgIFN1YmplY3Q6IFJlOiBbU3VwYV0gSW5mb3JtYXRpb24gbW9kZWxzIGFuZCBEYXRh IG1vZGVscyAtIFdHIGFkb3Bpb24/DQo+Pj4+Pj4NCj4+Pj4+PiAgICAgIEhpIE5ldmlsLA0KPj4+ Pj4+DQo+Pj4+Pj4gICAgICBJIGFtIG5vdCBhcmd1aW5nIGluZm9ybWF0aW9uIG1vZGVsIGlzIHVz ZWxlc3MsIGJ1dCBpdCBjYW4gYmUNCj4+Pj4+PiB3b3JrZWQgb3V0IGluIG90aGVyIG9yZ2FuaXph dGlvbnMgaWYgbmVjZXNzYXJ5LCBlLmcuIFRNRi4NCj4+Pj4+PiAgICAgIElmIGluIFNVUEEgd2Ug Y2FuIHdvcmtlZCBvbiBZQU5HIGRhdGEgbW9kZWxzIGRpcmVjdGx5LCB3aHkgd2UNCj4+Pj4+PiBm aXJzdGx5IHdvcmsgb24gYW4gaW5mb3JtYXRpb24gbW9kZWwgYW5kIHRoZW4gdHJhbnNsYXRlIGl0 IHRvDQo+Pj4+Pj4gICAgICBZQU5HIGRhdGEgbW9kZWw/DQo+Pj4+Pj4gICAgICBJdCBqdXN0IG5v dCBtYWtlcyBzZW5zZSB0byBtZS4NCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgVGlhbnJhbg0KPj4+Pj4+ DQo+Pj4+Pj4gICAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gICAgICA+ IEZyb206IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmcNCj4+Pj4+PiA8bWFpbHRv OnN1cGEtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBOZXZpbCBCcm93bmxlZQ0KPj4+ Pj4+ICAgICAgPiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDAyLCAyMDE2IDY6NTYgQU0NCj4+Pj4+ PiAgICAgID4gVG86IFpob3V0aWFucmFuDQo+Pj4+Pj4gICAgICA+IENjOiBTVVBBIGxpc3QNCj4+ Pj4+PiAgICAgID4gU3ViamVjdDogUmU6IFtTdXBhXSBJbmZvcm1hdGlvbiBtb2RlbHMgYW5kIERh dGEgbW9kZWxzIC0gV0cNCj4+Pj4+PiBhZG9waW9uPw0KPj4+Pj4+ICAgICAgPg0KPj4+Pj4+ICAg ICAgPg0KPj4+Pj4+ICAgICAgPiBIaSBUaWFucmFuOg0KPj4+Pj4+ICAgICAgPg0KPj4+Pj4+ICAg ICAgPiBJbiBteSBleHBlcmllbmNlcywgaGF2aW5nIGEgd2VsbC1kZWZpbmVkIGluZm9ybWF0aW9u IG1vZGVsDQo+Pj4+Pj4gaXMgYSBnb29kIHN0YXJ0aW5nDQo+Pj4+Pj4gICAgICA+IHBvaW50LiAg SXQgYWxsb3dzIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMsIGVhY2ggb2Ygd2hpY2gNCj4+Pj4+ PiBjYW4gZGV2ZWxvcCBpdCdzDQo+Pj4+Pj4gICAgICA+IG93biBkYXRhIG1vZGVsIC0gaW4gb3Ro ZXIgd29yZHMsIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBpcyBhDQo+Pj4+Pj4gZ29vZCB1bmlmeWlu Zw0KPj4+Pj4+ICAgICAgPiBpbmZsdWVuY2UgLSB3aGljaCBpcyB3aHkgcHVibGlzaGluZyBzdWNo IGEgZG9jdW1lbnQgaXMgdGhlDQo+Pj4+Pj4gc2Vjb25kIG9mIG91cg0KPj4+Pj4+ICAgICAgPiBj aGFydCBpdGVtcy4gIEkgaG9wZSB0aGF0IGdldHRpbmcgYSBnb29kIGRhdGEgbW9kZWwgd2lsbA0K Pj4+Pj4+IGhlbHAgdXMgd2l0aCB0aGUNCj4+Pj4+PiAgICAgID4gZmlyc3QgY2hhcnQgaXRlbSAo InNjb3BlIG9mIHRoZSBwb2xpY3ktYmFzZWQgbWFuYWdlbWVudA0KPj4+Pj4+IGZyYW1ld29yayIp Lg0KPj4+Pj4+ICAgICAgPg0KPj4+Pj4+ICAgICAgPiBkcmFmdC1zdHJhc3NuZXItc3VwYS1nZW5l cmljLXBvbGljeS1pbmZvLW1vZGVsIGlzIHRoZSBvbmx5IFNVUEENCj4+Pj4+PiAgICAgID4gaW5m b3JtYXRpb24gbW9kZWwgdGhhdCdzIGhhZCBhbnkgd29yayBkb25lIG9uIGl0IHNpbmNlIElFVEYN Cj4+Pj4+PiA5NSwgdGhlcmVmb3JlDQo+Pj4+Pj4gICAgICA+IEkndmUgcHJvcG9zZWQgaXQgZm9y IFdHIGFkb3B0aW9uLg0KPj4+Pj4+ICAgICAgPg0KPj4+Pj4+ICAgICAgPiBBcyBmb3IgdGhlIHRo aXJkIGNoYXJ0ZXIgaXRlbSAtICJzZXQgb2YgWUFORyBkYXRhIG1vZGVscyIsDQo+Pj4+Pj4gdGhl cmUgYXJlIHR3bw0KPj4+Pj4+ICAgICAgPiBvZiB0aGVzZSBvbiB0aGUgU1VQQSBkb2N1bWVudHMg cGFnZS4gIEl0IHdvdWxkIGhlbHAgYXQgdGhpcw0KPj4+Pj4+IHN0YWdlIGlmIHRoZWlyDQo+Pj4+ Pj4gICAgICA+IGF1dGhvcnMgY291bGQgY29tbWVudCBvbiB0aGlzIGxpc3QgYWJvdXQgdGhlIHN0 YXR1cyBvZiB0aGVzZQ0KPj4+Pj4+IGRyYWZ0cy4gIEluDQo+Pj4+Pj4gICAgICA+IHBhcnRpY3Vs YXIsIGphdmUgdGhleSBiZWVuIHdvcmtpbmcgb24gYSBuZXcgdmVyc2lvbj8NCj4+Pj4+PiAgICAg ID4NCj4+Pj4+PiAgICAgID4gT3ZlcmFsbCwgd2UgcmVhbGx5IG5lZWQgbW9yZSBkaXNjdXNzaW9u IG9uIHRoZSBsaXN0IG9mDQo+Pj4+Pj4gd2hhdCdzIGhhcHBlbmluZw0KPj4+Pj4+ICAgICAgPiB3 aXRoIHRoZSBTVVBBIHdvcmshDQo+Pj4+Pj4gICAgICA+DQo+Pj4+Pj4gICAgICA+IENoZWVycywg TmV2aWwNCj4+Pj4+PiAgICAgID4NCj4+Pj4+PiAgICAgID4NCj4+Pj4+PiAgICAgID4gT24gMS8w My8xNiA2OjEzIHBtLCBaaG91dGlhbnJhbiB3cm90ZToNCj4+Pj4+PiAgICAgID4gPiBJZiB0aGlz IGlzIGEgcG9sbCBmb3IgV0cgYWRvcHRpb24sIEkgd291bGQgc2F5IG5vdCBzdXBwb3J0Lg0KPj4+ Pj4+ICAgICAgPiA+DQo+Pj4+Pj4gICAgICA+ID4gSWYgd2Ugd2FudCB0byBmaW5hbGx5IGdlbmVy YXRlIFlBTkcgZGF0YSBtb2RlbHMgaGVyZSwgd2h5DQo+Pj4+Pj4gZG8gd2Ugc3BlbmQNCj4+Pj4+ PiAgICAgID4gdGltZSB3b3JraW5nIG9uIHRoaXMgaW5mb3JtYXRpb24gbW9kZWw/DQo+Pj4+Pj4g ICAgICA+ID4NCj4+Pj4+PiAgICAgID4gPiBXaHkgbm90IGZvY3VzIG9uIHRoZSBFQ0EgWUFORyBk YXRhIG1vZGVsIGRpcmVjdGx5IGFzDQo+Pj4+Pj4gc3RhbmRhcmQgdHJhY2s/DQo+Pj4+Pj4gICAg ICA+ID4NCj4+Pj4+PiAgICAgID4gPg0KPj4+Pj4+ICAgICAgPiA+IFRpYW5yYW4NCj4+Pj4+PiAg ICAgID4gPg0KPj4+Pj4+ICAgICAgPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ Pj4+ICAgICAgPiA+PiBGcm9tOiBTdXBhIFttYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnDQo+ Pj4+Pj4gPG1haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSUVURg0K Pj4+Pj4+ICAgICAgPiA+PiBTZWNyZXRhcmlhdA0KPj4+Pj4+ICAgICAgPiA+PiBTZW50OiBNb25k YXksIEZlYnJ1YXJ5IDI5LCAyMDE2IDY6MzUgQU0NCj4+Pj4+PiAgICAgID4gPj4gVG86DQo+Pj4+ Pj4gZHJhZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5mby1tb2RlbEBpZXRmLm9y Zw0KPj4+Pj4+IDxtYWlsdG86ZHJhZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5m by1tb2RlbEBpZXRmLm9yZz47DQo+Pj4+Pj4gICAgICA+ID4+IHN1cGEtY2hhaXJzQGlldGYub3Jn IDxtYWlsdG86c3VwYS1jaGFpcnNAaWV0Zi5vcmc+Ow0KPj4+Pj4+IHN1cGFAaWV0Zi5vcmcgPG1h aWx0bzpzdXBhQGlldGYub3JnPg0KPj4+Pj4+ICAgICAgPiA+PiBTdWJqZWN0OiBbU3VwYV0gVGhl IFNVUEEgV0cgaGFzIHBsYWNlZA0KPj4+Pj4+ICAgICAgPiA+PiBkcmFmdC1zdHJhc3NuZXItc3Vw YS1nZW5lcmljLXBvbGljeS1pbmZvLW1vZGVsIGluIHN0YXRlDQo+Pj4+Pj4gIkNhbGwgRm9yDQo+ Pj4+Pj4gICAgICA+ID4+IEFkb3B0aW9uIEJ5IFdHIElzc3VlZCINCj4+Pj4+PiAgICAgID4gPj4N Cj4+Pj4+PiAgICAgID4gPj4NCj4+Pj4+PiAgICAgID4gPj4gVGhlIFNVUEEgV0cgaGFzIHBsYWNl ZA0KPj4+Pj4+IGRyYWZ0LXN0cmFzc25lci1zdXBhLWdlbmVyaWMtcG9saWN5LWluZm8tbW9kZWwN Cj4+Pj4+PiAgICAgID4gPj4gaW4gc3RhdGUgQ2FsbCBGb3IgQWRvcHRpb24gQnkgV0cgSXNzdWVk IChlbnRlcmVkIGJ5IE5ldmlsDQo+Pj4+Pj4gQnJvd25sZWUpDQo+Pj4+Pj4gICAgICA+ID4+DQo+ Pj4+Pj4gICAgICA+ID4+IFRoZSBkb2N1bWVudCBpcyBhdmFpbGFibGUgYXQNCj4+Pj4+PiAgICAg ID4gPj4NCj4+Pj4+PiAgICAgID4NCj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1zdHJhc3NuZXItc3VwYS1nZW5lcmljLXBvbGljeS0NCj4+Pj4+PiAgICAgID4g Pj4gaQ0KPj4+Pj4+ICAgICAgPiA+PiBuZm8tbW9kZWwvDQo+Pj4+Pj4gICAgICA+ID4+DQo+Pj4+ Pj4gICAgICA+ID4+DQo+Pj4+Pj4gICAgICA+ID4+IENvbW1lbnQ6DQo+Pj4+Pj4gICAgICA+ID4+ IFRoaXMgaXMgdGhlIGZpcnN0IG9mIG91ciBjaGFydGVyIGRvY3VtZW50cywgdGhlIG90aGVyDQo+ Pj4+Pj4gY2hhcnRlciBpdGVtcw0KPj4+Pj4+ICAgICAgPiA+PiBidWlsZCBvbiB0aGlzDQo+Pj4+ Pj4gICAgICA+ID4+DQo+Pj4+Pj4gICAgICA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gICAgICA+ID4+IFN1cGEgbWFpbGluZyBsaXN0 DQo+Pj4+Pj4gICAgICA+ID4+IFN1cGFAaWV0Zi5vcmcgPG1haWx0bzpTdXBhQGlldGYub3JnPg0K Pj4+Pj4+ICAgICAgPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1 cGENCj4+Pj4+PiAgICAgID4NCj4+Pj4+PiAgICAgID4NCj4+Pj4+PiAgICAgID4gLS0NCj4+Pj4+ PiAgICAgID4NCj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+PiAgICAgID4gICBOZXZpbCBCcm93 bmxlZSAgICAgICAgICAgICAgICAgICAgICAgICAgQ29tcHV0ZXIgU2NpZW5jZQ0KPj4+Pj4+IERl cGFydG1lbnQNCj4+Pj4+PiAgICAgID4gICBQaG9uZTogKzY0IDkgMzczIDc1OTkgeDg4OTQxICAg ICAgICAgICAgIFRoZSBVbml2ZXJzaXR5IG9mDQo+Pj4+Pj4gQXVja2xhbmQNCj4+Pj4+PiAgICAg ID4gICBGQVg6ICs2NCA5IDM3MyA3NDUzICAgUHJpdmF0ZSBCYWcgOTIwMTksIEF1Y2tsYW5kIDEx NDIsIE5ldw0KPj4+Pj4+IFplYWxhbmQNCj4+Pj4+PiAgICAgID4NCj4+Pj4+PiAgICAgID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiAgICAg ID4gU3VwYSBtYWlsaW5nIGxpc3QNCj4+Pj4+PiAgICAgID4gU3VwYUBpZXRmLm9yZyA8bWFpbHRv OlN1cGFAaWV0Zi5vcmc+DQo+Pj4+Pj4gICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3VwYQ0KPj4+Pj4+DQo+Pj4+Pj4gICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+ICAgICAgU3VwYSBtYWlsaW5nIGxp c3QNCj4+Pj4+PiAgICAgIFN1cGFAaWV0Zi5vcmcgPG1haWx0bzpTdXBhQGlldGYub3JnPg0KPj4+ Pj4+ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhDQo+Pj4+ Pj4NCj4+Pj4+PiAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+Pj4gICAgICBTdXBhIG1haWxpbmcgbGlzdA0KPj4+Pj4+ICAgICAgU3VwYUBp ZXRmLm9yZyA8bWFpbHRvOlN1cGFAaWV0Zi5vcmc+DQo+Pj4+Pj4gICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+ Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+Pj4gU3VwYSBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBTdXBhQGlldGYub3JnDQo+Pj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhDQo+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gU3VwYSBt YWlsaW5nIGxpc3QNCj4+Pj4+IFN1cGFAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KPj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gU3VwYSBtYWlsaW5nIGxpc3QNCj4+ Pj4gU3VwYUBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3N1cGENCj4+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+IFN1cGEgbWFpbGluZyBsaXN0DQo+Pj4gU3VwYUBpZXRmLm9yZw0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KPj4+DQo+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBTdXBhIG1h aWxpbmcgbGlzdA0KPj4+IFN1cGFAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3N1cGENCj4+Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+U3VwYSBtYWlsaW5nIGxpc3QNCj4+U3VwYUBpZXRm Lm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGE= From nobody Tue Mar 8 08:40:24 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB0E12D7E4 for ; Tue, 8 Mar 2016 08:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6emSH5HEug5S for ; Tue, 8 Mar 2016 08:40:21 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4033E12D81C for ; Tue, 8 Mar 2016 08:40:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0F80A24EA8B; Tue, 8 Mar 2016 08:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1457455221; bh=oNoKvvcIFNFx9I+5AfYc2a/Jk0gXTU3vPfGQCONFTn0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ULi01UJ8Gztd4QKC20Re6ukOFhZRo3d8TMQJVQy7qKIaRtX6RN6KO4FYcNK6Coe7m Yc74kWM/Q1e6eHH7+MabIB9MZeeo0gavW7mKHWi34Y74ziAt43rkj658rSSEOBW41Z 23vv1Lwc5aP3GlhAVtQfKmfLU6ycmaOeRPsKPJ1A= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 8984424EAD1; Tue, 8 Mar 2016 08:40:20 -0800 (PST) To: joel jaeggli , Andy Bierman , SUPA list References: <20160307232308.GA5410@elstar.local> <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> <20160308070934.GB5979@elstar.local> From: "Joel M. Halpern" Message-ID: <56DF006B.9080303@joelhalpern.com> Date: Tue, 8 Mar 2016 11:40:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160308070934.GB5979@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Supa] SUPA - Domain Specific Languages X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 16:40:23 -0000 With regard to using domain specific langauges for policy configuration, I have a number of reactions. 1) We actually allow that. In the next revision of the information model, we will include for supa encoded clause a language identifier. THe list will be small, but extensible. So a SUPA encoded clause can be used to carry / point to a domain specific langague policy expression. (We only noticed the absence of the language tag in an internal review after we sent the document to the WG. 2) In terms of modeling, a domain specific lanague is very hard to use interoperably. It only works on entities that support that specific lanague. We want to have a representation that is actually interoperable. When you combine this with the instruction from the charter to focus on imperative event-condition-action policy expressions, we are sort of stuck with what we put in. Yours, Joel On 3/8/16 2:09 AM, Juergen Schoenwaelder wrote: > On Mon, Mar 07, 2016 at 03:38:30PM -0800, joel jaeggli wrote: >>> >>> Yep, unfortunately the SUPA charter is all about decoration but not >>> the cake that makes a policy engine do real stuff. >>> >>> I had hoped that SUPA would allow me to express policy-driven >>> operations on YANG defined data models, nicely integrating with >>> NETCONF/RESTCONF primitives, i.e., a policy layer with well defined >>> primitives that operate on YANG defined data models. But somehow this >>> idea did not fly through the chartering process and instead SUPA is >>> chartered to work on another policy meta-model. >> >> I'm a little disappointed with this discussion. Supa was chartered with >> a explicitly simple set of work items under the assumption that they >> could be completed in a timely fashion and that the working group could >> then move on. > > For me, the idea of modeling clauses that consist of terms which again > consist of variables and operators and values all as distinct policy > objects is like letting programmers fill in the internal data > structures of a compiler directly. Nobody I know of programs at that > level of abstraction. The tools I have been using to administrate a > small zoo of Unix boxes all use domain specific languages to express > things like conditions and actions; they do not expose expression > syntax trees as the level of abstraction to an administrator. > >> The fact that it doesn't attempt to do everything in one go should >> hopefully not be a surprise. >> >> Appropriately minded individuals don't need permission to infill the >> missing pieces for their application. the working group should not take >> up such items until it's rechartered. > > Yep. I will stay silent and check back in a couple of years. ;-) > > /js > From nobody Tue Mar 8 10:27:44 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0829612D984 for ; Tue, 8 Mar 2016 10:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX3ShrZKONxH for ; Tue, 8 Mar 2016 10:27:40 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E105C12D97D for ; Tue, 8 Mar 2016 10:27:39 -0800 (PST) Received: by mail-lb0-x22c.google.com with SMTP id bc4so30734720lbc.2 for ; Tue, 08 Mar 2016 10:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=AV+R3Fy/vodzoMtTXv/TeJuUIDUv4LMnRq3qy+FBEA8=; b=GFK3OXUuE16tPYcTFkWIIDgCXmY35+ciI2AAS97a7JsCfXi/h9eCnl4kyAJdPZGlQ+ k8AMDciv12ll/KKyAfiDhDutbVLWgBwVLn8o5K9thnGm3cz7blNaIVc5HnYYezFeFIyd 7liN8dv+/9vOfvk7LXY/Kxje7EUOqCnqj24M+WkihGlM5NtpXC4nGBcbMhKj6afFkG78 02/0jJ1EZGIUZrusPne7MDkXNPlIcPQyDJL5M66U75Ktik/TGNEh+yZVCH5YZX7NqK8O wXbsWf4aoJMW/ydrM3up8LbuNT+O/Q1+Scl043tttYVyQ3kUwOU+uaNjy8ffnKP+Cqmk xbVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=AV+R3Fy/vodzoMtTXv/TeJuUIDUv4LMnRq3qy+FBEA8=; b=TycJbcIiONasKmcU6gRAmRcZUbyGrAAbB5RBjIO9KKPWuwUgpHnCrrScBK9G4hoBdV cTPa80Mu9HyNRuGldeYpSDJ24SMbTVxenI8QzJZTcqUKj/6ETBfWJ3VA5fFMR2LB/GfJ qTQ0h36dnzBM7BZRZv5+nv3GYwuXdV33eg90OR/5S9Fs8hJNkZryP3BsnNdryZMipyor FfEC04LuLf5oSZ4CM6pfSwIIMWY92WTwvM1O49ADP5Lzt9aIj99P7Y13RvMLLtYncVFi V5alG8N13R2fdfkmL6SZbfH7DCIjMdn0ENL+wKsSM75qQv4KH3mzwt0wrgOMJCGN5SBE wlkA== X-Gm-Message-State: AD7BkJKZO+pmv8NN1nK8WxeNOlEufGb3OmyXNCf5SZZFD2ACmOwY29uhAsZkXAl27OeRY+ChjSXUjpAV+lg95Q== MIME-Version: 1.0 X-Received: by 10.112.147.101 with SMTP id tj5mr2828513lbb.119.1457461658100; Tue, 08 Mar 2016 10:27:38 -0800 (PST) Received: by 10.112.132.65 with HTTP; Tue, 8 Mar 2016 10:27:37 -0800 (PST) In-Reply-To: <20160308070934.GB5979@elstar.local> References: <20160307232308.GA5410@elstar.local> <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> <20160308070934.GB5979@elstar.local> Date: Tue, 8 Mar 2016 10:27:37 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , joel jaeggli , Andy Bierman , SUPA list Content-Type: multipart/alternative; boundary=047d7b3a8bd267c84a052d8dbcfd Archived-At: Subject: Re: [Supa] SUPA charter questions X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 18:27:43 -0000 --047d7b3a8bd267c84a052d8dbcfd Content-Type: text/plain; charset=UTF-8 On Mon, Mar 7, 2016 at 11:09 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Mar 07, 2016 at 03:38:30PM -0800, joel jaeggli wrote: > > > > > > Yep, unfortunately the SUPA charter is all about decoration but not > > > the cake that makes a policy engine do real stuff. > > > > > > I had hoped that SUPA would allow me to express policy-driven > > > operations on YANG defined data models, nicely integrating with > > > NETCONF/RESTCONF primitives, i.e., a policy layer with well defined > > > primitives that operate on YANG defined data models. But somehow this > > > idea did not fly through the chartering process and instead SUPA is > > > chartered to work on another policy meta-model. > > > > I'm a little disappointed with this discussion. Supa was chartered with > > a explicitly simple set of work items under the assumption that they > > could be completed in a timely fashion and that the working group could > > then move on. > > For me, the idea of modeling clauses that consist of terms which again > consist of variables and operators and values all as distinct policy > objects is like letting programmers fill in the internal data > structures of a compiler directly. Nobody I know of programs at that > level of abstraction. The tools I have been using to administrate a > small zoo of Unix boxes all use domain specific languages to express > things like conditions and actions; they do not expose expression > syntax trees as the level of abstraction to an administrator. > > This is my reaction as well, thinking about a YANG version of the info model. But I don't think the charter requires that. It seems to me the DMs in (3) are focused on common terminology and common typedefs. This is a useful, small step towards a solution. When I think of simple policy examples, like the SNMP example you suggested last year, it seems there is still a lot of magic pushed off into implementation details. This may be OK or not -- we need actual solution proposals to see how the generic SUPA data model would interact with a concrete policy like "disable SNMP from outside this administrative domain". For example, there is nothing in the policy that says "use the ACL module if it is supported" or anything else to help map the policy to an implementation. It seems this is just hard-coded by an implementer. What about a policy like "there must be at least 2 DNS resolvers running at all times in this administrative domain". What does the generic YANG look like? What does the "DNS specific" YANG look like? This is clearly a network-wide policy that cannot be enforced or implmeneted on a single NE. There might be a companion NE policy that says "every host must be configured to get DNS config from DHCP". Verifying this NE policy gets very implementation-specific. > > The fact that it doesn't attempt to do everything in one go should > > hopefully not be a surprise. > > > > Appropriately minded individuals don't need permission to infill the > > missing pieces for their application. the working group should not take > > up such items until it's rechartered. > > Yep. I will stay silent and check back in a couple of years. ;-) > I think Joel is right that this phase should get done quickly. It might take 2 years to agree on an info model that represents all possible policy logic solutions. IMO we do not need that at all to come up with common terminology and typedefs. > > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --047d7b3a8bd267c84a052d8dbcfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 7, 2016 at 11:09 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Mar 07, 2016 at 03:38:30PM -0800, joel jaegg= li wrote:
> >
> > Yep, unfortunately the SUPA charter is all about decoration but n= ot
> > the cake that makes a policy engine do real stuff.
> >
> > I had hoped that SUPA would allow me to express policy-driven
> > operations on YANG defined data models, nicely integrating with > > NETCONF/RESTCONF primitives, i.e., a policy layer with well defin= ed
> > primitives that operate on YANG defined data models. But somehow = this
> > idea did not fly through the chartering process and instead SUPA = is
> > chartered to work on another policy meta-model.
>
> I'm a little disappointed with this discussion. Supa was chartered= with
> a explicitly simple set of work items=C2=A0 under the assumption that = they
> could be completed in a timely fashion and that the working group coul= d
> then move on.

For me, the idea of modeling clauses that consist of terms which again
consist of variables and operators and values all as distinct policy
objects is like letting programmers fill in the internal data
structures of a compiler directly. Nobody I know of programs at that
level of abstraction. The tools I have been using to administrate a
small zoo of Unix boxes all use domain specific languages to express
things like conditions and actions; they do not expose expression
syntax trees as the level of abstraction to an administrator.



This is my reaction as = well, thinking about a YANG version of the info model.
But I don&= #39;t think the charter requires that.=C2=A0 It seems to me the DMs in (3)<= /div>
are focused on common terminology and common typedefs.
= This is a useful, small step towards a solution.

W= hen I think of simple policy examples, like the SNMP example
you = suggested last year, it seems there is still a lot of
magic pushe= d off into implementation details.=C2=A0 This may be OK
or not --= we need actual solution proposals to see how the generic SUPA
da= ta model would interact with a concrete policy like "disable SNMP
from outside this administrative domain".=C2=A0 For example, the= re is nothing
in the policy that says "use the ACL module if= it is supported" or
anything else to help map the policy to= an implementation.
It seems this is just hard-coded by an implem= enter.

What about a policy like "there must b= e at least
2 DNS resolvers running at all times in this administr= ative domain".
What does the generic YANG look like? What do= es the "DNS specific"
YANG look like?

This is clearly a network-wide policy that cannot be enforced or im= plmeneted
on a single NE.=C2=A0 There might be a companion NE pol= icy that
says "every host must be configured to get DNS conf= ig from DHCP".
Verifying this NE policy gets very implementa= tion-specific.

=C2=A0
> The fact that it doesn't attempt to do everything in one go should=
> hopefully not be a surprise.
>
> Appropriately minded individuals don't need permission to infill t= he
> missing pieces for their application. the working group should not tak= e
> up such items until it's rechartered.

Yep. I will stay silent and check back in a couple of years. ;-)

I think Joel is right that this phase should get = done quickly.
It might take 2 years to agree on an info model tha= t represents
all possible policy logic solutions.=C2=A0 IMO we do= not need that at all
to come up with common terminology and type= defs.

=C2=A0

/js


Andy
=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--047d7b3a8bd267c84a052d8dbcfd-- From nobody Tue Mar 8 16:43:33 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949DB12D6AB for ; Tue, 8 Mar 2016 16:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x4cNZZOfA5Z for ; Tue, 8 Mar 2016 16:43:30 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E748112D6AA for ; Tue, 8 Mar 2016 16:43:29 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-50-56df7191315a Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 3D.10.32102.1917FD65; Wed, 9 Mar 2016 01:42:58 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Tue, 8 Mar 2016 19:43:27 -0500 From: Dave Hood To: "supa@ietf.org" Thread-Topic: Time as a dimension in policy Thread-Index: AdF5lPbn0i/bFerwQpaptukobfJzzg== Date: Wed, 9 Mar 2016 00:43:26 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA64516E244F@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA64516E244Feusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPoO6kwvthBo8nCVnM3rKK2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGWf2b2UueJFQ0Xt3GWMD493gLkYODgkBE4kTE8S7GDmBTDGJ C/fWs3UxcnEICRxhlDhw+BMrhLOMUeJm4zcWkCo2AQ2JJ5cmM4HYIgLKEjPWzWYFsYUF1CTO 3nnCCBHXlti++io7hK0nsXjhV3aQZSwCKhJ3b4OV8Ar4Suz++4MZxGYEWvz91BqwkcwC4hK3 nsxngjhIQGLJnvPMELaoxMvH/1ghbCWJj7/ns0PU50s8uD+FFWKmoMTJmU9YJjAKzUIyahaS sllIyiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRo7S4oKc3HQjw02MwLA/JsHmuINx b6/nIUYBDkYlHt6CyPthQqyJZcWVuYcYJTiYlUR4w/OBQrwpiZVVqUX58UWlOanFhxilOViU xHm/fbwcJiSQnliSmp2aWpBaBJNl4uCUamBsm3XmVV1u+nxnvbgtGVzSPYwBifHblzbMyvwz 55BU/9X376Yd3eBsP6NdtN7p+JTq73fU2Kw/3p0q67D1lNPGypPyyuGbbc+p9k+3kz56Z88S Wd+f86b1dcvP/X1CZBlr5Iyj8vJ3rTluJceFebIwTjR/uSzge2fmXuW5ZtPvT5ba4Gh/neOi EktxRqKhFnNRcSIAJzWiFHcCAAA= Archived-At: Subject: [Supa] Time as a dimension in policy X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 00:43:32 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA64516E244Feusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In looking at draft-strassner-supa-generic-policy-info-model-04, I found my= self confused at the idea that all policy clauses were boolean, then realiz= ed that the root cause of my discomfort was the absence of a time dimension= in the policy concepts. A quick look at RFCs 3060 and 3460 indicates that = they also don't reflect the passage of time. For this discussion, consider the event-condition-action model, but keep ot= her models in mind for applicability. First, events We (I) think of policy as an algorithm that is evaluated from time to time,= but not continuously with infinitesimal granularity (note). If this be tru= e, execution of the algorithm is triggered by an event, which may be the ti= ck of a clock. Taking the concept of state very broadly, event reports are = generated by changes in state of some domain of interest. I assert that sta= te is rarely boolean: more often than not, state is multi-valued, and may w= ell be multi-dimensional. If we require an event to be a boolean clause, we= must construct it along the lines: (observedState =3D=3D x) AND (in the most recent previous iteration of the = algorithm, observedState <> x) Surely it is more straightforward to recognize the event as the trigger for= execution of the algorithm. (And besides, the expression above looks like = a condition, not obviously an event.) We may wish to filter events: if events a, b, but not c all occur within th= e most recent 1-second sliding window, then trigger the algorithm. Such an = expression looks boolean, but it exists in time, not in the static space of= logic. Binary is perhaps a better word than boolean; we do indeed expect a= yes/no result from each term. Note - applied to driving a car, an example of a policy in continuous time = might be something like, "The center line shall be maintained on a visual r= eference point." Whether continuous time is of interest in our work is an o= pen question: we speak of examples such as, "don't let server loading excee= d x%" - how are we to understand the microscopic or even milliscopic time d= ependency of such a policy? Second, conditions When we begin the evaluation of a policy algorithm, we imagine that the uni= verse freezes, or at least that we have a static snapshot substrate on whic= h to perform the evaluation. Given that assumption - and it should be clear= ly stated - it is probably okay to evaluate conditions as booleans. Third, actions Actions necessarily involve a time aspect: as the result of a policy evalua= tion, we wish to change some state (or not). It is not clear how we would c= onstruct meaningful action clauses that were intrinsically boolean. Yes, th= ey can be combined in boolean ways: (do action x) AND (do action y). Even h= ere, the sensible combinations are limited. We would probably not say (do x= ) OR (do y), nor would we say (do x) AND (don't do y). Am I completely off in the weeds on this? Or if this is all old news, could= someone point me to the RFC (or other) material that rationalizes time int= o this story? Thanks, Dave --_000_8D15A2BAF93E9C49AB037A0647E5FA64516E244Feusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In looking at draft-strassner-supa= -generic-policy-info-model-04, I found myself confused at the idea that all= policy clauses were boolean, then realized that the root cause of my discomfort was the absence of a time dimension in the policy c= oncepts. A quick look at RFCs 3060 and 3460 indicates that they also don= 217;t reflect the passage of time.

 

For this discussion, consider the = event-condition-action model, but keep other models in mind for applicabili= ty.

 

First, events

We (I) = think of policy as an algorithm that is evaluated from time to time, but no= t continuously with infinitesimal granularity (note). If this be true, execution of the algorithm is triggered by an event, which may be= the tick of a clock. Taking the concept of state very broadly, event repor= ts are generated by changes in state of some domain of interest. I assert t= hat state is rarely boolean: more often than not, state is multi-valued, and may well be multi-dimensional. = If we require an event to be a boolean clause, we must construct it along t= he lines:

&n= bsp;

(obser= vedState =3D=3D x) AND (in the most recent previous iteration of the algori= thm, observedState <> x)

&n= bsp;

Surely = it is more straightforward to recognize the event as the trigger for execut= ion of the algorithm. (And besides, the expression above looks like a condition, not obviously an event.)

&n= bsp;

We may = wish to filter events: if events a, b, but not c all occur within the most = recent 1-second sliding window, then trigger the algorithm. Such an expression looks boolean, but it exists in time, not in the static= space of logic. Binary is perhaps a better word than boolean; we do indeed= expect a yes/no result from each term.

&n= bsp;

Note &= #8211; applied to driving a car, an example of a policy in continuous time = might be something like, “The center line shall be maintained on a visual reference point.” Whether continuous time is of interest in= our work is an open question: we speak of examples such as, “donR= 17;t let server loading exceed x%” – how are we to understand t= he microscopic or even milliscopic time dependency of such a policy?

 

Second, conditions

When we= begin the evaluation of a policy algorithm, we imagine that the universe f= reezes, or at least that we have a static snapshot substrate on which to perform the evaluation. Given that assumption – and it s= hould be clearly stated – it is probably okay to evaluate conditions = as booleans.

&n= bsp;

Third, actions

Actions= necessarily involve a time aspect: as the result of a policy evaluation, w= e wish to change some state (or not). It is not clear how we would construct meaningful action clauses that were intrinsically boole= an. Yes, they can be combined in boolean ways: (do action x) AND (do action= y). Even here, the sensible combinations are limited. We would probably no= t say (do x) OR (do y), nor would we say (do x) AND (don’t do y).

&n= bsp;

Am I completely off in the weeds o= n this? Or if this is all old news, could someone point me to the RFC (or o= ther) material that rationalizes time into this story?

 

Thanks,

Dave

--_000_8D15A2BAF93E9C49AB037A0647E5FA64516E244Feusaamb105erics_-- From nobody Tue Mar 8 19:56:49 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0CF12DE36 for ; Tue, 8 Mar 2016 19:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.608 X-Spam-Level: * X-Spam-Status: No, score=1.608 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=2.399] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=randy_presuhn@mindspring.com header.d=mindspring.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNPYYLGFtp4d for ; Tue, 8 Mar 2016 19:56:47 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 5048A12DE32 for ; Tue, 8 Mar 2016 19:56:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qYCbl7EJEpKWjnymjpOMIDK2VBL5IC4R4ND7Q6ip4ybok/2SjAU+MFhwpKcpTUiB; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1adVEn-0000TT-JT for supa@ietf.org; Tue, 08 Mar 2016 22:56:41 -0500 Received: from 76.254.51.138 by webmail.earthlink.net with HTTP; Tue, 8 Mar 2016 22:56:41 -0500 Message-ID: <5172640.1457495801418.JavaMail.wam@mswamui-billy.atl.sa.earthlink.net> Date: Tue, 8 Mar 2016 19:56:41 -0800 (GMT-08:00) From: Randy Presuhn To: "supa@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddcf9a642c162b977aff1ba2b6e42f1915a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.27 Archived-At: Subject: Re: [Supa] Time as a dimension in policy X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Randy Presuhn List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 03:56:48 -0000 Hi - > From: Dave Hood > Sent: Mar 8, 2016 4:43 PM > To: "supa@ietf.org" > Subject: [Supa] Time as a dimension in policy .. > Am I completely off in the weeds on this? Or if this is > all old news, could someone point me to the RFC (or other) > material that rationalizes time into this story? RFC 2981, 2982, and 2592/3165 address these issues in the SNMP universe. Randy From nobody Wed Mar 9 00:23:31 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F4E12DF6C for ; Wed, 9 Mar 2016 00:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM6Q2i9Cnqu1 for ; Wed, 9 Mar 2016 00:23:27 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0392E12DEFD for ; Wed, 9 Mar 2016 00:23:27 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7809720FE; Wed, 9 Mar 2016 09:23:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fBcByt40N8tc; Wed, 9 Mar 2016 09:23:13 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 9 Mar 2016 09:23:24 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C8922003D; Wed, 9 Mar 2016 09:23:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id raRz1aOb315u; Wed, 9 Mar 2016 09:23:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9ABB12003A; Wed, 9 Mar 2016 09:23:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0C7AC3A2AB83; Wed, 9 Mar 2016 09:23:12 +0100 (CET) Date: Wed, 9 Mar 2016 09:23:12 +0100 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20160309082312.GA8538@elstar.local> Mail-Followup-To: "Joel M. Halpern" , joel jaeggli , Andy Bierman , SUPA list References: <20160307232308.GA5410@elstar.local> <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> <20160308070934.GB5979@elstar.local> <56DF006B.9080303@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56DF006B.9080303@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: joel jaeggli , Andy Bierman , SUPA list Subject: Re: [Supa] SUPA - Domain Specific Languages X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 08:23:29 -0000 On Tue, Mar 08, 2016 at 11:40:11AM -0500, Joel M. Halpern wrote: > With regard to using domain specific langauges for policy configuration, > I have a number of reactions. > > 1) We actually allow that. In the next revision of the information > model, we will include for supa encoded clause a language identifier. > THe list will be small, but extensible. So a SUPA encoded clause can be > used to carry / point to a domain specific langague policy expression. > (We only noticed the absence of the language tag in an internal review > after we sent the document to the WG. > > 2) In terms of modeling, a domain specific lanague is very hard to use > interoperably. It only works on entities that support that specific > lanague. We want to have a representation that is actually > interoperable. When you combine this with the instruction from the > charter to focus on imperative event-condition-action policy > expressions, we are sort of stuck with what we put in. > NETCONF supports XPATH filtering since its origin. The SUPAPolicyTerms in the I-D is far from XPATH in terms of expressiveness. Very far. I am not saying XPATH is the answer but the claim that domain specific languages are very hard to use interoperably is surprising from a NETCONF/YANG perspective. YANG itself is a domain specific data modeling language... SUPAPolicyTerms constructed out of variables, a limited set of operators, and values really do not cut it. You can't even compare two variables! Parenthesis? No. Addition? No. Multiplication? No. String operators? No. And then there is a type system completely detached from YANG's type system because it needs to be generic (and so we pick a random selection of ~10 possibly useful types and we will worry about figuring out how all of this maps to YANG later). I understand that the details can be changed and improved. I do not want to go into a discussion of details since my concern is way more fundamental. I believe in a domain specific policy language approach and I believe in an approach that tightly integrates with YANG (i.e., builds on YANG's type system and naming system). I believe it is of key importance to make it easy for humans to read policies and to write policies. The implementors view is of least importance. Being able to write down expressions on top of YANG defined data models is where things start. I need an expression language to do that. I do not care how this is implemented internally or how terms and clauses are represented internally in an implementation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 9 05:50:37 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60FA12D624 for ; Wed, 9 Mar 2016 05:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yG2hziB4kl3 for ; Wed, 9 Mar 2016 05:50:29 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841AB12D527 for ; Wed, 9 Mar 2016 05:50:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 5DB31245BC3; Wed, 9 Mar 2016 05:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1457531429; bh=4G8ep/c/mLwA2jT8o5TO++1JLWSshTUg7ijZ784mSLw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jTA5cBIZ/BwlOcvPIXUzecZec0KFf+R7/X0jYqL3/nGD6jCWFnKqIpNFjStnTV7a0 SiBh2S3XvyBhKLTX2GxDJ9qfddqhEwz+n6o9wiZUPRyDD0OeMrCuuG2dAociidWFVW 4/3rBlaRryr9IxXttqralqqB45bn/lUKhVoaHGTU= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id DC2CD2407EC; Wed, 9 Mar 2016 05:50:28 -0800 (PST) To: joel jaeggli , Andy Bierman , SUPA list References: <20160307232308.GA5410@elstar.local> <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> <20160308070934.GB5979@elstar.local> <56DF006B.9080303@joelhalpern.com> <20160309082312.GA8538@elstar.local> From: "Joel M. Halpern" Message-ID: <56E02A19.2020509@joelhalpern.com> Date: Wed, 9 Mar 2016 08:50:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160309082312.GA8538@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Supa] SUPA - Domain Specific Languages X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 13:50:35 -0000 Juergen, I can not tell which of several very different requests you are making. One set of interpretations relate to the expressions of constraints in the model. One possible interpretation of your note is that we should include xpath expressions as one of the possible constraint languages in the Infomration Model and Data Model. A second possible interpretation is that we should make xpath the only possible constraint language. Another set relates to the policy clauses and terms we can express in the model. You could be asking that we allow xpath as a language for expressing policy rules in the encoded clause. You could be asking that we mandate xpath as the langauge for the encoded clause. And what it looks like you are mandating is that we require that xpath based encoded clauses be the only way of expressing policy clauses (that we not allow composition in terms of variables, operators, and values. In each of these sets of interpretations, the first request, namely including xpath in what can be used, seems reasonable. Mandating xpath in this model seems quite counter-productive. In terms of a domain specific language for expressing policy, that humans can work in easily, I do not consider UML, xpath, or YANG, to be such languages. Yours, Joel On 3/9/16 3:23 AM, Juergen Schoenwaelder wrote: > On Tue, Mar 08, 2016 at 11:40:11AM -0500, Joel M. Halpern wrote: >> With regard to using domain specific langauges for policy configuration, >> I have a number of reactions. >> >> 1) We actually allow that. In the next revision of the information >> model, we will include for supa encoded clause a language identifier. >> THe list will be small, but extensible. So a SUPA encoded clause can be >> used to carry / point to a domain specific langague policy expression. >> (We only noticed the absence of the language tag in an internal review >> after we sent the document to the WG. >> >> 2) In terms of modeling, a domain specific lanague is very hard to use >> interoperably. It only works on entities that support that specific >> lanague. We want to have a representation that is actually >> interoperable. When you combine this with the instruction from the >> charter to focus on imperative event-condition-action policy >> expressions, we are sort of stuck with what we put in. >> > > NETCONF supports XPATH filtering since its origin. The SUPAPolicyTerms > in the I-D is far from XPATH in terms of expressiveness. Very far. I > am not saying XPATH is the answer but the claim that domain specific > languages are very hard to use interoperably is surprising from a > NETCONF/YANG perspective. YANG itself is a domain specific data > modeling language... > > SUPAPolicyTerms constructed out of variables, a limited set of > operators, and values really do not cut it. You can't even compare two > variables! Parenthesis? No. Addition? No. Multiplication? No. String > operators? No. > > And then there is a type system completely detached from YANG's type > system because it needs to be generic (and so we pick a random > selection of ~10 possibly useful types and we will worry about > figuring out how all of this maps to YANG later). > > I understand that the details can be changed and improved. I do not > want to go into a discussion of details since my concern is way more > fundamental. I believe in a domain specific policy language approach > and I believe in an approach that tightly integrates with YANG (i.e., > builds on YANG's type system and naming system). I believe it is of > key importance to make it easy for humans to read policies and to > write policies. The implementors view is of least importance. Being > able to write down expressions on top of YANG defined data models is > where things start. I need an expression language to do that. I do not > care how this is implemented internally or how terms and clauses are > represented internally in an implementation. > > /js > From nobody Wed Mar 9 07:13:48 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A1612D6D4 for ; Wed, 9 Mar 2016 06:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKmHknUBWhCH for ; Wed, 9 Mar 2016 06:55:27 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6744912D709 for ; Wed, 9 Mar 2016 06:52:16 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BAE851DD5; Wed, 9 Mar 2016 15:52:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wm4Cq7POGvH8; Wed, 9 Mar 2016 15:52:01 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 9 Mar 2016 15:52:13 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 572F820051; Wed, 9 Mar 2016 15:52:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WhDZlNVyQDFu; Wed, 9 Mar 2016 15:52:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B4CD2003D; Wed, 9 Mar 2016 15:52:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6CAB83A2B4FC; Wed, 9 Mar 2016 15:52:11 +0100 (CET) Date: Wed, 9 Mar 2016 15:52:11 +0100 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20160309145211.GA354@elstar.local> Mail-Followup-To: "Joel M. Halpern" , joel jaeggli , Andy Bierman , SUPA list References: <20160307232308.GA5410@elstar.local> <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> <20160308070934.GB5979@elstar.local> <56DF006B.9080303@joelhalpern.com> <20160309082312.GA8538@elstar.local> <56E02A19.2020509@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56E02A19.2020509@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: joel jaeggli , Andy Bierman , SUPA list Subject: Re: [Supa] SUPA - Domain Specific Languages X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 14:55:31 -0000 Joel, I think my message is as clear as I can express myself. - The first paragraph responds to your claim that a domain specific lanague is very hard to use interoperably. - The second and third paragraph point out examples where the I-D is (a) rather limited compared what NETCONF can already do using xpath (and see my text in paranthesis) and (b) that being generic instead of tight to YANG requires translations and mappings (the type system being an easy example since I did not find anything quickly where the generic model talks about instance naming). - The last paragraph is the real essence. (i) By being generic you introduce a lot of additional mapping complexity. (ii) By following an object-oriented approach instead of a domain specific language approach you may make it easier for implementors but way harder for human policy readers and policy writers. I used xpath as an _example_ since xpath is part of NETCONF and YANG. xpath expressions are reasonable to read/write for humans. What I am looking for in my dreams is a YANG policy language that builds on YANG (its type system, its naming, etc) and that provides me the primitives needed to express events, conditions and actions (that operate on YANG-defined data) in a concise syntax. This WG may not be chartered to provide this, so I may keep dreaming elsewhere. /js On Wed, Mar 09, 2016 at 08:50:17AM -0500, Joel M. Halpern wrote: > Juergen, I can not tell which of several very different requests you are > making. > > One set of interpretations relate to the expressions of constraints in > the model. > > One possible interpretation of your note is that we should include xpath > expressions as one of the possible constraint languages in the > Infomration Model and Data Model. > > A second possible interpretation is that we should make xpath the only > possible constraint language. > > Another set relates to the policy clauses and terms we can express in > the model. > > You could be asking that we allow xpath as a language for expressing > policy rules in the encoded clause. > > You could be asking that we mandate xpath as the langauge for the > encoded clause. > > And what it looks like you are mandating is that we require that xpath > based encoded clauses be the only way of expressing policy clauses (that > we not allow composition in terms of variables, operators, and values. > > In each of these sets of interpretations, the first request, namely > including xpath in what can be used, seems reasonable. > Mandating xpath in this model seems quite counter-productive. > > In terms of a domain specific language for expressing policy, that > humans can work in easily, I do not consider UML, xpath, or YANG, to be > such languages. > > Yours, > Joel > > On 3/9/16 3:23 AM, Juergen Schoenwaelder wrote: > >On Tue, Mar 08, 2016 at 11:40:11AM -0500, Joel M. Halpern wrote: > >>With regard to using domain specific langauges for policy configuration, > >>I have a number of reactions. > >> > >>1) We actually allow that. In the next revision of the information > >>model, we will include for supa encoded clause a language identifier. > >>THe list will be small, but extensible. So a SUPA encoded clause can be > >>used to carry / point to a domain specific langague policy expression. > >>(We only noticed the absence of the language tag in an internal review > >>after we sent the document to the WG. > >> > >>2) In terms of modeling, a domain specific lanague is very hard to use > >>interoperably. It only works on entities that support that specific > >>lanague. We want to have a representation that is actually > >>interoperable. When you combine this with the instruction from the > >>charter to focus on imperative event-condition-action policy > >>expressions, we are sort of stuck with what we put in. > >> > > > >NETCONF supports XPATH filtering since its origin. The SUPAPolicyTerms > >in the I-D is far from XPATH in terms of expressiveness. Very far. I > >am not saying XPATH is the answer but the claim that domain specific > >languages are very hard to use interoperably is surprising from a > >NETCONF/YANG perspective. YANG itself is a domain specific data > >modeling language... > > > >SUPAPolicyTerms constructed out of variables, a limited set of > >operators, and values really do not cut it. You can't even compare two > >variables! Parenthesis? No. Addition? No. Multiplication? No. String > >operators? No. > > > >And then there is a type system completely detached from YANG's type > >system because it needs to be generic (and so we pick a random > >selection of ~10 possibly useful types and we will worry about > >figuring out how all of this maps to YANG later). > > > >I understand that the details can be changed and improved. I do not > >want to go into a discussion of details since my concern is way more > >fundamental. I believe in a domain specific policy language approach > >and I believe in an approach that tightly integrates with YANG (i.e., > >builds on YANG's type system and naming system). I believe it is of > >key importance to make it easy for humans to read policies and to > >write policies. The implementors view is of least importance. Being > >able to write down expressions on top of YANG defined data models is > >where things start. I need an expression language to do that. I do not > >care how this is implemented internally or how terms and clauses are > >represented internally in an implementation. > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 9 07:23:28 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3902112E1B9 for ; Wed, 9 Mar 2016 07:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP7ZlUes_j6r for ; Wed, 9 Mar 2016 07:14:16 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B9F12DFB4 for ; Wed, 9 Mar 2016 07:02:46 -0800 (PST) Received: by mail-lb0-x22b.google.com with SMTP id k15so69904486lbg.0 for ; Wed, 09 Mar 2016 07:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7ETr6fAxu3dLeUTEYfsKoyqR7eRoxLdFS/8MiBzoEb8=; b=173goGEiG4Fe7JBThemwugCoEDu2qeLKJb4DZxjAizUkljA3bXuZbvhTMNDk2A13g6 fX8lpDWyd5vW3625WXOV5e7skQFlpj27u+hnTHh9tP4o1tf842GCYLEx32DRbXzsJRG/ AP7cDaPbjAEa6rOpe6FZxlYsaXgEbDM/jWgs3lPDCPe/G6X/6ovYM3H00Hs4O9L9gkeB OQyxA0OSdOeUKBaXon50GurGFWIOMdfyZS+s6BJRfE5mF/5mGXejhXiFRh+zOdjvVSEF 4EgI8FD+Hbo2MqgNytXEVl8Xvx1p6XQW7Tft98j5q3BDk8+QJJXHSOdOvJhR6olhxBQx PZsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7ETr6fAxu3dLeUTEYfsKoyqR7eRoxLdFS/8MiBzoEb8=; b=aTfv0+Vp0TpDJklyS0/ZNTe05uA9ynAhRSPXWNtteQ5PcjOqlXP0SqOn3z6m23z9DA xZ0vBKh5Gp2Cp6STJVB2uSVG2oR+GUZ6WlkVieqhsTr6/BL59ADmnXlw8Xsu+ZqWgyKh Jt1ykEhT1lnGfFF+kh5Mtts+6Deo158tzJ29v4qGXwOZeI2sEZHiz1XIEWroGnBZ7zvP ayEvdy0mLh3BSShXbNmLqgnHoCnblgVv3jymHd14U1yIvc7w3MZFwIXybRIcP9mWu2CP VB602U3SepURPyVfTQoW6PdyuKVb3p2nweY7+NdQhNYtLpUffGBD4XJQhivNbXzJvMPz Lz7w== X-Gm-Message-State: AD7BkJIPOzQfcHxoeXokWzb1l36+jxvJO4ltLQlHHJMmdrw1nfczduutU9OmoYKvNylxClOAjiM9pqoefBdOBg== MIME-Version: 1.0 X-Received: by 10.112.129.169 with SMTP id nx9mr11852195lbb.96.1457535734059; Wed, 09 Mar 2016 07:02:14 -0800 (PST) Received: by 10.112.132.65 with HTTP; Wed, 9 Mar 2016 07:02:13 -0800 (PST) In-Reply-To: <56E02A19.2020509@joelhalpern.com> References: <20160307232308.GA5410@elstar.local> <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> <20160308070934.GB5979@elstar.local> <56DF006B.9080303@joelhalpern.com> <20160309082312.GA8538@elstar.local> <56E02A19.2020509@joelhalpern.com> Date: Wed, 9 Mar 2016 07:02:13 -0800 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7b3441daad37d4052d9efb50 Archived-At: Cc: joel jaeggli , SUPA list Subject: Re: [Supa] SUPA - Domain Specific Languages X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 15:14:20 -0000 --047d7b3441daad37d4052d9efb50 Content-Type: text/plain; charset=UTF-8 Hi, I have also brought up XPath before as an example of an existing standard that can be used to specify an expression. I agree with Juergen that XPath is far more powerful and complete than the SUPA info model logic trees. That does not mean XPath is a policy language, but rather just a good way to express some logic. I would much rather fill in 1 XPath leaf than 50 or 60 logic tree leafs. I would rather be able to use the YANG 1.1 XPath function library than hack new solutions to get those same features. I am interested in a YANG-based solution, same as Juergen. I expect YANG to change over the years. In fact, v. 1.1 is not yet an RFC, so YANG is changing this year. If it gets dumped in the future for something better, that's fine. We can deal with that issue if it ever comes up. But for now, if you have a better language for the IETF to use, then let's see it. Andy On Wed, Mar 9, 2016 at 5:50 AM, Joel M. Halpern wrote: > Juergen, I can not tell which of several very different requests you are > making. > > One set of interpretations relate to the expressions of constraints in the > model. > > One possible interpretation of your note is that we should include xpath > expressions as one of the possible constraint languages in the Infomration > Model and Data Model. > > A second possible interpretation is that we should make xpath the only > possible constraint language. > > Another set relates to the policy clauses and terms we can express in the > model. > > You could be asking that we allow xpath as a language for expressing > policy rules in the encoded clause. > > You could be asking that we mandate xpath as the langauge for the encoded > clause. > > And what it looks like you are mandating is that we require that xpath > based encoded clauses be the only way of expressing policy clauses (that we > not allow composition in terms of variables, operators, and values. > > In each of these sets of interpretations, the first request, namely > including xpath in what can be used, seems reasonable. > Mandating xpath in this model seems quite counter-productive. > > In terms of a domain specific language for expressing policy, that humans > can work in easily, I do not consider UML, xpath, or YANG, to be such > languages. > > Yours, > Joel > > On 3/9/16 3:23 AM, Juergen Schoenwaelder wrote: > >> On Tue, Mar 08, 2016 at 11:40:11AM -0500, Joel M. Halpern wrote: >> >>> With regard to using domain specific langauges for policy configuration, >>> I have a number of reactions. >>> >>> 1) We actually allow that. In the next revision of the information >>> model, we will include for supa encoded clause a language identifier. >>> THe list will be small, but extensible. So a SUPA encoded clause can be >>> used to carry / point to a domain specific langague policy expression. >>> (We only noticed the absence of the language tag in an internal review >>> after we sent the document to the WG. >>> >>> 2) In terms of modeling, a domain specific lanague is very hard to use >>> interoperably. It only works on entities that support that specific >>> lanague. We want to have a representation that is actually >>> interoperable. When you combine this with the instruction from the >>> charter to focus on imperative event-condition-action policy >>> expressions, we are sort of stuck with what we put in. >>> >>> >> NETCONF supports XPATH filtering since its origin. The SUPAPolicyTerms >> in the I-D is far from XPATH in terms of expressiveness. Very far. I >> am not saying XPATH is the answer but the claim that domain specific >> languages are very hard to use interoperably is surprising from a >> NETCONF/YANG perspective. YANG itself is a domain specific data >> modeling language... >> >> SUPAPolicyTerms constructed out of variables, a limited set of >> operators, and values really do not cut it. You can't even compare two >> variables! Parenthesis? No. Addition? No. Multiplication? No. String >> operators? No. >> >> And then there is a type system completely detached from YANG's type >> system because it needs to be generic (and so we pick a random >> selection of ~10 possibly useful types and we will worry about >> figuring out how all of this maps to YANG later). >> >> I understand that the details can be changed and improved. I do not >> want to go into a discussion of details since my concern is way more >> fundamental. I believe in a domain specific policy language approach >> and I believe in an approach that tightly integrates with YANG (i.e., >> builds on YANG's type system and naming system). I believe it is of >> key importance to make it easy for humans to read policies and to >> write policies. The implementors view is of least importance. Being >> able to write down expressions on top of YANG defined data models is >> where things start. I need an expression language to do that. I do not >> care how this is implemented internally or how terms and clauses are >> represented internally in an implementation. >> >> /js >> >> --047d7b3441daad37d4052d9efb50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have also brought up XPath before= as an example of an existing standard
that can be used to specif= y an expression.=C2=A0 I agree with Juergen that XPath
is far mor= e powerful and complete than the SUPA info model logic trees.
That does not mean XPath is a policy language, but rather just = a good
way to express some logic.=C2=A0 I would much rather fill = in 1 XPath leaf
than 50 or 60 logic tree leafs.=C2=A0 I would rat= her be able to use
the YANG 1.1 XPath function library than hack = new solutions to get
those same features.

I am interested in a YANG-based solution, same as Juergen.
I ex= pect YANG to change over the years.=C2=A0 In fact, v. 1.1 is not
= yet an RFC, so YANG is changing this year.=C2=A0 If it gets dumped in the f= uture
for something better, that's fine.=C2=A0 We can deal wi= th that issue if it ever comes up.

But for now, if= you have a better language for the IETF to use,
then let's s= ee it.=C2=A0

Andy



On Wed, Mar 9,= 2016 at 5:50 AM, Joel M. Halpern <jmh@joelhalpern.com> wr= ote:
Juergen, I can not tell which of sev= eral very different requests you are making.

One set of interpretations relate to the expressions of constraints in the = model.

One possible interpretation of your note is that we should include xpath ex= pressions as one of the possible constraint languages in the Infomration Mo= del and Data Model.

A second possible interpretation is that we should make xpath the only poss= ible constraint language.

Another set relates to the policy clauses and terms we can express in the m= odel.

You could be asking that we allow xpath as a language for expressing policy= rules in the encoded clause.

You could be asking that we mandate xpath as the langauge for the encoded c= lause.

And what it looks like you are mandating is that we require that xpath base= d encoded clauses be the only way of expressing policy clauses (that we not= allow composition in terms of variables, operators, and values.

In each of these sets of interpretations, the first request, namely includi= ng xpath in what can be used, seems reasonable.
Mandating xpath in this model seems quite counter-productive.

In terms of a domain specific language for expressing policy, that humans c= an work in easily, I do not consider UML, xpath, or YANG, to be such langua= ges.

Yours,
Joel

On 3/9/16 3:23 AM, Juergen Schoenwaelder wrote:
On Tue, Mar 08, 2016 at 11:40:11AM -0500, Joel M. Halpern wrote:
With regard to using domain specific langauges for policy configuration, I have a number of reactions.

1) We actually allow that.=C2=A0 In the next revision of the information model, we will include for supa encoded clause a language identifier.
THe list will be small, but extensible.=C2=A0 So a SUPA encoded clause can = be
used to carry / point to a domain specific langague policy expression.
(We only noticed the absence of the language tag in an internal review
after we sent the document to the WG.

2) In terms of modeling, a domain specific lanague is very hard to use
interoperably.=C2=A0 It only works on entities that support that specific lanague.=C2=A0 We want to have a representation that is actually
interoperable.=C2=A0 When you combine this with the instruction from the charter to focus on imperative event-condition-action policy
expressions, we are sort of stuck with what we put in.


NETCONF supports XPATH filtering since its origin. The SUPAPolicyTerms
in the I-D is far from XPATH in terms of expressiveness. Very far. I
am not saying XPATH is the answer but the claim that domain specific
languages are very hard to use interoperably is surprising from a
NETCONF/YANG perspective. YANG itself is a domain specific data
modeling language...

SUPAPolicyTerms constructed out of variables, a limited set of
operators, and values really do not cut it. You can't even compare two<= br> variables!=C2=A0 Parenthesis? No. Addition? No. Multiplication?=C2=A0 No. S= tring
operators?=C2=A0 No.

And then there is a type system completely detached from YANG's type system because it needs to be generic (and so we pick a random
selection of ~10 possibly useful types and we will worry about
figuring out how all of this maps to YANG later).

I understand that the details can be changed and improved. I do not
want to go into a discussion of details since my concern is way more
fundamental. I believe in a domain specific policy language approach
and I believe in an approach that tightly integrates with YANG (i.e.,
builds on YANG's type system and naming system). I believe it is of
key importance to make it easy for humans to read policies and to
write policies. The implementors view is of least importance.=C2=A0 Being able to write down expressions on top of YANG defined data models is
where things start. I need an expression language to do that. I do not
care how this is implemented internally or how terms and clauses are
represented internally in an implementation.

/js


--047d7b3441daad37d4052d9efb50-- From nobody Wed Mar 9 07:31:24 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA9112E2A9 for ; Wed, 9 Mar 2016 07:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pS3BzhltTOZz for ; Wed, 9 Mar 2016 07:30:23 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF0312E1A2 for ; Wed, 9 Mar 2016 07:12:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C532E24EA8B; Wed, 9 Mar 2016 07:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1457536362; bh=U8M+XOPrn3K+NEcZCWFepwneBpWntjDDR5UnVXxguzY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ISSL3ZkigCHg/9aXLHONjx5qnysnZPCukLK2xi6/raNNjilgyHgtYpwRBk2QX1y/Z gE/SuRVVWcTx4XXNThsrMrqmNIKk8tL1RbRW9X7lnsdvBO0vSk9yOhslhc8VLUGxCI k+LMLUauEjR+Xew5k924e2p6oQUp+mUBUxhWqiOA= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4843F246502; Wed, 9 Mar 2016 07:12:42 -0800 (PST) To: Andy Bierman References: <20160307232308.GA5410@elstar.local> <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> <20160308070934.GB5979@elstar.local> <56DF006B.9080303@joelhalpern.com> <20160309082312.GA8538@elstar.local> <56E02A19.2020509@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <56E03D5E.8070406@joelhalpern.com> Date: Wed, 9 Mar 2016 10:12:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: joel jaeggli , SUPA list Subject: Re: [Supa] SUPA - Domain Specific Languages X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 15:30:45 -0000 We will include xpath in the language lists for both constraints and encoded expressions in the next rev of the information model (and the YANG). That makes good sense. Yours, Joel On 3/9/16 10:02 AM, Andy Bierman wrote: > Hi, > > I have also brought up XPath before as an example of an existing standard > that can be used to specify an expression. I agree with Juergen that XPath > is far more powerful and complete than the SUPA info model logic trees. > > That does not mean XPath is a policy language, but rather just a good > way to express some logic. I would much rather fill in 1 XPath leaf > than 50 or 60 logic tree leafs. I would rather be able to use > the YANG 1.1 XPath function library than hack new solutions to get > those same features. > > I am interested in a YANG-based solution, same as Juergen. > I expect YANG to change over the years. In fact, v. 1.1 is not > yet an RFC, so YANG is changing this year. If it gets dumped in the future > for something better, that's fine. We can deal with that issue if it > ever comes up. > > But for now, if you have a better language for the IETF to use, > then let's see it. > > Andy > > > > On Wed, Mar 9, 2016 at 5:50 AM, Joel M. Halpern > wrote: > > Juergen, I can not tell which of several very different requests you > are making. > > One set of interpretations relate to the expressions of constraints > in the model. > > One possible interpretation of your note is that we should include > xpath expressions as one of the possible constraint languages in the > Infomration Model and Data Model. > > A second possible interpretation is that we should make xpath the > only possible constraint language. > > Another set relates to the policy clauses and terms we can express > in the model. > > You could be asking that we allow xpath as a language for expressing > policy rules in the encoded clause. > > You could be asking that we mandate xpath as the langauge for the > encoded clause. > > And what it looks like you are mandating is that we require that > xpath based encoded clauses be the only way of expressing policy > clauses (that we not allow composition in terms of variables, > operators, and values. > > In each of these sets of interpretations, the first request, namely > including xpath in what can be used, seems reasonable. > Mandating xpath in this model seems quite counter-productive. > > In terms of a domain specific language for expressing policy, that > humans can work in easily, I do not consider UML, xpath, or YANG, to > be such languages. > > Yours, > Joel > > On 3/9/16 3:23 AM, Juergen Schoenwaelder wrote: > > On Tue, Mar 08, 2016 at 11:40:11AM -0500, Joel M. Halpern wrote: > > With regard to using domain specific langauges for policy > configuration, > I have a number of reactions. > > 1) We actually allow that. In the next revision of the > information > model, we will include for supa encoded clause a language > identifier. > THe list will be small, but extensible. So a SUPA encoded > clause can be > used to carry / point to a domain specific langague policy > expression. > (We only noticed the absence of the language tag in an > internal review > after we sent the document to the WG. > > 2) In terms of modeling, a domain specific lanague is very > hard to use > interoperably. It only works on entities that support that > specific > lanague. We want to have a representation that is actually > interoperable. When you combine this with the instruction > from the > charter to focus on imperative event-condition-action policy > expressions, we are sort of stuck with what we put in. > > > NETCONF supports XPATH filtering since its origin. The > SUPAPolicyTerms > in the I-D is far from XPATH in terms of expressiveness. Very far. I > am not saying XPATH is the answer but the claim that domain specific > languages are very hard to use interoperably is surprising from a > NETCONF/YANG perspective. YANG itself is a domain specific data > modeling language... > > SUPAPolicyTerms constructed out of variables, a limited set of > operators, and values really do not cut it. You can't even > compare two > variables! Parenthesis? No. Addition? No. Multiplication? No. > String > operators? No. > > And then there is a type system completely detached from YANG's type > system because it needs to be generic (and so we pick a random > selection of ~10 possibly useful types and we will worry about > figuring out how all of this maps to YANG later). > > I understand that the details can be changed and improved. I do not > want to go into a discussion of details since my concern is way more > fundamental. I believe in a domain specific policy language approach > and I believe in an approach that tightly integrates with YANG > (i.e., > builds on YANG's type system and naming system). I believe it is of > key importance to make it easy for humans to read policies and to > write policies. The implementors view is of least importance. Being > able to write down expressions on top of YANG defined data models is > where things start. I need an expression language to do that. I > do not > care how this is implemented internally or how terms and clauses are > represented internally in an implementation. > > /js > > From nobody Thu Mar 10 04:04:34 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA6112D6CE for ; Thu, 10 Mar 2016 04:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8Y_TCBPcDB4c for ; Thu, 10 Mar 2016 04:04:30 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF7112D6A3 for ; Thu, 10 Mar 2016 04:04:28 -0800 (PST) Received: by mail-lb0-x22e.google.com with SMTP id k15so109645450lbg.0 for ; Thu, 10 Mar 2016 04:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=RcB1gQLuACqhToliY3yS8qssFoe3fB5VPRNJL+io5Bk=; b=DvUZbVSBQ8h6JkU05M9W7lq1QAKiuS6WOzMzRxtr6B6spCGFCIUD/fxxRYhZ1x6k7z 7z274giFBIP+YmHlnrWLZ0UcD6tloaV6nTbcFkZAK8ocCLfmJ2TGtA/Z60bgixcnSykc gdsEKPdshWFLFIqISxOtMhstkv8XwIYeVmVRSzfOBxvzRu5LoceBPlQVAshzB0uehcOE FvlofbDu/aHljv7I8jSWJrp4QrrtAMIb9VnaBIGhi99ykcmR4NUHHJzY0z23rSetiAoD Q7BiYPfllPHfYFzdrnW6o3S5vZ32RwIExNFm82jnBj9aeY5vWuAlAxuJEKhmf+fYvxyj Ssbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=RcB1gQLuACqhToliY3yS8qssFoe3fB5VPRNJL+io5Bk=; b=Np6poc1z4JmlBaZBqeltlGKeLKbrFL5T5HLm8YXybbqTy/J61Sv6FZRR1vWNoIUNya cBLPVji1RWi2wiEEvSiMY01IAlmpMArw7YSlfbAF/8F6PaVmulmSTxIEc4iv/OiUZiH6 VRoyg04CVYsd8PVY1I/nrSK6jZcM2c53Gp4pJQPjhTtjfJRvG2tYtCYmtgwkixwM+m+x npZfwzCqBuvKox9FV9yAqogd424A6vK4Rf9W3ilwWUtvqLJRWmoOaMOkYib34bU0htaR D1wpfOFGUX6ryzuPxsvaSkeXU8qxat9JoyVhQiQtClqKn/r7MTJB7OEWqVpTYpU7PRG+ ic7A== X-Gm-Message-State: AD7BkJKQW155Y9GnNhnl6GEScw2j1mnNPUFg+4YpE4ItCdoMp0cGp3z0MfsC0N+cPcn0tE43FmJKTMv5QL+Wzw== MIME-Version: 1.0 X-Received: by 10.25.21.151 with SMTP id 23mr1085541lfv.89.1457611466084; Thu, 10 Mar 2016 04:04:26 -0800 (PST) Received: by 10.25.156.76 with HTTP; Thu, 10 Mar 2016 04:04:25 -0800 (PST) In-Reply-To: <20160309082312.GA8538@elstar.local> References: <20160307232308.GA5410@elstar.local> <20097333-8856-2956-7578-2fd7fc9d1873@bogus.com> <20160308070934.GB5979@elstar.local> <56DF006B.9080303@joelhalpern.com> <20160309082312.GA8538@elstar.local> Date: Thu, 10 Mar 2016 04:04:25 -0800 Message-ID: From: John Strassner To: Juergen Schoenwaelder , "Joel M. Halpern" , joel jaeggli , Andy Bierman , SUPA list , John Strassner Content-Type: multipart/alternative; boundary=001a11406aaea81c12052db09dbb Archived-At: Subject: Re: [Supa] SUPA - Domain Specific Languages X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 12:04:33 -0000 --001a11406aaea81c12052db09dbb Content-Type: text/plain; charset=UTF-8 > NETCONF supports XPATH filtering since its origin. The > SUPAPolicyTerms in the I-D is far from XPATH in terms > of expressiveness. Very far. SUPAPolicyTerm does not define a path filter. It only has a single attribute, supaPolTermIsNegated. Perhaps you are talking about SUPAPolicyComponentDecorator? That class defines supaPolCompConstraintEncoding, which specifies how to interpret the supaAPolCompConstraint attribute. However, XPATH (whether it is 1.0 or 3.1) is NOT a constraint language. I am confused why people think that XPATH is anything more than a query language for selecting nodes. In contrast, this class, and its attirbutes, are defined for expressing generic constraints. That is why OCL, QVT, and Alloy are specified. Please read the definitions of these languages and then explain why XPATH should be selected as a constraint language. That being said, if what is desired is to provide XPATH filtering, that is a reasonable request that we can add in the next version of the I-D. Let's just please get our terminology straight. > SUPAPolicyTerms constructed out of variables, a limited set of > operators, and values really do not cut it. You can't even compare two > variables! Parenthesis? No. Addition? No. Multiplication? No. String > operators? No. Comparison is supported in the enumeration. Parentheses is supported when you create the final version of the clause. Other operators are not normative, since they may or may not be relevant for a given application. We could certainly add text that specifies how this could be done. The point, however, is that this is ONE of MANY options available in creating a SUPAPolicyClause. If you don't like SUPAPolicyTerm and its subclasses, you are not mandated to use it. regards, John On Wed, Mar 9, 2016 at 12:23 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Mar 08, 2016 at 11:40:11AM -0500, Joel M. Halpern wrote: > > With regard to using domain specific langauges for policy configuration, > > I have a number of reactions. > > > > 1) We actually allow that. In the next revision of the information > > model, we will include for supa encoded clause a language identifier. > > THe list will be small, but extensible. So a SUPA encoded clause can be > > used to carry / point to a domain specific langague policy expression. > > (We only noticed the absence of the language tag in an internal review > > after we sent the document to the WG. > > > > 2) In terms of modeling, a domain specific lanague is very hard to use > > interoperably. It only works on entities that support that specific > > lanague. We want to have a representation that is actually > > interoperable. When you combine this with the instruction from the > > charter to focus on imperative event-condition-action policy > > expressions, we are sort of stuck with what we put in. > > > > NETCONF supports XPATH filtering since its origin. The SUPAPolicyTerms > in the I-D is far from XPATH in terms of expressiveness. Very far. I > am not saying XPATH is the answer but the claim that domain specific > languages are very hard to use interoperably is surprising from a > NETCONF/YANG perspective. YANG itself is a domain specific data > modeling language... > > SUPAPolicyTerms constructed out of variables, a limited set of > operators, and values really do not cut it. You can't even compare two > variables! Parenthesis? No. Addition? No. Multiplication? No. String > operators? No. > > And then there is a type system completely detached from YANG's type > system because it needs to be generic (and so we pick a random > selection of ~10 possibly useful types and we will worry about > figuring out how all of this maps to YANG later). > > I understand that the details can be changed and improved. I do not > want to go into a discussion of details since my concern is way more > fundamental. I believe in a domain specific policy language approach > and I believe in an approach that tightly integrates with YANG (i.e., > builds on YANG's type system and naming system). I believe it is of > key importance to make it easy for humans to read policies and to > write policies. The implementors view is of least importance. Being > able to write down expressions on top of YANG defined data models is > where things start. I need an expression language to do that. I do not > care how this is implemented internally or how terms and clauses are > represented internally in an implementation. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > -- regards, John --001a11406aaea81c12052db09dbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> NETCONF supports XPATH filtering since its origi= n. The
>=C2=A0SUPAPolicyTerms in the I-D is far from XPATH in = terms
>=C2=A0of expressiveness. Very far.

=
SUPAPolicyTerm does not define a path filter. It only has a
= single attribute, supaPolTermIsNegated.

Perhaps yo= u are talking about SUPAPolicyComponentDecorator?
That class defi= nes supaPolCompConstraintEncoding, which specifies
how to interpr= et the supaAPolCompConstraint attribute.

However, = XPATH (whether it is 1.0 or 3.1) is NOT a constraint
language. I = am confused why people think that XPATH is anything more
than a q= uery language for selecting nodes. In contrast, this class,
and i= ts attirbutes, are defined for expressing generic constraints. That is
why OCL, QVT, and Alloy are specified. Please read the definitions of=
these languages and then explain why XPATH should be selected as= a
constraint language.

That being said,= if what is desired is to provide XPATH filtering, that is
a reas= onable request that we can add in the next version of the I-D.
Le= t's just please get our terminology straight.

=
>=C2=A0SUPAPolicyTerms constructed out of variables, a limited set o= f
> operators, and values really do not cut it. You can't even c= ompare two
> variables!=C2=A0 Parenthesis? No. Addition? No. Multipl= ication?=C2=A0 No. String
> operators?=C2=A0 No.

Comparison is supported in the enumeration. Parentheses is supported<= /div>
when you create the final version of the clause.=C2=A0Other opera= tors are not
normative, since they may or may not be relevant for= a given application.
We could certainly add text that specifies = how this could be done.

The point, however, is tha= t this is ONE of MANY options available in
creating a SUPAPolicyC= lause. If you don't like SUPAPolicyTerm and its
subclasses, y= ou are=C2=A0not mandated to use it.

regards,
=
John

On Wed, Mar 9, 2016 at 12:23 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Mar 08, 2016 at 11:40:11AM -0500, Joel M. Ha= lpern wrote:
> With regard to using domain specific langauges for policy configuratio= n,
> I have a number of reactions.
>
> 1) We actually allow that.=C2=A0 In the next revision of the informati= on
> model, we will include for supa encoded clause a language identifier.<= br> > THe list will be small, but extensible.=C2=A0 So a SUPA encoded clause= can be
> used to carry / point to a domain specific langague policy expression.=
> (We only noticed the absence of the language tag in an internal review=
> after we sent the document to the WG.
>
> 2) In terms of modeling, a domain specific lanague is very hard to use=
> interoperably.=C2=A0 It only works on entities that support that speci= fic
> lanague.=C2=A0 We want to have a representation that is actually
> interoperable.=C2=A0 When you combine this with the instruction from t= he
> charter to focus on imperative event-condition-action policy
> expressions, we are sort of stuck with what we put in.
>

NETCONF supports XPATH filtering since its origin. The SUPAPolicyTerms
in the I-D is far from XPATH in terms of expressiveness. Very far. I
am not saying XPATH is the answer but the claim that domain specific
languages are very hard to use interoperably is surprising from a
NETCONF/YANG perspective. YANG itself is a domain specific data
modeling language...

SUPAPolicyTerms constructed out of variables, a limited set of
operators, and values really do not cut it. You can't even compare two<= br> variables!=C2=A0 Parenthesis? No. Addition? No. Multiplication?=C2=A0 No. S= tring
operators?=C2=A0 No.

And then there is a type system completely detached from YANG's type system because it needs to be generic (and so we pick a random
selection of ~10 possibly useful types and we will worry about
figuring out how all of this maps to YANG later).

I understand that the details can be changed and improved. I do not
want to go into a discussion of details since my concern is way more
fundamental. I believe in a domain specific policy language approach
and I believe in an approach that tightly integrates with YANG (i.e.,
builds on YANG's type system and naming system). I believe it is of
key importance to make it easy for humans to read policies and to
write policies. The implementors view is of least importance.=C2=A0 Being able to write down expressions on top of YANG defined data models is
where things start. I need an expression language to do that. I do not
care how this is implemented internally or how terms and clauses are
represented internally in an implementation.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa



--
regards,
John
--001a11406aaea81c12052db09dbb-- From nobody Fri Mar 11 11:10:43 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E36312DAA1 for ; Fri, 11 Mar 2016 11:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3K8xKx1Lm5c2 for ; Fri, 11 Mar 2016 11:10:38 -0800 (PST) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2E412DAAF for ; Fri, 11 Mar 2016 11:10:37 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud2.xs4all.net with ESMTP id UjAZ1s00U3vXPcr01jAawD; Fri, 11 Mar 2016 20:10:35 +0100 To: Joel Halpern , supa@ietf.org References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> From: "Bert Wijnen (IETF)" Message-ID: <56E31829.1080208@bwijnen.net> Date: Fri, 11 Mar 2016 20:10:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56BE4E09.3010402@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 19:10:41 -0000 Finally went through the whole document. Pffff many many pages. And sect 4.5 with subsections just states: This section will be completed in the next revision of this document. Oh well I am not ready to say yes or no for "WG adoption". The document feels very complex to me. I need to re-read it at least one or two more times in order to get it all. But I do have some comments/remarks/questions of the bat: some of this is nits, but since I was composing a list of comments anyways I figured I might as well add them. - in the document you speak of cardinality and multiplicity. are they used as synonyms of each other, of does one have a different meaning than the other? - on page 12 and 13 you talk about IM and DM and refer to RFC3198. I would think that a reference to RFC3444 would also make sense. As an informative reference. It explains a lot about the difference between the 2. Actually, I wonder if referencing 3198 is wise. It also contains a lot of stuff that never really took off in IETF or the industry. For exmplae it talks about SPPI, PIB and COPS-PR, which we (IETF) are in the process of declaring it HISTORIC. So why would we overload younger people with all that now more or less irrelevant material? - page 14: In this context, "manage" means that at least create, read, query, update, and delete functions are supported. Is there a difference between "read" an "query" is CRUD not enough? - page 16 This principle is one of the key characteristics that is NOT followed in [4], [6], [RFC3060], and [RFC3460]. That may very well be true, but why is this relevant? And why would that make RFC3060 and 3460 NORMATIVE references? I see some more references to these 2 documents, They all seem to indicate that something was wrong in those fcs or that we do things different. I do not see why that has to be NORMATIVE - section: 3.3.5. Association Class AM I missing D in the picture? Or am I just not understanding this at all? - please expand acronym RM-ODP's om page 23 - when I see figure 2, then I wonder why we do not split of EPRIM in to a separate document? - please expand LSIM on page 27 - It seems you want to make absolutely sure that we: Please see Appendix A for a comparison to previous work. it occurs manty times. oh well - I do not find this text (on page30): It is often necessary to construct groups of policies. The GPIM follows [2] and [5], and uses the composite pattern [11] to implement this functionality easy to read. One has to go to the reference section to figure out what (big) documents is refered to. Then, when I see DEN and SID. I start to worry. IIRC I once called SID the "spaghetti bowl of spaghetti bowls". COMPLEX and just the UNION of everything else as opposed to the INTERSECTION off all other specs. But that maybe a personal issue that no one else shares? - In figure 5 Why is the left subclass tagged as type C (Concrete) ? It does not have to be, does it? - When I read on page 38: A SUPAPolicySource MAY be mapped to a role (e.g., using the role-object pattern [11]); Then I get the feeling that [11] would be normative, no? I guess I need to understand [11] in order to use that role-object pattern. - page 50 towards bottom: Similarly, all SUPA classes are attributes are both uniquely for the first occurence of "are" I suspect s/are/and/ ?? - I see at various places text aka SUPAPolicyStructure was abstracted from DEN-ng [2], and a version of this class is in the process of being added to [5] Is that something we need to exactly know for each object? Would it not be better to state somewhere in an aknowledgement section or in the introduction that we have build on and used some of DEN-ng? - I see double negation aka: which is an enumerated non-negative integer Would it not be better and clearer to just say whic is a nonzero positive integer? mmm I see that zero is also a value that can occur. In SNMP we never wanted to use zero. Because it can often occur as an error when not initialized (yet). - sometimes I see If the value of this attribute is true other times I see If the value of this attribute is TRUE I guess it is better to be consistent and choose between the lowercase and uppercase. - I see (for example) this enumerated list multiple times: 0: undefined 1: String 2: GUID 3: UUID 4: URI 5: FQDN In SMI (SNMP) we used Textual Conventions for that. Is there such a thing or can/should we consider such a thing for GPIM too? - I see: 5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]" This is an optional array of string attributes that identifies the Mmmm in the prigrammin languages that I know (not too many I must confess, but still multiple), arrays are indexed from [0..n-1]. SO I wonder if this could lead to mis-understandings and/or programming errors. later on you use [0..n], so maybe this is just a typo. - section 5.7.2.1 Pls expand acronums OCL, QVT, SAT that are all use here for the 1st time in the document I believe. Maybe a reference to each will also be helpful. - page 91 pls expand acronyms DNF and CNF (used for the first time here I believe) Bert On 12/02/16 22:26, Joel Halpern wrote: > Below is the announcement of the revision of the Generic Information Model for the SUPA work. John has done the heavy lifting on > this, with help from Jason and myself. > > Over the last several months, we have made a lot of changes to this model. > > We really need working group review and comment on this. > > We will be working with the team that produced the earlier YANG models to drive a new YANG model that reflects this information > model. So if we have made mistakes here, we need to know ASAP. > > In the absence of significant concerns, once we have gotten a YANG model derived, we will also ask for WG adoption of this document. > > So please, read it and comment. > > Yours, > Joel > > > -------- Forwarded Message -------- > Subject: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt > Date: Fri, 12 Feb 2016 11:09:50 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA) > Authors : John Strassner > Joel Halpern > Jason Coleman > Filename : draft-strassner-supa-generic-policy-info-model-04.txt > Pages : 115 > Date : 2016-02-12 > > Abstract: > This document defines an information model for representing > policies using a common extensible framework that is independent > of language, protocol, repository. It is also independent of the > level of abstraction of the content and meaning of a policy. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-strassner-supa-generic-policy-info-model/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-strassner-supa-generic-policy-info-model-04 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Sun Mar 13 13:07:05 2016 Return-Path: X-Original-To: supa@ietf.org Delivered-To: supa@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 195AB12DD79; Fri, 11 Mar 2016 15:05:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230544.15028.631.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:44 -0800 Archived-At: X-Mailman-Approved-At: Sun, 13 Mar 2016 13:07:04 -0700 Cc: bclaise@cisco.com, supa@ietf.org Subject: [Supa] supa - Requested session has been scheduled for IETF 95 X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:44 -0000 Dear Daniel King, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. supa Session 1 (1:00:00) Friday, Afternoon Session I 1220-1320 Room Name: Atlantico C size: 225 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Simplified Use of Policy Abstractions Area Name: Operations and Management Area Session Requester: Daniel King Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 75 Conflicts to Avoid: First Priority: i2nsf l3sm lime netmod netconf opsarea opsawg sdnrg pce Second Priority: rtgarea rtgwg i2rs Special Requests: --------------------------------------------------------- From nobody Mon Mar 14 19:19:18 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674D712D827 for ; Mon, 14 Mar 2016 19:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 He0pjbsf03ft for ; Mon, 14 Mar 2016 19:18:58 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741A012D6A6 for ; Mon, 14 Mar 2016 19:18:57 -0700 (PDT) Received: by mail-lb0-x235.google.com with SMTP id bc4so4052225lbc.2 for ; Mon, 14 Mar 2016 19:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wzfdYqAj9K3137YkpsRSl0RoyvwKdVrxDX6/sVn/dAk=; b=J7p8CwI44jbdl/4iOJBUpVNQLWDBseXpupv8aoymmiiMiX7hASBsCfUZeJ+1NEEM6l MwLHI8LyJU77/68NwRFNKrzoy0AZUJi1nNX0XJ4ykTjPMOUWjwSf+syTL4pZoigKRk/1 MoYXB5DDj6ZydmtCyRWB5pC/5Zunplt6rPNFmrl7SR2lM1B42UFpt0tL7V9ThAuq9Na0 XZKLHpBsrWO2lgyTIdItn7h7bQHG61Grt4J03QWPdd4JHNOdNqemkbRG7gLzIsy65r+k 1wx7MIgXu6dcoWzPS0Bjsryvt4pZPlJ9winb03U4xi6ei93WzBxFvjE8+Wh2RK0DDQL8 S/5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wzfdYqAj9K3137YkpsRSl0RoyvwKdVrxDX6/sVn/dAk=; b=NiCUrqor3iuI1+RNaWD58FWuK8KYAaezldFY9LneCE/6bpz3aMHmuCM4eghN8vQCN4 M/kqs3R7Xmh7/j4FwYzFVx2LeLCZ5fF3oSSXa0VPGZGeHXE0J5Q5D5zgf2r9tfeMYnJ7 /I3xAqzJKlIsk+qWyOdxSOsPgn1RK5NKwPudUy58wU9pPkwoipvqcPwo/+53GxKk+IgU wnuPdy73bVgDD2799QO0dsxki3Srq4tnhGG9R6VZDa47XCAkUAHRjh/IfkssfADn1MRh rwuOzNaNCK1yD+HHvy+LjhLPD/0DjLEvXvVv51FrNsCIwdnD8RNFQP7X1hBaE/C/MhEN C3YA== X-Gm-Message-State: AD7BkJKD0d+hBCBFhz9h9jGYtMkwXMupHtaI9d7xmQODSm8cz+bYZ52ChDM2iHaITgF5ypugTa3C5a9vqXgVYg== MIME-Version: 1.0 X-Received: by 10.25.18.158 with SMTP id 30mr9638348lfs.16.1458008335414; Mon, 14 Mar 2016 19:18:55 -0700 (PDT) Received: by 10.25.156.76 with HTTP; Mon, 14 Mar 2016 19:18:55 -0700 (PDT) In-Reply-To: <56E31829.1080208@bwijnen.net> References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> Date: Mon, 14 Mar 2016 19:18:55 -0700 Message-ID: From: John Strassner To: "Bert Wijnen (IETF)" , John Strassner , Jason Coleman Content-Type: multipart/alternative; boundary=001a113f1fe0e97bdf052e0d04ea Archived-At: Cc: Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 02:19:16 -0000 --001a113f1fe0e97bdf052e0d04ea Content-Type: text/plain; charset=UTF-8 Hi Bert, comments below using .. ... - in the document you speak of cardinality and multiplicity. are they used as synonyms of each other, of does one have a different meaning than the other? Multiplicity refers to the relationship (i.e., association, aggregation, or composition) as a whole. It consists of two cardinalities, one for each side of the relationship. We will update the terminology to clarify this. - on page 12 and 13 you talk about IM and DM and refer to RFC3198. I would think that a reference to RFC3444 would also make sense. As an informative reference. It explains a lot about the difference between the 2. I used RFC3198 because RFC3444 does not provide a definition; it provides a discussion. In addition, it contains some errors (e.g., it says that UML is a "formal language", which is incorrect. However, your suggestion is a good one - we will work in a reference of RFC3444 somewhere... Actually, I wonder if referencing 3198 is wise. It also contains a lot of stuff that never really took off in IETF or the industry. For exmplae it talks about SPPI, PIB and COPS-PR, which we (IETF) are in the process of declaring it HISTORIC. So why would we overload younger people with all that now more or less irrelevant material? See above - page 14: In this context, "manage" means that at least create, read, query, update, and delete functions are supported. Is there a difference between "read" an "query" is CRUD not enough? "Read" is, at least to me, a simple command to provide a result. In contrast, "Query" is a more complex operation that may involve pre- and/or post- processing of the results of the operation. Note that many people think of SQL as a query language; in that case, the definition of query expands to include data definition, data control, and data manipulation languages. Would you like the above text included? - page 16 This principle is one of the key characteristics that is NOT followed in [4], [6], [RFC3060], and [RFC3460]. That may very well be true, but why is this relevant? And why would that make RFC3060 and 3460 NORMATIVE references? I see some more references to these 2 documents, They all seem to indicate that something was wrong in those fcs or that we do things different. I do not see why that has to be NORMATIVE This is relevant because it is a key design principle for scalable and extensible information models. I'm happy to make PCIM and PCIMe INFORMATIVE, good catch. - section: 3.3.5. Association Class AM I missing D in the picture? Or am I just not understanding this at all? Sorry, D is the association. Fixed. - please expand acronym RM-ODP's om page 23 Done. - when I see figure 2, then I wonder why we do not split of EPRIM in to a separate document? The thinking was: 1) there would be a lot of repeated text, and 2) it would be difficult for readers - they would have to have two documents open at the same time to understand the work - please expand LSIM on page 27 LSIM was defined on page 11, but sure, no problem - It seems you want to make absolutely sure that we: Please see Appendix A for a comparison to previous work. it occurs manty times. oh well It occurs 7 times. This happened as other WGs were starting to use PCIM, and were confused what the difference was between SUPA and PCIM - I do not find this text (on page30): It is often necessary to construct groups of policies. The GPIM follows [2] and [5], and uses the composite pattern [11] to implement this functionality easy to read. One has to go to the reference section to figure out what (big) documents is refered to. Then, when I see DEN and SID. I start to worry. IIRC I once called SID the "spaghetti bowl of spaghetti bowls". COMPLEX and just the UNION of everything else as opposed to the INTERSECTION off all other specs. But that maybe a personal issue that no one else shares? The point was to talk about the composite pattern ([11]) and note that it is used in many other works; two of those are [2] and [5]. - In figure 5 Why is the left subclass tagged as type C (Concrete) ? It does not have to be, does it? Oops, sorry about that, FIXED. - When I read on page 38: A SUPAPolicySource MAY be mapped to a role (e.g., using the role-object pattern [11]); Then I get the feeling that [11] would be normative, no? I guess I need to understand [11] in order to use that role-object pattern. [11] defines the original role-object pattern; there are many variants (but all are similar). I'll fix the wording. - page 50 towards bottom: Similarly, all SUPA classes are attributes are both uniquely for the first occurence of "are" I suspect s/are/and/ ?? Oops, good catch. FIXED. - I see at various places text aka SUPAPolicyStructure was abstracted from DEN-ng [2], and a version of this class is in the process of being added to [5] Is that something we need to exactly know for each object? Would it not be better to state somewhere in an aknowledgement section or in the introduction that we have build on and used some of DEN-ng? I didn't want to give the impression that everything was DEN-ng, but ok - I see double negation aka: which is an enumerated non-negative integer Would it not be better and clearer to just say whic is a nonzero positive integer? mmm I see that zero is also a value that can occur. In SNMP we never wanted to use zero. Because it can often occur as an error when not initialized (yet). Here, we use 0 as an explicit error, and link that to system initialization. I guess this could be changed if people want it. - sometimes I see If the value of this attribute is true other times I see If the value of this attribute is TRUE I guess it is better to be consistent and choose between the lowercase and uppercase. OK - I see (for example) this enumerated list multiple times: 0: undefined 1: String 2: GUID 3: UUID 4: URI 5: FQDN In SMI (SNMP) we used Textual Conventions for that. Is there such a thing or can/should we consider such a thing for GPIM too? We are trying to make the UML as generic as possible. UML enums complicate the model, and require relationships that could be misleading to data model developers that are not well-versed in UML. In the data model, we will use proper enumerations. - I see: 5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]" This is an optional array of string attributes that identifies the Mmmm in the prigrammin languages that I know (not too many I must confess, but still multiple), arrays are indexed from [0..n-1]. SO I wonder if this could lead to mis-understandings and/or programming errors. later on you use [0..n], so maybe this is just a typo. Both are UML-ese for defining a collection; it is not referring to indexing an array - section 5.7.2.1 Pls expand acronums OCL, QVT, SAT that are all use here for the 1st time in the document I believe. Maybe a reference to each will also be helpful. Good idea, thanks! - page 91 pls expand acronyms DNF and CNF (used for the first time here I believe) They were defined in 3.1, but agreed, and FIXED regards, John On Fri, Mar 11, 2016 at 11:10 AM, Bert Wijnen (IETF) wrote: > Finally went through the whole document. Pffff many many pages. > And sect 4.5 with subsections just states: > > This section will be completed in the next revision of this > document. > > Oh well > > I am not ready to say yes or no for "WG adoption". The document feels very > complex > to me. I need to re-read it at least one or two more times in order to get > it all. > > But I do have some comments/remarks/questions of the bat: > some of this is nits, but since I was composing a list of comments anyways > I figured I might as well add them. > - in the document you speak of cardinality and multiplicity. > are they used as synonyms of each other, of does one have a different > meaning than the other? > - on page 12 and 13 you talk about IM and DM and refer to RFC3198. > I would think that a reference to RFC3444 would also make sense. > As an informative reference. It explains a lot about the difference > between the 2. > Actually, I wonder if referencing 3198 is wise. It also contains a lot > of > stuff that never really took off in IETF or the industry. For exmplae > it talks about SPPI, PIB and COPS-PR, which we (IETF) are in the process > of declaring it HISTORIC. So why would we overload younger people > with all that now more or less irrelevant material? > - page 14: > > In this context, "manage" means that at least create, read, > query, update, and delete functions are supported. > > Is there a difference between "read" an "query" > is CRUD not enough? > - page 16 > > This principle is one of the key characteristics > that is NOT followed in [4], [6], [RFC3060], and [RFC3460]. > > That may very well be true, but why is this relevant? And why would that > make RFC3060 and 3460 NORMATIVE references? > > I see some more references to these 2 documents, They all seem to > indicate > that something was wrong in those fcs or that we do things different. > I do not see why that has to be NORMATIVE > > - section: 3.3.5. Association Class > AM I missing D in the picture? Or am I just not understanding this at > all? > > - please expand acronym RM-ODP's om page 23 > > - when I see figure 2, then I wonder why we do not split of EPRIM in to a > separate > document? > > - please expand LSIM on page 27 > > - It seems you want to make absolutely sure that we: > Please see Appendix A for a comparison to previous work. > it occurs manty times. oh well > > - I do not find this text (on page30): > > It is often necessary to construct groups of policies. The GPIM > follows [2] and [5], and uses the composite pattern [11] to > implement this functionality > > easy to read. One has to go to the reference section to figure out > what (big) documents is refered to. Then, when I see DEN and SID. I > start to worry. > IIRC I once called SID the "spaghetti bowl of spaghetti bowls". COMPLEX > and just > the UNION of everything else as opposed to the INTERSECTION off all > other specs. > But that maybe a personal issue that no one else shares? > > - In figure 5 > Why is the left subclass tagged as type C (Concrete) ? It does not have > to be, does it? > > - When I read on page 38: > > A SUPAPolicySource MAY be mapped to a role (e.g., using the > role-object pattern [11]); > > Then I get the feeling that [11] would be normative, no? I guess I need > to understand > [11] in order to use that role-object pattern. > > - page 50 towards bottom: > > Similarly, all SUPA classes are attributes are both uniquely > > for the first occurence of "are" I suspect s/are/and/ ?? > > - I see at various places text aka > > SUPAPolicyStructure was abstracted > from DEN-ng [2], and a version of this class is in the process of > being added to [5] > > Is that something we need to exactly know for each object? Would it not > be better to > state somewhere in an aknowledgement section or in the introduction > that we have build > on and used some of DEN-ng? > > - I see double negation aka: > > which is an enumerated non-negative integer > Would it not be better and clearer to just say > whic is a nonzero positive integer? > mmm I see that zero is also a value that can occur. > In SNMP we never wanted to use zero. Because it can often > occur as an error when not initialized (yet). > > - sometimes I see > > If the value of this attribute is true > > other times I see > > If the value of this attribute is TRUE > > I guess it is better to be consistent and choose between the lowercase > and uppercase. > > - I see (for example) this enumerated list multiple times: > > 0: undefined > 1: String > 2: GUID > 3: UUID > 4: URI > 5: FQDN > > In SMI (SNMP) we used Textual Conventions for that. Is there such a > thing or > can/should we consider such a thing for GPIM too? > > - I see: > > 5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]" > > This is an optional array of string attributes that identifies the > > Mmmm in the prigrammin languages that I know (not too many I must > confess, > but still multiple), arrays are indexed from [0..n-1]. SO I wonder if > this could > lead to mis-understandings and/or programming errors. > > later on you use [0..n], so maybe this is just a typo. > > - section 5.7.2.1 > Pls expand acronums OCL, QVT, SAT that are all use here for the 1st time > in the document I believe. Maybe a reference to each will also be > helpful. > > - page 91 > pls expand acronyms DNF and CNF (used for the first time here I believe) > > Bert > > On 12/02/16 22:26, Joel Halpern wrote: > >> Below is the announcement of the revision of the Generic Information >> Model for the SUPA work. John has done the heavy lifting on this, with >> help from Jason and myself. >> >> Over the last several months, we have made a lot of changes to this model. >> >> We really need working group review and comment on this. >> >> We will be working with the team that produced the earlier YANG models to >> drive a new YANG model that reflects this information model. So if we have >> made mistakes here, we need to know ASAP. >> >> In the absence of significant concerns, once we have gotten a YANG model >> derived, we will also ask for WG adoption of this document. >> >> So please, read it and comment. >> >> Yours, >> Joel >> >> >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt >> Date: Fri, 12 Feb 2016 11:09:50 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Generic Policy Information Model for Simplified >> Use of Policy Abstractions (SUPA) >> Authors : John Strassner >> Joel Halpern >> Jason Coleman >> Filename : >> draft-strassner-supa-generic-policy-info-model-04.txt >> Pages : 115 >> Date : 2016-02-12 >> >> Abstract: >> This document defines an information model for representing >> policies using a common extensible framework that is independent >> of language, protocol, repository. It is also independent of the >> level of abstraction of the content and meaning of a policy. >> >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-strassner-supa-generic-policy-info-model/ >> >> There's also a htmlized version available at: >> >> https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-04 >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=draft-strassner-supa-generic-policy-info-model-04 >> >> >> 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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > -- regards, John --001a113f1fe0e97bdf052e0d04ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bert,

comments below usin= g <jcs>..</jcs>


...

=C2=A0- in the document you speak of cardinality and multiplicit= y.
=C2=A0 =C2=A0are they used as synonyms of each other, of does one ha= ve a different
=C2=A0 =C2=A0meaning than the other?
<jcs&g= t;
Multiplicity refers to the relationship (i.e., association, ag= gregation, or
composition) as a whole. It consists of two cardina= lities, one for each side
of the relationship. We will update the= terminology to clarify this.
</jcs>


=C2=A0- on page 12 and 13 you talk about IM and DM and refer to RFC3= 198.
=C2=A0 =C2=A0I would think that a reference to RFC3444 would also = make sense.
=C2=A0 =C2=A0As an informative reference. It explains a lot= about the difference
=C2=A0 =C2=A0between the 2.
<jcs>=
I used RFC3198 because RFC3444 does not provide a definition; it= provides
a discussion. In addition, it contains some errors (e.g= ., it says that UML is a
"formal language", which is in= correct.

However, your suggestion is a good one - = we will work in a reference of
RFC3444 somewhere...
</jcs>


=C2=A0=C2=A0=C2=A0=C2=A0Actually= , I wonder if referencing 3198 is wise. It also contains a lot of
=C2= =A0 =C2=A0stuff that never really took off in IETF or the industry. For exm= plae
=C2=A0 =C2=A0it talks about SPPI, PIB and COPS-PR, which we (IETF)= are in the process
=C2=A0 =C2=A0of declaring it HISTORIC. So why would= we overload younger people
=C2=A0 =C2=A0with all that now more or less= irrelevant material?
<jcs>
See above
</jcs>


=C2=A0- page 14:

=C2= =A0 =C2=A0 In this context, "manage" means that at least create, = read,
=C2=A0 =C2=A0 query, update, and delete functions are supported.<= br>
=C2=A0 =C2=A0Is there a difference between "read" an &quo= t;query"
=C2=A0 =C2=A0is CRUD not enough?
<jcs>
"Read" is, at least to me, a simple command to provide a = result. In contrast,
"Query" is a more complex operatio= n that may involve pre- and/or post-
processing of the results of= the operation.

Note that many people think of SQL= as a query language; in that case, the
definition of query expan= ds to include data definition, data control, and data
manipulatio= n languages.

Would you like the above text include= d?
</jcs>


=C2=A0- page 16
<= br> =C2=A0 =C2=A0This principle is one of the key characteristics
=C2= =A0 =C2=A0that is NOT followed in [4], [6], [RFC3060], and [RFC3460].
=C2=A0 =C2=A0That may very well be true, but why is this relevant? And w= hy would that
=C2=A0 =C2=A0make RFC3060 and 3460 NORMATIVE references?<= br>
=C2=A0 =C2=A0I see some more references to these 2 documents, They = all seem to indicate
=C2=A0 =C2=A0that something was wrong in those fcs= or that we do things different.
=C2=A0 =C2=A0I do not see why that has= to be NORMATIVE
<jcs>
This is relevant because i= t is a key design principle for scalable and
extensible informati= on models.

I'm happy to make PCIM and PCIMe IN= FORMATIVE, good catch.
</jcs>


=C2=A0- sec= tion: 3.3.5. Association Class
=C2=A0 =C2=A0AM I missing D in the pictu= re? Or am I just not understanding this at all?
<jcs>
S= orry, D is the association. Fixed.
</jcs>

=C2=A0- please expand acronym RM-ODP's om page 23
<jcs><= /div>
Done.
</jcs>


=C2=A0- when I= see figure 2, then I wonder why we do not split of EPRIM in to a separate<= br> =C2=A0 =C2=A0document?
<jcs>
The thinking was:
=C2=A0=C2=A0 1) there would be a lot of repeated text, and
=C2=A0=C2=A0 2) it would be difficult for readers - they would have to = have two documents
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 open at t= he same time to understand the work
</jcs>

=C2=A0- please expand LSIM on page 27
<jcs>
LSI= M was defined on page 11, but sure, no problem
</jcs>
=C2=A0- It seems you want to make absolutely sure that we:
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Please see Appendix A for a comparison to previous = work.
=C2=A0 =C2=A0it occurs manty times. oh well
<jc= s>
It occurs 7 times. This happened as other WGs were starting=
to use PCIM, and were confused what the difference was
between SUPA and PCIM
</jcs>

=C2=A0- I do not find = this text (on page30):

=C2=A0 =C2=A0It is often necessary to constr= uct groups of policies. The GPIM
=C2=A0 =C2=A0follows [2] and [5], and = uses the composite pattern [11] to
=C2=A0 =C2=A0implement this function= ality

=C2=A0 =C2=A0easy to read. One has to go to the reference sec= tion to figure out
=C2=A0 =C2=A0what (big) documents is refered to. The= n, when I see DEN and SID. I start to worry.
=C2=A0 =C2=A0IIRC I once c= alled SID the "spaghetti bowl of spaghetti bowls". COMPLEX and ju= st
=C2=A0 =C2=A0the UNION of everything else as opposed to the INTERSEC= TION off all other specs.
=C2=A0 =C2=A0But that maybe a personal issue = that no one else shares?
<jcs>
The point was to ta= lk about the composite pattern ([11]) and note that it is used
in= many other works; two of those are [2] and [5].
</jcs>
=

=C2=A0- In figure 5
=C2=A0 =C2=A0Why is the left subclass tagge= d as type C (Concrete) ? It does not have to be, does it?
<jcs&= gt;
Oops, sorry about that, FIXED.
</jcs>

=
=C2=A0- When I read on page 38:

=C2=A0 =C2=A0A SUPAPolicySource= MAY be mapped to a role (e.g., using the
=C2=A0 =C2=A0role-object patt= ern [11]);

=C2=A0 =C2=A0Then I get the feeling that [11] would be n= ormative, no? I guess I need to understand
=C2=A0 =C2=A0[11] in order t= o use that role-object pattern.
<jcs>
[11] defines= the original role-object pattern; there are many variants (but all are
similar). I'll fix the wording.
</jcs>

=C2=A0- page 50 towards bottom:

=C2=A0 =C2=A0Similarly, all SUPA = classes are attributes are both uniquely

=C2=A0 =C2=A0for the first= occurence of "are" I suspect s/are/and/ ??
&= lt;jcs>
Oops, good catch. FIXED.
</jcs>
<= div>

=C2=A0- I see at various places text aka

=C2=A0 =C2=A0 = SUPAPolicyStructure was abstracted
=C2=A0 =C2=A0 from DEN-ng [2], and a= version of this class is in the process of
=C2=A0 =C2=A0 being added t= o [5]

=C2=A0 =C2=A0Is that something we need to exactly know for ea= ch object? Would it not be better to
=C2=A0 =C2=A0state somewhere in an= aknowledgement section or in the introduction that we have build
=C2= =A0 =C2=A0on and used some of DEN-ng?
<jcs>
I didn= 't want to give the impression that everything was DEN-ng, but ok
=
</jcs>


=C2=A0- I see double negation aka:

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which is an enumerated non-negative integer<= br> =C2=A0 =C2=A0Would it not be better and clearer to just say
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 whic is=C2=A0 a nonzero positive integer?
= =C2=A0 =C2=A0mmm I see that zero is also a value that can occur.
=C2=A0= =C2=A0In SNMP we never wanted to use zero. Because it can often
=C2=A0= =C2=A0occur as an error when not initialized (yet).
<jcs>
Here, we use 0 as an explicit error, and link that to system
=
initialization. I guess this could be changed if people want it.
=
</jcs>


=C2=A0- sometimes I see

=C2=A0 =C2=A0 = If the value of this attribute is true

=C2=A0 =C2=A0other times I s= ee

=C2=A0 =C2=A0 If the value of this attribute is TRUE

=C2= =A0 I guess it is better to be consistent and choose between the lowercase = and uppercase.
<jcs>
OK
</jcs>
=

=C2=A0- I see (for example) this enumerated list multiple times:
=C2=A0 =C2=A0 =C2=A0 0:=C2=A0 undefined
=C2=A0 =C2=A0 =C2=A0 1:= =C2=A0 String
=C2=A0 =C2=A0 =C2=A0 2:=C2=A0 GUID
=C2=A0 =C2=A0 =C2= =A0 3:=C2=A0 UUID
=C2=A0 =C2=A0 =C2=A0 4:=C2=A0 URI
=C2=A0 =C2=A0 = =C2=A0 5:=C2=A0 FQDN

=C2=A0 =C2=A0 In SMI (SNMP) we used Textual Co= nventions for that. Is there such a thing or
=C2=A0 =C2=A0 can/should w= e consider such a thing for GPIM too?
<jcs>
We are= trying to make the UML as generic as possible. UML enums complicate
<= div>the model, and require relationships that could be misleading to data m= odel
developers that are not well-versed in UML. In the data mode= l, we will use
proper enumerations.
</jcs>

=C2=A0- I see:

5.3.2.6.2. The Attribute "supaPolExecFailT= akeActionName[1..n]"

=C2=A0 =C2=A0 This is an optional array o= f string attributes that identifies the

=C2=A0 =C2=A0Mmmm in the pr= igrammin languages that I know (not too many I must confess,
=C2=A0 =C2= =A0but still multiple), arrays are indexed from [0..n-1]. SO I wonder if th= is could
=C2=A0 =C2=A0lead to mis-understandings and/or programming err= ors.

=C2=A0=C2=A0=C2=A0=C2=A0later on you use [0..n], so maybe= this is just a typo.
<jcs>
Both are UML-ese for definin= g a collection; it is not referring to indexing an array
</jcs= >


=C2=A0- section 5.7.2.1
=C2=A0 =C2=A0Pls expand acronum= s OCL, QVT, SAT that are all use here for the 1st time
=C2=A0 =C2=A0in = the document I believe. Maybe a reference to each will also be helpful.<jcs>
Good idea, thanks!
</jcs>

=C2=A0- page 91
=C2=A0 =C2=A0pls expand acronyms DNF a= nd CNF (used for the first time here I believe)
<jcs><= /div>
They were defined in 3.1, but agreed, and FIXED
</jc= s>



=C2=A0regards,
John
=

On Fri, Mar 11, 2016 at 11= :10 AM, Bert Wijnen (IETF) <bwietf@bwijnen.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Finally went through the whole document. Pfff= f many many pages.
And sect 4.5 with subsections just=C2=A0 states:

=C2=A0 =C2=A0This section will be completed in the next revision of this =C2=A0 =C2=A0document.

Oh well

I am not ready to say yes or no for "WG adoption". The document f= eels very complex
to me. I need to re-read it at least one or two more times in order to get = it all.

But I do have some comments/remarks/questions of the bat:
some of this is nits, but since I was composing a list of comments anyways<= br> I figured I might as well add them.
- in the document you speak of cardinality and multiplicity.
=C2=A0 =C2=A0are they used as synonyms of each other, of does one have a di= fferent
=C2=A0 =C2=A0meaning than the other?
- on page 12 and 13 you talk about IM and DM and refer to RFC3198.
=C2=A0 =C2=A0I would think that a reference to RFC3444 would also make sens= e.
=C2=A0 =C2=A0As an informative reference. It explains a lot about the diffe= rence
=C2=A0 =C2=A0between the 2.
=C2=A0 =C2=A0Actually, I wonder if referencing 3198 is wise. It also contai= ns a lot of
=C2=A0 =C2=A0stuff that never really took off in IETF or the industry. For = exmplae
=C2=A0 =C2=A0it talks about SPPI, PIB and COPS-PR, which we (IETF) are in t= he process
=C2=A0 =C2=A0of declaring it HISTORIC. So why would we overload younger peo= ple
=C2=A0 =C2=A0with all that now more or less irrelevant material?
- page 14:

=C2=A0 =C2=A0 In this context, "manage" means that at least creat= e, read,
=C2=A0 =C2=A0 query, update, and delete functions are supported.

=C2=A0 =C2=A0Is there a difference between "read" an "query&= quot;
=C2=A0 =C2=A0is CRUD not enough?
- page 16

=C2=A0 =C2=A0This principle is one of the key characteristics
=C2=A0 =C2=A0that is NOT followed in [4], [6], [RFC3060], and [RFC3460].
=C2=A0 =C2=A0That may very well be true, but why is this relevant? And why = would that
=C2=A0 =C2=A0make RFC3060 and 3460 NORMATIVE references?

=C2=A0 =C2=A0I see some more references to these 2 documents, They all seem= to indicate
=C2=A0 =C2=A0that something was wrong in those fcs or that we do things dif= ferent.
=C2=A0 =C2=A0I do not see why that has to be NORMATIVE

- section: 3.3.5. Association Class
=C2=A0 =C2=A0AM I missing D in the picture? Or am I just not understanding = this at all?

- please expand acronym RM-ODP's om page 23

- when I see figure 2, then I wonder why we do not split of EPRIM in to a s= eparate
=C2=A0 =C2=A0document?

- please expand LSIM on page 27

- It seems you want to make absolutely sure that we:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please see Appendix A for a comparison to= previous work.
=C2=A0 =C2=A0it occurs manty times. oh well

- I do not find this text (on page30):

=C2=A0 =C2=A0It is often necessary to construct groups of policies. The GPI= M
=C2=A0 =C2=A0follows [2] and [5], and uses the composite pattern [11] to =C2=A0 =C2=A0implement this functionality

=C2=A0 =C2=A0easy to read. One has to go to the reference section to figure= out
=C2=A0 =C2=A0what (big) documents is refered to. Then, when I see DEN and S= ID. I start to worry.
=C2=A0 =C2=A0IIRC I once called SID the "spaghetti bowl of spaghetti b= owls". COMPLEX and just
=C2=A0 =C2=A0the UNION of everything else as opposed to the INTERSECTION of= f all other specs.
=C2=A0 =C2=A0But that maybe a personal issue that no one else shares?

- In figure 5
=C2=A0 =C2=A0Why is the left subclass tagged as type C (Concrete) ? It does= not have to be, does it?

- When I read on page 38:

=C2=A0 =C2=A0A SUPAPolicySource MAY be mapped to a role (e.g., using the =C2=A0 =C2=A0role-object pattern [11]);

=C2=A0 =C2=A0Then I get the feeling that [11] would be normative, no? I gue= ss I need to understand
=C2=A0 =C2=A0[11] in order to use that role-object pattern.

- page 50 towards bottom:

=C2=A0 =C2=A0Similarly, all SUPA classes are attributes are both uniquely
=C2=A0 =C2=A0for the first occurence of "are" I suspect s/are/and= / ??

- I see at various places text aka

=C2=A0 =C2=A0 SUPAPolicyStructure was abstracted
=C2=A0 =C2=A0 from DEN-ng [2], and a version of this class is in the proces= s of
=C2=A0 =C2=A0 being added to [5]

=C2=A0 =C2=A0Is that something we need to exactly know for each object? Wou= ld it not be better to
=C2=A0 =C2=A0state somewhere in an aknowledgement section or in the introdu= ction that we have build
=C2=A0 =C2=A0on and used some of DEN-ng?

- I see double negation aka:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which is an enumerated non-negative integ= er
=C2=A0 =C2=A0Would it not be better and clearer to just say
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 whic is=C2=A0 a nonzero positive integer= ?
=C2=A0 =C2=A0mmm I see that zero is also a value that can occur.
=C2=A0 =C2=A0In SNMP we never wanted to use zero. Because it can often
=C2=A0 =C2=A0occur as an error when not initialized (yet).

- sometimes I see

=C2=A0 =C2=A0 If the value of this attribute is true

=C2=A0 =C2=A0other times I see

=C2=A0 =C2=A0 If the value of this attribute is TRUE

=C2=A0 I guess it is better to be consistent and choose between the lowerca= se and uppercase.

- I see (for example) this enumerated list multiple times:

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

=C2=A0 =C2=A0 In SMI (SNMP) we used Textual Conventions for that. Is there = such a thing or
=C2=A0 =C2=A0 can/should we consider such a thing for GPIM too?

- I see:

5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]"
=C2=A0 =C2=A0 This is an optional array of string attributes that identifie= s the

=C2=A0 =C2=A0Mmmm in the prigrammin languages that I know (not too many I m= ust confess,
=C2=A0 =C2=A0but still multiple), arrays are indexed from [0..n-1]. SO I wo= nder if this could
=C2=A0 =C2=A0lead to mis-understandings and/or programming errors.

=C2=A0 =C2=A0later on you use [0..n], so maybe this is just a typo.

- section 5.7.2.1
=C2=A0 =C2=A0Pls expand acronums OCL, QVT, SAT that are all use here for th= e 1st time
=C2=A0 =C2=A0in the document I believe. Maybe a reference to each will also= be helpful.

- page 91
=C2=A0 =C2=A0pls expand acronyms DNF and CNF (used for the first time here = I believe)

Bert

On 12/02/16 22:26, Joel Halpern wrote:
Below is the announcement of the revision of the Generic Information Model = for the SUPA work.=C2=A0 John has done the heavy lifting on this, with help= from Jason and myself.

Over the last several months, we have made a lot of changes to this model.<= br>
We really need working group review and comment on this.

We will be working with the team that produced the earlier YANG models to d= rive a new YANG model that reflects this information model.=C2=A0 So if we = have made mistakes here, we need to know ASAP.

In the absence of significant concerns, once we have gotten a YANG model de= rived, we will also ask for WG adoption of this document.

So please, read it and comment.

Yours,
Joel


-------- Forwarded Message --------
Subject: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt<= br> Date: Fri, 12 Feb 2016 11:09:50 -0800
From: interne= t-drafts@ietf.org
Reply-To: int= ernet-drafts@ietf.org
To: i-d-announce= @ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Generic Policy Information Model for Simplified Use of Policy Abstractions= (SUPA)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: John= Strassner
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Joel Halpern
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jason Coleman
=C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-strassner-supa-ge= neric-policy-info-model-04.txt
=C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 115
=C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2016-02-12
Abstract:
=C2=A0 =C2=A0This document defines an information model for representing =C2=A0 =C2=A0policies using a common extensible framework that is independe= nt
=C2=A0 =C2=A0of language, protocol, repository. It is also independent of t= he
=C2=A0 =C2=A0level of abstraction of the content and meaning of a policy.


The IETF datatracker status page for this draft is:
https://datatracker.= ietf.org/doc/draft-strassner-supa-generic-policy-info-model/

There's also a htmlized version available at:
https://tools.ietf.org/= html/draft-strassner-supa-generic-policy-info-model-04

A diff from the previous version is available at:
https://www.iet= f.org/rfcdiff?url2=3Ddraft-strassner-supa-generic-policy-info-model-04<= br>

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa


_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa



--
regards,
John
--001a113f1fe0e97bdf052e0d04ea-- From nobody Tue Mar 15 00:10:57 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9142F12D8F0 for ; Tue, 15 Mar 2016 00:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 fZmeoszOVl_y for ; Tue, 15 Mar 2016 00:10:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FDD312D8AE for ; Tue, 15 Mar 2016 00:10:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4C366105A; Tue, 15 Mar 2016 08:10:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0v16T3ZqEEUF; Tue, 15 Mar 2016 08:10:45 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 15 Mar 2016 08:10:51 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F3D82003D; Tue, 15 Mar 2016 08:10:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NPwysKT-vh31; Tue, 15 Mar 2016 08:10:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32BF62003A; Tue, 15 Mar 2016 08:10:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0A5023A31099; Tue, 15 Mar 2016 08:10:49 +0100 (CET) Date: Tue, 15 Mar 2016 08:10:49 +0100 From: Juergen Schoenwaelder To: John Strassner Message-ID: <20160315071049.GA18078@elstar.local> Mail-Followup-To: John Strassner , "Bert Wijnen (IETF)" , Jason Coleman , Joel Halpern , "supa@ietf.org" References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Jason Coleman , Joel Halpern , "supa@ietf.org" , "Bert Wijnen \(IETF\)" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 07:10:56 -0000 On Mon, Mar 14, 2016 at 07:18:55PM -0700, John Strassner wrote: > > I used RFC3198 because RFC3444 does not provide a definition; it provides > a discussion. In addition, it contains some errors (e.g., it says that UML > is a > "formal language", which is incorrect. > > However, your suggestion is a good one - we will work in a reference of > RFC3444 somewhere... > RFC 3444 says: [...] One of the possibilities to formally specify IMs is to use class diagrams of the Unified Modeling Language (UML). Note that RFC 3444 makes a distinction between informally defined IMs (e.g, using natural language) and formally defined IMs (using a notational system, i.e, a formalism). IMs can be defined in an informal way, using natural languages such as English. Alternatively, IMs can be defined using a formal language or a semi- formal structured language. Hence, I am not convinced that RFC 3444 contains an _error_. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 15 02:00:04 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7DC12D940 for ; Tue, 15 Mar 2016 02:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 19B7i8GZh-XO for ; Tue, 15 Mar 2016 02:00:00 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7EB12D90B for ; Tue, 15 Mar 2016 01:59:59 -0700 (PDT) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id W8zv1s00t3vXPcr018zwex; Tue, 15 Mar 2016 09:59:58 +0100 To: John Strassner , Jason Coleman References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> From: "Bert Wijnen (IETF)" Message-ID: <56E7CF0B.6010602@bwijnen.net> Date: Tue, 15 Mar 2016 09:59:55 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 09:00:02 -0000 Thanks John, W.r.t. the below (RFC3198 reference): Since you (as far as I could tell) only use a couple fo definitions, maybe it is better (and faster for the reader) if you just repeat them in the IM document. Bert On 15/03/16 03:18, John Strassner wrote: > > - on page 12 and 13 you talk about IM and DM and refer to RFC3198. > I would think that a reference to RFC3444 would also make sense. > As an informative reference. It explains a lot about the difference > between the 2. > > I used RFC3198 because RFC3444 does not provide a definition; it provides > a discussion. In addition, it contains some errors (e.g., it says that UML is a > "formal language", which is incorrect. > > However, your suggestion is a good one - we will work in a reference of > RFC3444 somewhere... > > > > Actually, I wonder if referencing 3198 is wise. It also contains a lot of > stuff that never really took off in IETF or the industry. For exmplae > it talks about SPPI, PIB and COPS-PR, which we (IETF) are in the process > of declaring it HISTORIC. So why would we overload younger people > with all that now more or less irrelevant material? > > See above > > From nobody Tue Mar 15 02:02:38 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5652712D90B for ; Tue, 15 Mar 2016 02:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4hywg0TKcf7p for ; Tue, 15 Mar 2016 02:02:33 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1D7512D968 for ; Tue, 15 Mar 2016 02:02:31 -0700 (PDT) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id W92U1s01e3vXPcr0192VPY; Tue, 15 Mar 2016 10:02:29 +0100 To: John Strassner , Jason Coleman References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> From: "Bert Wijnen (IETF)" Message-ID: <56E7CFA4.1030909@bwijnen.net> Date: Tue, 15 Mar 2016 10:02:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 09:02:35 -0000 On 15/03/16 03:18, John Strassner wrote: > > - page 14: > > In this context, "manage" means that at least create, read, > query, update, and delete functions are supported. > > Is there a difference between "read" an "query" > is CRUD not enough? > > "Read" is, at least to me, a simple command to provide a result. In contrast, > "Query" is a more complex operation that may involve pre- and/or post- > processing of the results of the operation. > > Note that many people think of SQL as a query language; in that case, the > definition of query expands to include data definition, data control, and data > manipulation languages. > > Would you like the above text included? > Ah. Thanks. I guess it would be good to indeed explain the difference. Would you see access control to be different for a query as opposed to a read? That is where my question came from. Bert From nobody Tue Mar 15 02:05:39 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F21612D90B for ; Tue, 15 Mar 2016 02:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WfdshBHE8B5E for ; Tue, 15 Mar 2016 02:05:36 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79CF912D642 for ; Tue, 15 Mar 2016 02:05:35 -0700 (PDT) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id W95W1s00b3vXPcr0195XJD; Tue, 15 Mar 2016 10:05:31 +0100 To: John Strassner , Jason Coleman References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> From: "Bert Wijnen (IETF)" Message-ID: <56E7D05A.8000005@bwijnen.net> Date: Tue, 15 Mar 2016 10:05:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 09:05:37 -0000 On 15/03/16 03:18, John Strassner wrote: > > - page 16 > > This principle is one of the key characteristics > that is NOT followed in [4], [6], [RFC3060], and [RFC3460]. > > That may very well be true, but why is this relevant? And why would that > make RFC3060 and 3460 NORMATIVE references? > > I see some more references to these 2 documents, They all seem to indicate > that something was wrong in those fcs or that we do things different. > I do not see why that has to be NORMATIVE > > This is relevant because it is a key design principle for scalable and > extensible information models. > > I'm happy to make PCIM and PCIMe INFORMATIVE, good catch. > I can see that it may be relevant. but that indeed does not mean it is normative. I think it can be (for some) extra background reading for better understanding as to why things are done here the way they are done. I think moving it to the informative section would be good. In the past (when I was still writing lots of code, unfortunately I am not doing much of that these days), I always looked at the normative referenes and figured that I better understand those documents completely before I would start implementing anything. Thank, Bert From nobody Tue Mar 15 02:09:20 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B73912D642 for ; Tue, 15 Mar 2016 02:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sPQPWotg1R21 for ; Tue, 15 Mar 2016 02:09:14 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3720B12D51B for ; Tue, 15 Mar 2016 02:09:14 -0700 (PDT) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id W99B1s01W3vXPcr0199CM3; Tue, 15 Mar 2016 10:09:12 +0100 To: John Strassner , Jason Coleman References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> From: "Bert Wijnen (IETF)" Message-ID: <56E7D137.8010205@bwijnen.net> Date: Tue, 15 Mar 2016 10:09:11 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 09:09:17 -0000 On 15/03/16 03:18, John Strassner wrote: > - when I see figure 2, then I wonder why we do not split of EPRIM in to a separate > document? > > The thinking was: > 1) there would be a lot of repeated text, and > 2) it would be difficult for readers - they would have to have two documents > open at the same time to understand the work > Mmmmm.... now I am really getting worried. Are you saying i MUST understand EPRIM in order to understand GPIM ????? That would not be good. The other way around, YES. So if I want to expand GPIM with a IM for declarative, then (I hope) there should be no need to understand/read EPRIM. So I would not have to be bothered with it, no? I should be able to do a DPRIM document without reading or understanding EPRIM. Bert From nobody Tue Mar 15 02:12:47 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C737512D8ED for ; Tue, 15 Mar 2016 02:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JQ1a-8TeSgQg for ; Tue, 15 Mar 2016 02:12:44 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25F912D514 for ; Tue, 15 Mar 2016 02:12:43 -0700 (PDT) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id W9Cg1s00b3vXPcr019ChEM; Tue, 15 Mar 2016 10:12:41 +0100 To: John Strassner , Jason Coleman References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> From: "Bert Wijnen (IETF)" Message-ID: <56E7D208.6040206@bwijnen.net> Date: Tue, 15 Mar 2016 10:12:40 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 09:12:46 -0000 On 15/03/16 03:18, John Strassner wrote: > - please expand LSIM on page 27 > > LSIM was defined on page 11, but sure, no problem > Sorry. I had missed that one. In that case then there is no formal need to repeat. Bert From nobody Tue Mar 15 02:21:58 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9368312D87D for ; Tue, 15 Mar 2016 02:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 16GRgWSkt5kb for ; Tue, 15 Mar 2016 02:21:53 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031B812D62D for ; Tue, 15 Mar 2016 02:21:52 -0700 (PDT) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id W9Mk1s00f3vXPcr019Mlcx; Tue, 15 Mar 2016 10:21:45 +0100 To: John Strassner , Jason Coleman References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> From: "Bert Wijnen (IETF)" Message-ID: <56E7D428.5090903@bwijnen.net> Date: Tue, 15 Mar 2016 10:21:44 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 09:21:56 -0000 On 15/03/16 03:18, John Strassner wrote: > > - I see: > > 5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]" > > This is an optional array of string attributes that identifies the > > Mmmm in the prigrammin languages that I know (not too many I must confess, > but still multiple), arrays are indexed from [0..n-1]. SO I wonder if this could > lead to mis-understandings and/or programming errors. > > later on you use [0..n], so maybe this is just a typo. > > Both are UML-ese for defining a collection; it is not referring to indexing an array > Mmmm I I guess I demonstrated, my knowledge about UML is very limited. But when I see that notation, and the next sentence is: This is an optional array of string attributes that identifies the Then is it just me who thinks that [1..n] indicates the index into the array? Maybe se, then pls ignore. If there are others who were put on the wrong footing by that, then pls speak up, because then maybe we should make it clearer. But still, in some cases you use [1..n] and in other cases [0..n] So is there a difference between those 2, and if so, what is it? Pls document (unless this is all 100% clear to UML folk, then maybe I should just study UML first; I hope not though) Bert From nobody Tue Mar 15 08:07:13 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3914112D52E for ; Tue, 15 Mar 2016 04:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 RYYtaTYtwFgc for ; Tue, 15 Mar 2016 04:11:16 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C30D12D52B for ; Tue, 15 Mar 2016 04:11:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 1BAFCD5A69F; Tue, 15 Mar 2016 04:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1458040276; bh=0n7O9RpF0CZw4y3T8v+NsKE97XkM7XggKWkFMdD2jC0=; h=Date:Subject:From:To:Cc:From; b=JzxzmYB+xk6fCTc3TB8Rok1lNf2oH9+aZpmP6s30+K2OFDWNYkZmGfDaoKgIhq9oA Q0vNdwrThUlGkKhEdRK6Af08kAuGgEDvOORIYCapf/UR8Wte7iKngmpxiBiC7bEWIZ klZ2FL8+i6iQJBcr7mTby/Q28NoaciI3XxeH3sCw= X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [10.34.82.48] (mobile-166-171-248-087.mycingular.net [166.171.248.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 69C1FD40CB8; Tue, 15 Mar 2016 04:11:14 -0700 (PDT) Date: Tue, 15 Mar 2016 12:11:05 +0100 Message-ID: <4bicl84weg6fmk2ia4pyhief.1458040265984@email.android.com> Importance: normal From: "jmh.direct" To: "Bert Wijnen (IETF)" , John Strassner , Jason Coleman MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1211815455016860" Archived-At: X-Mailman-Approved-At: Tue, 15 Mar 2016 08:07:12 -0700 Cc: Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 11:11:18 -0000 ----_com.samsung.android.email_1211815455016860 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 V2l0aCByZWdhcmQgdG8gc3BsaXR0aW5nIMKgKG9yIG5vdCkgRVBSSU0gZnJvbSBHUElNLCB0aGVy ZSBpcyBhIHRlbnNpb24uIMKgT24gb25lIGhhbmQsIHlvdSBkb24ndCBuZWVkIHRvIHVuZGVyc3Rh bmQgRVBSSU0gdG8gdW5kZXJzdGFuZCBHUElNLiDCoEJ1dCBwZW9wbGUgc2VlbSB0byBmaW5kIHRo ZSBkZXRhaWxzIHVzZWZ1bCBmb3IgdW5kZXJzdGFuZGluZyB3aHkgdGhlIEdQSU0gaGFzIHRoZSBz aG93biBzdHJ1Y3R1cmUuIMKgU29tZSBmb2xrcyBhcmUgZXZlbiBzYXlpbmcgdGhleSBuZWVkIG1v cmUgZGV0YWlscyB0byB1bmRlcnN0YW5kIGl0LlNvIHdoaWxlIHdlIGNvdWxkIHNwbGl0IHRoZSB0 d28sIEkgdGhpbmsgcGVvcGxlIHdvdWxkIGZpbmQgaXQgaGFyZGVyIHRvIHVuZGVyc3RhbmQuCllv dXJzLEpvZWwKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgU8KuIDYsIGFuIEFUJlQgNEcg TFRFIHNtYXJ0cGhvbmUtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTogIkJl cnQgV2lqbmVuIChJRVRGKSIgPGJ3aWV0ZkBid2lqbmVuLm5ldD4gRGF0ZTogMy8xNS8yMDE2ICAx MDowOSBBTSAgKEdNVCswMTowMCkgVG86IEpvaG4gU3RyYXNzbmVyIDxzdHJhenBkakBnbWFpbC5j b20+LCBKYXNvbiBDb2xlbWFuIDxyb3V0ZXJqb2NrZXlAbWUuY29tPiBDYzogSm9lbCBIYWxwZXJu IDxqbWhAam9lbGhhbHBlcm4uY29tPiwgc3VwYUBpZXRmLm9yZyBTdWJqZWN0OiBSZTogW1N1cGFd IEZ3ZDogSS1EIEFjdGlvbjoKICBkcmFmdC1zdHJhc3NuZXItc3VwYS1nZW5lcmljLXBvbGljeS1p bmZvLW1vZGVsLTA0LnR4dCAKT24gMTUvMDMvMTYgMDM6MTgsIEpvaG4gU3RyYXNzbmVyIHdyb3Rl Ogo+wqAgLSB3aGVuIEkgc2VlIGZpZ3VyZSAyLCB0aGVuIEkgd29uZGVyIHdoeSB3ZSBkbyBub3Qg c3BsaXQgb2YgRVBSSU0gaW4gdG8gYSBzZXBhcmF0ZQo+wqDCoMKgIGRvY3VtZW50Pwo+IDxqY3M+ Cj4gVGhlIHRoaW5raW5nIHdhczoKPsKgwqDCoCAxKSB0aGVyZSB3b3VsZCBiZSBhIGxvdCBvZiBy ZXBlYXRlZCB0ZXh0LCBhbmQKPsKgwqDCoCAyKSBpdCB3b3VsZCBiZSBkaWZmaWN1bHQgZm9yIHJl YWRlcnMgLSB0aGV5IHdvdWxkIGhhdmUgdG8gaGF2ZSB0d28gZG9jdW1lbnRzCj7CoMKgwqDCoMKg wqDCoCBvcGVuIGF0IHRoZSBzYW1lIHRpbWUgdG8gdW5kZXJzdGFuZCB0aGUgd29yawo+IDwvamNz PgpNbW1tbS4uLi4gbm93IEkgYW0gcmVhbGx5IGdldHRpbmcgd29ycmllZC4KQXJlIHlvdSBzYXlp bmcgaSBNVVNUIHVuZGVyc3RhbmQgRVBSSU0gaW4gb3JkZXIgdG8KdW5kZXJzdGFuZCBHUElNID8/ Pz8/CgpUaGF0IHdvdWxkIG5vdCBiZSBnb29kLiBUaGUgb3RoZXIgd2F5IGFyb3VuZCwgWUVTLgoK U28gaWYgSSB3YW50IHRvIGV4cGFuZCBHUElNIHdpdGggYSBJTSBmb3IgZGVjbGFyYXRpdmUsCnRo ZW4gKEkgaG9wZSkgdGhlcmUgc2hvdWxkIGJlIG5vIG5lZWQgdG8gdW5kZXJzdGFuZC9yZWFkCkVQ UklNLiBTbyBJIHdvdWxkIG5vdCBoYXZlIHRvIGJlIGJvdGhlcmVkIHdpdGggaXQsIG5vPwpJIHNo b3VsZCBiZSBhYmxlIHRvIGRvIGEgRFBSSU0gZG9jdW1lbnQgd2l0aG91dApyZWFkaW5nIG9yIHVu ZGVyc3RhbmRpbmcgRVBSSU0uCgpCZXJ0Cg== ----_com.samsung.android.email_1211815455016860 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PldpdGggcmVnYXJkIHRvIHNw bGl0dGluZyAmbmJzcDsob3Igbm90KSBFUFJJTSBmcm9tIEdQSU0sIHRoZXJlIGlzIGEgdGVuc2lv bi4gJm5ic3A7T24gb25lIGhhbmQsIHlvdSBkb24ndCBuZWVkIHRvIHVuZGVyc3RhbmQgRVBSSU0g dG8gdW5kZXJzdGFuZCBHUElNLiAmbmJzcDtCdXQgcGVvcGxlIHNlZW0gdG8gZmluZCB0aGUgZGV0 YWlscyB1c2VmdWwgZm9yIHVuZGVyc3RhbmRpbmcgd2h5IHRoZSBHUElNIGhhcyB0aGUgc2hvd24g c3RydWN0dXJlLiAmbmJzcDtTb21lIGZvbGtzIGFyZSBldmVuIHNheWluZyB0aGV5IG5lZWQgbW9y ZSBkZXRhaWxzIHRvIHVuZGVyc3RhbmQgaXQuPC9kaXY+PGRpdj5TbyB3aGlsZSB3ZSBjb3VsZCBz cGxpdCB0aGUgdHdvLCBJIHRoaW5rIHBlb3BsZSB3b3VsZCBmaW5kIGl0IGhhcmRlciB0byB1bmRl cnN0YW5kLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+WW91cnMsPC9kaXY+PGRpdj5Kb2VsPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0i Y29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3 NTciPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQmYW1wO1QgNEcgTFRF IHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjoj MDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1l c3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206ICJCZXJ0IFdpam5lbiAoSUVURikiICZsdDti d2lldGZAYndpam5lbi5uZXQmZ3Q7IDwvZGl2PjxkaXY+RGF0ZTogMy8xNS8yMDE2ICAxMDowOSBB TSAgKEdNVCswMTowMCkgPC9kaXY+PGRpdj5UbzogSm9obiBTdHJhc3NuZXIgJmx0O3N0cmF6cGRq QGdtYWlsLmNvbSZndDssIEphc29uIENvbGVtYW4gJmx0O3JvdXRlcmpvY2tleUBtZS5jb20mZ3Q7 IDwvZGl2PjxkaXY+Q2M6IEpvZWwgSGFscGVybiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDss IHN1cGFAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogW1N1cGFdIEZ3ZDogSS1EIEFj dGlvbjoKICBkcmFmdC1zdHJhc3NuZXItc3VwYS1nZW5lcmljLXBvbGljeS1pbmZvLW1vZGVsLTA0 LnR4dCA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5PbiAxNS8wMy8xNiAwMzoxOCwgSm9obiBT dHJhc3NuZXIgd3JvdGU6PGJyPiZndDsmbmJzcDsgLSB3aGVuIEkgc2VlIGZpZ3VyZSAyLCB0aGVu IEkgd29uZGVyIHdoeSB3ZSBkbyBub3Qgc3BsaXQgb2YgRVBSSU0gaW4gdG8gYSBzZXBhcmF0ZTxi cj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRvY3VtZW50Pzxicj4mZ3Q7ICZsdDtqY3MmZ3Q7PGJy PiZndDsgVGhlIHRoaW5raW5nIHdhczo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAxKSB0aGVy ZSB3b3VsZCBiZSBhIGxvdCBvZiByZXBlYXRlZCB0ZXh0LCBhbmQ8YnI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyAyKSBpdCB3b3VsZCBiZSBkaWZmaWN1bHQgZm9yIHJlYWRlcnMgLSB0aGV5IHdvdWxk IGhhdmUgdG8gaGF2ZSB0d28gZG9jdW1lbnRzPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgb3BlbiBhdCB0aGUgc2FtZSB0aW1lIHRvIHVuZGVyc3RhbmQg dGhlIHdvcms8YnI+Jmd0OyAmbHQ7L2pjcyZndDs8YnI+TW1tbW0uLi4uIG5vdyBJIGFtIHJlYWxs eSBnZXR0aW5nIHdvcnJpZWQuPGJyPkFyZSB5b3Ugc2F5aW5nIGkgTVVTVCB1bmRlcnN0YW5kIEVQ UklNIGluIG9yZGVyIHRvPGJyPnVuZGVyc3RhbmQgR1BJTSA/Pz8/Pzxicj48YnI+VGhhdCB3b3Vs ZCBub3QgYmUgZ29vZC4gVGhlIG90aGVyIHdheSBhcm91bmQsIFlFUy48YnI+PGJyPlNvIGlmIEkg d2FudCB0byBleHBhbmQgR1BJTSB3aXRoIGEgSU0gZm9yIGRlY2xhcmF0aXZlLDxicj50aGVuIChJ IGhvcGUpIHRoZXJlIHNob3VsZCBiZSBubyBuZWVkIHRvIHVuZGVyc3RhbmQvcmVhZDxicj5FUFJJ TS4gU28gSSB3b3VsZCBub3QgaGF2ZSB0byBiZSBib3RoZXJlZCB3aXRoIGl0LCBubz88YnI+SSBz aG91bGQgYmUgYWJsZSB0byBkbyBhIERQUklNIGRvY3VtZW50IHdpdGhvdXQ8YnI+cmVhZGluZyBv ciB1bmRlcnN0YW5kaW5nIEVQUklNLjxicj48YnI+QmVydDxicj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_1211815455016860-- From nobody Tue Mar 15 08:07:15 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA1B12D991 for ; Tue, 15 Mar 2016 04:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 n2DMcKN31rM7 for ; Tue, 15 Mar 2016 04:37:09 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0CD12D98E for ; Tue, 15 Mar 2016 04:37:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9BFB2241023; Tue, 15 Mar 2016 04:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1458041829; bh=HTvz3YE+3FyvubRkRf83NRN5DgmYcNQ/OI2wWBZgVl0=; h=Date:Subject:From:To:Cc:From; b=k3d3B15GIeNIMCzvhAq90VZ6sl7OXPvP2Dh6IkdoJEj078dox/F9ggdnRUUyt0VnU kU6n6u2o6zjyXN3VmyHWAQodzvmYQDhLCCO8C6YVW+pUqAA3v1a2txiYv744ZWR5Cg KZmYScycJDM6MZkw0qkuyX/XuH+XRH0JNQBF664U= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.240.18.90] (mobile-166-171-249-045.mycingular.net [166.171.249.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 68AC524089D; Tue, 15 Mar 2016 04:37:08 -0700 (PDT) Date: Tue, 15 Mar 2016 12:37:03 +0100 Message-ID: Importance: normal From: "jmh.direct" To: "Bert Wijnen (IETF)" , John Strassner , Jason Coleman MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1219287161552910" Archived-At: X-Mailman-Approved-At: Tue, 15 Mar 2016 08:07:12 -0700 Cc: Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 11:37:13 -0000 ----_com.samsung.android.email_1219287161552910 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhvc2Ugc2hvdWxkIGJlIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMuIMKgU29ycnkuSm9lbAoKClNl bnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQmVCA0RyBMVEUgc21hcnRwaG9u ZS0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiAiQmVydCBXaWpuZW4gKElF VEYpIiA8YndpZXRmQGJ3aWpuZW4ubmV0PiBEYXRlOiAzLzE1LzIwMTYgIDEwOjA1IEFNICAoR01U KzAxOjAwKSBUbzogSm9obiBTdHJhc3NuZXIgPHN0cmF6cGRqQGdtYWlsLmNvbT4sIEphc29uIENv bGVtYW4gPHJvdXRlcmpvY2tleUBtZS5jb20+IENjOiBKb2VsIEhhbHBlcm4gPGptaEBqb2VsaGFs cGVybi5jb20+LCBzdXBhQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbU3VwYV0gRndkOiBJLUQgQWN0 aW9uOgogIGRyYWZ0LXN0cmFzc25lci1zdXBhLWdlbmVyaWMtcG9saWN5LWluZm8tbW9kZWwtMDQu dHh0IApPbiAxNS8wMy8xNiAwMzoxOCwgSm9obiBTdHJhc3NuZXIgd3JvdGU6Cj4KPsKgIC0gcGFn ZSAxNgo+Cj7CoMKgwqAgVGhpcyBwcmluY2lwbGUgaXMgb25lIG9mIHRoZSBrZXkgY2hhcmFjdGVy aXN0aWNzCj7CoMKgwqAgdGhhdCBpcyBOT1QgZm9sbG93ZWQgaW4gWzRdLCBbNl0sIFtSRkMzMDYw XSwgYW5kIFtSRkMzNDYwXS4KPgo+wqDCoMKgIFRoYXQgbWF5IHZlcnkgd2VsbCBiZSB0cnVlLCBi dXQgd2h5IGlzIHRoaXMgcmVsZXZhbnQ/IEFuZCB3aHkgd291bGQgdGhhdAo+wqDCoMKgIG1ha2Ug UkZDMzA2MCBhbmQgMzQ2MCBOT1JNQVRJVkUgcmVmZXJlbmNlcz8KPgo+wqDCoMKgIEkgc2VlIHNv bWUgbW9yZSByZWZlcmVuY2VzIHRvIHRoZXNlIDIgZG9jdW1lbnRzLCBUaGV5IGFsbCBzZWVtIHRv IGluZGljYXRlCj7CoMKgwqAgdGhhdCBzb21ldGhpbmcgd2FzIHdyb25nIGluIHRob3NlIGZjcyBv ciB0aGF0IHdlIGRvIHRoaW5ncyBkaWZmZXJlbnQuCj7CoMKgwqAgSSBkbyBub3Qgc2VlIHdoeSB0 aGF0IGhhcyB0byBiZSBOT1JNQVRJVkUKPiA8amNzPgo+IFRoaXMgaXMgcmVsZXZhbnQgYmVjYXVz ZSBpdCBpcyBhIGtleSBkZXNpZ24gcHJpbmNpcGxlIGZvciBzY2FsYWJsZSBhbmQKPiBleHRlbnNp YmxlIGluZm9ybWF0aW9uIG1vZGVscy4KPgo+IEknbSBoYXBweSB0byBtYWtlIFBDSU0gYW5kIFBD SU1lIElORk9STUFUSVZFLCBnb29kIGNhdGNoLgo+IDwvamNzPgpJIGNhbiBzZWUgdGhhdCBpdCBt YXkgYmUgcmVsZXZhbnQuIGJ1dCB0aGF0IGluZGVlZCBkb2VzIG5vdAptZWFuIGl0IGlzIG5vcm1h dGl2ZS4gSSB0aGluayBpdCBjYW4gYmUgKGZvciBzb21lKSBleHRyYQpiYWNrZ3JvdW5kIHJlYWRp bmcgZm9yIGJldHRlciB1bmRlcnN0YW5kaW5nIGFzIHRvIHdoeSB0aGluZ3MKYXJlIGRvbmUgaGVy ZSB0aGUgd2F5IHRoZXkgYXJlIGRvbmUuCgpJIHRoaW5rIG1vdmluZyBpdCB0byB0aGUgaW5mb3Jt YXRpdmUgc2VjdGlvbiB3b3VsZCBiZSBnb29kLgoKSW4gdGhlIHBhc3QgKHdoZW4gSSB3YXMgc3Rp bGwgd3JpdGluZyBsb3RzIG9mIGNvZGUsIHVuZm9ydHVuYXRlbHkKSSBhbSBub3QgZG9pbmcgbXVj aCBvZiB0aGF0IHRoZXNlIGRheXMpLCBJIGFsd2F5cyBsb29rZWQgYXQgdGhlCm5vcm1hdGl2ZSBy ZWZlcmVuZXMgYW5kIGZpZ3VyZWQgdGhhdCBJIGJldHRlciB1bmRlcnN0YW5kIHRob3NlCmRvY3Vt ZW50cyBjb21wbGV0ZWx5IGJlZm9yZSBJIHdvdWxkIHN0YXJ0IGltcGxlbWVudGluZyBhbnl0aGlu Zy4KClRoYW5rLApCZXJ0Cg== ----_com.samsung.android.email_1219287161552910 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PlRob3NlIHNob3VsZCBiZSBp bmZvcm1hdGl2ZSByZWZlcmVuY2VzLiAmbmJzcDtTb3JyeS48L2Rpdj48ZGl2PkpvZWw8L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21w b3Nlcl9zaWduYXR1cmUiPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyI+ U2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IFPCriA2LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21h cnRwaG9uZTwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAw MDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogIkJlcnQgV2lqbmVuIChJRVRGKSIgJmx0O2J3aWV0 ZkBid2lqbmVuLm5ldCZndDsgPC9kaXY+PGRpdj5EYXRlOiAzLzE1LzIwMTYgIDEwOjA1IEFNICAo R01UKzAxOjAwKSA8L2Rpdj48ZGl2PlRvOiBKb2huIFN0cmFzc25lciAmbHQ7c3RyYXpwZGpAZ21h aWwuY29tJmd0OywgSmFzb24gQ29sZW1hbiAmbHQ7cm91dGVyam9ja2V5QG1lLmNvbSZndDsgPC9k aXY+PGRpdj5DYzogSm9lbCBIYWxwZXJuICZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0Oywgc3Vw YUBpZXRmLm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbU3VwYV0gRndkOiBJLUQgQWN0aW9u OgogIGRyYWZ0LXN0cmFzc25lci1zdXBhLWdlbmVyaWMtcG9saWN5LWluZm8tbW9kZWwtMDQudHh0 IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2Pk9uIDE1LzAzLzE2IDAzOjE4LCBKb2huIFN0cmFz c25lciB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7IC0gcGFnZSAxNjxicj4mZ3Q7PGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBwcmluY2lwbGUgaXMgb25lIG9mIHRoZSBrZXkgY2hh cmFjdGVyaXN0aWNzPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhhdCBpcyBOT1QgZm9sbG93 ZWQgaW4gWzRdLCBbNl0sIFtSRkMzMDYwXSwgYW5kIFtSRkMzNDYwXS48YnI+Jmd0Ozxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYXQgbWF5IHZlcnkgd2VsbCBiZSB0cnVlLCBidXQgd2h5IGlz IHRoaXMgcmVsZXZhbnQ/IEFuZCB3aHkgd291bGQgdGhhdDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7IG1ha2UgUkZDMzA2MCBhbmQgMzQ2MCBOT1JNQVRJVkUgcmVmZXJlbmNlcz88YnI+Jmd0Ozxi cj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgc2VlIHNvbWUgbW9yZSByZWZlcmVuY2VzIHRvIHRo ZXNlIDIgZG9jdW1lbnRzLCBUaGV5IGFsbCBzZWVtIHRvIGluZGljYXRlPGJyPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsgdGhhdCBzb21ldGhpbmcgd2FzIHdyb25nIGluIHRob3NlIGZjcyBvciB0aGF0 IHdlIGRvIHRoaW5ncyBkaWZmZXJlbnQuPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBkbyBu b3Qgc2VlIHdoeSB0aGF0IGhhcyB0byBiZSBOT1JNQVRJVkU8YnI+Jmd0OyAmbHQ7amNzJmd0Ozxi cj4mZ3Q7IFRoaXMgaXMgcmVsZXZhbnQgYmVjYXVzZSBpdCBpcyBhIGtleSBkZXNpZ24gcHJpbmNp cGxlIGZvciBzY2FsYWJsZSBhbmQ8YnI+Jmd0OyBleHRlbnNpYmxlIGluZm9ybWF0aW9uIG1vZGVs cy48YnI+Jmd0Ozxicj4mZ3Q7IEknbSBoYXBweSB0byBtYWtlIFBDSU0gYW5kIFBDSU1lIElORk9S TUFUSVZFLCBnb29kIGNhdGNoLjxicj4mZ3Q7ICZsdDsvamNzJmd0Ozxicj5JIGNhbiBzZWUgdGhh dCBpdCBtYXkgYmUgcmVsZXZhbnQuIGJ1dCB0aGF0IGluZGVlZCBkb2VzIG5vdDxicj5tZWFuIGl0 IGlzIG5vcm1hdGl2ZS4gSSB0aGluayBpdCBjYW4gYmUgKGZvciBzb21lKSBleHRyYTxicj5iYWNr Z3JvdW5kIHJlYWRpbmcgZm9yIGJldHRlciB1bmRlcnN0YW5kaW5nIGFzIHRvIHdoeSB0aGluZ3M8 YnI+YXJlIGRvbmUgaGVyZSB0aGUgd2F5IHRoZXkgYXJlIGRvbmUuPGJyPjxicj5JIHRoaW5rIG1v dmluZyBpdCB0byB0aGUgaW5mb3JtYXRpdmUgc2VjdGlvbiB3b3VsZCBiZSBnb29kLjxicj48YnI+ SW4gdGhlIHBhc3QgKHdoZW4gSSB3YXMgc3RpbGwgd3JpdGluZyBsb3RzIG9mIGNvZGUsIHVuZm9y dHVuYXRlbHk8YnI+SSBhbSBub3QgZG9pbmcgbXVjaCBvZiB0aGF0IHRoZXNlIGRheXMpLCBJIGFs d2F5cyBsb29rZWQgYXQgdGhlPGJyPm5vcm1hdGl2ZSByZWZlcmVuZXMgYW5kIGZpZ3VyZWQgdGhh dCBJIGJldHRlciB1bmRlcnN0YW5kIHRob3NlPGJyPmRvY3VtZW50cyBjb21wbGV0ZWx5IGJlZm9y ZSBJIHdvdWxkIHN0YXJ0IGltcGxlbWVudGluZyBhbnl0aGluZy48YnI+PGJyPlRoYW5rLDxicj5C ZXJ0PGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_1219287161552910-- From nobody Tue Mar 15 14:03:02 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17DD12DAA4 for ; Tue, 15 Mar 2016 14:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3scud3QmvkEH for ; Tue, 15 Mar 2016 14:02:58 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF0712DDA9 for ; Tue, 15 Mar 2016 14:02:51 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id e138so4393503lfe.1 for ; Tue, 15 Mar 2016 14:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=Pj5yu/61uordLH7ZIqXdDd3Xkey/dCRvDNpiKJ91D90=; b=vqkMaz9hLt484IAcMakIYZ3SFGSRwrEGmAXBqDcT+mpSIHUx2sywvl8Z9lViw16UIH sA98UM+0xLnHCZnZq+ACr0v3ByC7bEOVvkqAj1kTbB6euK1dNBsxgKtcP8J+WkyeOLbv KoWgjax0DPmgdIOxvN3O3jfKP3tyn51EucMKPyjwrINaaSQr2EzPshJ/0EAawlOcmFyK FNDbIsTZ1KUBvU+yvbu01MZCM6NBwC0YVwWaGq+efyUfGe12jcl2qnGBVT1Ygao6zA3J MqXOY5vNamJdyBywmndwvQfEDgcv9gWj5gkv4pXwJ9OCPhHNxRBynR+qiesm+6CWSh5f osaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=Pj5yu/61uordLH7ZIqXdDd3Xkey/dCRvDNpiKJ91D90=; b=dCEWs6EMiVJuse0Hsync2F+6igepM/sMiHr5v6M+TR1qsJS6hVGEo5TCisVPk1owJx Evr0qD97ZMX6qMg9gfVR9xkfOCH501iKBDOvAeZluFP/L4MC+Xs9tiNq1gp9fTDGUZ0P SsK43T0+PnFPQF8b+8y0WgRJw8mOre2jvgvwSW8Mu4pjBiD4lQ6nxNG0QWvgyz5+QKn6 m2j0BAL8CbMxbufQPsjTuqW4CdovG/Qjf+gKsjuYWF/POeRy/ebV0fNqTe+sablbK3Dj 9NdSxj85LBGtmynYPFH1UgOTQ2zgI92zEsDoCD8hKlYb0AfXqwN9J3RtC5NcAcdp73kT cUXg== X-Gm-Message-State: AD7BkJJho0OmYSt8qYXMTJz6lEW8Qfk5e2FmqSH+HJC5hdxIYPJi2Ay9CLSEmOCCsykJosxHkZ/YrBp2pGDkfQ== MIME-Version: 1.0 X-Received: by 10.25.154.14 with SMTP id c14mr43396lfe.35.1458075769825; Tue, 15 Mar 2016 14:02:49 -0700 (PDT) Received: by 10.25.156.76 with HTTP; Tue, 15 Mar 2016 14:02:49 -0700 (PDT) In-Reply-To: <20160315071049.GA18078@elstar.local> References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> <20160315071049.GA18078@elstar.local> Date: Tue, 15 Mar 2016 14:02:49 -0700 Message-ID: From: John Strassner To: Juergen Schoenwaelder , John Strassner , "Bert Wijnen (IETF)" , Jason Coleman , Joel Halpern , "supa@ietf.org" Content-Type: multipart/alternative; boundary=001a11401aae50f882052e1cb86b Archived-At: Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:03:00 -0000 --001a11401aae50f882052e1cb86b Content-Type: text/plain; charset=UTF-8 RFC3444 says: "One of the possibilities to formally specify IMs is to use class diagrams of the Unified Modeling Language (UML)." Since UML is **not** a formal language, it is therefore an error to state that an IM can be formally specified using UML On Tue, Mar 15, 2016 at 12:10 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Mar 14, 2016 at 07:18:55PM -0700, John Strassner wrote: > > > > > I used RFC3198 because RFC3444 does not provide a definition; it provides > > a discussion. In addition, it contains some errors (e.g., it says that > UML > > is a > > "formal language", which is incorrect. > > > > However, your suggestion is a good one - we will work in a reference of > > RFC3444 somewhere... > > > > RFC 3444 says: > > [...] One of the possibilities to formally > specify IMs is to use class diagrams of the Unified Modeling Language > (UML). > > Note that RFC 3444 makes a distinction between informally defined IMs > (e.g, using natural language) and formally defined IMs (using a > notational system, i.e, a formalism). > > IMs can be defined in an informal way, using natural languages such > as English. > > Alternatively, IMs can be defined using a formal language or a semi- > formal structured language. > > Hence, I am not convinced that RFC 3444 contains an _error_. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > -- regards, John --001a11401aae50f882052e1cb86b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC3444 says:
=C2=A0 "One of the possi= bilities to formally specify IMs is to use class
=C2=A0 =C2=A0dia= grams of the Unified Modeling Language (UML)."

Since UML is **not** a formal language, it is therefore an error
to state that an IM can be formally specified using UML

On Tue, Mar 15, 2016 at= 12:10 AM, Juergen Schoenwaelder <j.schoenwaelder@jacob= s-university.de> wrote:
On = Mon, Mar 14, 2016 at 07:18:55PM -0700, John Strassner wrote:

> <jcs>
> I used RFC3198 because RFC3444 does not provide a definition; it provi= des
> a discussion. In addition, it contains some errors (e.g., it says that= UML
> is a
> "formal language", which is incorrect.
>
> However, your suggestion is a good one - we will work in a reference o= f
> RFC3444 somewhere...
> </jcs>

RFC 3444 says:

=C2=A0 =C2=A0[...] One of the possibilities to formally
=C2=A0 =C2=A0specify IMs is to use class diagrams of the Unified Modeling L= anguage
=C2=A0 =C2=A0(UML).

Note that RFC 3444 makes a distinction between informally defined IMs
(e.g, using natural language) and formally defined IMs (using a
notational system, i.e, a formalism).

=C2=A0 =C2=A0IMs can be defined in an informal way, using natural languages= such
=C2=A0 =C2=A0as English.

=C2=A0 =C2=A0Alternatively, IMs can be defined using a formal language or a= semi-
=C2=A0 =C2=A0formal structured language.

Hence, I am not convinced that RFC 3444 contains an _error_.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>



--
regards,
John
--001a11401aae50f882052e1cb86b-- From nobody Tue Mar 15 14:04:24 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FCC12D55F for ; Tue, 15 Mar 2016 14:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eh3NNZplvjle for ; Tue, 15 Mar 2016 14:04:21 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26E512D550 for ; Tue, 15 Mar 2016 14:04:20 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id h198so4990704lfh.0 for ; Tue, 15 Mar 2016 14:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=pZWEF/iJBfRumDk5LgeCnUsGv+V9hp+k+hIc84qQIHQ=; b=zAPWVeueTMlKgamqhpsu2n5F8KXSH9/tV1EDLIXH6xcmcYADMG7CtFtDSqQi62hNED xsihxn9FOt8cVZgPEP1NEOamqjAtDrwYt3yeXi16/K5UiAOuFIWMSCt6SZXKvJXfQyBt J1EahETnk+2bhKk3A8VT6PUj9wOOG4rTMxZQDzb6ba6vj2BvQ2z0QTD2adT/T0coiLMV wpvZb+WOYgkHV+NvsUlVfcSjl+Y4TWuLRl5C39ym1uxKuxElgiUe3Wp8HblUquKUmsYS BUqBSkki+FXgVilI2g7DSB08nwWH4i71ZONpGF5sEJ0HPVHlfTy0JmKqc+GH25V5ymmA x0yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=pZWEF/iJBfRumDk5LgeCnUsGv+V9hp+k+hIc84qQIHQ=; b=DWkEi5fWHqKjfdbfESmGjyroay7Zo3WT0E//TkSgh8bzu/4QdEJPlfk7PwNPi+/BX7 qlQDsfFehDcZOb7zn4XJXwPQq8DZ6QgeI2Xwde08rFKmjCaIENAsy44EU0ppRvrkVjZ/ afSR4WKh9qS3rL+B9g5FhLpMLBYTz3VBV/Hs3hWi9ZSzs6n8CJ9pJ1Udl3CifkYBs88A G6ilU8lI/BMZKHJvji0GwkX/G9TZdHxpIaFeqAV1wkUi0fo5cPK47dSYI20Yf4YUUxNJ CWXS8VyfWJr4ZgR3f71zLzTctkyMu0H6Sjc0xi7EjjK6EZH9XrefuvByOnXBtFvt5KYl +yEQ== X-Gm-Message-State: AD7BkJJ53KHKChAD2s/53LYmJsWT6QjByBPWspFD3r3r1eXiFepNOjAHORcmybtnQQifgCJhHJGEbZyFPdDvng== MIME-Version: 1.0 X-Received: by 10.25.143.141 with SMTP id r135mr58329lfd.100.1458075859206; Tue, 15 Mar 2016 14:04:19 -0700 (PDT) Received: by 10.25.156.76 with HTTP; Tue, 15 Mar 2016 14:04:19 -0700 (PDT) In-Reply-To: <56E7CF0B.6010602@bwijnen.net> References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> <56E7CF0B.6010602@bwijnen.net> Date: Tue, 15 Mar 2016 14:04:19 -0700 Message-ID: From: John Strassner To: "Bert Wijnen (IETF)" , John Strassner Content-Type: multipart/alternative; boundary=001a114016e4a4ccfb052e1cbd16 Archived-At: Cc: Jason Coleman , Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:04:23 -0000 --001a114016e4a4ccfb052e1cbd16 Content-Type: text/plain; charset=UTF-8 Hi Bert, OK, thanks for your help. DONE. regards, John On Tue, Mar 15, 2016 at 1:59 AM, Bert Wijnen (IETF) wrote: > Thanks John, > > W.r.t. the below (RFC3198 reference): > > Since you (as far as I could tell) only use a couple fo definitions, maybe > it is better (and faster for the reader) if you just repeat them in > the IM document. > > Bert > On 15/03/16 03:18, John Strassner wrote: > >> >> - on page 12 and 13 you talk about IM and DM and refer to RFC3198. >> I would think that a reference to RFC3444 would also make sense. >> As an informative reference. It explains a lot about the difference >> between the 2. >> >> I used RFC3198 because RFC3444 does not provide a definition; it provides >> a discussion. In addition, it contains some errors (e.g., it says that >> UML is a >> "formal language", which is incorrect. >> >> However, your suggestion is a good one - we will work in a reference of >> RFC3444 somewhere... >> >> >> >> Actually, I wonder if referencing 3198 is wise. It also contains a >> lot of >> stuff that never really took off in IETF or the industry. For exmplae >> it talks about SPPI, PIB and COPS-PR, which we (IETF) are in the >> process >> of declaring it HISTORIC. So why would we overload younger people >> with all that now more or less irrelevant material? >> >> See above >> >> >> > -- regards, John --001a114016e4a4ccfb052e1cbd16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bert,

OK, thanks for your= help. DONE.

regards,
John

On Tue, Mar 15, 201= 6 at 1:59 AM, Bert Wijnen (IETF) <bwietf@bwijnen.net> wrote= :
Thanks John,

W.r.t. the below (RFC3198 reference):

Since you (as far as I could tell) only use a couple fo definitions, maybe<= br> it is better (and faster for the reader) if you just repeat them in
the IM document.

Bert
On 15/03/16 03:18, John Strassner wrote:

=C2=A0- on page 12 and 13 you talk about IM and DM and refer to RFC3198. =C2=A0 =C2=A0I would think that a reference to RFC3444 would also make sens= e.
=C2=A0 =C2=A0As an informative reference. It explains a lot about the diffe= rence
=C2=A0 =C2=A0between the 2.
<jcs>
I used RFC3198 because RFC3444 does not provide a definition; it provides a discussion. In addition, it contains some errors (e.g., it says that UML = is a
"formal language", which is incorrect.

However, your suggestion is a good one - we will work in a reference of
RFC3444 somewhere...
</jcs>


=C2=A0 =C2=A0 Actually, I wonder if referencing 3198 is wise. It also conta= ins a lot of
=C2=A0 =C2=A0stuff that never really took off in IETF or the industry. For = exmplae
=C2=A0 =C2=A0it talks about SPPI, PIB and COPS-PR, which we (IETF) are in t= he process
=C2=A0 =C2=A0of declaring it HISTORIC. So why would we overload younger peo= ple
=C2=A0 =C2=A0with all that now more or less irrelevant material?
<jcs>
See above
</jcs>





--
regards,
John
--001a114016e4a4ccfb052e1cbd16-- From nobody Tue Mar 15 14:10:17 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D5D12D822 for ; Tue, 15 Mar 2016 14:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 i7NhouaT7-BC for ; Tue, 15 Mar 2016 14:10:12 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182C312DDB3 for ; Tue, 15 Mar 2016 14:08:53 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id l202so5064641lfl.2 for ; Tue, 15 Mar 2016 14:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kWbqSs0owmCfMjdAMsgTOD6uPfMhB2fTFinvGTkCZbg=; b=lwaHmJsIM+5z96JdwipXSTl25qiv9s9c8BN+srV5Nlh2svMvmylDyB+BH8tFiIWqpJ F19gcPz7UhAdpvTMIukbW83eKPZAq6Sa4fPL52OTTpuHQ8vZY55Cw6/RaaEbZQmC9QJB +hvLzkr2l9r6JxEkBj2GsdAQt6YFObL2mIVxi4roadBJGiWcy2HYid7zp9SFlNd/+0X5 NC9GlU5vTVXuqkIxsVp4ib+eyan7TRNtHKJr7A9FGJM5RTVV5qIXPpvXH7yYh4M4KOyC JIlS8ntqeewedDVLz1DBYD3WbrRLQ+Qp8PjGTc1m/4KSIn7fUJQis+xIthDYOVj+i/Lj u2Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kWbqSs0owmCfMjdAMsgTOD6uPfMhB2fTFinvGTkCZbg=; b=M6bO+DUUK068ruw/1yt1/OChEzDOezujpGpVfWIjsyQzZVot8wHEEy/v8qvh+AG9dT 6jSMZGY/7HQBm3SPX+MBfc5slmCgOOfAnpYs2UwQ/2OV8ehJugpSDXsZMB5SPa90geEU Vw3TzLS6K2b5qiryp1RzQXsF80xGiqUSAT2uLkTJrX03NAxWvwDUo6sEf7NYLld4nh5N GtMGKJMoATxOEfIuefy6pnbx0MwkFhXCv7GZQUtkhiXXbtzdKptrhE0rXcnrmzR9O3z0 XDjLKEwHy+kETS/OFU5FaGn2DoepwP2yBKm8UZKVCY5l0GdqE8UPkCmi9BHYRIPn84kZ mTkA== X-Gm-Message-State: AD7BkJIf2IrppSqIeoeJk1WWrV94HdS8B8fyStn34XjZaurXHZ0q14b1TjjIi7sZzKDNN1X+dczNQ/PHlU+iUw== MIME-Version: 1.0 X-Received: by 10.25.18.158 with SMTP id 30mr71488lfs.16.1458076131234; Tue, 15 Mar 2016 14:08:51 -0700 (PDT) Received: by 10.25.156.76 with HTTP; Tue, 15 Mar 2016 14:08:51 -0700 (PDT) In-Reply-To: <56E7CFA4.1030909@bwijnen.net> References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> <56E7CFA4.1030909@bwijnen.net> Date: Tue, 15 Mar 2016 14:08:51 -0700 Message-ID: From: John Strassner To: "Bert Wijnen (IETF)" , John Strassner Content-Type: multipart/alternative; boundary=001a113f1fe0db9e23052e1ccd2c Archived-At: Cc: Jason Coleman , Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:10:16 -0000 --001a113f1fe0db9e23052e1ccd2c Content-Type: text/plain; charset=UTF-8 You're welcome. Apologies for not being more clear in the first place. I would indeed see access control for a query as different; read is different than execute, for example. When I implemented RBAC and ABAC systems, we often made separate privileges for query, due to the additional processing involved. regards, John On Tue, Mar 15, 2016 at 2:02 AM, Bert Wijnen (IETF) wrote: > On 15/03/16 03:18, John Strassner wrote: > >> >> - page 14: >> >> In this context, "manage" means that at least create, read, >> query, update, and delete functions are supported. >> >> Is there a difference between "read" an "query" >> is CRUD not enough? >> >> "Read" is, at least to me, a simple command to provide a result. In >> contrast, >> "Query" is a more complex operation that may involve pre- and/or post- >> processing of the results of the operation. >> >> Note that many people think of SQL as a query language; in that case, the >> definition of query expands to include data definition, data control, and >> data >> manipulation languages. >> >> Would you like the above text included? >> >> > Ah. Thanks. I guess it would be good to indeed explain the difference. > > Would you see access control to be different for a query as opposed to > a read? That is where my question came from. > > Bert > -- regards, John --001a113f1fe0db9e23052e1ccd2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You're welcome. Apologies for not being more clea= r in the first place.

I would indeed see access co= ntrol for a query as different; read is
different than execute, f= or example. When I implemented RBAC and
ABAC systems, we often ma= de separate privileges for query, due to
the additional processin= g involved.

regards,
John

On Tue, Mar 15, 2016= at 2:02 AM, Bert Wijnen (IETF) <bwietf@bwijnen.net> wrote:=
On 15/03/16 03:18, John Strassner wrote:=

=C2=A0- page 14:

=C2=A0 =C2=A0 In this context, "manage" means that at least creat= e, read,
=C2=A0 =C2=A0 query, update, and delete functions are supported.

=C2=A0 =C2=A0Is there a difference between "read" an "query&= quot;
=C2=A0 =C2=A0is CRUD not enough?
<jcs>
"Read" is, at least to me, a simple command to provide a result. = In contrast,
"Query" is a more complex operation that may involve pre- and/or = post-
processing of the results of the operation.

Note that many people think of SQL as a query language; in that case, the definition of query expands to include data definition, data control, and d= ata
manipulation languages.

Would you like the above text included?
</jcs>
Ah. Thanks. I guess it would be good to indeed explain the difference.

Would you see access control to be different for a query as opposed to
a read? That is where my question came from.

Bert



--
regards,
John
--001a113f1fe0db9e23052e1ccd2c-- From nobody Tue Mar 15 14:10:45 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A295812D825 for ; Tue, 15 Mar 2016 14:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KBTDQ9ODwOgW for ; Tue, 15 Mar 2016 14:10:43 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B8E12D822 for ; Tue, 15 Mar 2016 14:10:36 -0700 (PDT) Received: by mail-lb0-x231.google.com with SMTP id oe12so35623105lbc.0 for ; Tue, 15 Mar 2016 14:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=9xZTgvS38yOfwF2xdq5TniabrYBkR7ng8P/Cc4/FkgU=; b=EEPe8Yuk6E4fTaXgoAs9zvjTq1v4btH0flK/Y1UZQeWwgTrx3prlX3bn1egm80p63F YqHdrNMs6J1EUf/f1sFTwqlXAU33HPx4wQe6ws+6Pz06RlLbnjvAjNqWSQZ6YA0YxnqS MRYTvWtloOxCu18n3cWDcgFxO6QMWfzfzK4jcrJ4aku4anzN6s2LaE/2UIsOloThlAub ceXSQhAT2TsdXWnWsG5NdtFx/cVM9b7Dy4W3mA+WFOirM4hGiw7koX6UulHtaDmmCDAO qIdt+EnP+Yu3oCAO1/vEZDHXUr3+sYWW8H4KofrximH1uITbFYMOFsoN/YqBGlc0Aap2 r/Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9xZTgvS38yOfwF2xdq5TniabrYBkR7ng8P/Cc4/FkgU=; b=UlMo3ITXf1hZ90t3auPhjZSP2qKQnfEbLZLPfmuNt1PP3GoaOzUnWWR+4ko8//S0hi ErC+C6eGzU1EMi9J2hpW8QtW54XuziJU24jKoW0d2g3zl7L/Is8LNB9JSk4D0fM2saxO Gebe+LQAux+qxk4VkarqfHBjAqM/j2MSohRYKZrIBooq2gtBh3jwpEpk04xsP5uYddjX jFUrk3H3LYGJhCIIDe4jzS//y5xm3NeDs1j9rbLsNUDEM2LcCsM7tIMkvpnqzCFoXjgY VKy0bxVL0xaNPdmLdsYewMFVWYgLVtl9Z54aAmalisfXb157i7PmB2DbZC4/lXxrsSic VVhA== X-Gm-Message-State: AD7BkJKk69a/sbaeJnsR513GdHiLIJgQMbZiJbSDmiNZasoIlR6g/NbsOeBJBrIBz6j5mik1mhNlQu9uhkSIdA== MIME-Version: 1.0 X-Received: by 10.112.210.130 with SMTP id mu2mr46266lbc.144.1458076234387; Tue, 15 Mar 2016 14:10:34 -0700 (PDT) Received: by 10.25.156.76 with HTTP; Tue, 15 Mar 2016 14:10:34 -0700 (PDT) In-Reply-To: <56E7D05A.8000005@bwijnen.net> References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> <56E7D05A.8000005@bwijnen.net> Date: Tue, 15 Mar 2016 14:10:34 -0700 Message-ID: From: John Strassner To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=001a11c30fd401972d052e1cd49d Archived-At: Cc: Jason Coleman , Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:10:45 -0000 --001a11c30fd401972d052e1cd49d Content-Type: text/plain; charset=UTF-8 For the record, I agree with you and Joel - these should be informative. Sorry! regards, John On Tue, Mar 15, 2016 at 2:05 AM, Bert Wijnen (IETF) wrote: > On 15/03/16 03:18, John Strassner wrote: > >> >> - page 16 >> >> This principle is one of the key characteristics >> that is NOT followed in [4], [6], [RFC3060], and [RFC3460]. >> >> That may very well be true, but why is this relevant? And why would >> that >> make RFC3060 and 3460 NORMATIVE references? >> >> I see some more references to these 2 documents, They all seem to >> indicate >> that something was wrong in those fcs or that we do things different. >> I do not see why that has to be NORMATIVE >> >> This is relevant because it is a key design principle for scalable and >> extensible information models. >> >> I'm happy to make PCIM and PCIMe INFORMATIVE, good catch. >> >> > I can see that it may be relevant. but that indeed does not > mean it is normative. I think it can be (for some) extra > background reading for better understanding as to why things > are done here the way they are done. > > I think moving it to the informative section would be good. > > In the past (when I was still writing lots of code, unfortunately > I am not doing much of that these days), I always looked at the > normative referenes and figured that I better understand those > documents completely before I would start implementing anything. > > Thank, > Bert > -- regards, John --001a11c30fd401972d052e1cd49d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For the record, I agree with you and Joel - these sho= uld be informative. Sorry!

regards,
John=

On Tu= e, Mar 15, 2016 at 2:05 AM, Bert Wijnen (IETF) <bwietf@bwijnen.net>= ; wrote:
On 15/03/16 03:18, John S= trassner wrote:

=C2=A0- page 16

=C2=A0 =C2=A0This principle is one of the key characteristics
=C2=A0 =C2=A0that is NOT followed in [4], [6], [RFC3060], and [RFC3460].
=C2=A0 =C2=A0That may very well be true, but why is this relevant? And why = would that
=C2=A0 =C2=A0make RFC3060 and 3460 NORMATIVE references?

=C2=A0 =C2=A0I see some more references to these 2 documents, They all seem= to indicate
=C2=A0 =C2=A0that something was wrong in those fcs or that we do things dif= ferent.
=C2=A0 =C2=A0I do not see why that has to be NORMATIVE
<jcs>
This is relevant because it is a key design principle for scalable and
extensible information models.

I'm happy to make PCIM and PCIMe INFORMATIVE, good catch.
</jcs>
I can see that it may be relevant. but that indeed does not
mean it is normative. I think it can be (for some) extra
background reading for better understanding as to why things
are done here the way they are done.

I think moving it to the informative section would be good.

In the past (when I was still writing lots of code, unfortunately
I am not doing much of that these days), I always looked at the
normative referenes and figured that I better understand those
documents completely before I would start implementing anything.

Thank,
Bert



--
regards,
John
--001a11c30fd401972d052e1cd49d-- From nobody Tue Mar 15 14:22:45 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5DD12D7F4 for ; Tue, 15 Mar 2016 14:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WqbCzo_f6bXs for ; Tue, 15 Mar 2016 14:22:42 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B3212D786 for ; Tue, 15 Mar 2016 14:22:41 -0700 (PDT) Received: by mail-lb0-x229.google.com with SMTP id x1so35593785lbj.3 for ; Tue, 15 Mar 2016 14:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=RFuIDfbt3CmwOCJqVwxdZ75eRuEwpZ2ZuB6YVJ2Sq18=; b=nRFgKbKY7C07mhpDd0LPSlMrnxhElmRP/EJX0+IZtKtH84/xrU6YplviXYnVzrNSKK LxILI28FoSXDD29kRXea0vO2BO5YrZrh5OlHms0k+s8livemQ/cx/0U6sfMrEpQo1WVQ x+KHcJpScSEjU6qJC5aIM2JE179FzrNupdFIW5k0A+j6F9Bp5XbLKBdXJhmYRW50AK/j icav6t+T1U85uqn4STMd5vpW1jM5xSYAZgCCujcysamyzah0gO5rUzOgF0jlv0+4hvug HI1FmDls6hEHG6/B5WjCOIDEY5HqA/pie0vafWAu+O5Anp3brCkRObWqpBF49mfrUGUk LqHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RFuIDfbt3CmwOCJqVwxdZ75eRuEwpZ2ZuB6YVJ2Sq18=; b=Q/EKBTRh/AzE1OAaK0BCzWcZikaRB2ZAbYjHCCSwC/w7Mq6Zbrv265yjvOgpDSksFr /8Uq7UaGbgCMMuTK9iPSJ9LrQzlko8SsNSXzaGsAIjP/RmW91T5dzOECh1vNFoTn43tR 9PTecaPkDPPkWy47WK+yBywWWkDIRMqx8zP5GHMJmq9pYA7a4GuXS9/Q1RBUZsIDsylR KPON/FLDa06+2Gcisw/V2WJMbeEZiDJObNacMsMLNK7JvuoWfgQUYE4HDsKpUGYlAJLh tRrMBg8vgYnbLXHy0tHDCavpefC/dmgBdjuxxoEm+ziZT6lS/Aih1z7/EvUOxlze+m/8 QbOw== X-Gm-Message-State: AD7BkJLoXwIYFdDVhO1jqai9X65uL4zhFh2qDIFqJkB88R9eXP4lcY4Q4kNPrGMbrZb7sJx0fVQtHMM3yWxQow== MIME-Version: 1.0 X-Received: by 10.112.170.68 with SMTP id ak4mr62570lbc.94.1458076959874; Tue, 15 Mar 2016 14:22:39 -0700 (PDT) Received: by 10.25.156.76 with HTTP; Tue, 15 Mar 2016 14:22:39 -0700 (PDT) In-Reply-To: <56E7D137.8010205@bwijnen.net> References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> <56E7D137.8010205@bwijnen.net> Date: Tue, 15 Mar 2016 14:22:39 -0700 Message-ID: From: John Strassner To: "Bert Wijnen (IETF)" , John Strassner Content-Type: multipart/alternative; boundary=001a11c259a83fa61b052e1cffd2 Archived-At: Cc: Jason Coleman , Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:22:44 -0000 --001a11c259a83fa61b052e1cffd2 Content-Type: text/plain; charset=UTF-8 On 15/03/16 03:18, John Strassner wrote: >>> - when I see figure 2, then I wonder why we do not split of EPRIM >>> in to a separate document? >> < jcs> >> The thinking was: >> 1) there would be a lot of repeated text, and >> 2) it would be difficult for readers - they would have to have two >> documents open at the same time to understand the work >> < /jcs> > Mmmmm.... now I am really getting worried. > Are you saying i MUST understand EPRIM in order to > understand GPIM ????? > > That would not be good. The other way around, YES. No, I MUST understand GPIM to understand EPRIM (since EPRIM extends GPIM). Note that this is a proper extension, as the EPRIM does not define any new classes that are not subclassed from a GPIM class. > So if I want to expand GPIM with a IM for declarative, > then (I hope) there should be no need to understand/read > EPRIM. So I would not have to be bothered with it, no? > I should be able to do a DPRIM document without > reading or understanding EPRIM. Yes, if you want to extend the GPIM, you do not need to use the EPRIM. Note that you could further refine the EPRIM as well. regards, John On Tue, Mar 15, 2016 at 2:09 AM, Bert Wijnen (IETF) wrote: > On 15/03/16 03:18, John Strassner wrote: > >> - when I see figure 2, then I wonder why we do not split of EPRIM in to >> a separate >> document? >> >> The thinking was: >> 1) there would be a lot of repeated text, and >> 2) it would be difficult for readers - they would have to have two >> documents >> open at the same time to understand the work >> >> > Mmmmm.... now I am really getting worried. > Are you saying i MUST understand EPRIM in order to > understand GPIM ????? > > That would not be good. The other way around, YES. > > So if I want to expand GPIM with a IM for declarative, > then (I hope) there should be no need to understand/read > EPRIM. So I would not have to be bothered with it, no? > I should be able to do a DPRIM document without > reading or understanding EPRIM. > > Bert > -- regards, John --001a11c259a83fa61b052e1cffd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 15/03/16 03:18, John Strassner wrote:
&g= t;>>=C2=A0- when I see figure 2, then I wonder why we do not split of= EPRIM
>>> in to a separate=C2=A0=C2=A0document?
>= >=C2=A0=C2=A0 < jcs>
>>=C2=A0=C2=A0 The thinking was:
= >>=C2=A0=C2=A0=C2=A0=C2=A0 1) there would be a lot of repeated text, = and
>>=C2=A0=C2=A0=C2=A0=C2=A0 2) it would be difficult for reader= s - they would have to have=C2=A0two
>>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 documents open at the same time to understand the wor= k
>>=C2=A0=C2=A0 < /jcs>
>=C2=A0=C2=A0 Mmmm= m.... now I am really getting worried.
>=C2=A0=C2=A0 Are you saying = i MUST understand EPRIM in order to
>=C2=A0=C2=A0 understand GPIM ??= ???
>
>=C2=A0=C2=A0 That would not be good. The other way arou= nd, YES.

No, I MUST understand GPIM to understand = EPRIM (since EPRIM
extends GPIM). Note that this is a proper exte= nsion, as the EPRIM
does not define any new classes that are not = subclassed from a
GPIM class.


=
>=C2=A0=C2=A0 So if I want to expand GPIM with a IM for declarative= ,
>=C2=A0=C2=A0 then (I hope) there should be no need to understand/= read
>=C2=A0=C2=A0 EPRIM. So I would not have to be bothered with it= , no?
>=C2=A0=C2=A0 I should be able to do a DPRIM document without<= br> >=C2=A0=C2=A0 reading or understanding EPRIM.

Yes, if you want to extend the GPIM, you do not need to
use th= e EPRIM.

Note that you could further refine the EP= RIM as well.

regards,
John

On Tue, Mar 15, 201= 6 at 2:09 AM, Bert Wijnen (IETF) <bwietf@bwijnen.net> wrote= :
On 15/03/16 03:18, John Strassner wrote= :
=C2=A0- when I see figure 2, then I wonder why we do not split of EPRIM in = to a separate
=C2=A0 =C2=A0document?
<jcs>
The thinking was:
=C2=A0 =C2=A01) there would be a lot of repeated text, and
=C2=A0 =C2=A02) it would be difficult for readers - they would have to have= two documents
=C2=A0 =C2=A0 =C2=A0 =C2=A0open at the same time to understand the work
</jcs>
Mmmmm.... now I am really getting worried.
Are you saying i MUST understand EPRIM in order to
understand GPIM ?????

That would not be good. The other way around, YES.

So if I want to expand GPIM with a IM for declarative,
then (I hope) there should be no need to understand/read
EPRIM. So I would not have to be bothered with it, no?
I should be able to do a DPRIM document without
reading or understanding EPRIM.

Bert



--
regards,
John
--001a11c259a83fa61b052e1cffd2-- From nobody Tue Mar 15 14:24:33 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E7212D69D for ; Tue, 15 Mar 2016 14:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 s9uvb7T7A9Ee for ; Tue, 15 Mar 2016 14:24:31 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CC012D58C for ; Tue, 15 Mar 2016 14:24:30 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id l83so5329654lfd.3 for ; Tue, 15 Mar 2016 14:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=BE2dbH83x2p0R6BSfBkcAy0niFEOXfctABPLyX3+F2M=; b=UYCF8KgBmhGaQ4ml5KDLLWdm4LzN2frAdAzKSRrhyJyCw2nYUqzZ2pPVoH77DD8EpI qUbSWHOUJHLQfs1nui53Nu1o6GKteRI06r+Sm0HGkoDYW3UOjdJmggtsgutgzzlHgE1X 7q49qqpWBg5qnaSyJxI0frtQ8636sqdaamAfBfnsebuLZFqB22HFhS7Ajs734I4jXzQZ Y7ZZw7LmwmYu+cf2HUl2DyhbcaQ1M5mnYM0UTWD/MQL2SElZmt2Jc9oMJQCJjqxy0vjx 9ChYN78Rwqe3+4+LiVaQQYtKTLedub2i3b9gK75qs8WfS4mGwinYYj4l3kLC3j76IAO5 uvRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BE2dbH83x2p0R6BSfBkcAy0niFEOXfctABPLyX3+F2M=; b=T83zbZwVT4cLaDByfRt8eEHeAwlkPTpItxCXFwb8U+WGKsws2SCZSv+gZoH36NTXzg 0l21g8hBB33M4y1FxV+SUKv6B7CNeuvx5FQD1i8SEd+TSYwPZtGyvxKrAA26C6TWCI5V 6T34bdAXYSC9gvGOMNTbH0cBuEbhzKIDsXIYy2mnUZZayNSZSAmfwBgLd2FyWdr0ClIS zU6kUNBY3rzPhvxhA77S0P8bA5MOm2/8ftL23Zi/6IsYeKTqUPpcuaC5R/Pf495ad7U9 KOcgRvGPKSkfUPF5xJb7HimMWUKB2FH4w2gq1OLPP1Yk+d+Y5URJjxqZkjv9v4+CiFsq 4gDw== X-Gm-Message-State: AD7BkJI1gOyS9bcbcN2W+kWiR/wZw2Hh0lG3OzO8kGULFga5zZlD/2b7gnprFtkqB5holR/PFqJOMSNg/OauiQ== MIME-Version: 1.0 X-Received: by 10.25.44.18 with SMTP id s18mr84541lfs.66.1458077068813; Tue, 15 Mar 2016 14:24:28 -0700 (PDT) Received: by 10.25.156.76 with HTTP; Tue, 15 Mar 2016 14:24:28 -0700 (PDT) In-Reply-To: <56E7D428.5090903@bwijnen.net> References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> <56E7D428.5090903@bwijnen.net> Date: Tue, 15 Mar 2016 14:24:28 -0700 Message-ID: From: John Strassner To: "Bert Wijnen (IETF)" , John Strassner Content-Type: multipart/alternative; boundary=001a11402ecebdef30052e1d0517 Archived-At: Cc: Jason Coleman , Joel Halpern , "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:24:32 -0000 --001a11402ecebdef30052e1d0517 Content-Type: text/plain; charset=UTF-8 Hi Bert, this is a good observation. We will better document these semantics. And you're right, there should be no need for you to study UML... regards, John On Tue, Mar 15, 2016 at 2:21 AM, Bert Wijnen (IETF) wrote: > On 15/03/16 03:18, John Strassner wrote: > >> >> - I see: >> >> 5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]" >> >> This is an optional array of string attributes that identifies the >> >> Mmmm in the prigrammin languages that I know (not too many I must >> confess, >> but still multiple), arrays are indexed from [0..n-1]. SO I wonder if >> this could >> lead to mis-understandings and/or programming errors. >> >> later on you use [0..n], so maybe this is just a typo. >> >> Both are UML-ese for defining a collection; it is not referring to >> indexing an array >> >> > > Mmmm I I guess I demonstrated, my knowledge about UML is > very limited. But when I see that notation, and the next sentence > is: This is an optional array of string attributes that identifies the > Then is it just me who thinks that [1..n] indicates the index > into the array? Maybe se, then pls ignore. If there are others > who were put on the wrong footing by that, then pls speak up, > because then maybe we should make it clearer. > > But still, in some cases you use [1..n] and in other cases [0..n] > So is there a difference between those 2, and if so, what is it? > Pls document (unless this is all 100% clear to UML folk, then > maybe I should just study UML first; I hope not though) > > Bert > > -- regards, John --001a11402ecebdef30052e1d0517 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bert,

this is a good obse= rvation. We will better document these
semantics. And you're = right, there should be no need for
you to study UML...
=
regards,
John

On Tue, Mar 15, 2016 at 2:21 AM, Bert Wijn= en (IETF) <bwietf@bwijnen.net> wrote:
On 15/03/16 03:18, John Strassner wrote:

=C2=A0- I see:

5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]"
=C2=A0 =C2=A0 This is an optional array of string attributes that identifie= s the

=C2=A0 =C2=A0Mmmm in the prigrammin languages that I know (not too many I m= ust confess,
=C2=A0 =C2=A0but still multiple), arrays are indexed from [0..n-1]. SO I wo= nder if this could
=C2=A0 =C2=A0lead to mis-understandings and/or programming errors.

=C2=A0 =C2=A0 later on you use [0..n], so maybe this is just a typo.
<jcs>
Both are UML-ese for defining a collection; it is not referring to indexing= an array
</jcs>

Mmmm I I guess I demonstrated, my knowledge about UML is
very limited. But when I see that notation, and the next sentence
is: This is an optional array of string attributes that identifies the
Then is it just me who thinks that [1..n] indicates the index
into the array? Maybe se, then pls ignore. If there are others
who were put on the wrong footing by that, then pls speak up,
because then maybe we should make it clearer.

But still, in some cases you use [1..n] and in other cases [0..n]
So is there a difference between those 2, and if so, what is it?
Pls document (unless this is all 100% clear to UML folk, then
maybe I should just study UML first; I hope not though)

Bert




--
regards,
John
--001a11402ecebdef30052e1d0517-- From nobody Tue Mar 15 15:02:05 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4368912DC70; Tue, 15 Mar 2016 15:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 R3iyb_B0REHs; Tue, 15 Mar 2016 15:02:00 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C107012D85B; Tue, 15 Mar 2016 15:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458079307; x=1489615307; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=5mnGYpVYmWcitvPZ6ecX9vxbk1We2n8BPGaP10KW630=; b=JdBBzxDgt/c358s3ZkxqN8D7Lr7GU2p0CpM7a7HgPANHGX8AcuypXFZ9 Wmyi8qrkvPDrj139akmddXcGi2FEA5/pjVsDQc9vLY8k50sozFLHq0sO9 VDBRY3HXzR8aDPyZYvxBsWUAYfO11QV773eyj7SwWm2fMsRO8jZXfRaBq C+PwPiBe4DAVPpzOAc3hHAx5YdrmGJo+KJiT6UQilU93DETy7VubPRmhT yEQCzqYjYr/s9+Zj9DyCKrhk90uEoXHPuw8VkgMkhLejwDdQMWAM6rxiq ztE/tvavP1KyL+foiTds7LcVGEYjJqycTK09q9k2jRxHRd1I9faYEY52t A==; X-IronPort-AV: E=Sophos;i="5.24,341,1454929200"; d="scan'208";a="74439830" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.7 - Outgoing - Outgoing-SSL Received: from sc-cs-316051.uoa.auckland.ac.nz (HELO [130.216.38.7]) ([130.216.38.7]) by mx4-int.auckland.ac.nz with ESMTP; 16 Mar 2016 11:01:44 +1300 To: SUPA list , "supa-chairs@ietf.org" From: Nevil Brownlee Message-ID: <56E88647.2060607@auckland.ac.nz> Date: Wed, 16 Mar 2016 11:01:43 +1300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Supa] SUPA at IETF 95, Buenos Aires X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 22:02:03 -0000 Hi all: IETF 95 is now only a bit over two weeks away, the SUPA WG meeting is scheduled at 1220-1320 on Friday, 8 April (the last slot of IETF 95)! At the meeting, I would would like discussion on "which drafts should be 'adopted by the WG,'" with the goal of picking the ones that people are currently working on, and that fit the 'work items' listed on our SUPA charter. The SUPA Documents page lists four drafts: - Two of these (information model and applicability statement) have groups working on them, they're clearly possible work items. - Our charter lists a 'Management Framework' item, there's been some mention of that on the list; we need this as a work item. - Our documents page lists two YANG Data Model drafts. These need some discussion Provided discussion at the meeting yields a set of supported drafts as work items, I'll move them to 'Proposed as work items' on Tracker. Then, provided there's reasonable support for them on the list, they can be formally adopted (i.e. new versions published as ietf-supa- drafts). Daniel is putting together a first draft of the agenda. If you're working on drafts within scope of the SUPA charter (as outlined above), please email supa-chairs@ietf.org to request some time to give a brief presentation, so that we can get you onto the agenda. Cheers, Nevil -- --------------------------------------------------------------------- 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 nobody Wed Mar 16 04:13:51 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C925012D6F5 for ; Wed, 16 Mar 2016 04:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 dM00ohxX3IGk for ; Wed, 16 Mar 2016 04:13:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C455012D54C for ; Wed, 16 Mar 2016 04:13:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8B2FCE86; Wed, 16 Mar 2016 12:13:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hYTlxjaUvaZZ; Wed, 16 Mar 2016 12:13:34 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 16 Mar 2016 12:13:45 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 980D620043; Wed, 16 Mar 2016 12:13:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qlLfVVtwpbsh; Wed, 16 Mar 2016 12:13:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 662DC2003D; Wed, 16 Mar 2016 12:13:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2428B3A37C17; Wed, 16 Mar 2016 12:13:43 +0100 (CET) Date: Wed, 16 Mar 2016 12:13:42 +0100 From: Juergen Schoenwaelder To: John Strassner Message-ID: <20160316111342.GA39598@elstar.local> Mail-Followup-To: John Strassner , "Bert Wijnen (IETF)" , Jason Coleman , Joel Halpern , "supa@ietf.org" References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> <20160315071049.GA18078@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Jason Coleman , Joel Halpern , "supa@ietf.org" , "Bert Wijnen \(IETF\)" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 11:13:50 -0000 The context of the sentence in RFC 3444 is in contrast to information models informally written in free form text. UML does add a formalism and hence the model is _formally specified_. (Whether UML is a formal language is a different question and likely depends on the definition of 'formal language' we would have to agree on.) I disagree RFC 3444 has an error here. (But all this is likely not relevant for SUPA so lets just disagree.) /js On Tue, Mar 15, 2016 at 02:02:49PM -0700, John Strassner wrote: > RFC3444 says: > "One of the possibilities to formally specify IMs is to use class > diagrams of the Unified Modeling Language (UML)." > > Since UML is **not** a formal language, it is therefore an error > to state that an IM can be formally specified using UML > > On Tue, Mar 15, 2016 at 12:10 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Mar 14, 2016 at 07:18:55PM -0700, John Strassner wrote: > > > > > > > > I used RFC3198 because RFC3444 does not provide a definition; it provides > > > a discussion. In addition, it contains some errors (e.g., it says that > > UML > > > is a > > > "formal language", which is incorrect. > > > > > > However, your suggestion is a good one - we will work in a reference of > > > RFC3444 somewhere... > > > > > > > RFC 3444 says: > > > > [...] One of the possibilities to formally > > specify IMs is to use class diagrams of the Unified Modeling Language > > (UML). > > > > Note that RFC 3444 makes a distinction between informally defined IMs > > (e.g, using natural language) and formally defined IMs (using a > > notational system, i.e, a formalism). > > > > IMs can be defined in an informal way, using natural languages such > > as English. > > > > Alternatively, IMs can be defined using a formal language or a semi- > > formal structured language. > > > > Hence, I am not convinced that RFC 3444 contains an _error_. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > > -- > regards, > John -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 16 09:36:36 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8754912D768 for ; Wed, 16 Mar 2016 09:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 BlRFPfyNVZbr for ; Wed, 16 Mar 2016 09:36:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED19412D751 for ; Wed, 16 Mar 2016 09:36:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGF70316; Wed, 16 Mar 2016 16:36:27 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 16 Mar 2016 16:36:21 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Thu, 17 Mar 2016 00:36:16 +0800 From: Zhoutianran To: John Strassner Thread-Topic: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt Thread-Index: AQHRe8m+iXPvxJK+zky41EQsoOtdw59ZRFyAgAB2IgCAAMnuAIABxryI Date: Wed, 16 Mar 2016 16:36:15 +0000 Message-ID: References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> <56E7D428.5090903@bwijnen.net>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.150] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2183B9D76DNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56E98B8B.02C7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f8accac78737458aa237c5ad6d60248d Archived-At: Cc: "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 16:36:34 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2183B9D76DNKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 TXkgY29uY2VybiBpcyBJIGFtIGFmcmFpZCB3aGVuIEkgYW0gcmVhZGluZyB5b3VyIGRvY3VtZW50 LCBJIGFtIHN0dWR5aW5nIFVNTC4NCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCreivP7IyzogU3VwYSBbc3VwYS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEpv aG4gU3RyYXNzbmVyIFtzdHJhenBkakBnbWFpbC5jb21dDQq3osvNyrG85DogMjAxNsTqM9TCMTbI 1SA1OjI0DQrK1bz+yMs6IEJlcnQgV2lqbmVuIChJRVRGKTsgSm9obiBTdHJhc3NuZXINCrOty806 IEphc29uIENvbGVtYW47IEpvZWwgSGFscGVybjsgc3VwYUBpZXRmLm9yZw0K1vfM4jogUmU6IFtT dXBhXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXN0cmFzc25lci1zdXBhLWdlbmVyaWMtcG9saWN5 LWluZm8tbW9kZWwtMDQudHh0DQoNCkhpIEJlcnQsDQoNCnRoaXMgaXMgYSBnb29kIG9ic2VydmF0 aW9uLiBXZSB3aWxsIGJldHRlciBkb2N1bWVudCB0aGVzZQ0Kc2VtYW50aWNzLiBBbmQgeW91J3Jl IHJpZ2h0LCB0aGVyZSBzaG91bGQgYmUgbm8gbmVlZCBmb3INCnlvdSB0byBzdHVkeSBVTUwuLi4N Cg0KcmVnYXJkcywNCkpvaG4NCg0KT24gVHVlLCBNYXIgMTUsIDIwMTYgYXQgMjoyMSBBTSwgQmVy dCBXaWpuZW4gKElFVEYpIDxid2lldGZAYndpam5lbi5uZXQ8bWFpbHRvOmJ3aWV0ZkBid2lqbmVu Lm5ldD4+IHdyb3RlOg0KT24gMTUvMDMvMTYgMDM6MTgsIEpvaG4gU3RyYXNzbmVyIHdyb3RlOg0K DQogLSBJIHNlZToNCg0KNS4zLjIuNi4yLiBUaGUgQXR0cmlidXRlICJzdXBhUG9sRXhlY0ZhaWxU YWtlQWN0aW9uTmFtZVsxLi5uXSINCg0KICAgIFRoaXMgaXMgYW4gb3B0aW9uYWwgYXJyYXkgb2Yg c3RyaW5nIGF0dHJpYnV0ZXMgdGhhdCBpZGVudGlmaWVzIHRoZQ0KDQogICBNbW1tIGluIHRoZSBw cmlncmFtbWluIGxhbmd1YWdlcyB0aGF0IEkga25vdyAobm90IHRvbyBtYW55IEkgbXVzdCBjb25m ZXNzLA0KICAgYnV0IHN0aWxsIG11bHRpcGxlKSwgYXJyYXlzIGFyZSBpbmRleGVkIGZyb20gWzAu Lm4tMV0uIFNPIEkgd29uZGVyIGlmIHRoaXMgY291bGQNCiAgIGxlYWQgdG8gbWlzLXVuZGVyc3Rh bmRpbmdzIGFuZC9vciBwcm9ncmFtbWluZyBlcnJvcnMuDQoNCiAgICBsYXRlciBvbiB5b3UgdXNl IFswLi5uXSwgc28gbWF5YmUgdGhpcyBpcyBqdXN0IGEgdHlwby4NCjxqY3M+DQpCb3RoIGFyZSBV TUwtZXNlIGZvciBkZWZpbmluZyBhIGNvbGxlY3Rpb247IGl0IGlzIG5vdCByZWZlcnJpbmcgdG8g aW5kZXhpbmcgYW4gYXJyYXkNCjwvamNzPg0KDQpNbW1tIEkgSSBndWVzcyBJIGRlbW9uc3RyYXRl ZCwgbXkga25vd2xlZGdlIGFib3V0IFVNTCBpcw0KdmVyeSBsaW1pdGVkLiBCdXQgd2hlbiBJIHNl ZSB0aGF0IG5vdGF0aW9uLCBhbmQgdGhlIG5leHQgc2VudGVuY2UNCmlzOiBUaGlzIGlzIGFuIG9w dGlvbmFsIGFycmF5IG9mIHN0cmluZyBhdHRyaWJ1dGVzIHRoYXQgaWRlbnRpZmllcyB0aGUNClRo ZW4gaXMgaXQganVzdCBtZSB3aG8gdGhpbmtzIHRoYXQgWzEuLm5dIGluZGljYXRlcyB0aGUgaW5k ZXgNCmludG8gdGhlIGFycmF5PyBNYXliZSBzZSwgdGhlbiBwbHMgaWdub3JlLiBJZiB0aGVyZSBh cmUgb3RoZXJzDQp3aG8gd2VyZSBwdXQgb24gdGhlIHdyb25nIGZvb3RpbmcgYnkgdGhhdCwgdGhl biBwbHMgc3BlYWsgdXAsDQpiZWNhdXNlIHRoZW4gbWF5YmUgd2Ugc2hvdWxkIG1ha2UgaXQgY2xl YXJlci4NCg0KQnV0IHN0aWxsLCBpbiBzb21lIGNhc2VzIHlvdSB1c2UgWzEuLm5dIGFuZCBpbiBv dGhlciBjYXNlcyBbMC4ubl0NClNvIGlzIHRoZXJlIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHRob3Nl IDIsIGFuZCBpZiBzbywgd2hhdCBpcyBpdD8NClBscyBkb2N1bWVudCAodW5sZXNzIHRoaXMgaXMg YWxsIDEwMCUgY2xlYXIgdG8gVU1MIGZvbGssIHRoZW4NCm1heWJlIEkgc2hvdWxkIGp1c3Qgc3R1 ZHkgVU1MIGZpcnN0OyBJIGhvcGUgbm90IHRob3VnaCkNCg0KQmVydA0KDQoNCg0KDQotLQ0KcmVn YXJkcywNCkpvaG4NCg== --_000_BBA82579FD347748BEADC4C445EA0F2183B9D76DNKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

My concern is I am afraid when I am reading your document= , I am studying UML.

 

 

 

=B7=A2=BC=FE=C8=CB: Supa [supa-bounces@iet= f.org] =B4=FA=B1=ED John Strassner [strazpdj@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA3=D4=C216=C8=D5 5:24
=CA=D5=BC=FE=C8=CB: Bert Wijnen (IETF); John Strassner
=B3=AD=CB=CD: Jason Coleman; Joel Halpern; supa@ietf.org
=D6=F7=CC=E2: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-gener= ic-policy-info-model-04.txt

Hi Bert,

this is a good observation. We will better document these
semantics. And you're right, there should be no need for
you to study UML...

regards,
John

On Tue, Mar 15, 2016 at 2:21 AM, Bert Wijnen (IE= TF) <bwietf@bwijnen.= net> wrote:
On 15/03/16 03:18, John Strassner wrote:

 - I see:

5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]"
    This is an optional array of string attributes that identifie= s the

   Mmmm in the prigrammin languages that I know (not too many I m= ust confess,
   but still multiple), arrays are indexed from [0..n-1]. SO I wo= nder if this could
   lead to mis-understandings and/or programming errors.

    later on you use [0..n], so maybe this is just a typo.
<jcs>
Both are UML-ese for defining a collection; it is not referring to indexing= an array
</jcs>

Mmmm I I guess I demonstrated, my knowledge about UML is
very limited. But when I see that notation, and the next sentence
is: This is an optional array of string attributes that identifies the
Then is it just me who thinks that [1..n] indicates the index
into the array? Maybe se, then pls ignore. If there are others
who were put on the wrong footing by that, then pls speak up,
because then maybe we should make it clearer.

But still, in some cases you use [1..n] and in other cases [0..n]
So is there a difference between those 2, and if so, what is it?
Pls document (unless this is all 100% clear to UML folk, then
maybe I should just study UML first; I hope not though)

Bert




--
regards,
John
--_000_BBA82579FD347748BEADC4C445EA0F2183B9D76DNKGEML515MBXchi_-- From nobody Wed Mar 16 09:41:02 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA2912D548 for ; Wed, 16 Mar 2016 09:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 wG-VVcxtT1-3 for ; Wed, 16 Mar 2016 09:40:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9BCC12D518 for ; Wed, 16 Mar 2016 09:40:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGF70715; Wed, 16 Mar 2016 16:40:56 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 16 Mar 2016 16:40:55 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 17 Mar 2016 00:40:49 +0800 From: Zhoutianran To: John Strassner , "supa@ietf.org" Thread-Topic: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt Thread-Index: AQHRe8m+iXPvxJK+zky41EQsoOtdw59ZRFyAgABRjoCAAOh2gIABzlL8 Date: Wed, 16 Mar 2016 16:40:49 +0000 Message-ID: References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> <20160315071049.GA18078@elstar.local>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.150] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2183B9D77DNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56E98C98.01B8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f8accac78737458aa237c5ad6d60248d Archived-At: Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 16:41:00 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2183B9D77DNKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIGxlYXJuIHdoYXQgbWFrZXMgYSBmb3JtYWwgbGFuZ3VhZ2UuDQoNCklm IElNIGNhbm5vdCBiZSBmb3JtYWxseSBzcGVjaWZpZWQgdXNpbmcgVU1MLCB0aGVuIGluIHdoYXQg d2F5IHdlIGNhbiBmb3JtYWxseSBkZXNjcmliZSB0aGUgSU0/DQoNCg0KDQpUaGFua3MsDQoNClRp YW5yYW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogU3VwYSBb c3VwYS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEpvaG4gU3RyYXNzbmVyIFtzdHJhenBkakBnbWFp bC5jb21dDQq3osvNyrG85DogMjAxNsTqM9TCMTbI1SA1OjAyDQrK1bz+yMs6IEp1ZXJnZW4gU2No b2Vud2FlbGRlcjsgSm9obiBTdHJhc3NuZXI7IEJlcnQgV2lqbmVuIChJRVRGKTsgSmFzb24gQ29s ZW1hbjsgSm9lbCBIYWxwZXJuOyBzdXBhQGlldGYub3JnDQrW98ziOiBSZTogW1N1cGFdIEZ3ZDog SS1EIEFjdGlvbjogZHJhZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5mby1tb2Rl bC0wNC50eHQNCg0KUkZDMzQ0NCBzYXlzOg0KICAiT25lIG9mIHRoZSBwb3NzaWJpbGl0aWVzIHRv IGZvcm1hbGx5IHNwZWNpZnkgSU1zIGlzIHRvIHVzZSBjbGFzcw0KICAgZGlhZ3JhbXMgb2YgdGhl IFVuaWZpZWQgTW9kZWxpbmcgTGFuZ3VhZ2UgKFVNTCkuIg0KDQpTaW5jZSBVTUwgaXMgKipub3Qq KiBhIGZvcm1hbCBsYW5ndWFnZSwgaXQgaXMgdGhlcmVmb3JlIGFuIGVycm9yDQp0byBzdGF0ZSB0 aGF0IGFuIElNIGNhbiBiZSBmb3JtYWxseSBzcGVjaWZpZWQgdXNpbmcgVU1MDQoNCk9uIFR1ZSwg TWFyIDE1LCAyMDE2IGF0IDEyOjEwIEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29i cy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQpPbiBNb24sIE1hciAxNCwgMjAxNiBhdCAwNzoxODo1 NVBNIC0wNzAwLCBKb2huIFN0cmFzc25lciB3cm90ZToNCg0KPiA8amNzPg0KPiBJIHVzZWQgUkZD MzE5OCBiZWNhdXNlIFJGQzM0NDQgZG9lcyBub3QgcHJvdmlkZSBhIGRlZmluaXRpb247IGl0IHBy b3ZpZGVzDQo+IGEgZGlzY3Vzc2lvbi4gSW4gYWRkaXRpb24sIGl0IGNvbnRhaW5zIHNvbWUgZXJy b3JzIChlLmcuLCBpdCBzYXlzIHRoYXQgVU1MDQo+IGlzIGENCj4gImZvcm1hbCBsYW5ndWFnZSIs IHdoaWNoIGlzIGluY29ycmVjdC4NCj4NCj4gSG93ZXZlciwgeW91ciBzdWdnZXN0aW9uIGlzIGEg Z29vZCBvbmUgLSB3ZSB3aWxsIHdvcmsgaW4gYSByZWZlcmVuY2Ugb2YNCj4gUkZDMzQ0NCBzb21l d2hlcmUuLi4NCj4gPC9qY3M+DQoNClJGQyAzNDQ0IHNheXM6DQoNCiAgIFsuLi5dIE9uZSBvZiB0 aGUgcG9zc2liaWxpdGllcyB0byBmb3JtYWxseQ0KICAgc3BlY2lmeSBJTXMgaXMgdG8gdXNlIGNs YXNzIGRpYWdyYW1zIG9mIHRoZSBVbmlmaWVkIE1vZGVsaW5nIExhbmd1YWdlDQogICAoVU1MKS4N Cg0KTm90ZSB0aGF0IFJGQyAzNDQ0IG1ha2VzIGEgZGlzdGluY3Rpb24gYmV0d2VlbiBpbmZvcm1h bGx5IGRlZmluZWQgSU1zDQooZS5nLCB1c2luZyBuYXR1cmFsIGxhbmd1YWdlKSBhbmQgZm9ybWFs bHkgZGVmaW5lZCBJTXMgKHVzaW5nIGENCm5vdGF0aW9uYWwgc3lzdGVtLCBpLmUsIGEgZm9ybWFs aXNtKS4NCg0KICAgSU1zIGNhbiBiZSBkZWZpbmVkIGluIGFuIGluZm9ybWFsIHdheSwgdXNpbmcg bmF0dXJhbCBsYW5ndWFnZXMgc3VjaA0KICAgYXMgRW5nbGlzaC4NCg0KICAgQWx0ZXJuYXRpdmVs eSwgSU1zIGNhbiBiZSBkZWZpbmVkIHVzaW5nIGEgZm9ybWFsIGxhbmd1YWdlIG9yIGEgc2VtaS0N CiAgIGZvcm1hbCBzdHJ1Y3R1cmVkIGxhbmd1YWdlLg0KDQpIZW5jZSwgSSBhbSBub3QgY29udmlu Y2VkIHRoYXQgUkZDIDM0NDQgY29udGFpbnMgYW4gX2Vycm9yXy4NCg0KL2pzDQoNCi0tDQpKdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODc8dGVsOiUyQjQ5JTIwNDIxJTIwMjAwJTIwMzU4Nz4g ICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0 OSA0MjEgMjAwIDMxMDM8dGVsOiUyQjQ5JTIwNDIxJTIwMjAwJTIwMzEwMz4gICAgICAgICA8aHR0 cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCg0KDQotLQ0KcmVnYXJkcywNCkpvaG4N Cg== --_000_BBA82579FD347748BEADC4C445EA0F2183B9D77DNKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I would like to learn what makes a formal language.

If IM cannot be formally specified using UML, then in what way we can fo= rmally describe the IM?

 

Thanks,

Tianran 

=B7=A2=BC=FE=C8=CB: Supa [supa-bounces@iet= f.org] =B4=FA=B1=ED John Strassner [strazpdj@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA3=D4=C216=C8=D5 5:02
=CA=D5=BC=FE=C8=CB: Juergen Schoenwaelder; John Strassner; Bert Wijn= en (IETF); Jason Coleman; Joel Halpern; supa@ietf.org
=D6=F7=CC=E2: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-gener= ic-policy-info-model-04.txt

RFC3444 says:
  "One of the possibilities to formally specify IMs is to us= e class
   diagrams of the Unified Modeling Language (UML)."

Since UML is **not** a formal language, it is therefore an error
to state that an IM can be formally specified using UML

On Tue, Mar 15, 2016 at 12:10 AM, Juergen Schoen= waelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Mar 14, 2016 at 07:18:55PM -0700, John Strassner wrote:

> <jcs>
> I used RFC3198 because RFC3444 does not provide a definition; it provi= des
> a discussion. In addition, it contains some errors (e.g., it says that= UML
> is a
> "formal language", which is incorrect.
>
> However, your suggestion is a good one - we will work in a reference o= f
> RFC3444 somewhere...
> </jcs>

RFC 3444 says:

   [...] One of the possibilities to formally
   specify IMs is to use class diagrams of the Unified Modeling L= anguage
   (UML).

Note that RFC 3444 makes a distinction between informally defined IMs
(e.g, using natural language) and formally defined IMs (using a
notational system, i.e, a formalism).

   IMs can be defined in an informal way, using natural languages= such
   as English.

   Alternatively, IMs can be defined using a formal language or a= semi-
   formal structured language.

Hence, I am not convinced that RFC 3444 contains an _error_.

/js

--
Juergen Schoenwaelder           Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 2= 8759 Bremen | Germany
Fax:   +49 421 200 3103      &= nbsp;  <http://www.jacobs-university.de/>



--
regards,
John
--_000_BBA82579FD347748BEADC4C445EA0F2183B9D77DNKGEML515MBXchi_-- From nobody Wed Mar 16 09:51:02 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE1212D9C3 for ; Wed, 16 Mar 2016 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9fr4ewXHvGwS for ; Wed, 16 Mar 2016 09:50:56 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F9212D65D for ; Wed, 16 Mar 2016 09:50:56 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id h198so23727369lfh.0 for ; Wed, 16 Mar 2016 09:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=z2+EMUu8scRVrLzoyFm1ZkgSOU0q7h3Y48CBMpJrpZY=; b=X/yDwL+N9NXX/Ich61MLmPuRRuyT+lCIDLLNFnUbFfMwgcnYMgbvGevn+eBoFKBUTo jnHtOgm8UCWERW+9v8RARbuklsgw5tmJDq/hzWH/kjrqaAnSAkp4pZM6zDtu+2dn3v13 /FG9TI4w4oOqMxCLepXZE9AJR7voYb6TbCWQnx2CcUTp5QKVWDMhgfXiGeSTGpV1l8Lc FKmRnhGpNVfhaFFc0U5Ih0NUlsC2+R4r5/VNY+34FEujQovf+A60nhOJMJy73R4Dq6wl zzVOCvIw0Cik8gw7DeHGcZ3DuOYZCpWcTBRVHrhAxjyObXoYiPtKZ9GoysbW/opu4FMU FRJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=z2+EMUu8scRVrLzoyFm1ZkgSOU0q7h3Y48CBMpJrpZY=; b=j8wzV/DzLB+jqhI7FPPO1+FKXXwcGmG6x7IqjbF+bTc7ZqG1h5/au6KHqc+aY9g5NC jwRkNQr7fXIX2x3Ah6ykPC85RaXP53YalAtuwyZL8+HTyYAuLMj8CuAKWTKWaE3CnW45 AIIV5dHbqCVzb7qUsRCuxbngiTOpr4iyADLgjXi98aSacWPW8A/OcTSUMQZo1GTUG5qO bD1PB42AQxwM7gcmwId++rsmFMosKljzBzVTTZbTbjMCJSXiaZ6nyflgWC5DK52bW5x6 7wQOE6Z/W5S5+xR6wY85AIK6oQU8kvFhJtBedlXE1UuRLxdX3jPsRfoqJO8Jv8458bzY gXKA== X-Gm-Message-State: AD7BkJInjN9zH3+NNikNKj6lwVNDjy5LplXOTtNkOn1q4lEL6zjEbdBK4Ijw060xETxpe9BcfroCQlM4rISECg== MIME-Version: 1.0 X-Received: by 10.25.18.158 with SMTP id 30mr1950188lfs.16.1458147054551; Wed, 16 Mar 2016 09:50:54 -0700 (PDT) Received: by 10.25.156.76 with HTTP; Wed, 16 Mar 2016 09:50:54 -0700 (PDT) In-Reply-To: References: <20160212190950.963.98316.idtracker@ietfa.amsl.com> <56BE4E09.3010402@joelhalpern.com> <56E31829.1080208@bwijnen.net> <56E7D428.5090903@bwijnen.net> Date: Wed, 16 Mar 2016 09:50:54 -0700 Message-ID: From: John Strassner To: Zhoutianran Content-Type: multipart/alternative; boundary=001a113f1fe037a262052e2d510f Archived-At: Cc: "supa@ietf.org" Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 16:50:59 -0000 --001a113f1fe037a262052e2d510f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That could apply to sections 3.2.3 and 3.3 specifically; otherwise, I fail to understand your concern. On Wed, Mar 16, 2016 at 9:36 AM, Zhoutianran wrote= : > My concern is I am afraid when I am reading your document, I am studying > UML. > > > > > > > ------------------------------ > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Supa [supa-bounces@ietf.org] =E4=BB=A3=E8= =A1=A8 John Strassner [strazpdj@gmail.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2016=E5=B9=B43=E6=9C=8816=E6=97= =A5 5:24 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Bert Wijnen (IETF); John Strassner > *=E6=8A=84=E9=80=81:* Jason Coleman; Joel Halpern; supa@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: [Supa] Fwd: I-D Action: > draft-strassner-supa-generic-policy-info-model-04.txt > > Hi Bert, > > this is a good observation. We will better document these > semantics. And you're right, there should be no need for > you to study UML... > > regards, > John > > On Tue, Mar 15, 2016 at 2:21 AM, Bert Wijnen (IETF) > wrote: > >> On 15/03/16 03:18, John Strassner wrote: >> >>> >>> - I see: >>> >>> 5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]" >>> >>> This is an optional array of string attributes that identifies the >>> >>> Mmmm in the prigrammin languages that I know (not too many I must >>> confess, >>> but still multiple), arrays are indexed from [0..n-1]. SO I wonder i= f >>> this could >>> lead to mis-understandings and/or programming errors. >>> >>> later on you use [0..n], so maybe this is just a typo. >>> >>> Both are UML-ese for defining a collection; it is not referring to >>> indexing an array >>> >>> >> >> Mmmm I I guess I demonstrated, my knowledge about UML is >> very limited. But when I see that notation, and the next sentence >> is: This is an optional array of string attributes that identifies the >> Then is it just me who thinks that [1..n] indicates the index >> into the array? Maybe se, then pls ignore. If there are others >> who were put on the wrong footing by that, then pls speak up, >> because then maybe we should make it clearer. >> >> But still, in some cases you use [1..n] and in other cases [0..n] >> So is there a difference between those 2, and if so, what is it? >> Pls document (unless this is all 100% clear to UML folk, then >> maybe I should just study UML first; I hope not though) >> >> Bert >> >> > > > -- > regards, > John > --=20 regards, John --001a113f1fe037a262052e2d510f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That could apply to sections 3.2.3 and 3.3 specifical= ly; otherwise, I
fail to understand your concern.

On Wed, Mar 16, 2016 = at 9:36 AM, Zhoutianran <zhoutianran@huawei.com> wrote:=

My concern is I=C2=A0am afraid=C2=A0when=C2=A0I am reading your document= ,=C2=A0I am=C2=A0studying UML.

=C2=A0

=C2=A0

=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: Supa [supa-bounces@ietf.org] =E4=BB=A3=E8=A1= =A8 John Strassner [strazpdj@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B43=E6=9C=8816=E6= =97=A5 5:24
=E6=94=B6=E4=BB=B6=E4=BA=BA: Bert Wijnen (IETF); John Strassner
=E6=8A=84=E9=80=81: Jason Coleman; Joel Halpern; supa@ietf.org
=E4=B8=BB=E9=A2=98: Re: [Supa] Fwd: I-D Action: draft-strassner-supa= -generic-policy-info-model-04.txt

Hi Bert,

this is a good observation. We will better document these
semantics. And you're right, there should be no need for
you to study UML...

regards,
John

On Tue, Mar 15, 2016 at 2:21 AM, Bert Wijnen (IE= TF) <bwietf@bwijnen.= net> wrote:
On 15/03/16 03:18, John Strassner wrote:

=C2=A0- I see:

5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]"
=C2=A0 =C2=A0 This is an optional array of string attributes that identifie= s the

=C2=A0 =C2=A0Mmmm in the prigrammin languages that I know (not too many I m= ust confess,
=C2=A0 =C2=A0but still multiple), arrays are indexed from [0..n-1]. SO I wo= nder if this could
=C2=A0 =C2=A0lead to mis-understandings and/or programming errors.

=C2=A0 =C2=A0 later on you use [0..n], so maybe this is just a typo.
<jcs>
Both are UML-ese for defining a collection; it is not referring to indexing= an array
</jcs>

Mmmm I I guess I demonstrated, my knowledge about UML is
very limited. But when I see that notation, and the next sentence
is: This is an optional array of string attributes that identifies the
Then is it just me who thinks that [1..n] indicates the index
into the array? Maybe se, then pls ignore. If there are others
who were put on the wrong footing by that, then pls speak up,
because then maybe we should make it clearer.

But still, in some cases you use [1..n] and in other cases [0..n]
So is there a difference between those 2, and if so, what is it?
Pls document (unless this is all 100% clear to UML folk, then
maybe I should just study UML first; I hope not though)

Bert




--
regards,
John



--
regards,
John
--001a113f1fe037a262052e2d510f-- From nobody Thu Mar 17 03:08:15 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB98512D559 for ; Thu, 17 Mar 2016 03:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com 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 0C66aFR7UJDf for ; Thu, 17 Mar 2016 03:08:10 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA7F12D81D for ; Thu, 17 Mar 2016 03:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1458209289; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=vyRQX4Wl18zaaKga7/ypMMlM4VKhmqb9I3HK6xYdiMg=; b=k1uIbQOIHtEmGPNhrVWScOfKGTmKNJGqJLX6Q3ASdaZFsyS62kDKpeJScMaUNjVRvfzn5rk1gRdespirYdGDWdWHBs04p/q6d4YtuQ/eKQGapWb0zmv3YoRYRcyzAZmA4IhBJvRmq2XjsBI+jRPdljFJGc8U3QuzL2IH03nGVRs= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R351e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03311; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; TI=SMTPD_----4cLYBmy_1458209283; Received: from 10.32.179.29(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.16) by smtp.aliyun-inc.com(127.0.0.1); Thu, 17 Mar 2016 18:08:06 +0800 User-Agent: Microsoft-MacOutlook/14.6.0.151221 Date: Thu, 17 Mar 2016 18:08:03 +0800 From: "Dacheng Zhang" To: "supa@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-vadrevu-supa-applicability-06.txt References: <20160317100611.19448.17726.idtracker@ietfa.amsl.com> In-Reply-To: <20160317100611.19448.17726.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: [Supa] FW: New Version Notification for draft-vadrevu-supa-applicability-06.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 10:08:14 -0000 Hi=A3=AC We have updated our capability draft. It would be great if you could have a look and tell us your comments. Really appreciated. Cheers Dacheng =D4=DA 16-3-17 =CF=C2=CE=E76:06=A3=AC "internet-drafts@ietf.org" = =D0=B4 =C8=EB: > >A new version of I-D, draft-vadrevu-supa-applicability-06.txt >has been successfully submitted by Dacheng Zhang and posted to the >IETF repository. > >Name: draft-vadrevu-supa-applicability >Revision: 06 >Title: Applicability of SUPA >Document date: 2016-03-17 >Group: Individual Submission >Pages: 26 >URL: =20 >https://www.ietf.org/internet-drafts/draft-vadrevu-supa-applicability-06.t >xt >Status: =20 >https://datatracker.ietf.org/doc/draft-vadrevu-supa-applicability/ >Htmlized: =20 >https://tools.ietf.org/html/draft-vadrevu-supa-applicability-06 >Diff: =20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-vadrevu-supa-applicability-06 > >Abstract: > SUPA will define a generic policy model, an imperative ECA (Event > Condition Action) policy information model and a declarative (intent- > based) policy information model which is the extension of the generic > model, and a set of policy data models which will make use of the > common concepts defined in the generic model. This memo will explore > some typical use cases and demonstrate the applicability of SUPA > policy models. > > > =20 > =20 > > >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 nobody Fri Mar 18 01:02:00 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E50E12D883 for ; Fri, 18 Mar 2016 01:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 ZVD8cK73fzms for ; Fri, 18 Mar 2016 01:01:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F10912D6AC for ; Fri, 18 Mar 2016 01:01:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGH42098; Fri, 18 Mar 2016 08:01:53 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Mar 2016 08:01:50 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Fri, 18 Mar 2016 16:01:43 +0800 From: Zhoutianran To: "supa@ietf.org" Thread-Topic: suggest to remove some redundancy Thread-Index: AdGA7CACjN0ghWE3QJOBrPzMizshzg== Date: Fri, 18 Mar 2016 08:01:42 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.195] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2183B9DFD9NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56EBB5F2.003C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 53a509f48fb8d74055e3c392cbccfac1 Archived-At: Subject: [Supa] suggest to remove some redundancy X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 08:01:58 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2183B9DFD9NKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 V2hlbiBJIHJlYWQgImRyYWZ0LXN0cmFzc25lci1zdXBhLWdlbmVyaWMtcG9saWN5LWluZm8tbW9k ZWwtMDQiLCBJIGZvdW5kIHNvbWUgYWNyb255bXMgYXJlIHJlcGVhdGx5IGV4cGxhaW5lZC4NCg0K Rm9yIGV4YW1wbGUsIHRoZSBHZW5lcmljIFBvbGljeSBJbmZvcm1hdGlvbiBNb2RlbCAoR1BJTSks IGFuZCBFQ0EgUG9saWN5IFJ1bGUgSW5mb3JtYXRpb24gTW9kZWwgKEVQUklNKS4NCg0KSSB0aGlu ayB0aGUgYWNyb255bXMgIGNvdWxkIGJlIG9ubHkgY2xhaW1lZCBvbmUgb3IgdHdpY2UuIEl0J3Mg ZW5vdWdoLg0KDQpUaG91Z2gsIHRoaXMgaXMgbWlub3IuDQoNCg0KDQpUaWFucmFuDQo= --_000_BBA82579FD347748BEADC4C445EA0F2183B9DFD9NKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

When I read "draft-strassner-supa-generic-policy-info-model-04"= ;, I found some acronyms are repeatly explained.

For example, the Generic Policy Information Model (GPIM), and ECA Policy= Rule Information Model (EPRIM).

I think the acronyms  could be only claimed one or twice. It's= enough.

Though, this is minor. 

 

Tianran

--_000_BBA82579FD347748BEADC4C445EA0F2183B9DFD9NKGEML515MBXchi_-- From nobody Fri Mar 18 01:32:28 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B625412D6D6 for ; Fri, 18 Mar 2016 01:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 qTZATr6egpuM for ; Fri, 18 Mar 2016 01:32:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4853112D6F1 for ; Fri, 18 Mar 2016 01:32:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKY58667; Fri, 18 Mar 2016 08:32:22 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Mar 2016 08:32:21 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Fri, 18 Mar 2016 16:32:17 +0800 From: Zhoutianran To: John Strassner Thread-Topic: about the query operation//RE: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt Thread-Index: AQHRgPCtKwd4BAeUU0GBXoetJbIbUQ== Date: Fri, 18 Mar 2016 08:32:16 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.124] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2183B9E019NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56EBBD16.0102, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0ac8aa1d4c6dd408ad3b1d7538254c25 Archived-At: Cc: "supa@ietf.org" Subject: [Supa] about the query operation//RE: Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 08:32:27 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2183B9E019NKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 IC0gcGFnZSAxNDoNCg0KICAgIEluIHRoaXMgY29udGV4dCwgIm1hbmFnZSIgbWVhbnMgdGhhdCBh dCBsZWFzdCBjcmVhdGUsIHJlYWQsDQogICAgcXVlcnksIHVwZGF0ZSwgYW5kIGRlbGV0ZSBmdW5j dGlvbnMgYXJlIHN1cHBvcnRlZC4NCg0KICAgSXMgdGhlcmUgYSBkaWZmZXJlbmNlIGJldHdlZW4g InJlYWQiIGFuICJxdWVyeSINCiAgIGlzIENSVUQgbm90IGVub3VnaD8NCg0KPGpjcz4NCiJSZWFk IiBpcywgYXQgbGVhc3QgdG8gbWUsIGEgc2ltcGxlIGNvbW1hbmQgdG8gcHJvdmlkZSBhIHJlc3Vs dC4gSW4gY29udHJhc3QsDQoiUXVlcnkiIGlzIGEgbW9yZSBjb21wbGV4IG9wZXJhdGlvbiB0aGF0 IG1heSBpbnZvbHZlIHByZS0gYW5kL29yIHBvc3QtDQpwcm9jZXNzaW5nIG9mIHRoZSByZXN1bHRz IG9mIHRoZSBvcGVyYXRpb24uDQoNCk5vdGUgdGhhdCBtYW55IHBlb3BsZSB0aGluayBvZiBTUUwg YXMgYSBxdWVyeSBsYW5ndWFnZTsgaW4gdGhhdCBjYXNlLCB0aGUNCmRlZmluaXRpb24gb2YgcXVl cnkgZXhwYW5kcyB0byBpbmNsdWRlIGRhdGEgZGVmaW5pdGlvbiwgZGF0YSBjb250cm9sLCBhbmQg ZGF0YQ0KbWFuaXB1bGF0aW9uIGxhbmd1YWdlcy4NCg0KV291bGQgeW91IGxpa2UgdGhlIGFib3Zl IHRleHQgaW5jbHVkZWQ/DQo8L2pjcz4NCg0KSGVyZSBJIGFtIHN0aWxsIG5vdCBjbGVhciBhYm91 dCB0aGUgcXVlcnkgb3BlcmF0aW9uLg0KSSB0aGluayBTUUwgaXMgYXMgYSAgcXVlcnkgbGFuZ3Vh Z2UgYmVjb3VzZSB0aGUgbWFqb3IgZmVhdHVyZSBpcyBxdWVyeS4gQW5kIGFmdGVyIGFsbCBpdCdz IG9ubHkgdGhlIG5hbWUgb2YgYSBsYW5nYWdlLg0KSXQgZG9lcyBub3QgbWVhbiBxdWVyeSBpbmNs dWRlcyBkYXRhIGRlZmluaXRpb24sIGRhdGEgY29udHJvbCwgYW5kIGRhdGEgbWFuaXB1bGF0aW9u Lg0KDQpDb21lIHRvIHRoaXMgZHJhZnQsIGRvIHlvdSBoYXZlIGFueSBjb25jcmV0ZSBleGFtcGxl IHRvIHNob3cgd2hhdCB5b3Ugc3VwcG9zZSB0byBkbyBmb3IgdGhlIHF1ZXJ5IG9wZXJhdGlvbj8N Cg0KDQoNCi0tVGlhbnJhbg0K --_000_BBA82579FD347748BEADC4C445EA0F2183B9E019NKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 - page 14:

    In this context, "manage" means that at lea= st create, read,
    query, update, and delete functions are supported.

   Is there a difference between "read" an "que= ry"
   is CRUD not enough?

<jcs>
"Read" is, at least to me, a simple command to provide a result. = In contrast,
"Query" is a more complex operation that may involve pre- and/or = post-
processing of the results of the operation.


Note that many people think of SQL as a query language; in that case, the definition of query expands to include data definition, data control, and d= ata
manipulation languages.


Would you like the above text included?
</jcs>


Here I am still not clear about the query operation.
I think SQL is as a  query language becouse the major feature is query= . And after all it's only the name of a langage.
It does not mean query includes data definition, data control, and data man= ipulation.

Come to this draft, do you have any concrete example to show what you su= ppose to do for the query operation?

 

--Tianran 

--_000_BBA82579FD347748BEADC4C445EA0F2183B9E019NKGEML515MBXchi_-- From nobody Mon Mar 21 13:53:57 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFD212DB46 for ; Mon, 21 Mar 2016 13:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 SlDzQCDrhYCy for ; Mon, 21 Mar 2016 13:53:53 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3A512D90A for ; Mon, 21 Mar 2016 13:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458593633; x=1490129633; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=be2ch0zeIJidNLj0rEb8BXveV3DtICojG1iSfVwVFF4=; b=Iy1BWZFVzyGnLR2UtC7u7WWEGrq29fcJLFjOEO1k/pFV3AQEUdp1kUw/ jXo26+23dRnycxgbL3fXkztA7ICXHJubqgiEP+7VYyeeobB1/+8r2Lo7v m9hYePpG0ubl3kZVpZLIPFSAwI+KpwMNxfWwJ7XigJ50/FrEiePbgu9ia hCVKrigTRNAp6Fhk03SsFWzclrPq+m93Cjw3wxkybcrCtwgoQ2oP7o34k 0g99M0is1XH4K4piNAfLVRtv2sBWJAkLaPT6TqZkCZwyoXeK08/ZOw+WN 0S3T/0/phr6RXxOVHYofruzLiSTTjS9Of6rjhpMT9DUFczvaXd1iXHhhh w==; X-IronPort-AV: E=Sophos;i="5.24,373,1454929200"; d="scan'208";a="75620493" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.7 - Outgoing - Outgoing-SSL Received: from sc-cs-316051.uoa.auckland.ac.nz (HELO [130.216.38.7]) ([130.216.38.7]) by mx4-int.auckland.ac.nz with ESMTP; 22 Mar 2016 09:53:48 +1300 From: Nevil Brownlee To: SUPA list Message-ID: <56F05F52.6090907@auckland.ac.nz> Date: Tue, 22 Mar 2016 09:53:38 +1300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Supa] Agenda for IETF 95, Buenos Aires (first draft) X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:53:56 -0000 Hi all: Here's the first draft of our agenda. Please send me any changes/improvements/etc. If you have drafts you would like to present, let us (supa-chairs@ietf.org ) know about those too. Cheers, Nevil ================================================== Simplified Use of Policy Abstractions WG (supa) Agenda for IETF 95, Buenos Aires (agenda-00) Friday, 8 April 2016, 1220-1320, Atlantico C ================================================== Chairs: Nevil Brownlee Daniel King AGENDA: 1. Note Well, Agenda review, Scribes = 3 min 2. Update from last meeting / WG Status (Nevil) = 3 min - Call for adoption issued for Policy Model - We need to decide on other drafts to adopt 3. Current charter work items = 35 min a) Generic Policy INformation Model draft-strassner-supa-generic-policy-info-model-04.txt b) Management Framework draft ? c) YANG model draft(s) ? d) Applicability of SUPA draft-vadrevu-supa-applicability-06 4. Discussion: which drafts to adopt as WG items? = 10 min 5. Milestones update = 6. Any Other Business = 9 min Presentation slides will be available at https://datatracker.ietf.org/meeting/95/materials.html (search for SUPA in the Operations and Management Area) Remote participation is offered via meetecho and also via jabber at supa@jabber.ietf.org, -- --------------------------------------------------------------------- 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 nobody Mon Mar 21 15:19:20 2016 Return-Path: X-Original-To: supa@ietf.org Delivered-To: supa@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A217112D109; Mon, 21 Mar 2016 15:10:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321221028.12227.24824.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 15:10:28 -0700 Archived-At: X-Mailman-Approved-At: Mon, 21 Mar 2016 15:19:19 -0700 Cc: supa@ietf.org Subject: [Supa] I-D Action: draft-strassner-supa-generic-policy-info-model-05.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 22:10:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simplified Use of Policy Abstractions of the IETF. Title : Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA) Authors : John Strassner Joel Halpern Jason Coleman Filename : draft-strassner-supa-generic-policy-info-model-05.txt Pages : 115 Date : 2016-03-21 Abstract: This document defines an information model for representing policies using a common extensible framework that is independent of language, protocol, repository. It is also independent of the level of abstraction of the content and meaning of a policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-strassner-supa-generic-policy-info-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-strassner-supa-generic-policy-info-model-05 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 19:47:51 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAB612D583 for ; Mon, 21 Mar 2016 19:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 qIiKsXzbgY2W for ; Mon, 21 Mar 2016 19:47:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8611D12D1DB for ; Mon, 21 Mar 2016 19:47:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLB88889; Tue, 22 Mar 2016 02:47:45 +0000 (GMT) Received: from SZXEMA415-HUB.china.huawei.com (10.82.72.33) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 22 Mar 2016 02:47:44 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.235]) by SZXEMA415-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0235.001; Tue, 22 Mar 2016 10:47:39 +0800 From: "Liushucheng (Will)" To: "supa@ietf.org" Thread-Topic: New Version Notification for draft-klyus-supa-value-proposition-00.txt Thread-Index: AQHRg28z+IpTspTmrkacOwMLF6zOLZ9kwZeg Date: Tue, 22 Mar 2016 02:47:39 +0000 Message-ID: References: <20160321124253.31915.72571.idtracker@ietfa.amsl.com> In-Reply-To: <20160321124253.31915.72571.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56F0B251.01A7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.235, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3a5a0001b24789e143b4bed133c29cfe Archived-At: Cc: "draft-klyus-supa-value-proposition@tools.ietf.org" Subject: [Supa] FW: New Version Notification for draft-klyus-supa-value-proposition-00.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 02:47:50 -0000 SGkgYWxsLA0KDQpCYXNlZCBvbiB0aGUgY29tbWVudHMgZnJvbSBwcmV2aW91cyBJRVRGIGFuZCBv ZmZsaW5lIGRpc2N1c3Npb25zLCBhbmQgdGhhbmtzIHRvIGNvLWF1dGhvcnMnIGVmZm9ydHMsIHdl IGp1c3QgdXBkYXRlZCB0aGUgcHJvcG9zaXRpb24gZHJhZnQuIFRoaXMgb25lIGZvcm1hbGx5IHJl cGxhY2VkIHRoZSB0d28gcHJldmlvdXMgZHJhZnRzOiANCmRyYWZ0LWtseXVzLXN1cGEtcHJvcG9z aXRpb24tMDIgYW5kIGRyYWZ0LWthcmFnaWFubmlzLXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQtMDcg Lg0KDQpZb3VyIHJldmlldyBhbmQgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KDQpSZWdhcmRz LA0KV2lsbCAoU2h1Y2hlbmcgTElVKQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDIxLCAyMDE2IDg6NDMgUE0NCj4gVG86 IExpdXNodWNoZW5nIChXaWxsKTsgTWF4aW0gS2x5dXM7IExpdXNodWNoZW5nIChXaWxsKTsgSnVu IEJpOyBKb2huIFN0cmFzc25lcjsNCj4gR2Vvcmdpb3MgS2FyYWdpYW5uaXMNCj4gU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rbHl1cy1zdXBhLXZhbHVlLXByb3Bv c2l0aW9uLTAwLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1rbHl1 cy1zdXBhLXZhbHVlLXByb3Bvc2l0aW9uLTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFdpbGwoU2h1Y2hlbmcpIExpdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+ IHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQta2x5dXMtc3VwYS12YWx1ZS1wcm9wb3Np dGlvbg0KPiBSZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlTVVBBIFZhbHVlIFByb3Bvc2l0aW9uDQo+ IERvY3VtZW50IGRhdGU6CTIwMTYtMDMtMjENCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCj4gUGFnZXM6CQkyMA0KPiBVUkw6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1rbHl1cy1zdXBhLXZhbHVlLXByb3Bvc2l0aW9uLTAwLnR4dA0KPiBTdGF0 dXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtseXVzLXN1cGEt dmFsdWUtcHJvcG9zaXRpb24vDQo+IEh0bWxpemVkOg0KPiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQta2x5dXMtc3VwYS12YWx1ZS1wcm9wb3NpdGlvbi0wMA0KPiANCj4gDQo+IEFi c3RyYWN0Og0KPiAgICBTaW1wbGlmaWVkIFVzZSBvZiBQb2xpY3kgQWJzdHJhY3Rpb25zIChTVVBB KSBkZWZpbmVzIGEgc2V0IG9mIHJ1bGVzDQo+ICAgIHRoYXQgZGVmaW5lIGhvdyBzZXJ2aWNlcyBh cmUgZGVzaWduZWQsIGRlbGl2ZXJlZCwgYW5kIG9wZXJhdGVkDQo+ICAgIHdpdGhpbiBhbiBvcGVy YXRvcidzIGVudmlyb25tZW50IGluZGVwZW5kZW50IG9mIGFueSBvbmUgcGFydGljdWxhcg0KPiAg ICBzZXJ2aWNlIG9yIG5ldHdvcmtpbmcgZGV2aWNlLiBTVVBBIGV4cHJlc3NlcyBwb2xpY3kgcnVs ZXMgdXNpbmcgYQ0KPiAgICBnZW5lcmljIHBvbGljeSBpbmZvcm1hdGlvbiBtb2RlbCwgd2hpY2gg c2VydmVzIGFzIGEgdW5pZnlpbmcNCj4gICAgaW5mbHVlbmNlIHRvIGVuYWJsZSBkaWZmZXJlbnQg ZGF0YSBtb2RlbCBpbXBsZW1lbnRhdGlvbnMgdG8gYmUNCj4gICAgc2ltdWx0YW5lb3VzbHkgZGV2 ZWxvcGVkLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Mar 22 02:36:12 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEA212D728 for ; Tue, 22 Mar 2016 02:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 me-4yaApojEJ for ; Tue, 22 Mar 2016 02:36:09 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205BF12D715 for ; Tue, 22 Mar 2016 02:36:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EB12B24EB6E for ; Tue, 22 Mar 2016 02:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1458639368; bh=q0+aq/KJtYAKlBTBsvTZZoG3MyZQm6kMVWbD5qWmPYY=; h=Subject:References:To:From:Date:In-Reply-To:From; b=NVlJlBCN2mgVttbycZ/bSJYDFZWhKFMoOZYHR7XaYJwquqS9n+6eECCkjrHH3tFT5 50Y6uTxdH9OeLCrsb7X2HObG4SFa+ns3uD1hRZAfN7DMxhbxC/gkXYcEC8u6sSTzhX C8GTBU6oC49JrZt7DzeqmzQdRqCDTscg419inJwc= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.126.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 7166E24EB61 for ; Tue, 22 Mar 2016 02:36:08 -0700 (PDT) References: <20160321214729.12231.44280.idtracker@ietfa.amsl.com> To: SUPA list From: Joel Halpern X-Forwarded-Message-Id: <20160321214729.12231.44280.idtracker@ietfa.amsl.com> Message-ID: <56F11206.5000504@joelhalpern.com> Date: Tue, 22 Mar 2016 05:36:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160321214729.12231.44280.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Supa] Fwd: I-D Action: draft-halpern-supa-generic-policy-data-model-00.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 09:36:10 -0000 John and I have put together a YANG data model derived from teh generic information model. Our apologies for the lack of explanatory text. We know we need to explain the structuring we used. We felt it was more important to make sure we got the YANG proposal to the working group in time for discussion before the meeting. Due to this, please assume that the explanations of all of the items would reflect the explanations in the information model, and use those explanations to understand these YANG groupings and containers. Two pieces of structural explanation: groupings with uses, and identities with based, are used to reflect inheritance from the information model. Containers of lists which use a grouping are used to contain instances of any classes from the information model which are to be concrete. We will add the other necessary items, including a tree diagram. Please, review and comment, Thank you, Joel Halpern (and John Strassner) -------- Forwarded Message -------- Subject: I-D Action: draft-halpern-supa-generic-policy-data-model-00.txt Date: Mon, 21 Mar 2016 14:47:29 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generic Policy Data Model for Simplified Use of Policy Abstractions (SUPA) Authors : Joel Halpern John Strassner Filename : draft-halpern-supa-generic-policy-data-model-00.txt Pages : 38 Date : 2016-03-21 Abstract: This document defines two YANG policy data models. The first is a generic policy model that is meant to be extended on an application- specific basis. The second is an exemplary extension of the first generic policy model, and defines rules as event-condition-action policies. Both models are independent of the level of abstraction of the content and meaning of a policy. From nobody Thu Mar 24 04:59:40 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D9212DAC6 for ; Thu, 24 Mar 2016 04:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, URIBL_BLACK=1.7] autolearn=no 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 ssV1RQQfK7LH for ; Thu, 24 Mar 2016 04:59:32 -0700 (PDT) Received: from out1-mx3.spamav.net (out1-mx3.spamav.net [213.163.77.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D065312DAC5 for ; Thu, 24 Mar 2016 04:59:31 -0700 (PDT) Received: from ns13.i3d.net ([213.163.76.137] helo=web13.i3d.net) by mx3.spamav.net with esmtps (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1aj3uu-0007JH-AP; Thu, 24 Mar 2016 12:59:28 +0100 Received: from [42.118.113.71] (helo=dxhia.com) by web13.i3d.net with esmtpsa (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.76) (envelope-from ) id 1aj3Cg-0004UL-W7; Thu, 24 Mar 2016 12:13:28 +0100 From: sfc-bounces@ietf.org To: "supa" , "Dhruv Dhody" , "Huaimo Chen" , "Vishnu Pavan Beeram" Date: Thu, 24 Mar 2016 14:13:32 +0300 Message-ID: <00001809c984$787214c8$702df2f8$@queuefull.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_24910E13.0EB35461" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdGIJB48+WKb6aaoWr+zHcTXr8fV1w== Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIYtRSRjxTq5Mv87j1YVhgu9bPEHsGmdeaLBA3n7ijN60Wywi3RPeT3mN b5O6yuT+gRYYBPTMeW7ADWP7vMN84CA3WiAPA8C+OQAtLj/ALU/rYQ0ljSajgtrpfyeEM64W1pSi 4qQ/vetGL30881HFA622Ll/8FJZI9IaGVljW4dtjooF9y5SuD7YZ/RqKuJDvA2vE/5tF8hfQUskO g+24f5/3bgzlnCGAmFfhzoZLyjh6Ja72NMA711Oy3hJvE+c3dgHlIR1vSn9CIxhTcAUSV34cuOJs a9gROWgGu8Lbq+Un0KWSJ1pKbTvQJheYLNAJTBv6sxFSY8ZeoCOFU89Qrt5Qoy+pfH8m9oHEUeLi WXgb2oo18KxP73vkeXQJ2uMPcgTSFwn/obMQpbfw0TRWajLaJodd864y11pbLWKfKrEf77c3ZeHl M8GJiisYJeqnM0fSiANMM0QlS90CyiTdnACq3kunSshyLlLBrZu6QBErdKfGyzdPVflT8opF67oF yqwzxIm2sFoIU8t16Vsvj1REA3XB6ozDErHpyu4Pzjw3OwaTiEVDMso+kscaN/cwncOz8KeMGK5A oc3isMD6nfn1JH2vQ/tMeiYvwOI8L9OMT25oOwg+Q701xXZRZ2LutroNaizZ97DFriJGDOL3NDX6 Gew4jH22624bXqDj0nE6iOaA1gsYqEZoFfxz/AGf5KwJHvzC2ARNECAcoP1ici4= X-Report-Abuse-To: spam@mx1.spamav.net X-Filter-Fingerprint: IFrWXGses7OKB5S5G8/dJRn/7L7+nnclbWGk7OJ1jHJA3cTUQ1R++keuE7RDJ8Kg3RbMLUalw1oC mj99/u+PoqoVy8a3lsStJtAvpObFX0Wok1JBYnOLzfRIhlEHQynLUpndEJ0YoaLytXXo8BMTaVt0 ARHRi6XGuAluI1udprFy32DUYpEhA3j9NJFmItfypuoazoDH3m92PL21GfhFYWcYmGLKZUTyGy/B A6iJtsD8WFC+rpTT4JYvoDjVeZUw3fI9smEy0EupqfCN6sn6Zg== X-Originating-IP: 213.163.76.137 X-i3D.net-Domain: auth.web13.i3d.net X-i3D.net-Username: 213.163.76.137 Authentication-Results: spamav.net; auth=pass smtp.auth=213.163.76.137@auth.web13.i3d.net X-i3D.net-Outgoing-Class: unsure X-i3D.net-Outgoing-Evidence: Combined (0.71) X-Recommended-Action: accept Archived-At: Subject: [Supa] Fw: new important message X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 11:59:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_24910E13.0EB35461 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello! New message, please read sfc-bounces@ietf.org ------=_NextPart_000_0001_24910E13.0EB35461 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= span lang=3DEN-US>Hello!

 

New message, please read http://vidtimeonline.azurewe= bsites.net/mean.php

 

sfc-bounces@ietf.org

------=_NextPart_000_0001_24910E13.0EB35461-- From nobody Fri Mar 25 00:10:24 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E7612D159 for ; Fri, 25 Mar 2016 00:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 31uu4Sv0hCJq for ; Fri, 25 Mar 2016 00:10:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017D612DBBB for ; Fri, 25 Mar 2016 00:10:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLF58068; Fri, 25 Mar 2016 07:10:10 +0000 (GMT) Received: from LHREML502-MBS.china.huawei.com ([10.125.30.101]) by lhreml707-cah.china.huawei.com ([10.201.5.199]) with mapi id 14.03.0235.001; Fri, 25 Mar 2016 07:10:04 +0000 From: Georgios Karagiannis To: Nevil Brownlee Thread-Topic: request for presentation time slot: RE: [Supa] Agenda for IETF 95, Buenos Aires (first draft) Thread-Index: AQHRg7PWY3D7zA7rrk2TAu6x+gBJVZ9pwosA Date: Fri, 25 Mar 2016 07:10:03 +0000 Message-ID: References: <56F05F52.6090907@auckland.ac.nz> In-Reply-To: <56F05F52.6090907@auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.84.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.56F4E453.002C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8b17d17bed799ad2063af521bf1f2c29 Archived-At: Cc: SUPA list Subject: [Supa] request for presentation time slot: RE: Agenda for IETF 95, Buenos Aires (first draft) X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 07:10:23 -0000 Hi Nevil, Hi all, Please note that I will need a time slot of approx. 20 minutes to present t= he following Internet draft: SUPA Value Proposition http://www.ietf.org/id/draft-klyus-supa-value-proposition-00.txt Best regards, Georgios -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Nevil Brownlee Sent: Monday, March 21, 2016 9:54 PM To: SUPA list Subject: [Supa] Agenda for IETF 95, Buenos Aires (first draft) Hi all: Here's the first draft of our agenda. Please send me any changes/improvements/etc. If you have drafts you would like to present, let us (supa-chairs@ietf.org = ) know about those too. Cheers, Nevil =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Simplified Use of Policy Abstractions WG (supa) Agenda for IETF 95, Buenos = Aires (agenda-00) Friday, 8 April 2016, 1220-1320, Atlantico C =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Chairs: Nevil Brownlee Daniel King AGENDA: 1. Note Well, Agenda review, Scribes =3D 3 min 2. Update from last meeting / WG Status (Nevil) =3D 3 min - Call for adoption issued for Policy Model - We need to decide on other drafts to adopt 3. Current charter work items =3D 35 min a) Generic Policy INformation Model draft-strassner-supa-generic-policy-info-model-04.txt b) Management Framework draft ? c) YANG model draft(s) ? d) Applicability of SUPA draft-vadrevu-supa-applicability-06 4. Discussion: which drafts to adopt as WG items? =3D 10 min 5. Milestones update =3D 6. Any Other Business =3D 9 min Presentation slides will be available at https://datatracker.ietf.org/meeting/95/materials.html (search for SUPA in the Operations and Management Area) Remote participation is offered via meetecho and also via jabber at supa@jabber.ietf.org, -- --------------------------------------------------------------------- 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 _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Mon Mar 28 00:59:11 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAC212D5B9 for ; Mon, 28 Mar 2016 00:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 P8XiokryTeXL for ; Mon, 28 Mar 2016 00:59:08 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id F222812D0DE for ; Mon, 28 Mar 2016 00:59:07 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R361e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03310; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; TI=SMTPD_----4eLmHeT_1459151939; Received: from 10.62.3.92(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.26) by smtp.aliyun-inc.com(127.0.0.1); Mon, 28 Mar 2016 15:59:03 +0800 User-Agent: Microsoft-MacOutlook/14.6.0.151221 Date: Mon, 28 Mar 2016 15:58:57 +0800 From: "Dacheng Zhang" To: Nevil Brownlee , SUPA list Message-ID: Thread-Topic: [Supa] Agenda for IETF 95, Buenos Aires (first draft) References: <56F05F52.6090907@auckland.ac.nz> In-Reply-To: <56F05F52.6090907@auckland.ac.nz> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Supa] Agenda for IETF 95, Buenos Aires (first draft) X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 07:59:10 -0000 Hi=A3=AC Thanks a lot for including our draft into the agenda. We are very happy to present our applicability draft of SUPA in the session. Can we get 15 minutes? Cheers Dacheng =D4=DA 16-3-22 =C9=CF=CE=E74:53=A3=AC "Supa on behalf of Nevil Brownlee" =D0=B4=C8=EB: > >Hi all: > >Here's the first draft of our agenda. > >Please send me any changes/improvements/etc. > >If you have drafts you would like to present, let us >(supa-chairs@ietf.org ) know >about those too. > >Cheers, Nevil > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Simplified Use of Policy Abstractions WG (supa) >Agenda for IETF 95, Buenos Aires (agenda-00) >Friday, 8 April 2016, 1220-1320, Atlantico C >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Chairs: >Nevil Brownlee >Daniel King > >AGENDA: > >1. Note Well, Agenda review, Scribes =3D 3 min > >2. Update from last meeting / WG Status (Nevil) =3D 3 min > - Call for adoption issued for Policy Model > - We need to decide on other drafts to adopt > >3. Current charter work items =3D 35 min > a) Generic Policy INformation Model > draft-strassner-supa-generic-policy-info-model-04.txt > > b) Management Framework draft ? > > c) YANG model draft(s) ? > > d) Applicability of SUPA > draft-vadrevu-supa-applicability-06 > >4. Discussion: which drafts to adopt as WG items? =3D 10 min > >5. Milestones update =3D > >6. Any Other Business =3D 9 min > >Presentation slides will be available at > https://datatracker.ietf.org/meeting/95/materials.html > (search for SUPA in the Operations and Management Area) > >Remote participation is offered via meetecho > and also via jabber at supa@jabber.ietf.org, > >--=20 >--------------------------------------------------------------------- > 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 > >_______________________________________________ >Supa mailing list >Supa@ietf.org >https://www.ietf.org/mailman/listinfo/supa From nobody Tue Mar 29 02:49:47 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8385212D5C1 for ; Tue, 29 Mar 2016 02:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 NtoaEB_ZDTHV for ; Tue, 29 Mar 2016 02:49:45 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C413712D115 for ; Tue, 29 Mar 2016 02:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2726; q=dns/txt; s=iport; t=1459244982; x=1460454582; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=kLcnoIRB1eW0Hqh03AR7e6MvT8GajkSEdeRXO/alKes=; b=I0fPCeDHuQm13bdyRx4SSvMPqAcMEs3mTQ9RqHd375Uh1awMqyUWzGuC oEZ7H6IVVSz4dpasgYh+aXF7J59SEx04WDuTmRttpDKaZZCpxWa9IHI/m oC5x8UsuF6qhtwpKl1ssY0UV8TDFixGa6B2SvhJYgr7pF4i0r5gFZKV8O o=; X-IronPort-AV: E=Sophos;i="5.24,410,1454976000"; d="scan'208";a="636620160" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2016 09:49:41 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u2T9nem8012925; Tue, 29 Mar 2016 09:49:41 GMT To: Joel Halpern , SUPA list References: <20160321214729.12231.44280.idtracker@ietfa.amsl.com> <56F11206.5000504@joelhalpern.com> From: Benoit Claise Message-ID: <56FA4FB4.4020600@cisco.com> Date: Tue, 29 Mar 2016 11:49:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56F11206.5000504@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Carl Moberg \(camoberg\)" Subject: Re: [Supa] Fwd: I-D Action: draft-halpern-supa-generic-policy-data-model-00.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 09:49:46 -0000 Hi Joel, It seems that the YANG model is broken. At least, we can't extract it from the draft. xym.py draft-halpern-supa-generic-policy-data-model-00bis.txt ERROR: 'draft-halpern-supa-generic-policy-data-model-00bis.txt', - EOF encountered while parsing the model No models created. Out of the curiosity, have you seen the similar error message when you posted the draft? Regards, Benoit > John and I have put together a YANG data model derived from teh > generic information model. > > Our apologies for the lack of explanatory text. We know we need to > explain the structuring we used. We felt it was more important to > make sure we got the YANG proposal to the working group in time for > discussion before the meeting. > > Due to this, please assume that the explanations of all of the items > would reflect the explanations in the information model, and use those > explanations to understand these YANG groupings and containers. > > Two pieces of structural explanation: > groupings with uses, and identities with based, are used to reflect > inheritance from the information model. > Containers of lists which use a grouping are used to contain instances > of any classes from the information model which are to be concrete. > > We will add the other necessary items, including a tree diagram. > > Please, review and comment, > Thank you, > Joel Halpern (and John Strassner) > > -------- Forwarded Message -------- > Subject: I-D Action: draft-halpern-supa-generic-policy-data-model-00.txt > Date: Mon, 21 Mar 2016 14:47:29 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Generic Policy Data Model for Simplified Use > of Policy Abstractions (SUPA) > Authors : Joel Halpern > John Strassner > Filename : draft-halpern-supa-generic-policy-data-model-00.txt > Pages : 38 > Date : 2016-03-21 > > Abstract: > This document defines two YANG policy data models. The first is a > generic policy model that is meant to be extended on an application- > specific basis. The second is an exemplary extension of the first > generic policy model, and defines rules as event-condition-action > policies. Both models are independent of the level of abstraction of > the content and meaning of a policy. > > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > . > From nobody Tue Mar 29 06:56:41 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BDA12D106 for ; Tue, 29 Mar 2016 06:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 JhVyrBsRGMjC for ; Tue, 29 Mar 2016 06:56:38 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D3212D1A9 for ; Tue, 29 Mar 2016 06:56:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9DAFC2A062C; Tue, 29 Mar 2016 06:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1459259797; bh=cZQFEMqZfdUTqW1jj0PFR+MurFal4lUifTryfCpRbnk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=oACzTmgncHSxTVpidwhbnBZndXTxPkJaziVAV487bd4301KzNz/N3cFs/18bpKUvk 5CRELzDCGn05O7ychUa9URv45BJ2y7MBT6kjFmXfvZmJ6r5S5sYJupJOz6sHaK2H4x Bwchu4m9IbDtmXmYlNXISWO5Zzi8dgjzzLlK+e3M= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E99692A05AE; Tue, 29 Mar 2016 06:56:36 -0700 (PDT) To: Benoit Claise , Joel Halpern , SUPA list References: <20160321214729.12231.44280.idtracker@ietfa.amsl.com> <56F11206.5000504@joelhalpern.com> <56FA4FB4.4020600@cisco.com> From: "Joel M. Halpern" Message-ID: <56FA898C.6070907@joelhalpern.com> Date: Tue, 29 Mar 2016 09:56:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56FA4FB4.4020600@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Carl Moberg \(camoberg\)" Subject: Re: [Supa] Fwd: I-D Action: draft-halpern-supa-generic-policy-data-model-00.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 13:56:40 -0000 No, we did not see that error when the draft was run against pyang. There were some errors around the must expressions, but that seemed to relate to it being yang 1.1. We were pressed for time and did not explore that aspect further. Yours, Joel On 3/29/16 5:49 AM, Benoit Claise wrote: > Hi Joel, > > It seems that the YANG model is broken. At least, we can't extract it > from the draft. > > xym.py draft-halpern-supa-generic-policy-data-model-00bis.txt > ERROR: 'draft-halpern-supa-generic-policy-data-model-00bis.txt', File> - EOF encountered while parsing the model > No models created. > > Out of the curiosity, have you seen the similar error message when you > posted the draft? > > Regards, Benoit >> John and I have put together a YANG data model derived from teh >> generic information model. >> >> Our apologies for the lack of explanatory text. We know we need to >> explain the structuring we used. We felt it was more important to >> make sure we got the YANG proposal to the working group in time for >> discussion before the meeting. >> >> Due to this, please assume that the explanations of all of the items >> would reflect the explanations in the information model, and use those >> explanations to understand these YANG groupings and containers. >> >> Two pieces of structural explanation: >> groupings with uses, and identities with based, are used to reflect >> inheritance from the information model. >> Containers of lists which use a grouping are used to contain instances >> of any classes from the information model which are to be concrete. >> >> We will add the other necessary items, including a tree diagram. >> >> Please, review and comment, >> Thank you, >> Joel Halpern (and John Strassner) >> >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-halpern-supa-generic-policy-data-model-00.txt >> Date: Mon, 21 Mar 2016 14:47:29 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Generic Policy Data Model for Simplified Use >> of Policy Abstractions (SUPA) >> Authors : Joel Halpern >> John Strassner >> Filename : draft-halpern-supa-generic-policy-data-model-00.txt >> Pages : 38 >> Date : 2016-03-21 >> >> Abstract: >> This document defines two YANG policy data models. The first is a >> generic policy model that is meant to be extended on an application- >> specific basis. The second is an exemplary extension of the first >> generic policy model, and defines rules as event-condition-action >> policies. Both models are independent of the level of abstraction of >> the content and meaning of a policy. >> >> >> >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> . >> > From nobody Tue Mar 29 11:38:41 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AF312DB19 for ; Tue, 29 Mar 2016 11:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BQyVLnwfqEJV for ; Tue, 29 Mar 2016 11:38:36 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E455F12E0C6 for ; Tue, 29 Mar 2016 11:09:15 -0700 (PDT) Received: by mail-lb0-x22d.google.com with SMTP id vo2so16287691lbb.1 for ; Tue, 29 Mar 2016 11:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5x8isj5sEshMO8ee/SpPE3vglwLGgWmu16bOX/++OLU=; b=UDEcqOnnO7dor6Nv67mbd1H1lkRo682PDEEmaUQp8U+g/vo/1ZK3uKEh86uPohpIug 46U2CWxfcYO6rqlY3FR1XqBTzW50W2z1l4EiWlPhr0BrONXVomvpLebcEdeK1x2HCfzt HeTZBMIPjp3jJaDwpKsA4em7YBKQcaNcrTzoOA3ysB85XwIkRUpZh1jAnWmwlTaS9FS2 WXmENZYskbP1uOy3k7Ss5ThbtUXMtdE62JMxTqFpBdI6TI4Qkacnoi0Tz9/nrpgi9LKr Xq602A2dVO8h2t3xiYyI2rjpq1u6j+IDpCBd3vHhrb7EYoKEwmxzLYyaJlQZPAPCrn8O xhzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5x8isj5sEshMO8ee/SpPE3vglwLGgWmu16bOX/++OLU=; b=AGWHjJUVMaNgSVYXHm8v4pYBiuReZ7hWfh1uPFr6n7gPHVnKVKQy3/v5VpswHg9wSx aPP34a+MYDwfhdnVXdZVSoVIPdVKOPl90NtunzB4OojkzitB6xoQz/XC5EJU8hCB2Aif LVoW4ghSDxgt4RpP90uQSZ5vIH1LkrM7UIAcodaMYBKlB3/qKtmu57jHoocjJWiqeC91 ratPQ2HHp9hATBANvs/NGdPP2iqXDtdyKn+dgiR/k6SY0UHKKReDBLmL6CFTjGeXtZJa HxIB8KJjJNYGBZDFtiIYdC0bO5SuUCsB7Hsargdg802wOde/Ee5wroc5Jw3cQPnv+TTH iB6w== X-Gm-Message-State: AD7BkJKjAfMSG1i4vVkUpowXmgYterkdgjmh5j342/gQDM8rGInSKkInYH9R3nGNhXlL8mQGkzTzKrPcm9q6uQ== MIME-Version: 1.0 X-Received: by 10.112.171.70 with SMTP id as6mr1788124lbc.85.1459274954001; Tue, 29 Mar 2016 11:09:14 -0700 (PDT) Received: by 10.25.22.19 with HTTP; Tue, 29 Mar 2016 11:09:13 -0700 (PDT) In-Reply-To: <56FA898C.6070907@joelhalpern.com> References: <20160321214729.12231.44280.idtracker@ietfa.amsl.com> <56F11206.5000504@joelhalpern.com> <56FA4FB4.4020600@cisco.com> <56FA898C.6070907@joelhalpern.com> Date: Tue, 29 Mar 2016 11:09:13 -0700 Message-ID: From: John Strassner To: "Joel M. Halpern" , John Strassner Content-Type: multipart/alternative; boundary=001a11c38b944353fa052f33ed40 Archived-At: Cc: Benoit Claise , "Carl Moberg \(camoberg\)" , SUPA list Subject: Re: [Supa] Fwd: I-D Action: draft-halpern-supa-generic-policy-data-model-00.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 18:38:39 -0000 --001a11c38b944353fa052f33ed40 Content-Type: text/plain; charset=UTF-8 Hi Benoit, we are working on updating the YANG model. Qin gave some very helpful feedback. We'll try and issue a revision when the submission system opens again. regards, John On Tue, Mar 29, 2016 at 6:56 AM, Joel M. Halpern wrote: > No, we did not see that error when the draft was run against pyang. There > were some errors around the must expressions, but that seemed to relate to > it being yang 1.1. We were pressed for time and did not explore that > aspect further. > > Yours, > Joel > > On 3/29/16 5:49 AM, Benoit Claise wrote: > >> Hi Joel, >> >> It seems that the YANG model is broken. At least, we can't extract it >> from the draft. >> >> xym.py draft-halpern-supa-generic-policy-data-model-00bis.txt >> ERROR: 'draft-halpern-supa-generic-policy-data-model-00bis.txt', > File> - EOF encountered while parsing the model >> No models created. >> >> Out of the curiosity, have you seen the similar error message when you >> posted the draft? >> >> Regards, Benoit >> >>> John and I have put together a YANG data model derived from teh >>> generic information model. >>> >>> Our apologies for the lack of explanatory text. We know we need to >>> explain the structuring we used. We felt it was more important to >>> make sure we got the YANG proposal to the working group in time for >>> discussion before the meeting. >>> >>> Due to this, please assume that the explanations of all of the items >>> would reflect the explanations in the information model, and use those >>> explanations to understand these YANG groupings and containers. >>> >>> Two pieces of structural explanation: >>> groupings with uses, and identities with based, are used to reflect >>> inheritance from the information model. >>> Containers of lists which use a grouping are used to contain instances >>> of any classes from the information model which are to be concrete. >>> >>> We will add the other necessary items, including a tree diagram. >>> >>> Please, review and comment, >>> Thank you, >>> Joel Halpern (and John Strassner) >>> >>> -------- Forwarded Message -------- >>> Subject: I-D Action: draft-halpern-supa-generic-policy-data-model-00.txt >>> Date: Mon, 21 Mar 2016 14:47:29 -0700 >>> From: internet-drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Generic Policy Data Model for Simplified Use >>> of Policy Abstractions (SUPA) >>> Authors : Joel Halpern >>> John Strassner >>> Filename : draft-halpern-supa-generic-policy-data-model-00.txt >>> Pages : 38 >>> Date : 2016-03-21 >>> >>> Abstract: >>> This document defines two YANG policy data models. The first is a >>> generic policy model that is meant to be extended on an application- >>> specific basis. The second is an exemplary extension of the first >>> generic policy model, and defines rules as event-condition-action >>> policies. Both models are independent of the level of abstraction of >>> the content and meaning of a policy. >>> >>> >>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> . >>> >>> >> > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > -- regards, John --001a11c38b944353fa052f33ed40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benoit,

we are working on= updating the YANG model. Qin gave some very helpful feedback. We'll tr= y and issue a revision when the submission system opens again.
regards,
John
=
On Tue, Mar 29, 2016 at 6:56 AM, Joel M. Hal= pern <jmh@joelhalpern.com> wrote:
No, we did not see that error when the draft was run against pyan= g. There were some errors around the must expressions, but that seemed to r= elate to it being yang 1.1.=C2=A0 We were pressed for time and did not expl= ore that aspect further.

Yours,
Joel

On 3/29/16 5:49 AM, Benoit Claise wrote:
Hi Joel,

It seems that the YANG model is broken. At least, we can't extract it from the draft.

xym.py draft-halpern-supa-generic-policy-data-model-00bis.txt
ERROR: 'draft-halpern-supa-generic-policy-data-model-00bis.txt', &l= t;End of
File> - EOF encountered while parsing the model
No models created.

Out of the curiosity, have you seen the similar error message when you
posted the draft?

Regards, Benoit
John and I have put together a YANG data model derived from teh
generic information model.

Our apologies for the lack of explanatory text.=C2=A0 We know we need to explain the structuring we used.=C2=A0 We felt it was more important to
make sure we got the YANG proposal to the working group in time for
discussion before the meeting.

Due to this, please assume that the explanations of all of the items
would reflect the explanations in the information model, and use those
explanations to understand these YANG groupings and containers.

Two pieces of structural explanation:
groupings with uses, and identities with based, are used to reflect
inheritance from the information model.
Containers of lists which use a grouping are used to contain instances
of any classes from the information model which are to be concrete.

We will add the other necessary items, including a tree diagram.

Please, review and comment,
Thank you,
Joel Halpern (and John Strassner)

-------- Forwarded Message --------
Subject: I-D Action: draft-halpern-supa-generic-policy-data-model-00.txt Date: Mon, 21 Mar 2016 14:47:29 -0700
From: interne= t-drafts@ietf.org
Reply-To: int= ernet-drafts@ietf.org
To: i-d-announce= @ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Generic Policy Data Model for Simplified Use
of Policy Abstractions (SUPA)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Joel= Halpern
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Strassner
=C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-halpern-supa-gene= ric-policy-data-model-00.txt
=C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 38
=C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2016-03-21
Abstract:
=C2=A0 =C2=A0This document defines two YANG policy data models. The first i= s a
=C2=A0 =C2=A0generic policy model that is meant to be extended on an applic= ation-
=C2=A0 =C2=A0specific basis. The second is an exemplary extension of the fi= rst
=C2=A0 =C2=A0generic policy model, and defines rules as event-condition-act= ion
=C2=A0 =C2=A0policies. Both models are independent of the level of abstract= ion of
=C2=A0 =C2=A0the content and meaning of a policy.




_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa
.



_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa



--
regards,
John
--001a11c38b944353fa052f33ed40--