Re: [netmod] draft netmod charter update proposal

Kent Watsen <kwatsen@juniper.net> Wed, 08 March 2017 00:51 UTC

Return-Path: <kwatsen@juniper.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8580129471; Tue, 7 Mar 2017 16:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 q1QML7GcSkVS; Tue, 7 Mar 2017 16:51:28 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0099.outbound.protection.outlook.com [104.47.42.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEBF126579; Tue, 7 Mar 2017 16:51:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ggs4RJCs0IDCVR9Tq719Nl5YgUdhu3U6qBca2zhFBEY=; b=Z9jCwk2FUYHD+TetpZjhvvF+CtY8B8fiUKOzQYxH2qMkzwuyag9b13gWXv84xjJ3xPnjQE2cz5a4u4ISNWcceq9cVn5angzbXDCiB8aFLTAEL2aodvksfhsWL2mHF4gghs6QbsrezFQfHzdTT9U1cbesbdZwarYmUaNilVJi6ts=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Wed, 8 Mar 2017 00:51:25 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.012; Wed, 8 Mar 2017 00:51:26 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Mehmet Ersue <mersue@gmail.com>, 'Susan Hares' <shares@ndzh.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] draft netmod charter update proposal
Thread-Index: AQHSjWtMgvd1I9y/IUSjVG5c54oSBqGJlI+AgAAfG4CAABJyAIAAIVUA///2HwA=
Date: Wed, 08 Mar 2017 00:51:25 +0000
Message-ID: <24CF7954-A7B3-4550-AFF7-9898EE175FA2@juniper.net>
References: <B6359563-0649-453A-B29F-28375F2BD3A4@juniper.net> <01a101d29757$b405beb0$1c113c10$@ndzh.com> <017401d29767$41970e50$c4c52af0$@gmail.com> <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> <027a01d29781$24d32b40$6e7981c0$@gmail.com>
In-Reply-To: <027a01d29781$24d32b40$6e7981c0$@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:PGduqYjfB6hL2WOOoHiiYcUeXWZdpEwnPF15I2RmWBb8LyM1CVT+iDkv1RlOISgJvRpLPDmt23Tnltq43bJl5g54qMPQnepPWBMd3iWA/bfsYcoEu0utkVv9EnSVjSA5kmV/CTTj9S88NQtn8cYUvwbQtyN5KeA3zRRDqaJ16mCzTbX3fxV9aMkQwSTjM3qRWH6nwaNPv32xMom1RD140enwWFi56Q89yTss3YwRse7c/DFQ32SIFOoYZ8JixsiUlMo7NKRJVHFc23AK21sOd5ktycoc+SzHkI59DG+L9F6A74WLx59MWFac/wN3dOQsHaIxQBhZGc03WO6Bmz3HJA==
x-ms-office365-filtering-correlation-id: 27483886-7ce3-4f2a-58c8-08d465bd3fe0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1441;
x-microsoft-antispam-prvs: <BN3PR0501MB1441C3A709031FED939242C1A52E0@BN3PR0501MB1441.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(35073007944872)(138986009662008)(95692535739014)(50582790962513);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441;
x-forefront-prvs: 02408926C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(51444003)(377454003)(13464003)(45074003)(305945005)(6116002)(8936002)(81166006)(8676002)(102836003)(93886004)(122556002)(3660700001)(54356999)(106116001)(50986999)(3846002)(3280700002)(76176999)(2501003)(86362001)(4001350100001)(5660300001)(66066001)(345774005)(2906002)(189998001)(36756003)(7736002)(83716003)(77096006)(33656002)(6246003)(6306002)(4326008)(53546006)(82746002)(53936002)(229853002)(99286003)(25786008)(2900100001)(15650500001)(6506006)(6436002)(39060400002)(6512007)(561944003)(2950100002)(83506001)(6486002)(38730400002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5004217CBC2623459565796936D805DB@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 00:51:25.9255 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/oH5R9etHBFt9aHsQu6hybP6Fly0>
Cc: "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>
Subject: Re: [netmod] draft netmod charter update proposal
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Mar 2017 00:51:31 -0000

Hi Sue,

First, please be aware that the next version of revised-datastores
draft further defines the control-plane datastore concept.  This
includes providing guidelines that other WGs can follow to define
their own control-plane datastores, and includes an Appendix section
outlining the creation of an "ephemeral" datastore.  The idea is
to give the I2RS WG the ability to define datastore(s) as needed 
(read: future I2RS WG drafts).

Regarding:

> Does c) and d) include additions to include I2RS ephemeral state
> as part of an I2RS control plane protocol?   If not, which WG
> works on the I2RS ephemeral additions to Yang for control plane
> data stores?

