Subject: [Netconf] NETCONF Charter

From: Kent Watsen <[email-masked]>
Date: Mon, 12 Feb 2018 22:15:50 +0000

Dear WG,

Mahesh and I have put together a proposal for a new charter for our
working group.  This charter proposal is comparable to the charter
that Lou and I recently put together for the NETMOD WG.  

Our primary objective to this update is to have a charter that is
sufficiently broad to not require frequent updates, and yet still
constrains us to specific objectives.

Note that the Milestones at the bottom detail the specific drafts
the WG is working on and, therefore, we chose to not call out the
individual drafts in the body of the charter itself.

Please review and send any comments that you may have regarding it.

Thanks,
Kent and Mahesh

===== charter proposal =====

Description of Working Group:
 
The Network Configuration (NETCONF) working group is responsible for
network management protocols, their transports and encodings, and
defining data models necessary to support the protocols.  The NETCONF
working group also defines mechanisms supporting the operational
deployment of systems using the protocols.
 
The NETCONF WG is responsible for:
 
   a) Maintaining the network management protocol NETCONF (RFC 6241).
      This effort entails periodically updating the NETCONF related
      specifications to address new requirements as they arise.
 
   b) Maintaining the network management protocol RESTCONF (RFC 8040).
      This effort entails periodically updating the RESTCONF related
      specifications to address new requirements as they arise.
 
   c) Defining transports and encodings used by the NETCONF and
      RESTCONF protocols.
 
   d) Defining data models that are related to network management
      protocols.  Specifically, data models enabling the configuration
      and/or monitoring of the NETCONF and RESTCONF servers themselves.
      Other examples include data models for configuring access
      controls or discovering server metadata.
 
   e) Defining mechanisms enabling devices to discover and establish
      secure connections to NETCONF and/or RESTCONF servers.
 
   The NETCONF working group consults with the NETMOD working group to
   ensure that new requirements are understood and can be met by the
   YANG data modeling language (RFC 7950) developed within that working
   group.

Goals and Milestones:
 
  This section is updated automatically via the Milestone tracker
    - https://datatracker.ietf.org/wg/netconf/milestones/
 
  And therefore the specific list of drafts is not included here.

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 12 Feb 2018 22:59:45 +0000

Hi,

I suggest adding an item regarding the use of Netconf for Service Assurance and automation, covering items like subscriptions to notifications and datastore updates (e.g. YANG-Push and follow-up work). 

Something like "Define and maintain mechanisms to manage subscriptions and notification and datastore streams related to NETCONF/RESTCONF, and provide related mechanisms that facilitate service assurance and network automation."

Thanks
--- Alex

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
> Sent: Monday, February 12, 2018 2:16 PM
> To: [email-masked]
> Subject: [Netconf] NETCONF Charter
> 
> 
> Dear WG,
> 
> Mahesh and I have put together a proposal for a new charter for our working
> group.  This charter proposal is comparable to the charter that Lou and I recently
> put together for the NETMOD WG.
> 
> Our primary objective to this update is to have a charter that is sufficiently broad
> to not require frequent updates, and yet still constrains us to specific objectives.
> 
> Note that the Milestones at the bottom detail the specific drafts the WG is
> working on and, therefore, we chose to not call out the individual drafts in the
> body of the charter itself.
> 
> The Network Configuration (NETCONF) working group is responsible for network
> management protocols, their transports and encodings, and defining data
> models necessary to support the protocols.  The NETCONF working group also
> defines mechanisms supporting the operational deployment of systems using the
> protocols.
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Feb 2018 08:22:38 +0100

I find the phrase 'provide related mechanisms that facilitate service
assurance and network automation' is too broad. I can't tell what this
includes or excludes.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 13 Feb 2018 15:41:11 +0100

I think the page https://datatracker.ietf.org/wg/netconf/milestones/
is not publicly available.

"You are not authorized to edit the milestones of this group."

Cheers,
Mehmet

> Sent: Monday, February 12, 2018 11:16 PM
> To: [email-masked]
working
> group.  This charter proposal is comparable to the charter that Lou and I
> recently put together for the NETMOD WG.
> 
sufficiently
> broad to not require frequent updates, and yet still constrains us to
specific
> objectives.
> working on and, therefore, we chose to not call out the individual drafts
in
> the body of the charter itself.
>

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 13 Feb 2018 17:02:36 +0100

Hi Kent, 

I support making the charter "sufficiently broad to not require frequent
updates".
Though we need to take care that it remains within agreed constraints.

"The NETCONF WG is responsible for:" looks like a limitation.
I would suggest to change as: "is currently responsible". 

Can you please clarify whether you wanted to give a link to goals and
milestones in the final charter text going to approval or 
you just skipped it in the current mail? Thanks.

Mehmet

working
sufficiently
specific
in

---

From: Kent Watsen <[email-masked]>
Date: Tue, 13 Feb 2018 16:47:04 +0000

Hi Mehmet,

I replaced the URL below with "<snip/>" do to my company's nasty
URL-mangler:

> I think the page <snip/> is not publicly available.
>

This is true, though we forgot to say so for everyone's benefit.
Thank you for raising awareness to this point Mehmet!

Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 13 Feb 2018 17:01:08 +0000

Hi Mehmet,

