Re: [netmod] draft netmod charter update proposal

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
> 