I don't fully understand the question, but believe that the NETMOD
activities needed to support I2RS are all covered by a), b), and c).
Things that belong to NETCONF WG will include any needed changes to
protocol, YANG-Library, or any other draft maintained by that WG.
Everything else goes to I2RS.

I'm not sure what Mehmet means by a "joint session", but I think
that it's too late to add such a session to the IETF Agenda at 
this point.  That said, I plan a schedule another datastore 
breakout session (likely on Wed morning) that could be used to
discuss I2RS some, and I also plan on attending the I2RS meeting
Wed afternoon.  

Kent


-----ORIGINAL MESSAGE-----

Sounds good as a first approximation. Though we need to discuss the details
and agree.
It might be useful to plan a joint session on Tue or Wed in Chicago.

Cheers,
Mehmet

> -----Original Message-----
> From: Susan Hares [mailto:shares@ndzh.com]
> Sent: Tuesday, March 7, 2017 7:27 PM
> To: 'Mehmet Ersue' <mersue@gmail.com>; 'Kent Watsen'
> <kwatsen@juniper.net>; netmod@ietf.org
> Cc: netmod-chairs@ietf.org
> Subject: RE: [netmod] draft netmod charter update proposal
> 
> Mehmet:
> 
> Thank you for the excellent question clarifying my questions.  My
questions
> (b) - related to protocol extension for I2RS for RESTCONF, NETCONF or
CoAP.
> I have removed that one.
> 
> I restate my question below, and the [xx] indicates my understanding.
> 
> Does c and d state the following are handled:
> 1) informational concepts for the DS handling - [Netmod]
> 2) generic extensions to Yang to describe control plane datastore yang
> modules - [netmod]
> 3) generic extensions to Yang to describe the ephemeral state in control
> plane yang modules - [I2RS]
> 4) I2RS specific extensions to support the I2RS control plane datastore's
> validation - [I2RS]
> 5) Any I2RS Yang modules- [I2RS]
> 
> To provide precision on this point, I will give examples of work related
to
> each question:
> 1)  draft-ietf-netmod-revised-datastores-00.txt   [netmod]
> 2) extensions to describe control plane data store yang modules:
>    a) control plane data store definitions added to
draft-ietf-netmod-yang-
> model-classification [netmod]
>    b) extensions to the Yang 1.1 - to provide a syntax to describe
datastores in
> which a module exists
>        datastore should include syntax to identify identity and
prioritization
> config data store. [netmod]
>    c) extension to describe the merged tree in applied datastore and
opstate
> datastore  [netmod]
>    d) mount extensions that allow mounting modules in different datastores
> 
> 3) generic extensions to describe ephemeral state the I2RS control plane
> datastore  [I2RS]
>      a) extensions can define validation specific to I2RS control plane
> datastore.
>      b) rpc can be used for validation of modules
>         that seek to mounted in either the I2RS control plane datastore or
the
> configuration data store.
> 
> 4) I2RS specific extensions to support I2RS features in the I2RS control
plane
> data store.
> 
> My earlier: - is a question for NETCONF/RESTCONF, or CoAP.
> b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF)
>    to enable the usage of DS - [protocol group or WG]
> 
> 
> Sue
> 
> 
> -----Original Message-----
> From: Mehmet Ersue [mailto:mersue@gmail.com]
> Sent: Tuesday, March 7, 2017 12:21 PM
> To: 'Susan Hares'; 'Kent Watsen'; netmod@ietf.org
> Cc: netmod-chairs@ietf.org
> Subject: RE: [netmod] draft netmod charter update proposal
> 
> Hi Sue,
> 
> AFAICS your question kind of mixes between "I2RS control plane protocol"
> and "ephemeral additions to Yang".
> I believe different WGs are responsible for the part they own.
> E.g. protocol-specific part should be done in the WG owning the protocol.
> 
> Can you please differentiate in your question between the aspects below
> (my assumption in [ ]?
> a) informational concept for the DS handling [netmod]
> b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) to
> enable the usage of DS [protocol WGs, e.g. I2RS]
> c) generic extensions to YANG language usable by many protocols [netmod]
> d) any specific YANG modules necessary for the use of DS [protocols WGs]
> 
> BR,
> Mehmet
> 
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan
> Hares
> > Sent: Tuesday, March 7, 2017 4:30 PM
> > To: 'Kent Watsen' <kwatsen@juniper.net>; netmod@ietf.org
> > Cc: netmod-chairs@ietf.org
> > Subject: Re: [netmod] draft netmod charter update proposal
> >
> > Kent and Lou:
> >
> > Clarifying questions:
> >
> > Does c) and d) include additions to include I2RS ephemeral state as
> > part
> of
> > an I2RS control plane protocol?      If not, which WG works on the I2RS
> > ephemeral additions to Yang for control plane data stores?
> >
> > Sue
> >
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent
> Watsen
> > Sent: Wednesday, February 22, 2017 7:25 PM
> > To: netmod@ietf.org
> > Cc: netmod-chairs@ietf.org
> > Subject: [netmod] draft netmod charter update proposal
> >
> >
> > Hi NETMOD WG,
> >
> > Please find below the draft charter update which we provided to our AD
> > for review.  Comments are welcomed.  Authors, please note the
> > milestone dates.
> >
> > Kent (and Lou)
> >
> >
> >
> >
> > Network Modeling (NETMOD)
> > -------------------------
> >
> > Charter
> >
> > Current Status: Active
> >
> > Chairs:
> >    Lou Berger <lberger@labn.net>
> >    Kent Watsen <kwatsen@juniper.net>
> >
> > Operations and Management Area Directors:
> >    Benoit Claise <bclaise@cisco.com>
> >    Joel Jaeggli <joelja@bogus.com>
> >
> > Operations and Management Area Advisor:
> >    Benoit Claise <bclaise@cisco.com>
> >
> > Secretary:
> >    Zitao (Michael) Wang <wangzitao@huawei.com>
> >
> > Mailing Lists:
> >    General Discussion: netmod@ietf.org
> >    To Subscribe:       https://www.ietf.org/mailman/listinfo/netmod
> >    Archive:            https://mailarchive.ietf.org/arch/browse/netmod/
> >
> > Description of Working Group:
> >
> >    The Network Modeling (NETMOD) working group is responsible for the
> > YANG
> >    data modeling language, and guidelines for developing YANG models.
> The
> >    NETMOD working group addresses general topics related to the use of
> the
> >    YANG language and YANG models, for example, the mapping of YANG
> > modeled
> >    data into various encodings.  Finally, the NETMOD working group also
> >    defines core YANG models used as basic YANG building blocks, and YANG
> >    models that do not otherwise fall under the charter of any other IETF
> >    working group.
> >
> > The NETMOD WG is responsible for:
> >
> >    a) Maintaining the data modeling language YANG.  This effort entails
> >       periodically updating the specification to address new
requirements
> >       as they arise.
> >
> >    b) Maintaining the guidelines for developing YANG models.  This
effort
> >       is primarily driven by updates made to the YANG specification.
> >
> >    c) Maintaining a conceptual framework in which YANG models are used.
> >       This effort entails describing the context that network management
> >       protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, and
> >       how certain YANG statements interact in that context.
> >
> >    d) Maintaining encodings for YANG modeled data.  This effort entails
> >       updating encodings already defined by the NETMOD working (XML and
> >       JSON) to accommodate changes to the YANG specification, and
defining
> >       new encodings that are needed and yet do not fall under the
charter
> >       of any other active IETF working group.
> >
> >    e) Maintaining YANG models used as basic YANG building blocks.  This
> >       effort entails updating existing YANG models (ietf-yang-types and
> >       ietf-inet-types) as needed, as well as defining additional core
YANG
> >       data models when necessary.
> >
> >    f) Defining and maintaining YANG models that do not fall under the
> >       charter of any other active IETF working group.
> >
> >    The NETMOD working group consults with the NETCONF working group to
> >    ensure that new requirements are and understood and can be met by
> >    the protocols developed within that working group (e.g., NETCONF
> >    and RESTCONF).  The NETMOD working group coordinates with other
> >    working groups on possible extensions to YANG to address new modeling
> >    requirements and, when needed, which group will run the process on a
> >    specific model.
> >
> >    The NETMOD working group does not serve as a review team for YANG
> >    modules developed by other working groups. Instead, the YANG doctors,
> >    as organized by the OPS area director responsible for network
> >    management, will act as advisors for other working groups and provide
> >    YANG reviews for the OPS area directors.
> >
> > Milestones:
> >
> >    Done     - Submit draft-ietf-netmod-rfc6087bis to IESG for
publication
> >    Mar 2016 - Submit draft-ietf-netmod-yang-model-classification to IESG
> >               for publication
> >    Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for
> publication
> >    Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for publication
> >    Mar 2017 - Submit draft-ietf-netmod-entity to IESG for publication
> >    Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for
> >               publication
> >    Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for
> publication
> >    Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for
> >               publication
> >    Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for
> >               publication
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>