> updates".  Though we need to take care that it remains within agreed 
> constraints.

Indeed, and thanks for your support.

> I would suggest to change as: "is currently responsible". 

Open to suggestions but, for the sake of discussion, note that this 
language (for better or worse) is present in NETMOD charter.  I see
your point, but do you also think that, assuming we don't change it,
that it would just be a matter of rechartering to provide updated
text at that time?   Maybe having this language is just the thing
needed to provide some contraints, are you thinking that it could
be used as a reason to shutdown the WG?  FWIW, I'm not worried
about that, the I think that WG will be shutdown when the time comes
regardless the language we put here.

> Can you please clarify whether you wanted to give a link to goals
> and milestones in the final charter text going to approval or 

We intended to give the link, but it was silliness on our part because,
as you noted, the link isn't accessible to anyone but the chairs.  As
for sending out the current Milestones for review, no, that is not our
intention at this time, as the Milestones don't need to be reviewed by
the WG.  Our only intention was to highlight that individual drafts are
tracked separately, and hence don't need to be in the Charter text
itself, just as they are not in the NETMOD charter text.

Thanks again,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 13 Feb 2018 17:34:41 +0000

Hi Alex,

I'm not opposed to the idea of adding something along these lines, but in the effort to keep the text as tight as possible, is it not the case that:

  - yang-push and subscribed-notifications fall under the "data models" clause?
  - netconf-event-notifications, notification-messages, etc. fall under the
    "maintaining protocols" clause?

To clarify, already NC/RC have notifications, the drafts the WG have been working on recently are like "better notifications".  It seems like we're maintaining protocols and defining data models, no?  

Playing devil's advocate, if we add something along the lines of your proposal, would we then find ourselves needing to recharter every time we want to add a new feature to the protocols? 

Kent

===== original message =====

Hi,

Thanks
--- Alex

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 13 Feb 2018 18:35:50 +0100

Hi Kent,

I think "is currently responsible" does not change much. It only indicates that the list of protocols and work can be extended in the future. This flexibility is indeed what we discussed in recent meetings. You are right, to define a concrete work item a new charter needs to be approved.

> . . ., as the Milestones don't need to be reviewed by the WG.

I agree in general that there is a tendency to make charters more flexible within agreed constraints.
Though I think differently for this point.

RFC 2418 says in section 2.2.: 
  "Charters may be renegotiated periodically to reflect the current
   status, organization or goals of the working group (see section 5).
   Hence, a charter is a contract between the IETF and the working group
   which is committing to meet explicit milestones and delivering
   specific "products"."
Same RFC also says:
 "A charter:  . . .  
   3. Enumerates a set of milestones together with time frames for their completion.".

We all know the deadlines give only a reasonable constraint as a starting point at the time of charter approval. However, I think the list of the drafts and their milestones are part of the charter and subject to approval together with the charter text.

Thanks,
Mehmet

> From: Kent Watsen [mailto:[email-masked]]
> Sent: Tuesday, February 13, 2018 6:01 PM
> To: Mehmet Ersue <[email-masked]>; [email-masked]
> Subject: Re: [Netconf] NETCONF Charter
> 
> Hi Mehmet,
> 
> 
> > I support making the charter "sufficiently broad to not require
> > frequent updates".  Though we need to take care that it remains within
> > agreed constraints.
> 
> Open to suggestions but, for the sake of discussion, note that this language
> (for better or worse) is present in NETMOD charter.  I see your point, but do
> you also think that, assuming we don't change it, that it would just be a
> matter of rechartering to provide updated
> needed to provide some contraints, are you thinking that it could be used as
> a reason to shutdown the WG?  FWIW, I'm not worried about that, the I think
> that WG will be shutdown when the time comes regardless the language we
> put here.
> 
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 13 Feb 2018 10:40:27 -0800

Mehmet,

> On Feb 13, 2018, at 9:35 AM, Mehmet Ersue <[email-masked]> wrote:
> 
> However, I think the list of the drafts and their milestones are part of the charter and subject to approval together with the charter text.

Nobody is disagreeing that milestones are part of the charter. Is there something in the current list of milestones that are published here <https://datatracker.ietf.org/wg/netconf/about/> for anyone’s consumption that you would think would be a problem for adoption of the charter?

Mahesh Jethanandani
[email-masked]

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 13 Feb 2018 19:55:55 +0100

Mahesh,

the documents in the current list of milestones on the datatracker page are all active WG items. So they are all OK.

AFAICS the deadlines (aka. “time frames for their completion”) need to be updated based on the current schedule assumption. I think 6536bis can be indicated as “done” now (assuming it’ll be published until charter approval).

Cheers,

Mehmet

