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
