[netmod] FW: draft netmod charter update proposal

["Mehmet Ersue" <[e-mail]>]

Hi Lou,

no issue at all, we can get in sync again. As I see in exchanged mails we discussed to not hurry and to plan a joint session.

AFAIK the timing between 7950bis and NETCONF documents as well as the content split is still subject to finalize.
It is not clear yet how and where to address draft-voit-netmod-yang-notifications2. Eric Voit's proposal is to do it in NETMOD WG.
Kent was asking for a discussion in NETCONF WG on to how we can address NETCONF extensions going to be proposed in the new DS concept draft.

I would like to suggest to continue the discussion on the maillist but give WG members in IETF 98 some room to comment before calling it final and giving to Benoit.
This I believe is necessary because of the dependent work we have on the two charters.

Thanks,
Mehmet

-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Wednesday, March 8, 2017 10:50 PM
To: Mehmet Ersue <[e-mail]>; 'Kent Watsen' <[e-mail]>; 'Susan Hares' <[e-mail]>; [e-mail]
Cc: [e-mail]; 'Benoit Claise' <[e-mail]>; 'Mahesh Jethanandani' <[e-mail]>
Subject: Re: [netmod] draft netmod charter update proposal

Mehmet,

I'm sorry if we somehow got out of sync.  I certainly agree that we've agreed to having the chairs only coordination meeting you suggested, but I (and I suspect Kent) never thought this gated work on the NetMod charter but was more to ensure smooth cooperation between the groups.  I also thought we made it clear that we expected to have per-WG charter discussions in our respective session s on Tuesday rather than in a joint session.  It was always our hope that the NetMod WG charter would be finalized before Chicago -- I'm sorry if we didn't state this explicitly.  We expect to have a lot to discuss in the NetMod WG sessions and wanted to allocate time to focus on technical progress vs process, as well as ensure that all in the WG had equal opportunity to provide input via the list.

Certainly Benoit and the IESG will need to approve both Charters, but the timing of this is up to them.  I personally see that NetMod and NetConf efforts are largely deconflicted at this point so I don't have reservations with them progressing separately.

Lou

On 3/8/2017 4:25 PM, Mehmet Ersue wrote:
> 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:[e-mail]]
>> Sent: Wednesday, March 8, 2017 7:18 PM
>> To: Mehmet Ersue <[e-mail]>; 'Kent Watsen'
>> <[e-mail]>; 'Susan Hares' <[e-mail]>; 
>> [e-mail]
>> Cc: [e-mail]
>> 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:[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
>>>>
>>>
>
>