From: Mahesh Jethanandani [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2018 7:40 PM
To: Mehmet Ersue <[email-masked]>
Cc: Kent Watsen <[email-masked]>; [email-masked]
Subject: Re: [Netconf] NETCONF Charter

Mehmet,

On Feb 13, 2018, at 9:35 AM, Mehmet Ersue <[email-masked] <mailto:[email-masked]> > wrote:

Mahesh Jethanandani

[email-masked] <mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 13 Feb 2018 11:27:31 -0800

Mehmet,

For the purpose of the charter discussion, let us assume that the current milestone list <https://datatracker.ietf.org/wg/netconf/about/> is part of the charter.

RFC6536bis is in the RFC Editors queue, and it will be marked done when it is published. The list of drafts and their milestones is a dynamic list that will need updates as they move through the WG. We would rather have the datatracker tool keep the list up-to-date.

Thanks.

> On Feb 13, 2018, at 10:55 AM, Mehmet Ersue <[email-masked]> wrote:
> 
> Mahesh,
>  
>> On Feb 13, 2018, at 9:35 AM, Mehmet Ersue <[email-masked] <mailto:[email-masked]>> wrote:
>>  
Mahesh Jethanandani
[email-masked]

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 13 Feb 2018 19:53:55 +0000

Well, we can certainly rephrase it.  The point is, there is a considerable portion of work going on regarding the ability to subscribe to information and data streams from Netconf/Restconf servers - what started with YANG-Push and subscribed-notifications, but also includes related work (including support for other filters, multiple stream originators, etc).  

Many (but not the only) uses of this concern service assurance and network automation.  You don't want to be polling-based, or else Netconf/Restconf is not really better than SNMP, and at the same time you don't want to restrict Netconf/Restconf to configurations only or else we would not be having the entire NMDA discussion and support for operational data.  

I believe that the charter needs to reflect this. 

--- Alex 

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Monday, February 12, 2018 11:23 PM
> To: Alexander Clemm <[email-masked]>
> I find the phrase 'provide related mechanisms that facilitate service assurance
> and network automation' is too broad. I can't tell what this includes or excludes.
> 
> /js
> 
> > I suggest adding an item regarding the use of Netconf for Service Assurance
> and automation, covering items like subscriptions to notifications and datastore
> updates (e.g. YANG-Push and follow-up work).
> >
> > Something like "Define and maintain mechanisms to manage subscriptions and
> notification and datastore streams related to NETCONF/RESTCONF, and provide
> related mechanisms that facilitate service assurance and network automation."
> >
> > Thanks
> > --- Alex
> >
> > > sufficiently broad to not require frequent updates, and yet still constrains us
> to specific objectives.
> > >
> > > defining data models necessary to support the protocols.  The
> > > NETCONF working group also defines mechanisms supporting the
> > > operational deployment of systems using the protocols.
> > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Feb 2018 21:00:41 +0100

Then make a proposal that is concrete and which does not include
something as open ended as 'provide related mechanisms that facilitate
service assurance and network automation'. My concern is that this
second part of the sentence is way too open ended. I also do not know
what 'datastore streams' are. I am not objecting about added a bullet
about work you have in mind, I am objecting against text I find way
too broad to be useful or which uses terms I have no clue what they
mean.

/js

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 13 Feb 2018 21:42:41 +0000

How about:

Define and maintain mechanisms to manage subscriptions to information updates from datastores, in order to support applications related to network automation and service assurance that cannot afford to rely on polling.  

(I think the intent is clear; perhaps someone else has a better proposal?)  

--- Alex

> Sent: Tuesday, February 13, 2018 12:01 PM
> Then make a proposal that is concrete and which does not include something as
> open ended as 'provide related mechanisms that facilitate service assurance and
> network automation'. My concern is that this second part of the sentence is way
> too open ended. I also do not know what 'datastore streams' are. I am not
> objecting about added a bullet about work you have in mind, I am objecting
> against text I find way too broad to be useful or which uses terms I have no clue
> what they mean.
> 
> /js
> 
> > Well, we can certainly rephrase it.  The point is, there is a considerable portion
> of work going on regarding the ability to subscribe to information and data
> streams from Netconf/Restconf servers - what started with YANG-Push and
> subscribed-notifications, but also includes related work (including support for
> other filters, multiple stream originators, etc).
> >
> > Many (but not the only) uses of this concern service assurance and network
> automation.  You don't want to be polling-based, or else Netconf/Restconf is not
> really better than SNMP, and at the same time you don't want to restrict
> Netconf/Restconf to configurations only or else we would not be having the
> entire NMDA discussion and support for operational data.
> >
> > > From: Juergen Schoenwaelder
> > > [mailto:[email-masked]]
> > > I find the phrase 'provide related mechanisms that facilitate
> > > service assurance and network automation' is too broad. I can't tell what this
> includes or excludes.
> > >
> > > /js
> > >
> > > and automation, covering items like subscriptions to notifications
> > > and datastore updates (e.g. YANG-Push and follow-up work).
> > > >
> > > notification and datastore streams related to NETCONF/RESTCONF, and
> > > provide related mechanisms that facilitate service assurance and network
> automation."
> > > >
> > > > Thanks
> > > > --- Alex
> > > >
> > > > > Mahesh and I have put together a proposal for a new charter for
> > > > > our working group.  This charter proposal is comparable to the
> > > > > charter that Lou and I recently put together for the NETMOD WG.
> > > > >
> > > > > Our primary objective to this update is to have a charter that
> > > > > is sufficiently broad to not require frequent updates, and yet
> > > > > still constrains us
> > > to specific objectives.
> > > > >
> > > > > Note that the Milestones at the bottom detail the specific
> > > > > drafts the WG is working on and, therefore, we chose to not call
> > > > > out the individual drafts in the body of the charter itself.
> > > > >
> > > > > The Network Configuration (NETCONF) working group is responsible
> > > > > for network management protocols, their transports and
> > > > > encodings, and defining data models necessary to support the
> > > > > protocols.  The NETCONF working group also defines mechanisms
> > > > > supporting the operational deployment of systems using the protocols.
> > > > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Feb 2018 23:07:20 +0100

Looks better. You can remove 'related to network automation and
service assurance' without loosing anything.

/js

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 13 Feb 2018 22:25:24 +0000

Works for me...
--- Alex

> Sent: Tuesday, February 13, 2018 2:07 PM
> Looks better. You can remove 'related to network automation and service
> assurance' without loosing anything.
> 
> /js
> 
> > Define and maintain mechanisms to manage subscriptions to information
> updates from datastores, in order to support applications related to network
> automation and service assurance that cannot afford to rely on polling.
> >
> > > something as open ended as 'provide related mechanisms that
> > > facilitate service assurance and network automation'. My concern is
> > > that this second part of the sentence is way too open ended. I also
> > > do not know what 'datastore streams' are. I am not objecting about
> > > added a bullet about work you have in mind, I am objecting against
> > > text I find way too broad to be useful or which uses terms I have no clue what
> they mean.
> > >
> > > /js
> > >
> > > of work going on regarding the ability to subscribe to information
> > > and data streams from Netconf/Restconf servers - what started with
> > > YANG-Push and subscribed-notifications, but also includes related
> > > work (including support for other filters, multiple stream originators, etc).
> > > >
> > > automation.  You don't want to be polling-based, or else
> > > Netconf/Restconf is not really better than SNMP, and at the same
> > > time you don't want to restrict Netconf/Restconf to configurations
> > > only or else we would not be having the entire NMDA discussion and support
> for operational data.
> > > >
> > > > > and automation, covering items like subscriptions to
> > > > > notifications and datastore updates (e.g. YANG-Push and follow-up
> work).
> > > > > >
> > > > > notification and datastore streams related to NETCONF/RESTCONF,
> > > > > and provide related mechanisms that facilitate service assurance
> > > > > and network
> > > automation."
> > > > > >
> > > > > > Thanks
> > > > > > --- Alex
> > > > > >
> > > > > > > Mahesh and I have put together a proposal for a new charter
> > > > > > > for our working group.  This charter proposal is comparable
> > > > > > > to the charter that Lou and I recently put together for the NETMOD
> WG.
> > > > > > >
> > > > > > > Our primary objective to this update is to have a charter
> > > > > > > that is sufficiently broad to not require frequent updates,
> > > > > > > and yet still constrains us
> > > > > to specific objectives.
> > > > > > >
> > > > > > > drafts the WG is working on and, therefore, we chose to not
> > > > > > > call out the individual drafts in the body of the charter itself.
> > > > > > >
> > > > > > > The Network Configuration (NETCONF) working group is
> > > > > > > responsible for network management protocols, their
> > > > > > > transports and encodings, and defining data models necessary
> > > > > > > to support the protocols.  The NETCONF working group also
> > > > > > > defines mechanisms supporting the operational deployment of
> systems using the protocols.
> > > > > > >
> > > > > > >    a) Maintaining the network management protocol NETCONF
> > > > > > > (RFC
> > > 6241).
> > > > > > >    b) Maintaining the network management protocol RESTCONF
> > > > > > > (RFC
> > > 8040).
> > > > > > >    The NETCONF working group consults with the NETMOD
> > > > > > > working group
> > > to
> > > > > > >    YANG data modeling language (RFC 7950) developed within
> > > > > > > that
> > > working
> > > > > > >    group.
> > > > > > >
> > > > > > >
> > > > > > > Goals and Milestones:
> > > > > > >

