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
