Re: [netmod] draft netmod charter update proposal

["Susan Hares" <[e-mail]>]

Sounds like a great idea!

Sue 

-----Original Message-----
From: Mehmet Ersue [mailto:[e-mail]] 
Sent: Wednesday, March 8, 2017 11:01 AM
To: 'Kent Watsen'; 'Susan Hares'; [e-mail]
Cc: [e-mail]
Subject: RE: [netmod] draft netmod charter update proposal

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:[e-mail]]
> Sent: Wednesday, March 8, 2017 1:51 AM
> To: Mehmet Ersue <[e-mail]>; 'Susan Hares'
> <[e-mail]>; [e-mail]
> Cc: [e-mail]
> 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:[e-mail]]
> > Sent: Tuesday, March 7, 2017 7:27 PM
> > To: 'Mehmet Ersue' <[e-mail]>; 'Kent Watsen'
> > <[e-mail]>; [e-mail]
> > Cc: [e-mail]
> > 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:[e-mail]]
> > Sent: Tuesday, March 7, 2017 12:21 PM
> > To: 'Susan Hares'; 'Kent Watsen'; [e-mail]
> > Cc: [e-mail]
> > 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:[e-mail]] On Behalf Of Susan
> > Hares
> > > Sent: Tuesday, March 7, 2017 4:30 PM
> > > To: 'Kent Watsen' <[e-mail]>; [e-mail]
> > > Cc: [e-mail]
> > > 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:[e-mail]] On Behalf Of Kent
> > Watsen
> > > Sent: Wednesday, February 22, 2017 7:25 PM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > 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 <[e-mail]>
> > >    Kent Watsen <[e-mail]>
> > >
> > > Operations and Management Area Directors:
> > >    Benoit Claise <[e-mail]>
> > >    Joel Jaeggli <[e-mail]>
> > >
> > > Operations and Management Area Advisor:
> > >    Benoit Claise <[e-mail]>
> > >
> > > Secretary:
> > >    Zitao (Michael) Wang <[e-mail]>
> > >
> > > Mailing Lists:
> > >    General Discussion: [e-mail]
> > >    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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> 
>