---

From: Kent Watsen <[email-masked]>
Date: Tue, 13 Feb 2018 22:35:09 +0000

And me  :)

K.

=om=

Works for me...
--- Alex

> > > > > > >     - https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_wg_netconf_milestones_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=AGdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=mOtH82--0nKcHnxkoY1JSlrszfIEQHhbnSB7348GPBw&e=
> > > > > > >
> > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=AGdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=c8hFbol_Bsjwm7OKLCni66viUP9epI20_F_Z7Gpodks&e=
> > > > > >
> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=AGdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=c8hFbol_Bsjwm7OKLCni66viUP9epI20_F_Z7Gpodks&e=
> > > > >
> > > > > --
> > > > > Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=AGdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=ofFyi0mgLs8zZ257hzKkF0FuRgSSUQyekrJp5VS1IzA&e=>
> > >
> > > --
> > > Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=AGdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=ofFyi0mgLs8zZ257hzKkF0FuRgSSUQyekrJp5VS1IzA&e=>
> 
> --
> Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=AGdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=ofFyi0mgLs8zZ257hzKkF0FuRgSSUQyekrJp5VS1IzA&e=>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 13 Feb 2018 14:44:08 -0800

So the final consensus is addition of another bullet item in the charter that says:

Define and maintain mechanisms to manage subscription to information updates from datastores. 

> On Feb 13, 2018, at 2:35 PM, Kent Watsen <[email-masked]> wrote:
> 
> And me  :)
> 
> K.
> 
> =om=
> 
> 
> Works for me...
> --- Alex
> 

