Re: [netmod] draft netmod charter update proposal

Lou,

I don't understand the plan change.
We were discussing to have time for a joint charter discussion in Chicago.

Any decision/agreement in a physical WG session will be verified on the maillist.
In any case once we are finished on the maillist, Benoit will review both together.
The two charters from NETCONF/NETMOD have to go hand in hand and one cannot be approved by IESG before the other.

Mehmet

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, March 8, 2017 7:18 PM
> To: Mehmet Ersue <mersue@gmail.com>; 'Kent Watsen'
> <kwatsen@juniper.net>; 'Susan Hares' <shares@ndzh.com>;
> netmod@ietf.org
> Cc: netmod-chairs@ietf.org
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> Hi Mehmet/Sue,
> 
> Our (NETMOD chair's) plan is to have had sufficient on-list discussion so that
> we can submit the updated charter to the IESG *before* the Chicago
> meeting, and then to review the changes in Chicago.  We want to ensure that
> we have full participation and input on the list as this
> *is* official process and we want to be sensitive to those who may not be
> able to travel to this meeting.
> 
> Lou
> 
> 
> On 3/8/2017 11:00 AM, Mehmet Ersue wrote:
> > What I meant with joint session can be achieved with a (e.g. 20-30min)
> time-slot in NETMOD or NETCONF session on Tuesday where we invite I2RS
> people to attend. We can discuss the charter details and agree "all together"
> on the plan and work split.
> >
> > Does this make sense?
> >
> > Mehmet
> >
> >> -----Original Message-----
> >> From: Kent Watsen [mailto:kwatsen@juniper.net]
> >> Sent: Wednesday, March 8, 2017 1:51 AM
> >> To: Mehmet Ersue <mersue@gmail.com>; 'Susan Hares'
> >> <shares@ndzh.com>; netmod@ietf.org
> >> Cc: netmod-chairs@ietf.org
> >> Subject: Re: [netmod] draft netmod charter update proposal
> >>
> >> 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
> >>
> >>
> >
> >