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