Mahesh Jethanandani
[email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 13 Feb 2018 23:04:03 +0000

Looks goods to me.

> >> updates from datastores, in order to support applications related to
> >> network automation and service assurance that cannot afford to rely on
> polling.
> >>>
> >>>>>>>> responsible for network management protocols, their transports
> >>>>>>>> and encodings, and defining data models necessary to support
> >>>>>>>> the protocols.  The NETCONF working group also defines
> >>>>>>>> mechanisms supporting the operational deployment of
> >>>>>>>>   The NETCONF working group consults with the NETMOD working
> >>>>>>>> group
> >>>> to
> >>>>>>>>    -
> >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracke
> >>>>>>>>
> r.ietf.org_wg_netconf_milestones_&d=DwIFAg&c=HAkYuh63rsuhr6Scbf
> >>>>>>>> h0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjI
> >>>>>>>>
> SlaJdcZo&m=AGdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=mOt
> H82
> >>>>>>>> --0nKcHnxkoY1JSlrszfIEQHhbnSB7348GPBw&e=
> >>>>>>>>
> >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.o
> >>>>>>>>
> rg_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBX
> >>>>>>>> eMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdc
> >>>>>>>>
> Zo&m=AGdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=c8hFbol_
> Bsjw
> >>>>>>>> m7OKLCni66viUP9epI20_F_Z7Gpodks&e=
> >>>>>>>
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.or
> >>>>>>>
> g_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeM
> >>>>>>> K-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&
> >>>>>>>
> m=AGdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=c8hFbol_Bsjw
> m7OK
> >>>>>>> LCni66viUP9epI20_F_Z7Gpodks&e=
> >>>>>>
> >>>>>> --
> >>>>>> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-
> 2Duniversity.de_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A
> GdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=ofFyi0mgLs8zZ257
> hzKkF0FuRgSSUQyekrJp5VS1IzA&e=>
> >>>>
> >>>> --
> >>>> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-
> 2Duniversity.de_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A
> GdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=ofFyi0mgLs8zZ257
> hzKkF0FuRgSSUQyekrJp5VS1IzA&e=>
> >>
> >> --
> >> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-
> 2Duniversity.de_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=A
> GdmvgcFondRV9xW_GLdkNC11BV3wjMN_5X8rZHbMUA&s=ofFyi0mgLs8zZ257
> hzKkF0FuRgSSUQyekrJp5VS1IzA&e=>
> >
> >

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Feb 2018 00:12:21 +0000

Wait, no, if you take Alex's proposal and Juergen's subtraction, you get:

"Define and maintain mechanisms to manage subscriptions to information updates from datastores, in order to support applications that cannot afford to rely on polling."

which I think is slightly more meaningful.  Mahesh/Eric?  

That said, I wonder if we shouldn't also cut out the "from datastores" part? - I know that all information is in a datastore, but do we need to say it here? 

Kent

Looks goods to me.

> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=uPqCGUqeFXHRBfTJWeoWvH_Q3cY4Kw1mksMkyKL9IXY&s=Y_I9oIU1XN8Q4vvM9Px5aAtyYBwYy9JCpUe7kh1BCEQ&e=
> 
> Mahesh Jethanandani
> [email-masked]
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=uPqCGUqeFXHRBfTJWeoWvH_Q3cY4Kw1mksMkyKL9IXY&s=Y_I9oIU1XN8Q4vvM9Px5aAtyYBwYy9JCpUe7kh1BCEQ&e=

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 13 Feb 2018 17:57:48 -0800

Why is it important to exclude polling? And is not being too specific? What if there were other ways to get updates? Would they also be excluded?

> On Feb 13, 2018, at 4:12 PM, Kent Watsen <[email-masked]> wrote:
> 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=uPqCGUqeFXHRBfTJWeoWvH_Q3cY4Kw1mksMkyKL9IXY&s=Y_I9oIU1XN8Q4vvM9Px5aAtyYBwYy9JCpUe7kh1BCEQ&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=uPqCGUqeFXHRBfTJWeoWvH_Q3cY4Kw1mksMkyKL9IXY&s=Y_I9oIU1XN8Q4vvM9Px5aAtyYBwYy9JCpUe7kh1BCEQ&e=>
>> 
>> Mahesh Jethanandani
>> [email-masked] <mailto:[email-masked]>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=uPqCGUqeFXHRBfTJWeoWvH_Q3cY4Kw1mksMkyKL9IXY&s=Y_I9oIU1XN8Q4vvM9Px5aAtyYBwYy9JCpUe7kh1BCEQ&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=uPqCGUqeFXHRBfTJWeoWvH_Q3cY4Kw1mksMkyKL9IXY&s=Y_I9oIU1XN8Q4vvM9Px5aAtyYBwYy9JCpUe7kh1BCEQ&e=>
Mahesh Jethanandani
[email-masked]

---

From: "t.petch" <[email-masked]>
Date: Wed, 14 Feb 2018 11:59:52 -0000

Kent

When I read that first sentence, I thought ah, a home for SNMP:-)

As it stands, if someone came up with something new, e.g. a NETCONF-lite
for constrained devices, then that would be within the scope of that
first sentence.  Should it be?

