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

"Natale, Bob" <RNATALE@mitre.org> Tue, 08 March 2016 09:21 UTC

Return-Path: <RNATALE@mitre.org>
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 <supa@ietfa.amsl.com>; 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 <supa@ietfa.amsl.com>; 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 <supa@ietf.org>; 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" <RNATALE@mitre.org>
To: Zhoutianran <zhoutianran@huawei.com>, "colemaj@cisco.com" <colemaj@cisco.com>
Thread-Topic: [Supa] Information models and Data models - WG adoption?
Thread-Index: AdF5C9Btf6PL2XwARoWr2zneEGCjlQ==
Date: Tue, 08 Mar 2016 07:26:26 +0000
Message-ID: <CY1PR09MB092298B7E5D80818698BE776A8B20@CY1PR09MB0922.namprd09.prod.outlook.com>
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: <CY1PR09MB092120AB4F76607C30746F32A8B20@CY1PR09MB0921.namprd09.prod.outlook.com>
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: <http://mailarchive.ietf.org/arch/msg/supa/2nR4te_r2hJbLedwQpXqMOA_4tE>
Cc: SUPA list <supa@ietf.org>
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." <supa.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/supa>, <mailto:supa-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/supa/>
List-Post: <mailto:supa@ietf.org>
List-Help: <mailto:supa-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/supa>, <mailto:supa-request@ietf.org?subject=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 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:

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?"

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 view about WHAT to standardize -- i.e., such an approach often has a positive 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 absence of a general 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 discrete 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.

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 <supa@ietf.org>
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 
>model clearly

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

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

Best,
Tianran

> -----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 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 <d.king@lancaster.ac.uk>; Joel M. Halpern 
> ><jmh@joelhalpern.com>; Andy Bierman <andy@yumaworks.com>; John 
> >Strassner <John.sc.Strassner@huawei.com>; Zhoutianran 
> ><zhoutianran@huawei.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  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 <jmh@joelhalpern.com>; Andy Bierman 
> >> <andy@yumaworks.com>; John Strassner <John.sc.Strassner@huawei.com>
> >> Cc: Zhoutianran <zhoutianran@huawei.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?  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 
> >>>>> <John.sc.Strassner@huawei.com 
> >>>>> <mailto: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 
> >>>>> <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 
> >>>>> <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 
> >>>>> <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
> >>>>> <mailto:draft-strassner-supa-generic-policy-info-model@ietf.org>;
> >>>>>      > >> supa-chairs@ietf.org <mailto:supa-chairs@ietf.org>; 
> >>>>> supa@ietf.org <mailto: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 <mailto: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 <mailto:Supa@ietf.org>
> >>>>>      > https://www.ietf.org/mailman/listinfo/supa
> >>>>>
> >>>>>      _______________________________________________
> >>>>>      Supa mailing list
> >>>>>      Supa@ietf.org <mailto:Supa@ietf.org>
> >>>>>      https://www.ietf.org/mailman/listinfo/supa
> >>>>>
> >>>>>      _______________________________________________
> >>>>>      Supa mailing list
> >>>>>      Supa@ietf.org <mailto: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