I think that the first sentence is important for most people, although
perhaps not for those in this discussion, so I would like to exclude
SNMP; I don't know whether or not you intend to exclude all but NETCONF
and RESTCONF.

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Feb 2018 17:30:55 +0000

Hi Mahesh,

It doesn't say apps can't poll, it's just that they can't afford to poll.  My view is that it helps to frame the motivation (an important optimization).  Perhaps we could turn it around and say it more positively?

(Note, I do a few more things here too)

"Define and maintain data models for subscriptions to information and protocol bindings to have relevant data pushed to clients in an expedient manner."

Happy to get other opinions on this.

Kent

On 2/13/18, 8:57 PM, "Mahesh Jethanandani" <[email-masked]<mailto:[email-masked]>> wrote:

On Feb 13, 2018, at 4:12 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Kent

Looks goods to me.

So the final consensus is addition of another bullet item in the charter that
says:

Define and maintain mechanisms to manage subscription to information
updates from datastores.

On Feb 13, 2018, at 2:35 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

And me  :)

K.

=om=

Works for me...
--- Alex

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]]
Sent: Tuesday, February 13, 2018 2:07 PM
To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>
Cc: Kent Watsen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] NETCONF Charter

/js

How about:

Define and maintain mechanisms to manage subscriptions to
information
updates from datastores, in order to support applications related to
network automation and service assurance that cannot afford to rely on
polling.

(I think the intent is clear; perhaps someone else has a better
proposal?)

--- Alex

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]]
Sent: Tuesday, February 13, 2018 12:01 PM
To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>
Cc: Kent Watsen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] NETCONF Charter

text I find way too broad to be useful or which uses terms I have
no clue what
they mean.

/js

Well, we can certainly rephrase it.  The point is, there is a
considerable portion

Many (but not the only) uses of this concern service assurance and
network
automation.  You don't want to be polling-based, or else
Netconf/Restconf is not really better than SNMP, and at the same
time you don't want to restrict Netconf/Restconf to configurations
only or else we would not be having the entire NMDA discussion and
support
for operational data.

--- Alex

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]]
Sent: Monday, February 12, 2018 11:23 PM
To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>
Cc: Kent Watsen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] NETCONF Charter

I find the phrase 'provide related mechanisms that facilitate
service assurance and network automation' is too broad. I can't
tell what this
includes or excludes.

/js

Hi,

I suggest adding an item regarding the use of Netconf for
Service Assurance
and automation, covering items like subscriptions to
notifications and datastore updates (e.g. YANG-Push and follow-up
work).

Something like "Define and maintain mechanisms to manage
subscriptions and
notification and datastore streams related to NETCONF/RESTCONF,
and provide related mechanisms that facilitate service assurance
and network
automation."

Thanks
--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of
Kent Watsen
Sent: Monday, February 12, 2018 2:16 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Netconf] NETCONF Charter

Dear WG,

Mahesh and I have put together a proposal for a new charter for
our working group.  This charter proposal is comparable to the
charter that Lou and I recently put together for the NETMOD
WG.

Please review and send any comments that you may have regarding
it.

Thanks,
Kent and Mahesh

 a) Maintaining the network management protocol NETCONF (RFC
6241).

 b) Maintaining the network management protocol RESTCONF (RFC
8040).

 d) Defining data models that are related to network management
    protocols.  Specifically, data models enabling the configuration
    and/or monitoring of the NETCONF and RESTCONF servers
themselves.

 ensure that new requirements are understood and can be met by
the

 YANG data modeling language (RFC 7950) developed within that
working

 group.

Goals and Milestones:

h0UjBXeMK-

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.o
rg_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBX

eMK-

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.or
g_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeM

K-

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
Germany

Fax:   +49 421 200 3103

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=uPqCGUqeFXHRBfTJWeoWvH_Q3cY4Kw1mksMkyKL9IXY&s=Y_I9oIU1XN8Q4vvM9Px5aAtyYBwYy9JCpUe7kh1BCEQ&e=

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=uPqCGUqeFXHRBfTJWeoWvH_Q3cY4Kw1mksMkyKL9IXY&s=Y_I9oIU1XN8Q4vvM9Px5aAtyYBwYy9JCpUe7kh1BCEQ&e=

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Feb 2018 17:49:34 +0000

Hi Tom,

Yes, that first sentence begs the question, not just SNMP, but COAP as well!

(and notice here I'm using Mehmet's "currently")

OLD:

The Network Configuration (NETCONF) working group is responsible for
network management protocols, 

OPTION-1:

The Network Configuration (NETCONF) working group is currently responsible for
the network management protocols listed below, 

OPTION-2:

The Network Configuration (NETCONF) working group is currently responsible for
the network management protocols NETCONF (RFC6241) and RESTCONF (RFC 8040), 

Thoughts?
Kent

Kent

Tom Petch

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: <[email-masked]>
Sent: Monday, February 12, 2018 10:15 PM
Subject: [Netconf] NETCONF Charter

themselves.
working
>     - https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_wg_netconf_milestones_&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=mUkjYhuVX0FNcW1y0H4sgc6DmI0TeFqPYJjvLNa08gU&s=uzrGB-U8Z4eReZah-v589Ggzlk3et2Dm2p6Fqeix9wM&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=mUkjYhuVX0FNcW1y0H4sgc6DmI0TeFqPYJjvLNa08gU&s=3R26HtJRFTbBnbfvDtohYxejH6y9H09Epo3vN28uC8w&e=

---

From: Robert Wilton <[email-masked]>
Date: Wed, 14 Feb 2018 18:03:18 +0000

On 14/02/2018 17:30, Kent Watsen wrote:
>
> Hi Mahesh,
>
> It doesn't say apps can't poll, it's just that they can't afford to 
> poll.  My view is that it helps to frame the motivation (an important 
> optimization).  Perhaps we could turn it around and say it more 
> positively?
>
> "Define and maintain data models for subscriptions to information and 
> protocol bindings to have relevant data pushed to clients in an 
> expedient manner."
>
I prefer this latter phrasing.

Thanks,
Rob

> Why is it important to exclude polling? And is not being too specific? 
> What if there were other ways to get updates? Would they also be 
> excluded?
>
>
>
>     "Define and maintain mechanisms to manage subscriptions to
>     information updates from datastores, in order to support
>     applications that cannot afford to rely on polling."
>
>     That said, I wonder if we shouldn't also cut out the "from
>     datastores" part? - I know that all information is in a datastore,
>     but do we need to say it here?
>
>     Kent
>
>             On Feb 13, 2018, at 2:35 PM, Kent Watsen
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>             And me  :)
>
>             K.
>
>             =om=
>
>
>             Works for me...
>             --- Alex
>
>
>                 Cc: Kent Watsen <[email-masked]
>                 <mailto:[email-masked]>>; [email-masked]
>                 <mailto:[email-masked]>
>                         To: Alexander Clemm
>                         <[email-masked]
>                         <mailto:[email-masked]>>
>                         Cc: Kent Watsen <[email-masked]
>                         <mailto:[email-masked]>>;
>                         [email-masked] <mailto:[email-masked]>
>                                 To: Alexander Clemm
>                                 <[email-masked]
>                                 <mailto:[email-masked]>>
>                                 Cc: Kent Watsen <[email-masked]
>                                 <mailto:[email-masked]>>;
>                                 [email-masked] <mailto:[email-masked]>
>                                         From: Netconf
>                                         [mailto:[email-masked]]
>                                         On Behalf Of
>                                         Kent Watsen
>                                         <mailto:[email-masked]>
>                                         our working group.  This
>                                         charter proposal is comparable
>                                         to the
>                                         charter that Lou and I
>                                         recently put together for the
>                                         NETMOD
>
>                 WG.
>
>
>                                         Please review and send any
>                                         comments that you may have
>                                         regarding
>
>                 it.
>
>
>                                         Thanks,
>                                         Kent and Mahesh
>
>
>                                         transports
>                                             This effort entails
>                                         periodically updating the
>                                         NETCONF related
>                                             This effort entails
>                                         periodically updating the
>                                         RESTCONF related
>                                             protocols.  Specifically,
>                                         data models enabling the
>                                         configuration
>                                          e) Defining mechanisms
>                                         enabling devices to discover
>                                         and establish
>                                             secure connections to
>                                         This section is updated
>                                         automatically via the
>                                         Milestone tracker
>                                         And therefore the specific
>                                         list of drafts is not included
>                                         here.
>
>
>
>
>
>
>
>                                         <mailto:[email-masked]>
>                                     <mailto:[email-masked]>

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 14 Feb 2018 18:11:08 +0000

This wording looks fine to me.  And I do agree that framing the motivation makes sense.
--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Wednesday, February 14, 2018 10:03 AM
To: Kent Watsen <[email-masked]>; Mahesh Jethanandani <[email-masked]>; [email-masked]
Subject: Re: [Netconf] NETCONF Charter

Thanks,
Rob

Kent

Kent

Looks goods to me.

And me  :)

K.

=om=

Works for me...
--- Alex

-----Original Message-----

/js

How about:

--- Alex

-----Original Message-----

/js

--- Alex

-----Original Message-----

/js

Hi,

Thanks
--- Alex

-----Original Message-----

Dear WG,

Thanks,
Kent and Mahesh

 group.

Goals and Milestones:

h0UjBXeMK-

eMK-

K-

Fax:   +49 421 200 3103

Mahesh Jethanandani

Mahesh Jethanandani

Netconf mailing list

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Feb 2018 19:19:40 +0100

> "Define and maintain data models for subscriptions to information and protocol bindings to have relevant data pushed to clients in an expedient manner."

- information == data or not?

- implied parenthesis are not clear

NEW:

Define and maintain (i) data models for subscriptions to data and (ii)
protocol bindings to have relevant data pushed to clients in an
expedient manner.

Now remove stuff not needed and move to active phrasing:

NEWER:

Define and maintain (i) data models for subscriptions to data and (ii)
protocol bindings for pushing subscribed data to clients.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Feb 2018 19:20:26 +0100

OPTION-2 since it is bad style to start with a forward reference.

/js

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 14 Feb 2018 10:58:46 -0800

Works for me. Thanks. 

Mahesh Jethanandani 
[email-masked]

> On Feb 14, 2018, at 9:30 AM, Kent Watsen <[email-masked]> wrote:
> 
> Hi Mahesh,
>  
> On 2/13/18, 8:57 PM, "Mahesh Jethanandani" <[email-masked]> wrote:
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 14 Feb 2018 19:31:11 +0000

The words are good.  I do see one other consideration.  Beyond the subscription models, there is draft-ietf-netconf-notification-messages which explores a transport independent headers for YANG notifications.  How would that fit into the text?  Perhaps a tweak to:

“Define and maintain data models for subscriptions to information as well as the protocol bindings and notification messages necessary to have relevant data pushed to clients in an expedient manner.”

Eric

From: Mahesh Jethanandani, February 14, 2018 1:59 PM

Works for me. Thanks.

Mahesh Jethanandani

On Feb 14, 2018, at 9:30 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mahesh,

Kent

Kent

Looks goods to me.

And me  :)

K.

=om=

Works for me...
--- Alex

-----Original Message-----

/js

How about:

--- Alex

-----Original Message-----

/js

--- Alex

-----Original Message-----

/js

Hi,

Thanks
--- Alex

-----Original Message-----

Dear WG,

Thanks,
Kent and Mahesh

 group.

Goals and Milestones:

h0UjBXeMK-

eMK-

K-

Fax:   +49 421 200 3103

Mahesh Jethanandani

Mahesh Jethanandani

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 14 Feb 2018 19:40:12 +0000

And incorporating the phrasing from Juergen, the text might be:

Define and maintain (i) data models for subscriptions to data, (ii) protocol bindings and (iii) the notification messages for pushing subscribed data to clients.

Either way works for me.

Eric

From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, February 14, 2018 2:31 PM
To: Mahesh Jethanandani <[email-masked]>; Kent Watsen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] NETCONF Charter

Eric

Mahesh Jethanandani

Kent

Kent

Looks goods to me.

And me  :)

K.

=om=

Works for me...
--- Alex

-----Original Message-----

/js

How about:

--- Alex

-----Original Message-----

/js

--- Alex

-----Original Message-----

/js

Hi,

Thanks
--- Alex

-----Original Message-----

Dear WG,

Thanks,
Kent and Mahesh

 group.

Goals and Milestones:

h0UjBXeMK-

eMK-

K-

Fax:   +49 421 200 3103

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Feb 2018 19:50:20 +0000

Hi Eric,

I assumed that the notification-messages draft was covered already under the "protocol bindings" clause.

Kent

On 2/14/18, 2:40 PM, "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>> wrote:

Either way works for me.

Eric

Eric

Mahesh Jethanandani

Kent

Kent

Looks goods to me.

And me  :)

K.

=om=

Works for me...
--- Alex

-----Original Message-----

/js

How about:

--- Alex

-----Original Message-----

/js

--- Alex

-----Original Message-----

/js

Hi,

Thanks
--- Alex

-----Original Message-----

Dear WG,

Thanks,
Kent and Mahesh

 group.

Goals and Milestones:

h0UjBXeMK-

eMK-

K-

Fax:   +49 421 200 3103

Mahesh Jethanandani

Mahesh Jethanandani

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 14 Feb 2018 20:02:46 +0000

Hi Kent,

As draft-ietf-netconf-notification-messages is transport protocol agnostic, it wasn’t clear to me that protocol bindings covered it.  But if everyone thinks the wording is fine, I am good too.

Eric

From: Kent Watsen, February 14, 2018 2:50 PM

Hi Eric,

Kent

Either way works for me.

Eric

From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, February 14, 2018 2:31 PM
To: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>; Kent Watsen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] NETCONF Charter

Eric

Mahesh Jethanandani

Kent

Kent

Looks goods to me.

And me  :)

K.

=om=

Works for me...
--- Alex

-----Original Message-----

/js

How about:

--- Alex

-----Original Message-----

/js

--- Alex

-----Original Message-----

/js

Hi,

Thanks
--- Alex

-----Original Message-----

Dear WG,

Thanks,
Kent and Mahesh

 group.

Goals and Milestones:

h0UjBXeMK-

eMK-

K-

Fax:   +49 421 200 3103

Mahesh Jethanandani

Mahesh Jethanandani

---

From: "t.petch" <[email-masked]>
Date: Fri, 16 Feb 2018 09:10:17 -0000

--- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Wednesday, February 14, 2018 6:20 PM

> OPTION-2 since it is bad style to start with a forward reference.

I agree

Tom Petch

> > > Mahesh and I have put together a proposal for a new charter for
our
it.
> > > The Network Configuration (NETCONF) working group is responsible
for
> > > defining data models necessary to support the protocols.  The
NETCONF
6241).
8040).
> > >    The NETCONF working group consults with the NETMOD working
group to
the
> > >   This section is updated automatically via the Milestone tracker
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.or
g_wg_netconf_milestones_&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDT
XcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=mUkjYhuVX0FNcW1y
0H4sgc6DmI0TeFqPYJjvLNa08gU&s=uzrGB-U8Z4eReZah-v589Ggzlk3et2Dm2p6Fqeix9w
M&e=
> > >   And therefore the specific list of drafts is not included here.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
n_listinfo_netconf&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoC
I&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=mUkjYhuVX0FNcW1y0H4sgc
6DmI0TeFqPYJjvLNa08gU&s=3R26HtJRFTbBnbfvDtohYxejH6y9H09Epo3vN28uC8w&e=